知识卡片
短迭代发布
内容
增量发布要求每次交付最小但可用的价值块，并用 1-4 周左右的短迭代维持专注。周期过长会让反馈变迟、目标变虚。发散：短迭代的真正压力，是迫使团队持续做取舍。
参考来源
- 位置：第4章《交付用户想要的软件》"17 使用短迭代，增量发布"（源文件：_epub-src/OEBPS/text00000.html）
- 结论依据：原文明确"给我一份详细的长期计划，我就会给你一个注定完蛋的项目"，用XML DTD到Schema的迭代改进为例说明提早发布获得经验，并给出具体节奏：每个增量开发使用1~4周迭代、每个迭代不超过两周，直接支持卡片结论。
- 原始内容："给我一份详细的长期计划，我就会给你一个注定完蛋的项目……根据项目的大小，理想的发布周期是几周到几个月。在每个增量开发周期里，应该使用短的迭代（不应该超过两周）。每个迭代都要有演示，选择可能提供反馈的用户，给他们每人一份最新的产品副本。……增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1～4周左右迭代周期。"