转载。
公司在CMMI上学。 虽然很多人认为那是形象工程。 公司同事说，骑CMMI可以惊动政府，但最可怕的是领导人真的把骑CMCMI当回事。 我在项目上试用了几个月，但是感觉不到大的颜色。 曾经有人说，中国不适合追求印度式的软件开发过程。 印度人死板，适合做没有创造力的工作。 虽然中国的国情不同，但中国的开发者们是非常有创造性的人。 他们的创造力曾经抹去了一些错误的开发方法。 曾经强烈推荐印度的软件开发流程，现在聪明的人醒了。 Thoughtwork中国公司一直采用敏捷开发就是一个很好的证明，采用敏捷开发方法可以有效地降低软件开发。 但国内许多软件公司缺乏创新，仍然墨守成规。
工作中要勇于尝试，看Scrum是否真的适合我们的项目，从实践中梳理
以下是我为团队定义的一些开发规范
团队中的一些基本原则：
开发、分享、坦诚、愉快的工作，团队所有成员都是一体的，任何问题都不应追究个人。
必须将其归类为团队集体责任，人人是平等地位和责任的集体所有制。
开发要求：
1、按照《项目开发规范》和CheckStyle的要求编写代码
2、实施TDD开发
TDD给设计带来了好处：
在编写代码之前，必须考虑更多对象之间的交互
我们被迫将对象的创建封装到更好的级别
编写更小更凝聚的方法，使得方法复用和纠错更加方便快捷。
3、执行模糊羽毛配新鸟原则
项目流程定义
项目流程说明：
重复时间为30天(sprint )
必须在一个打印周期内完成的模块(backlog ) )。
1、每天早上10-15分钟的会议(morning meet ) )。
报告的主题是，今天完成了什么？ 你遇到障碍了吗？ 你接下来要做什么？
2、每周二、四晚的代码检查(代码检查) ) )。
一个人写的代码至少要两个人检查测试，进行代码审核的人需要对程序提出意见和建议，并反馈给代码开发人员
3、每两周的项目审查(review meeting ) )。
开发团队的成员需要在会议上说明自己实现了什么功能，展示自己的工作成果。
寻找项目和团队中存在的问题，改进后续工作
4、月初项目规划会议(sprint planning meeting ) )。
通常一天(7小时)。 在这次会议中，产品的Owner (业务人员)和团队成员将自己的功能模块(backlog )分解成小的功能模块。
决定在即将进行的sprint中需要完成多少小功能模块，并决定这个Product Backlog的任务优先级。 此外，该会议还需要详细讨论如何根据需要
完成这些小功能模块。 创建的这些模块的工作量按时间计算。
5、每周五下午的技术会议(technologic session )。
可以分享和讨论项目中遇到的困难、挑战、陌生技术或最佳做法
在会议上，不管提出什么样的疑问，大家都可以讨论。 不同的思维可以帮助大家更深入地理解问题，讨论可以帮助我们解决一些疑难杂症。
六、合作、反馈(Feedback ) )。
BA每天早会后，向客户(客户代表)和PM汇总报告邮件，确保客户(客户代表)及时了解进展情况。
每周总结错误的详细内容并发送给团队所有人。
BA尽量保持每天与客户代表的沟通，讨论各项业务细节，确保各项业务细节的准确性。
Dev能否从开发者、以及整体系统架构设计师的角度考虑需求的可行性，用最简单的方法提供同样的功能。
一些聪明的做法
不做单纯反复的劳动，让机器代替这些工作。 (手动执行简单的任务只会让你更笨) ) )。
快捷方式的一般命令
根据需要进行配对编程
以下是诺基亚的Scrum标准。 请作为参考
迭代需要一定的时间(TimeBox )，且不能超过6周。
在每个迭代结束时，代码必须接受QA测试。
Scrum团队必须有产品负责人，团队必须知道这个人是谁。
产品负责人必须有产品的Backlog，其中团队对其进行报价。
球队必须有燃烧殆尽的照片，必须了解他们的工作效率。
在Sprint中，外人不能干涉团队的工作。
Backlog是Scrum的核心，基本上他是由需求、故事或特性组成的列表，按重要性排序。 必须是顾客想要的东西，用顾客的声音记述。 一个条目不是故事(Story )。 建议在每个故事中包含这些字段。
ID (统一标记) )
名称
Imp (重要性) )
初始估计)
演示的制作方法)。
r> Notes（其它）每一个故事有3+1个变量（范围、重要性、估算）+质量，无论如何不能在质量上让步。
质量分为内部质量和外部质量：
外部质量是用户可以感知的，如运行缓慢，让人迷糊的界面等。
内部质量一般指用户看不见的原素，它对系统的可维护性有深远的影响，如系统设计的一致性、测试覆盖率、代码可读性等。
记住，在松散的沙滩上永远不能建立起精美的楼阁，经验证明牺牲内部质量是一个糟糕透顶的想法，现在省下来的一点时间，接下来的日子，你就要一直为它付出代价。
在Scrum中一切事情都是有时间盒的，到时必须交货。
“这个Sprint让大家不太好过，但是我们应该看到它的正面影响，整个团队从中获益匪浅，下个迭代会议会更有效率。”
学会按照时间盒安排工作，学会制定各种合乎情理的时间盒，这对sprint会议的长度同样有效。
典型的Sprint时间表，每一个小时休息10分钟：
30分钟的总体介绍，概括产品的Backlog。
20分钟的时间估算。
1个小时的Story选择，计算生产率。
1个小时的站立会议安排和将故事拆分为任务。
比较理想的一个Sprint长度为3个星期，（目前公司每日的Build版本，发布到测试部进行测试，应该是一个自动化测试的过程，而人工测试的应该是每个月发布的正常版本）
半死不活的目标比什么都没有强。
在Sprint中包含多少个故事由团队决定，而不是产品的负责人或其它人，但是产品负责人要对sprint中放入哪些Story产生影响。
自动生成故事卡的脚本下载地址：
http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html
计划指派的点数：0、1/2、1、2、3、5、8、13、20、40、100、？、Coffee。