软件开发项目迭代管理与执行策略
在软件开发项目中，拥有可运行的代码是评估质量水平和验证早期设计假设的最安全、最有效的方法。可运行、经过测试和集成的代码是衡量项目成功的唯一明确标准。与 PowerPoint 状态报告不同，可运行的代码能让每个人保持诚实，呈现未经过滤的第一手真相，而且项目跟踪也会更简单，因为每日构建质量就能说明进展情况。
1. 项目的节奏：迭代开发
强调以小增量迭代的方式进行开发非常重要。新功能将逐步添加到项目交付成果中，每一步都包括设计、编码、单元测试以及功能验证测试。
在整个迭代过程中，任何代码更改都要持续集成。代码更改需要确保整个系统的稳定性，每次迭代都要达到一定的质量水平，作为后续迭代的基线。理想情况下，这个质量水平应能让客户立即安装并评估交付成果。
关于迭代的最佳持续时间，一直存在很多争论。通常来说，两周是一个比较常见的经验法则。显然，迭代持续时间应该较短，以避免在结束时形成一个带有重大里程碑的小型版本发布，所以六周的迭代时间太长，很容易演变成瀑布模型。如果在一次迭代中无法完成某项任务，那么下一次在迭代中完成并交付它的机会不应间隔太久。如果需要等待数周，就可能会急于匆忙完成测试，从而牺牲质量。
开发人员编写的代码越多，代码库中的更改就越多，对集成和稳定的需求也就越大。分配给集成和稳定的时间越多，迭代就应该越短，以避免被新代码的数量和复杂性压垮。
比每次迭代的实际持续时间更重要的是，迭代应该是有时间限制的。它们有固定的长度，所有团队的开始和结束日期都是同步的。迭代的时间是固定的，不会改变，但迭代内交付的内容量取决于实际的进展速度。也就是说，迭代的长度受时间限制，而交付的内容量受交付高质量代码的需求限制。 <
