转载。。。
公司在上CMMI ，虽然很多人都觉得那是那是形象工程。公司的同事说，上CMMI可以忽悠一下政府可以，最怕的就是领导把上CMCMI还真当回事了。在项目里面试用了几个月没感觉到很大起色,曾经有人说中国根本就不适合去追求印度式的那种软件开发过程，印度人太死板，适合做这些没有创造力的活儿。中国国情不同，中国的开发人员都是一群很有创造力的人，他们的创造力曾经给一些错误的开发方法磨灭了，曾经的一段时间，大家极力推崇印度的软件开发过程，现在聪明的人清醒过来了，通过采用敏捷开发方法能有效的降低软件开发成，Thoughtwork中国公司一直采用敏捷开发就是个很好的证明。可是国内很多软件公司缺乏创新，还是老一套。
工作中要勇于尝试，看看Scrum是否真的合适我们项目还要从实践中得出整理，
下面是我给团队定义的一些开发规范
团队中的一些基本原则：
开发、共享、坦诚、快乐的工作，团队所有成员是一个整体、不应为任何问题追究到个人，
而应把它归为团队集体责任，所有人都是平等的地位和责任集体所有制。
开发要求：
1、 遵循《项目开发规范》和CheckStyle的要求写代码
2、实行TDD开发
TDD能给设计带来好处：
迫使你在编写代码之前，考虑更多对象之间的交互
迫使你把对象的创建封装在一个更好的层次上
写出更加小而内聚的方法，从而使方法的重用及纠错变得更加方便、快速。
3、实行老鸟带新鸟的原则
项目过程定义
项目过程说明：
每一次迭代时间周期为30天（sprint）
一个sprint周期内需要完成的模块（backlog）
1、每天早上10-15分钟站立会议（morning meet）
报告的主题是：今天完成了什么？、是否遇到了障碍？、即将要做什么？
2、每周二、四晚上代码检查（code check）
一个人写的代码至少两个人检查测试，进行代码复查的人需要针对程序提出意见或建议，然后反馈给代码开发员
3、每2周项目回顾（review meeting）
开发团队中成员需要在会议上说明自己实现了哪些功能、并作展示自己的工作成果。
寻找项目和团队中存在的问题，并作后续的工作给予改进
4、每月初项目计划会议（ sprint planning meeting）
一般为一天时间（7小时）。该会议需要制定的任务是：产品Owner（业务人员）和团队成员将自己的功能模块（backlog）分解成小的功能模块,
决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需
求完成这些小功能模块。制定的这些模块的工作量以小时计算。
5、每周五下午技术会议（technologic session）
项目中遇到的一些困难、难题、陌生的技术或是你得最佳实践都可以拿出来共享与讨论
会议上，可以抛出任何疑问大家讨论，不同的思考会让大家对问题了解更加深刻，讨论也可以帮助我们解决一些疑难症状。
6、协作、反馈（Feedback）
BA在每天在晨会后总结一封报告邮件给客户（客户代表）和PM，让客户（客户代表）能及时了解进度情况。
每周一总结Bug明细并发给小组全体成员。
BA尽量保持每日与客户代表沟通、讨论各个业务细节，力保每个业务细节的正确性。
Dev可从开发者，以及整体系统架构设计者角度考虑一下需求的可行性，是否能以最简单的方式提供同样的功能。
一些聪明的做法
不做简单重复的劳动，让这些工作给机器代替。（手工执行简单的任务只会让你变得更傻）
快捷化常用命令
必要时候结对编程
下面一个是Nokia的Scrum标准：可以拿来做参考
迭代要有固定的时长（TimeBox），不能超过六个星期。
每一次迭代的结尾，代码必须经过QA的测试。
Scrum团队必须有产品负责人，而且团队都清楚这个人是谁。
产品负责人必须有产品的Backlog，其中包括团队对它进行的估算。
团队必须有一个燃尽图，而且要了解他们自己的生产效率。
在一个Sprint中，外人不能干涉团队的工作。
Backlog是Scrum的核心，从根本上说，他就是一个需求、或故事，或特性组成的列表，并且按照重要性进行了排序，一定是客户想要的东西，并且用客户的语音进行描述，没一个条目是一个故事（Story），建议每个故事包含这些字段：
ID（统一标示）
Name（名称）
Imp（重要程度）
Est（初始估算）
How to demo（如何做演示）
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。
