14.2  迭代规划和发布规划的区别

发布计划是对整个产品发布过程的展望，通常是从新项目启动开始3～6个月的时间。与之相对，迭代计划只是对一次迭代的展望，通常是2～4周的时间。在迭代计划中，发布计划中的用户故事分解成了任务。对迭代计划中的用户故事进行估计时采用的是故事点或者理想日，而对迭代计划中的任务进行估计则是采用的理想小时。

为什么用小时来估计迭代计划中的任务，而对发布计划中的用户故事则是采用故事点或者理想日？主要是因为可以这样做了。在迭代中，离工作开始的时间不会超过几周，而且开发小组对这些工作应该已经具有相当深刻的认识，尤其是在经过了迭代规划会议的讨论之后。这使得他们可以相当可信地按照小时来估计迭代中的任务。而组成一次发布的用户故事，每个都代表了多项任务，它们更为模糊，开发小组对它们的了解也更少，所以必须采用更为抽象的单位，例如故事点或理想日来进行估计。

表14-2总结了发布计划和迭代计划之间的主要区别。

表14-2  发布计划和迭代计划之间的主要区别

迭代规划的主要目标是对在粒度较粗的发布规划中建立的假定进行细化。在发布计划中，通常都故意地模糊化了对用户故事的处理顺序。此外，在进行迭代规划的时候，开发小组对项目的了解也比最后一次更新发布计划的时候更多。在迭代开始的时候进行规划使得小组可以使用他们最近获得的知识。这样，敏捷规划成为了一个有两个阶段的过程。第一个阶段产生发布计划，边界粗糙并具有总体的不确定性。第二个阶段产生迭代计划。迭代计划仍然有一些粗糙的边界，也存在一些不确定性。但是，由于是在开始一次新的迭代的同时建立它的迭代计划，所以迭代计划会比发布计划详细得多。

建立迭代计划的过程会引导开发小组对产品设计和软件设计都展开讨论。例如，产品设计讨论的主题可能是关于诸如为了优化价值而对用户故事进行最佳的组合，对向客户展示可用软件后获得的反馈进行解释理解，或者是需要的功能应实现到何种程度(也就是说，是否20％的努力就可以交付80％的价值？)，等等。软件设计讨论则可能是关于采用适当的体系结构层来实现新的功能，应该采用哪种技术，是否可以重用已有的代码，等等。通过这些讨论，开发小组可以更好地理解应该和将要构建什么东西，他们还会建立为了达到此次迭代的目标所需完成任务的列表。