项目经理制定迭代计划

迭代的时间长度通常为2～6周，越短越好，尤其是在项目的早期阶段。经常有人问及迭代的长度是否可以有所不同这个问题。根据我的经验，在整个项目中采用固定长度的迭代最好。我见到过这样的项目：项目经理以两个4周迭代作为开始，而后把节拍切换成2周。有许多很好的原因支持这种做法。其中一个原因是可以减少新敏捷团队2周一次迭代的压力。一旦团队对迭代-增量开发更为熟悉，那么缩短迭代的周期就会更为有益。但我们不推荐按照所计划的故事的密度来变更迭代长度（比如：2、3、4、2，然后5周），这样做也是没有必要的。有很多伟大的书可帮助你将需求（故事、用例和非功能性需求）指派成迭代，而不是相反而行。在索引卡片上记录成文档的故事对敏捷开发人员来说很常见，它们是制定迭代计划时所用的技巧。

如果敏捷项目使用用例而不是故事，迭代计划的制定过程还是相似的。用例表示一组从头到尾的业务场景。场景中有一些较为常见、较为典型，其他的场景可能是待选的或例外的案例，很少执行到。用例的挑战在于，有些用例又长又复杂，而另外一些则较为简单。另外，用例之间存在依赖关系。如果仔细研究用例，不难注意到它们通常由许多冗余的场景组成。所以，团队必须把焦点放在各个场景之上而不是直接解决整个用例。通过使用这种方法，即使是场景之间的依赖关系也可以得到解决。以这种格式来标识场景并编写这些场景的文档，自然就与业务分析师通常执行的工作一致。这是使用用例来编写需求文档的正面。

虽然大致轮廓和高优先级的需求是由顾客来定的，但项目经理要和团队其他成员一起推动迭代计划的制定。于是，按照顾客的愿望列表，需求之间的依赖关系就可以得到考虑，适合于即将到来的迭代的最好的可能计划就可以得到组装。