您是否希望实现敏捷规划？您是否正在进行迭代开发并且仍然身陷困境？在本文中，作者将利用他的经验帮助并指导
IBM 产品团队获得能够回答上述问题的路线图：“如何利用敏捷规划开始开发发布版软件”？他介绍了敏捷规划的基本知识，并分享了他的一些观点，指出了哪些方法是有效的以及哪些方法是无效的。
“我们正在进行敏捷开发，因为我们在开发中利用了迭代”。宣称已经实现了敏捷开发的团队经常这样说。然而，真正意义上的敏捷开发，不仅仅是在开发中实现迭代开发那么简单。
过去，开发团队提供了具体的发行版，包含预先确定的内容和预先确定的日期。在每个发行版之初，管理团队要和开发团队进行会谈，讨论发行日期和内容实现方面的压力。
在这种情况下，遇到的挑战就是管理层试图指定发行日期和内容，而开发团队的观点是他们只能实现其中之一。在实际中，发行版的内容可能要比开发团队的最初设想更加灵活。不幸的是，开发团队并不能总是意识到这一点，而人们已经开始忙碌地工作。
本文将为您提供一个路线图，帮助克服这些困难并使团队从简单的迭代开发过渡到敏捷开发。路线图包括：
- 帮助团队转移到使用敏捷规划的建议。
- 有关迭代开发的指导。迭代开发应当持续多长时间？在给定的发行版期间，团队是否只能从事迭代开发？团队在各个发行版之间应该执行哪些工作？
- 有关创建用户描述（user story）以及理解产品所有者角色的建议。用户描述是什么？应该由谁编写？综述（Epics）和用户描述之间有什么区别？描述中包含的工作应该持续多长时间？产品所有者是谁？产品所有者在这个过程中的作用是什么？
- 有关在产品、发行和重复阶段计划和管理计划安排（backlog）的建议。每个规划阶段都有自己的计划安排。这些不同的计划安排应当包含哪些内容？对于每个规划阶段，需要进行何种程度的评估？
- 评测和解释团队进度的技巧。可以从团队进度中推断出哪些信息。
在开始实现过渡之前，需要考虑下面这些事项：
- 理解您希望在过渡过程中实现哪些目标。对于某些人来说，他们很难接受变化，并且您需要理解，要获得所需的结果，您希望在早期流程的哪些位置作出妥协。一旦证实了您获得了所需的结果，那么就可以始终推动更多内容；要表示您需要添加哪些内容，这将是过程演变中的下一个步骤。
- 不要草率地开始过渡流程。如果过渡流程对于团队来说是必然之举，而团队并没有进行适当的培训，那么这将产生严重的受挫情绪，并且影响到团队成员对新流程的信心。
- 要清楚培训的必要性。了解需要学习哪些内容，然后掌握这些知识。尝试首先对一些小型项目使用敏捷方法，从中获得一些思路。学习了所需的知识后，对团队的其余成员进行培训。确保在开始之前，所有团队成员使用相同的词汇表并对流程有相同的认识。培训过程将帮助您找到自己的知识体系中的缺口。
- 坚持完成流程。一旦开始流程后，就不要走回头路。您只能选择做与不做，而没有别的选择。如果发现有出错的苗头，那么对新流程作出调整，而不是继续沿用旧方法。
您需要团队做出一定的成功承诺。要获得他们的承诺，首先您自己要对流程充满信心。如果您坚信自己可以顺利完成的话，那么敏捷规划就可以为您的团队工作。
让我们首先以一个常见的问题开始：“您的迭代开发应当持续多长时间？”迭代开发的目标是允许团队及早并经常性地从相关人员（客户、产品所有者和其他人）处获得反馈。
常见的迭代开发的时间长度为两到四周（有时长达 6 周）。时间较短的迭代开发往往更容易进行规划，因为快速的修改意味着一定的紧急性。较长时间的迭代开发容易让人误认为有大量时间可供使用
— 这会导致严重错误。
迭代开发是团队工作的重中之重。您应当始终进行迭代开发，即使当前并没有开发发行版。这允许团队为下一个发行版安排早期的调研（也称为架构研究（architecture
spikes））、原型化或用户描述创建。在实际进行发行版的 “正式” 迭代开发之前，执行上面这些工作可以帮助您及早发现风险并在需要时制定迁移计划。
在开发发行版期间，不要仅仅为了满足特定的发行日期而改变迭代开发的时间期限。在进行变更时，可能会遇到来自团队的阻力，并且，不断修改迭代开发期限并不能表明您的团队主管对新的流程抱有信心。同样，如果迭代开发期限经常变化，那么计算团队的开发进度就会更加困难（我们稍后将在
计算开发进度 中加以讨论），因为您并没有使用恒定的时间期限进行计算。
倾向于短期迭代开发的例外情况是最后一次迭代开发。如果在最后一次迭代开发中，主要包含的是全球化和 bug
修复之类的善后工作，那么团队可以在此时考虑使用较短的迭代开发期限。
除了为最后一次迭代开发安排较短的开发期限，另一种方法是为所有迭代开发安排较短的时间期限（比如两周）。通过使用这种方式，如果发行日期并没有安排在迭代开发的末期，那么您将能够提前一个星期完成发行版的开发。
在迭代开发的最后阶段，确定迭代开发的演示和复审时间，而且包括开发人员、管理团队和相关人员。特性演示可以帮助所有人了解团队开发的流程，并且提供了获得早期反馈的机会，从而促使在发行期间实现重要的调整。
用户描述 是陈述用户需求的一段简单内容。想象一下，您如何向客户解释您目前所做的工作。用户描述关注的是用户的需求；并没有涉及到实现细节。
产品所有者需要与客户沟通以理解他们的需求，然后创建一组初始的高级用户描述。要创建更加详细的用户描述，可能需要组建一个客户团队，成员包括产品经理、测试人员、实际用户和交互设计师。下面的模板可以帮助编写用户描述：
作为一名<角色>，我希望通过设立<目标> 实现<业务价值>。
用户描述也可以使用一个分层架构。综述 是在更高级别上描述特性或功能的用户描述。可以查看这些内容，分解它们，并生成新的用户描述和综述。图
1 演示了一个被分解为多个更小的用户描述的综述。
图 1. 一个被分解为多个用户描述的综述
用户描述描述了团队要实现产品需求而必须完成的工作。用户描述包含多少内容？对于综述，这个问题不太重要；因为可以分解为多个更小的部分。而对于团队将在迭代开发期间处理的用户描述，需要花费两到三天的时间完成此工作，并且应该在任何可能的情况下实现功能驱动。
您不应当针对迭代开发来调整用户描述的大小。例如，如果迭代开发期限为 4 周，那么您的用户描述可能非常庞大，无法包含在迭代开发中。在迭代开发的末期，您会发现团队无法承受它所承诺的工作。
在发行版的计划安排中，通常包含了大量的用户描述。可以查看这些描述作为参考。如果只有少数用户描述，但是需要花很多的时间实现，这表示您没有良好地描述所需完成的工作。
在构建用户描述时，您需要尝试采用构建块方法。您所能交付的最小的功能性行为是什么？从这一点入手，然后为下一个功能性行为集合创建另一个描述，继续执行这个过程，直到创建的描述涵盖了全部特性。
注意，描述可能涉及产品的不同组件。在这种情况下，团队只需要在迭代开发规划阶段为每个组件创建任务。
接下来需要识别产品的所有者。产品所有者指与用户建立联系并理解他们的需求的人。产品所有者将确定产品所需的特性，这些特性可以帮助产品在市场上取得成功并满足用户需求。
产品所有者和开发团队之间的关系非常类似于客户和提供商之间的关系。有关敏捷规划的关键点是，开发团队应当始终开发产品所有者认为重要的特性。这就是产品计划安排和发行版计划安排如此重要的原因。
即使产品所有者是最终决定特性优先级别的人，仍然需要在开发团队和产品所有者之间维护良好的关系。开发团队必须确保他们的需求（有关用于交付发行版计划安排的架构工作方面的需求）得到了理解并设置了合适的优先级别。
产品所有者的职责是确保产品计划安排和发行版计划安排设置了合适的优先级别，从而保证团队能够始终开发最重要的工作内容。
产品计划安排
产品所有者负责实现产品计划安排，这是一组高优先级的用户描述，需要在产品中加以实现。
您的团队可能已经具有一个需求或单项产品数据库。如果是这样的话，那么就具备了一个构建产品计划安排的良好起点。要改造现有的数据库，产品所有者应当仔细研究需求数据库并确定一些彼此相关的高级用户描述。
计划安排需要划分优先级，因为它允许产品所有者选择比较重要的需求部分加以实现。单个需求也许可以分解为十个用户描述，但是，如果开发团队完成了其中五个最关键的描述，那么也许就足以满足客户的需求了。
图 2. 产品计划安排如何满足所有其他需求
团队需要使用描述点（story points）对产品计划安排中的高级描述进行评估。在交付特性（开发、质量保证和文档化）过程中涉及到的所有各方都要参与到评估流程中。这些评估将为产品所有者描绘出每个特性的相对成本。
产品计划安排旨在实现动态性，可以添加、移除特性并重新划分优先级。同时，它需要具有可维护性。产品计划安排中出现的工作不应该超过
18 个月。超过这一阈值后，优先级较低的特性应当从列表中删除。
计划安排为何要保持较短的期限？这项建议来自于精简式原则（参见
敏捷软件开发简介）。在队列中放入大量的工作，以至于无法在合理的时间内实际完成，这样做没有任何价值。如果一个好的想法没有被纳入到计划安排中，那么如果它真的有价值的话，它最终会包含到计划安排中，并且您将能够接触到用户需求。因此，可以放心地精简特性列表。
发行版计划安排
在发行版的早期，产品所有者将查看产品计划安排并确定将被包含到下一个发行版的用户描述。这些内容随后被移动到发行版计划安排中。
通常，在这个时候会出现一些来自各方面的压力。开发团队必须与产品所有者紧密合作，确保已确定的内容适合发行版的大小和发行期限。在发行期间，跟踪团队的开发进度将能够使您更清晰地了解最终将要实现的工作量。
在创建发行版计划安排时，将任何高级用户描述分解为多个更小的用户描述。在执行这项任务时，考虑组建一个客户团队，成员包括产品经理、测试人员、实际用户和交互设计师。
客户团队将与产品所有者展开一致合作，对新的描述划分优先级并将它们添加到发行版计划安排中。开发团队随后对这些新的描述进行评估，并为它们指定描述点。这个阶段的目标是通过评估较小的描述，更好地理解发行版的需求。
在迭代开发期间，随着开发团队对用户描述不断进行研究，产品所有者和开发团队从中获得了许多知识。这些知识可能会生成新的用户描述，或者证实某些描述并不是特别重要。对于新的描述，产品所有者和开发团队需要再一次进行评估和优先级划分。对于不太重要的描述，产品所有者应当将它们从发行版计划安排中移除，或降低它们在计划安排中的优先级。团队还可以使用这些新知识对计划安排中的现有描述进行重新评估。
发行版计划安排具有动态特性，但是一旦开始了迭代开发后，产品所有者就不能再修改已经为迭代开发选定的工作了。在开始这些工作后，如果团队获取的知识表明某些内容并不适合发行版或迭代开发，那么这就另当别论了（在下一小节中讨论）。在迭代开发期间，开发团队必须能够关注他们的可交付任务。
迭代开发计划安排
在迭代开发的早期，产品所有者可以对发行版计划安排重新划分优先级，这样开发团队就能够知道接下来要开发的内容。产品所有者和开发团队应当在开始迭代开发的第一天中，使用半天的时间召开有关迭代开发规划的会议。在会议上，团队应当从发行版计划安排中选择它所能承受的尽可能多的高优先级内容项，并将这些内容添加到迭代开发计划安排中。
要将这个会议的时间限制为半天，关键是要准备好一个良好的发行版计划安排。如果团队针对每一次迭代开发创建用户描述（而不是尽早创建），那么会浪费宝贵的时间，并且将延长作出规划的时间。并且，您永远也不会真正了解需要为您的发行版安排多少工作。
在规划会议期间，对于迭代开发计划安排中的每一个用户描述，团队需要分解所有必需的任务，以便对描述进行详细周到的分析。与描述所涉及的每个人有关的任务（开发、质量保证和文档化）都需要被识别出来。团队需要花几个小时对每项任务进行评估，并将这些评估添加到规划中。
在这里，最大的问题是过度承诺。在初始的迭代开发中，查看评估得出的小时数，确保工作可以在为迭代开发分配的时间内完成。如果团队提前完成了工作，它始终可以重新返回发行版计划安排，并挑选额外一些可以在迭代开发内部完成的工作项。
另一个问题是不能确定完成某个用户描述所需的所有任务。不幸的是，将在初始迭代开发中出现这一问题。这些被遗忘的内容累积起来，致使您无法在迭代开发期间完善描述。下面展示了有关这一常见错误的两个例子：
- 有一个名为 “Testing” 的 bucket，其中没有包括用于编写测试用例的时间。
- 没有包括开发团队编写自动化单元测试的任务。
在团队返回到发行版计划安排之前，确保迭代开发中的描述已被实际实现（随后确保它们又被实现了两次！）。换句话说，是否所有任务都是完善的？如果某项测试对于一个用户描述十分重要，那么让开发人员帮助测试人员完成这项测试将非常有益。如果迭代开发中创建的用户描述仍有缺陷，那么在继续深入开发之前修复它们。构建良好的品质；它和迭代开发中要做的工作量无关，而是和已交付工作中的
bug 的多少有关。
您将需要为迭代开发确定退出条件。例如，要实现完善的描述，必须解决所有高优先级（最严重的前两个）缺陷。任何未解决的低优先级（严重性排在第三和第四位）缺陷必须在随后的迭代开发中解决，并被添加到迭代开发计划安排中的顶部。一定不要将缺陷保留过长的时间。这样，在发行版的善后工作中，您会更加轻松。
如果团队在迭代开发期间认识到某个用户描述要比最初设想的更加复杂，并且不能在迭代开发甚至在发行版中包含它，那么应当尽早提出这个问题。一定要确定您的选择。是否能够通过某种方法缩小用户描述，同时仍然能够在当前发行版中为用户交付一些价值？如果是的话，创建合适的用户描述并与产品所有者进行讨论。简化后的版本可能只是暂时性的举措：如果有充足的时间的话，您将怎么做？为这些内容确定用户描述并与产品所有者进行讨论。它们可能会包含到产品的后续发行版中。
团队可以在迭代开发计划中添加任何类型的工作。如果某个特性需要进行架构研究，那么将它的用户描述添加到计划安排中并具备
“设计”、“构建原型” 或 “调研” 等任务。向发行版计划安排中为架构研究添加用户描述的优点是允许产品所有者对用户描述指定优先级。如果产品所有者认为这种研究的成本太高，那么应当将架构研究描述放到列表中优先级较低的位置，否则该特性将从发行版中移除。
在产品计划安排和发行版计划安排中，开发团队将评估每个用户描述并为其分配描述点。为什么要使用描述点，而不是小时之类的时间单位？主要原因是在开发的早期阶段，您并不了解您需要为某个描述完成的实际工作量。并且，如果您提前完成了所有分析和设计工作，那么您的设计可能不会随着您对该特性的进一步了解而发生改变。
使用描述点而不是时间单位的另一个原因是，对于不同的人来说，所需的时间是不同的。如果进行评估和实际实施是由不同的人完成的，那么所作的评估可能就是错误的。
使用描述点的最后一个原因是理想时间评估最初可能会被错误地解释为过期时间评估。过期时间
指在考虑到员工在日常工作中所遇到的所有中断后完成任务所需的实际时间。因此，比如，估计可在 5 天内完成的任务，如果考虑到日常会议、电子邮件、电话呼叫和复查后，实际上需要
8 到 9 天的时间才能完成。
在使用描述点时，您实际所做的工作就是比较每个特性的相对复杂性。如果某个描述包含一个描述点，并且将它与拥有
5 个描述点的描述比较，那么实际上得出的比较结果就是第二个描述所含的工作量是第一个描述的 5 倍。注意，这并不一定表示完成第二个描述所需的时间是第一个描述的
5 倍。
由于存在太多未知的因素，团队可能无法对某些用户描述作出评估。在这种情况下，团队可以在计划安排中新增一个用户描述，进行额外的研究。完成研究后，团队可以重新审视描述来指定描述点。
在最开始的阶段，评估描述点可能比较困难，因为团队无法获得任何参考。在完成了大量评估后，评估将变得越来越准确。要执行描述点评估，可以使用
Planning Poker 技巧。
Planning Poker 是一种基于共识的评估方法，可以评估软件开发中完成某些任务所需的工作或任务的相对大小。这种方法将试图最小化锚定操作（anchoring）（团队成员在早期注释中表示为
“锚定” 任务时间）。所有团队成员将玩一套评估纸牌（评估纸牌的牌面包括 0、0.5、1、2、3、5、8、13、20、40、100，但是没有计量单位；单位由仲裁者决定），其他玩牌者不能看到纸牌的内容。当所有玩牌者出完牌之后，所有纸牌的牌面都将公布出来。
开发进度 指长期跟踪团队在每次迭代开发中已经完成的工作量。它使用与发行版计划安排相同的衡量单位，即描述点。
团队首先为发行版计划安排中的每个用户描述分配描述点。在每次迭代开发的早期，团队将选择一些将在迭代开发过程中使用的描述。要获得为描述分配的描述点，团队必须完成该描述在迭代开发中的所有任务。
如果团队没有完成某个用户描述的一个或多个任务，那么对于该描述，在当前迭代开发结束时团队只能获得 0
个描述点，而该描述将被延期到下一次迭代开发中。如果团队在迭代开发中完成了该描述余下的任务，那么团队将获得此描述的描述点。
团队完成迭代开发后，将计算描述点，并查看此前的迭代开发的数据，将呈现一幅如图 3 所示的图片。注意，团队在每次迭代开发中为何没有获得相同数量的描述点。
图 3. 多次迭代开发的开发进度
开发进度的一个优点就是在完成一些迭代开发后，可以开始使用跟踪图表中的数字来推算您有能力完成的发行版计划安排中剩余内容项的数量。
表 1. 每次迭代开发中的描述点
| 迭代开发 |
描述点 |
| 1 |
28 |
| 2 |
32 |
| 3 |
36 |
| 4 |
34 |
| 5 |
33 |
| 6 |
37 |
| 7 |
31 |
| 8 |
35 |
表 1 展示了每次迭代开发中的描述点。使用表 1 中的数据，您可以推算出以下这些信息：
- 每次迭代开发中的描述点的平均数量为 33。
- 团队当前的开发进度为 35 个描述点。
- 三个最慢的迭代开发的开发进度平均值为 30 个描述点。
因此，假设您的发行版还剩下 6 次迭代开发，您可以开始作出以下假设：
- 按照平均开发进度，团队将完成额外的 198 个描述点（6 x 33）。
- 按照当前的开发进度，团队将完成额外的 210 个描述点（6 x 35）。
- 按照最慢的开发进度，团队将完成额外的 180 个描述点（6 x 30）。
在图 4 中，可以看到发行版计划安排被划分为三个部分。中间的部分表示，按照前面作出的假设可以被包含在最后
6 次迭代开发中的工作。
图 4. 推断工作的结束位置
图 4 同时也表明，开发团队无法在发行版计划安排中完成所有用户描述。然而，如果团队始终按照从上到下的顺序开发列表上的内容。那么团队将始终能够优先完成发行版中最重要的内容。
敏捷规划的首要目标是最大程度地明确 “已知” 工作并且完全公开它们。本文的重点是 “已知性”，因为当您了解了自己所做的工作时，可能需要将新的描述添加到计划安排中。这就允许产品所有者持续地对发行版计划安排划分优先级，并确保开发始终优先实现最重要的内容。
即使发行版中没有涵盖所有的描述，通常不会对产品所有者造成严重的影响。但是，如果团队将大量时间浪费在不重要的内容上，那么产品所有者就会陷入麻烦之中，并且无法在发行版中纳入所有重要的描述，因为他们的时间已经所剩无几。因此，要以对待用户的态度对待产品所有者，并不断满足他们提出的优先需求。
本文中的所有观点均属于作者本人的观点，与 IBM 无关。
学习
获得产品和技术
- 使用可直接从 developerWorks 下载的
IBM 试用软件 构建您的下一个 Linux 开发项目。
| 
