敏捷中的特性变化应对zz

采用敏捷开发过程（敏捷开发基本都是迭代开发），当前版本计划确定之后，除了团队内部自我调节，或者征得团队的同意，任何外部力量都不能变更原定的计划，例如需求变更或者增加任务。这是保证团队对本次迭代如期完成的承诺负责的基本前提。老板们必须遵守这个准则，否则就别玩迭代了，一定是个死。

有关你的问题建议如下：

1）怎么做计划？
有关如何较为准确的预估整个项目的工期，人力资源，成本是一个很大的话题，暂不叙述。这里假定此项工作已经完成，小组成员都已经配齐，准备开始开发。制定迭代计划步骤如下：
1.1）要选择迭代的频率，SCRUM是每月迭代，基本比较适合。太短，太长都不好。不过如果团队成员的技术水平和软件工程水平不高的情况下，建议2个月一次迭代（个人经验，呵呵。否则BUG都改不完）。
1.2）在整个项目的功能点清单中选择本次迭代的内容，由主需求人员和主设计人员共同选择（一个客户代表，一个实现代表），选择出客户最关心的和技术风险最高的功能点，然后评估是否能够完成。
1.3）两位核心觉得有谱了，就可以把团队成员召集在一起，将需求和系统概要设计讲解清楚，然后由开发、测试认领工作任务，下去看文档，不懂问。半天之后开计划会，团队共同制定计划，本次会议结束后产出如下文档：项目计划，问题风险以及应对策略表。
1.4）这是可以进入本次迭代了。


2）有没有碰到原定的Scope需要被拿掉的情况？
这是经常发生的事情。团队内部在无法完成任务的时候团队是可以砍掉特性并放到下一个版本。这同时带来了一个问题，如何保证下次迭代不会延期，最终整个项目无法延期呢？在迭代的初始版本阶段，往往会发生这样的事情，正常。需要的是在本次迭代结束的时候，团队必须开自我检查会议，对每项任务的预估时间和实际时间的偏差分析、对需求变更次数、BUG进行分析，找出延期的原因：是因为对任务的估计不足？是需求写的不够仔细？是开发的质量不高？等等。最后团队确定改善措施，避免下个版本不会犯同样的错误。这样在几次迭代之后，对迭代计划的制定就比较准确了。每次迭代之后要花3-4个小时的时间做上述的团队自我检查工作，非常重要。

这里只是说了敏捷开发计划制定的概念。建议看看SCRUM，XP的书。计划只是第一步，保证计划的顺利执行才是最难的。敏捷开发的一个基本原则是团队拥有话语权，每个人员对自己的工作拥有话语权。这听起来很激动人心，也确实正确。但是如果团队成员（至少核心人员）不是受过敏捷开发训练的合格的软件工程师，这将会是一场灾难。