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等)都需要或者强烈建议采用时间箱迭代。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。
时间: 2024-09-05 05:11:51