产品计划安排

产品所有者负责实现产品计划安排，这是一组高优先级的用户描述，需要在产品中加以实现。

您的团队可能已经具有一个需求或单项产品数据库。如果是这样的话，那么就具备了一个构建产品计划安排的良好起点。要改造现有的数据库，产品所有者应当仔细研究需求数据库并确定一些彼此相关的高级用户描述。

计划安排需要划分优先级，因为它允许产品所有者选择比较重要的需求部分加以实现。单个需求也许可以分解为十个用户描述，但是，如果开发团队完成了其中五个最关键的描述，那么也许就足以满足客户的需求了。

团队需要使用描述点（story points）对产品计划安排中的高级描述进行评估。在交付特性（开发、质量保证和文档化）过程中涉及到的所有各方都要参与到评估流程中。这些评估将为产品所有者描绘出每个特性的相对成本。

产品计划安排旨在实现动态性，可以添加、移除特性并重新划分优先级。同时，它需要具有可维护性。产品计划安排中出现的工作不应该超过 18 个月。超过这一阈值后，优先级较低的特性应当从列表中删除。

计划安排为何要保持较短的期限？这项建议来自于精简式原则（参见 敏捷软件开发简介）。在队列中放入大量的工作，以至于无法在合理的时间内实际完成，这样做没有任何价值。如果一个好的想法没有被纳入到计划安排中，那么如果它真的有价值的话，它最终会包含到计划安排中，并且您将能够接触到用户需求。因此，可以放心地精简特性列表。

发行版计划安排

在发行版的早期，产品所有者将查看产品计划安排并确定将被包含到下一个发行版的用户描述。这些内容随后被移动到发行版计划安排中。

通常，在这个时候会出现一些来自各方面的压力。开发团队必须与产品所有者紧密合作，确保已确定的内容适合发行版的大小和发行期限。在发行期间，跟踪团队的开发进度将能够使您更清晰地了解最终将要实现的工作量。

在创建发行版计划安排时，将任何高级用户描述分解为多个更小的用户描述。在执行这项任务时，考虑组建一个客户团队，成员包括产品经理、测试人员、实际用户和交互设计师。

客户团队将与产品所有者展开一致合作，对新的描述划分优先级并将它们添加到发行版计划安排中。开发团队随后对这些新的描述进行评估，并为它们指定描述点。这个阶段的目标是通过评估较小的描述，更好地理解发行版的需求。

在迭代开发期间，随着开发团队对用户描述不断进行研究，产品所有者和开发团队从中获得了许多知识。这些知识可能会生成新的用户描述，或者证实某些描述并不是特别重要。对于新的描述，产品所有者和开发团队需要再一次进行评估和优先级划分。对于不太重要的描述，产品所有者应当将它们从发行版计划安排中移除，或降低它们在计划安排中的优先级。团队还可以使用这些新知识对计划安排中的现有描述进行重新评估。

发行版计划安排具有动态特性，但是一旦开始了迭代开发后，产品所有者就不能再修改已经为迭代开发选定的工作了。在开始这些工作后，如果团队获取的知识表明某些内容并不适合发行版或迭代开发，那么这就另当别论了（在下一小节中讨论）。在迭代开发期间，开发团队必须能够关注他们的可交付任务。

迭代开发计划安排

在迭代开发的早期，产品所有者可以对发行版计划安排重新划分优先级，这样开发团队就能够知道接下来要开发的内容。产品所有者和开发团队应当在开始迭代开发的第一天中，使用半天的时间召开有关迭代开发规划的会议。在会议上，团队应当从发行版计划安排中选择它所能承受的尽可能多的高优先级内容项，并将这些内容添加到迭代开发计划安排中。

要将这个会议的时间限制为半天，关键是要准备好一个良好的发行版计划安排。如果团队针对每一次迭代开发创建用户描述（而不是尽早创建），那么会浪费宝贵的时间，并且将延长作出规划的时间。并且，您永远也不会真正了解需要为您的发行版安排多少工作。

在规划会议期间，对于迭代开发计划安排中的每一个用户描述，团队需要分解所有必需的任务，以便对描述进行详细周到的分析。与描述所涉及的每个人有关的任务（开发、质量保证和文档化）都需要被识别出来。团队需要花几个小时对每项任务进行评估，并将这些评估添加到规划中。

在这里，最大的问题是过度承诺。在初始的迭代开发中，查看评估得出的小时数，确保工作可以在为迭代开发分配的时间内完成。如果团队提前完成了工作，它始终可以重新返回发行版计划安排，并挑选额外一些可以在迭代开发内部完成的工作项。

另一个问题是不能确定完成某个用户描述所需的所有任务。不幸的是，将在初始迭代开发中出现这一问题。这些被遗忘的内容累积起来，致使您无法在迭代开发期间完善描述。下面展示了有关这一常见错误的两个例子：

• 有一个名为 “Testing” 的 bucket，其中没有包括用于编写测试用例的时间。
• 没有包括开发团队编写自动化单元测试的任务。

在团队返回到发行版计划安排之前，确保迭代开发中的描述已被实际实现（随后确保它们又被实现了两次！）。换句话说，是否所有任务都是完善的？如果某项测试对于一个用户描述十分重要，那么让开发人员帮助测试人员完成这项测试将非常有益。如果迭代开发中创建的用户描述仍有缺陷，那么在继续深入开发之前修复它们。构建良好的品质；它和迭代开发中要做的工作量无关，而是和已交付工作中的 bug 的多少有关。

您将需要为迭代开发确定退出条件。例如，要实现完善的描述，必须解决所有高优先级（最严重的前两个）缺陷。任何未解决的低优先级（严重性排在第三和第四位）缺陷必须在随后的迭代开发中解决，并被添加到迭代开发计划安排中的顶部。一定不要将缺陷保留过长的时间。这样，在发行版的善后工作中，您会更加轻松。

如果团队在迭代开发期间认识到某个用户描述要比最初设想的更加复杂，并且不能在迭代开发甚至在发行版中包含它，那么应当尽早提出这个问题。一定要确定您的选择。是否能够通过某种方法缩小用户描述，同时仍然能够在当前发行版中为用户交付一些价值？如果是的话，创建合适的用户描述并与产品所有者进行讨论。简化后的版本可能只是暂时性的举措：如果有充足的时间的话，您将怎么做？为这些内容确定用户描述并与产品所有者进行讨论。它们可能会包含到产品的后续发行版中。