本节书摘来自异步社区《敏捷迭代开发：管理者指南》一书中的第2章2.3节时间箱迭代开发，作者【美】Craig Larman，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.3 时间箱迭代开发
敏捷迭代开发：管理者指南
时间箱（timeboxing）迭代是将迭代的结束日期固定下来并不允许改变的实践（多站点时间箱迭代参见11.1.1节）。整个项目可能也需要确定的时间箱。如果几经努力还是出现某次迭代的需求（范围）在其迭代周期的时间箱内无法实现的局面，也不要推迟迭代的最终日期，而是要减小范围（将较低优先级的需求放回期望表中）（跨时间箱的重叠活动参见11.1.3节），如此便可以使部分的、增长的系统总是能够在最初计划的迭代结束日期内实现，依然得到稳定的、经过测试验证的版本，参见图2-3。
重点是：时间箱方法不是用来向开发人员施压，让他们加班加点，力争在即将来临的最后期限内完成任务的一种手段。如果正常的工作步调不足以完成任务，那么就缩小工作范围。
在绝大多数IID方法中，并不是所有的时间箱长度都是相等的（迭代长度参见11.1.19节）。例如，首次迭代可能是4周；第二次迭代可能是3周，等等（哪一天结束时间箱参见11.1.5节）。另外，Scrum方法推荐每个时间箱采用30个日历日。如上所述，绝大多数IID方法建议每个迭代时间箱周期控制在1～6周。
一个3个月或者6个月的时间箱迭代周期过于漫长，并且总是抓不住关键。研究表明较短的步骤能够降低复杂性和风险，获得更好的反馈，同时提高生产力和成功率。也就是说，对于拥有几百名开发人员的项目，才会因为开销，采用3个月的迭代周期。
所有现代的IID方法（包括Scrum、XP等）都需要或者强烈建议采用时间箱迭代。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
