• 每次迭代开发中的描述点的平均数量为 33。
• 团队当前的开发进度为 35 个描述点。
• 三个最慢的迭代开发的开发进度平均值为 30 个描述点。

因此，假设您的发行版还剩下 6 次迭代开发，您可以开始作出以下假设：

• 按照平均开发进度，团队将完成额外的 198 个描述点（6 x 33）。
• 按照当前的开发进度，团队将完成额外的 210 个描述点（6 x 35）。
• 按照最慢的开发进度，团队将完成额外的 180 个描述点（6 x 30）。

在图 4 中，可以看到发行版计划安排被划分为三个部分。中间的部分表示，按照前面作出的假设可以被包含在最后 6 次迭代开发中的工作。

图 4 同时也表明，开发团队无法在发行版计划安排中完成所有用户描述。然而，如果团队始终按照从上到下的顺序开发列表上的内容。那么团队将始终能够优先完成发行版中最重要的内容。

结束语

敏捷规划的首要目标是最大程度地明确 “已知” 工作并且完全公开它们。本文的重点是 “已知性”，因为当您了解了自己所做的工作时，可能需要将新的描述添加到计划安排中。这就允许产品所有者持续地对发行版计划安排划分优先级，并确保开发始终优先实现最重要的内容。

即使发行版中没有涵盖所有的描述，通常不会对产品所有者造成严重的影响。但是，如果团队将大量时间浪费在不重要的内容上，那么产品所有者就会陷入麻烦之中，并且无法在发行版中纳入所有重要的描述，因为他们的时间已经所剩无几。因此，要以对待用户的态度对待产品所有者，并不断满足他们提出的优先需求。（责任编辑：A6）