3G Eden
RSS
对迭代开发作出安排
让我们首先以一个常见的问题开始：“您的迭代开发应当持续多长时间？”迭代开发的目标是允许团队及早并经常性地从相关人员（客户、产品所有者和其他人）处获得反馈。
常见的迭代开发的时间长度为两到四周（有时长达 6 周）。时间较短的迭代开发往往更容易进行规划，因为快速的修改意味着一定的紧急性。较长时间的迭代开发容易让人误认为有大量时间可供使用 — 这会导致严重错误。
迭代开发是团队工作的重中之重。您应当始终进行迭代开发，即使当前并没有开发发行版。这允许团队为下一个发行版安排早期的调研（也称为架构研究（architecture spikes））、原型化或用户描述创建。在实际进行发行版的 “正式” 迭代开发之前，执行上面这些工作可以帮助您及早发现风险并在需要时制定迁移计划。
在开发发行版期间，不要仅仅为了满足特定的发行日期而改变迭代开发的时间期限。在进行变更时，可能会遇到来自团队的阻力，并且，不断修改迭代开发期限并不能表明您的团队主管对新的流程抱有信心。同样，如果迭代开发期限经常变化，那么计算团队的开发进度就会更加困难（我们稍后将在 计算开发进度 中加以讨论），因为您并没有使用恒定的时间期限进行计算。
倾向于短期迭代开发的例外情况是最后一次迭代开发。如果在最后一次迭代开发中，主要包含的是全球化和 bug 修复之类的善后工作，那么团队可以在此时考虑使用较短的迭代开发期限。
除了为最后一次迭代开发安排较短的开发期限，另一种方法是为所有迭代开发安排较短的时间期限（比如两周）。通过使用这种方式，如果发行日期并没有安排在迭代开发的末期，那么您将能够提前一个星期完成发行版的开发。
在迭代开发的最后阶段，确定迭代开发的演示和复审时间，而且包括开发人员、管理团队和相关人员。特性演示可以帮助所有人了解团队开发的流程，并且提供了获得早期反馈的机会，从而促使在发行期间实现重要的调整。
 |
创建用户描述
用户描述 是陈述用户需求的一段简单内容。想象一下，您如何向客户解释您目前所做的工作。用户描述关注的是用户的需求；并没有涉及到实现细节。
产品所有者需要与客户沟通以理解他们的需求，然后创建一组初始的高级用户描述。要创建更加详细的用户描述，可能需要组建一个客户团队，成员包括产品经理、测试人员、实际用户和交互设计师。下面的模板可以帮助编写用户描述：
作为一名<角色>，我希望通过设立<目标> 实现<业务价值>。
用户描述也可以使用一个分层架构。综述 是在更高级别上描述特性或功能的用户描述。可以查看这些内容，分解它们，并生成新的用户描述和综述。图 1 演示了一个被分解为多个更小的用户描述的综述。
图 1. 一个被分解为多个用户描述的综述
用户描述描述了团队要实现产品需求而必须完成的工作。用户描述包含多少内容？对于综述，这个问题不太重要；因为可以分解为多个更小的部分。而对于团队将在迭代开发期间处理的用户描述，需要花费两到三天的时间完成此工作，并且应该在任何可能的情况下实现功能驱动。
您不应当针对迭代开发来调整用户描述的大小。例如，如果迭代开发期限为 4 周，那么您的用户描述可能非常庞大，无法包含在迭代开发中。在迭代开发的末期，您会发现团队无法承受它所承诺的工作。
在发行版的计划安排中，通常包含了大量的用户描述。可以查看这些描述作为参考。如果只有少数用户描述，但是需要花很多的时间实现，这表示您没有良好地描述所需完成的工作。
在构建用户描述时，您需要尝试采用构建块方法。您所能交付的最小的功能性行为是什么？从这一点入手，然后为下一个功能性行为集合创建另一个描述，继续执行这个过程，直到创建的描述涵盖了全部特性。
注意，描述可能涉及产品的不同组件。在这种情况下，团队只需要在迭代开发规划阶段为每个组件创建任务。
|
识别产品所有者
接下来需要识别产品的所有者。产品所有者指与用户建立联系并理解他们的需求的人。产品所有者将确定产品所需的特性，这些特性可以帮助产品在市场上取得成功并满足用户需求。
产品所有者和开发团队之间的关系非常类似于客户和提供商之间的关系。有关敏捷规划的关键点是，开发团队应当始终开发产品所有者认为重要的特性。这就是产品计划安排和发行版计划安排如此重要的原因。
即使产品所有者是最终决定特性优先级别的人，仍然需要在开发团队和产品所有者之间维护良好的关系。开发团队必须确保他们的需求（有关用于交付发行版计划安排的架构工作方面的需求）得到了理解并设置了合适的优先级别。
产品所有者的职责是确保产品计划安排和发行版计划安排设置了合适的优先级别，从而保证团队能够始终开发最重要的工作内容。
