Lessons Learned 2（敏捷项目中的变更处理）

问题/现象：

通过近一年的开发，系统已经成形，目前主要是1个模块在推广，2个模块在试用，1个模块在开发。推广和试用中，不断有用户反馈，产生新增或修改的需求。这些变更，有的是在迭代前纳入了待办列表，有的则是在迭代中期强势插入的。对于中期插入的这些变更，PO是直接通知原故事的开发人员和测试。

同时，项目组内部也会对已完成的系统进行优化或重构，产生一些设计或实现上的变更。这些变更，多数都是由提出人自己就直接修改，然后通知AA审核，最后通知测试。

虽然通过Lessons Learned1中的经验对变更影响范围和评估进行了控制，没有出现过因变更导致的生产问题，但项目组还是感觉，迭代的节奏没有以前那么井然有序、张弛有度，团队容易产生疲劳感，经常出现故事的积压。

原因：

1、变更信息没有在团队内部充分的流通，变更范围多是通过事后沟通确定。

2、评估时，还停留在原有的瀑布思维，主要关注开发完成，而没有将测试完成视为变更处理完成的标志。

预防措施：

所有变更，在实施前需回答3个问题：

1、需不需要变？

2、影响点有哪些？

3、实施变更和测试完成，需要投入多少资源？

对于措施，可根据不同的变更类型来执行。比如需求变更，PO需先通知团队所有成员，明确变更的具体内容：谁，干什么，为什么；然后再与相关人员讨论确定以上三个问题；最后确定是否纳入本次迭代进行处理。对于内生的变更，提出人先提出理由和方案，告知团队所有成员，评估和确认以上三个问题后，确定是否在本迭代处理。

经验：

敏捷看起来不像瀑布那样在项目前期花大量的时间做计划，但实际上，它是将计划时间进行了分割，投入到了每个迭代中，所以，敏捷中的计划时间占比，不见得比瀑布少，而且更应该超过瀑布——因为迭代要保持均衡的节奏，就必须要有缜密的计划和安排。

当项目进行到一定程度时，变更会逐渐成为主要的工作对象。所以，对于变更，一定要做到先评估再实施，谋定而后动，减小对迭代节奏的冲击。