做了10年敏捷，有了非常多的团队实践，更有许多教训和经验，一直想写点东西。但过于忙碌，无暇分身。现争取一周写一点，逐步将自己的敏捷实践分享给朋友们。

       极限编程的团队中，会有许多游戏规则。

      游戏规则不同于公司的规章制度，在规章制度前，人们是被“迫”遵守的意味更强一点，随着规章制度执行周期长后，人们会麻木于遵守规章制度，甚至抑制创造力。

     敏捷实践的游戏规则、目的会更单纯一点，主要是稳定提高团队输出率、不断提升软件质量、培养团队快速反应能力等，没有强制性，更多的是强调参与度以及趣味性，在游戏规则得到较好推广的团队里，团队成员普遍具有成就感。假设拿法律条文来比较，法律条文可以看做比较精确但又机械的衡量方法；而敏捷实践游戏规则更象是一种团队向上的文化。

    在游戏规则中，许多量化的指标是可以根据团队处于不同阶段进行逐步调整的。我这里谈谈个人在实践中对敏捷的一些实践的游戏规则怎么推进？

需求管理

      在中小型企业中，一般最大问题还在于需求管理: 或是缺乏专门的需求管理人员，或是需求管理人员缺乏专业的手段，抑或是，需求管理人员无法有效和客户沟通，导致客户过度插手开发的细节；

      两年前在温州龙湾的一个项目中，我的一个团队就受制于“半专业”客户，导致项目团队疲于应付“赶工”需求，团队缺乏对项目的整体把握（类似于战场情报不清），长期加班极度疲累，“半专业”客户还经常推翻重做。团队的士气降落到极点。

     通常遇到这种情况，需要“节源开流”手段，一方面需求从固化流转到开发环节进行有效的控制，和客户约定游戏规则，另一方面，把团队的大面积功能赶工改回日常的任务派送，减小任务粒度，增加流转速度（任务小，开发速度快）。

     当然，这需要有效的需求管理能力和工具。我通常采用的手段很简单，如果客户要求“详细设计和概要设计”，泡制一份给他（千万别指望项目客户会按照详细设计和概要设计要求开发，那是不现实的，在没有见到软件之前或者原型之前，通常他提不出有效的建议）。

    在日常迭代滚进过程中，和客户约定按照事务表（敏捷中叫发布计划，里面是按照优先级排序过的故事列表）推进，同时会使用原型图搭建客户和开发人员之间的桥梁，最大程度消除沟通错误，更重要的是给开发人员一个相对稳定的需求环境，更具有信心一点的需求环境。 你的开发人员一定会喜欢原型图，那样理解需求更直观，技术上更加可评估，时间上更可评估。

     事务列表（故事列表）简单管理工具 下载  （mac下的压缩包，windows解压中文文件名可能会有问题，但应该不影响文件内容）

     以下是用Balsamiq Mockups 设计的原型图，由于取了很多现有的素材，设计这个原型图其实速度还是很快的。尤其是项目后面的功能，设计原型图速度是非常快的。

 对于已经成熟分工的团队，采用敏捷就更容易了，只是源、流需要掌握好节奏。内部的协作游戏规则制定起来更容易（尤其是自主开发产品的团队）

－－－－－－－－－－－－－－－－续昨日－－－－－－－－－－－－－－－

      前面谈过在中小型企业中，需求管理是问题的主要来源，其实归根结底是客户和研发团队之间缺乏有效的游戏规则。当大多数的概要设计和详细设计并不能反映项目现实，会导致客户方、开发方、质量保障方都存在疑虑。假设有“可快速维护和可快速传递设计思路的工具”（也即是上述的事务列表和原型图），作为两方甚至三方（需求、研发、质保）的一个游戏规则主要附着点，可以较快速度建立两者或三者合作的信心，本质是多方在玩一个简单可行的游戏规则。

    拥抱变化并非是一直在革命，而是让团队有能力应对在一定粒度内的变化，如果变化粒度过大，比如功能模块上的彻底变化，那已经属于企业商务谈判层次上的问题，不可将变化压力放到项目团队中。项目团队通常不具备企业商务谈判的能力， 现实中很多项目团队做了很多商务谈判的事情，我的建议书是量力而行。

    有人说纯粹的敏捷，应该是按照迭代滚进的方式来计费的（实际付出多少成本算多少），这个我同意，但是现实是：国内的项目大部分是固定金额的合同。