下载掌阅APP，畅读海量书库
立即打开
敏捷是许多适应型方法的总称。敏捷是一种思维方式，由价值观定义、由原则指导，并通过许多不同实践表现出来。与传统方法相比，敏捷中有更多的规划，但是不同的项目生命周期中，规划的分布是不同的。应该做一个负责任的前期规划。由于返工带来的疏忽和延误风险很高，因此，在前期规划很少的情况下应谨慎行事。如果前期做了太多规划，那么编制一个非常详细但不准确的进度计划的风险就会增加。最佳方法是仅做够用的前期规划，以最大限度地减少重复和返工的风险。
敏捷专注于缩短交付周期，以频繁和增量的方式获得可交付的成果。它侧重于实现中期利益，而不是活动的完成。敏捷方法的一个重要特点是多次迭代，而不是从一个阶段平滑地进入另一个阶段。
Scrum 和看板是经常交替使用的两个术语，但这两个敏捷框架之间存在显著差异。Scrum 使用广泛，用于将工作组织成小的、可管理的、以故事形式表示的部分。用户故事从最终用户的角度提供价值，并由跨职能团队在指定的时间段（称为Sprint或迭代）内完成。这些迭代通常为1～4周，由组织的项目管理方法或项目团队确定。项目团队在项目的整个生命周期内保持迭代持续时间，以建立项目节奏。
与Scrum一样，看板鼓励将工作分解为可管理的部分。Scrum限制交付周期（一个周期能完成的工作数量受限），看板限制任何一种情况下所允许的工作量（只有这么多的任务可以进行，只有这么多的任务可以在待办事项列表上）。Scrum和看板都允许将大型和复杂的需求分解为小的功能，以便高效地完成。
在图2-18中，迭代1和迭代2已完成，迭代3正在进行，迭代4待开始（未开始）。完成迭代所需的具有高优先级的任务项尚未添加到迭代中。在待办事项列表中的优先任务永远不会有工期估算。
图2-18 多个迭代或Sprints示例
项目团队根据优先级顺序，从产品待办事项列表中选择他们认为可以在迭代中完成的任务。作为迭代规划的一部分，项目团队根据这些功能和任务发布迭代待办事项列表。一旦团队承诺当前迭代将完成哪些用户故事，迭代工作就开始了。这些组件展示在图2-19中。在迭代过程中，团队每天以15分钟会议的形式相互检查，称为每日站会。在整个迭代周期中，团队以信息板的形式维护进度视图，该信息板可以直观地表示迭代目标的进度。在迭代结束时，项目团队向干系人展示他们已经完成的工作，并收集影响他们在未来迭代中工作的反馈。项目团队还要召开一次回顾会议，以确定未来迭代需要改进的内容。该过程如图2-19所示。
图2-19 典型的适应型项目生命周期
每次迭代的第一天都会召开一次会议。整个项目团队开会商定他们可以在迭代中完成的功能集，并商定与这些功能相关的任务。项目团队对这些估算进行再评估，以确认他们是否有足够的时间在一个迭代中完成所要求的所有功能。如果答案是肯定的，项目团队就开始聚焦于迭代的工作（见图2-20）。如果答案是否定的，项目团队则会将低优先级的功能放回产品待办事项列表中，直到整体工作负载小到一个迭代可以覆盖，项目团队才会承诺这个迭代的交付范围。一旦确认了迭代计划并且做出承诺，项目团队就开始使用可见的信息板跟踪整个迭代的进度。这些信息板包括燃尽图、燃起图和任务板。最常用的任务类别包括待办、进行中和完成。
图2-20 Sprint（迭代）规划会议的结果示例
虽然类似，但Scrum板和看板之间也有区别：
◆ 在Scrum板中，列标签反映了工作流中的时间段，从Sprint 待办事项列表开始，到满足团队对“完成”的定义为止。在每个迭代开始时添加到板中的所有故事都出现在该迭代结束时的最后一列中。迭代结束后，团队清空板上内容并为下一次迭代做准备。工作从左到右进行，直到Sprint中的所有工作都在“完成”列中，如图2-21所示。
图2-21 Scrum板
◆ 在看板中，列标签也显示工作流阶段，但与Scrum板有一个区别，即每列在任何时候允许的最大故事数是确定的。这将强制执行看板为每种情况规定的团队确定的限制。由于每列允许的故事数量有限，并且没有其他迭代的需要，因此无须随着工作的进展重置看板。只要项目继续进行，它将继续流动，根据需要增加新的故事，并在必要时重新评估已完成的故事，如图2-22所示。
图2-22 看板
依赖关系是敏捷方法中的另一个重要主题。敏捷试图避免需求之间的依赖关系，但这些依赖关系总是在实践中发生。需求之间存在依赖关系有几个原因，例如：
◆ 最终用户驱动的依赖关系（作为最终用户活动的结果，在业务领域中自然发生）。
◆ 需求分解依赖关系（当将大型需求分解为小型需求时，存在从原始大型需求到小型子需求之间的依赖关系）。
◆ 技术驱动的依赖关系（一些团队会依据特定的平台、子系统或架构层来确定需求）。
图2-23描述了一种简单的情况，其中一个敏捷项目组被分为五个小组（从A到E）。需求之间的箭头表示功能依赖关系。在本例中：
◆ A组的待办事项列表中的需求2依赖需求4。
◆ 需求4依赖B组的需求3，B组的需求3又依赖C组的需求5，C组的需求5依赖D组的需求2。
◆ D组的需求2依赖E组的需求2，E组的需求2又依赖D组的需求4，D组的需求4又依赖C组的需求7。
其他需求之间也可能存在依赖关系。
图2-23 需求之间依赖关系示例
可以使用一些策略来消除依赖关系，例如，重新确定一个或两个需求的优先级，使用一个模型来表示缺失的功能，直到它可用为止，或者重新定义需求。
燃尽图是团队使用的最常见的敏捷跟踪机制。燃尽图的应用和使用因敏捷项目而异，但关键点都是随着时间的推移跟踪剩余的工作。使用剩余工作量绘制燃尽图是使用燃尽图最有效的方法。第一步是创建WBS以编制待办事项列表，这是迭代规划的关键输入，通常在迭代规划会议期间完成。每个故事都应该有一个对应的度量单位，由项目团队在规划会议上决定。一旦工作分解到位，项目团队就可以绘制计划工作的燃尽图。假设所有任务都将在迭代中以统一的速率完成，由此可画出一条进度计划线。例如，如果迭代持续时间为2周，迭代的总工作量为420个故事点。在迭代第1天，一旦任务分解到位，计划的完成情况就可以绘制出来，如图2-24所示。
图2-24 典型的计划工作燃尽图
图2-24中的Y轴描绘了应在迭代结束时完成的总故事点数（420）。计划进度线已经绘制，它假设所有工作都将在迭代结束时完成。每个项目成员从工作分解中挑选要完成的工作。在一天结束时，项目团队用剩余的工作来更新工作分解。
随着迭代过程往前推进，图2-25显示了剩余工作的燃尽情况。
图2-25 剩余工作的燃尽图
在图2-25中，当剩余工作线在计划工作线上方时，这意味着项目团队的工作进度较慢，可能无法按时完成所有承诺。在项目或迭代刚开始时，剩余工作线预计会高于计划工作线，因为项目团队需要进行磨合，并学习与干系人交流。
图2-26显示了一个达成迭代承诺、迭代顺利推进的燃尽图。
图2-26 迭代顺利推进的燃尽图
图2-27表示迭代任务未能完成。在该迭代中，大约有100个故事点的工作没有完成。剩下的工作将成为产品待办事项列表的一部分，并转入后续迭代。
图2-27 未能达成目标的燃尽图
燃尽图的另一个例子如图2-28所示。在本例中，项目团队在迭代的前几天以缓慢的速度工作，但在迭代结束时加快推进，最终完成目标。
图2-28 剩余工作的燃尽图
在图2-29中，虽然最终达成了目标，但团队的绩效表现并不一致。这可能是通过在每周末强制加班完成每周工作来实现迭代目标的例子。
图2-29 目标达成的燃尽图
可以在迭代层面或发布层面绘制燃尽图。虽然通常使用剩余工作来跟踪迭代燃尽图，但使用故事点来跟踪发布燃尽图是一种常见的做法。故事点是实现故事所需工作的度量单位。
相同的数据可以用不同的图形表示，图2-30被称为燃起图。燃起图显示已完成的故事点，而不是燃尽图中显示的剩余工作。故事点仅在故事或功能完成时才被视为完成。一些项目团队试图在没有完成实际功能或故事的情况下测量故事点。当项目团队只测量故事点时，他们测量的是项目团队的最大工作量，而不是实际完成的工作量，这违反了敏捷原则，即“进度的主要衡量标准是可以工作的产品”。每个项目团队都有自己的最大工作量。当使用故事点时，请注意，一个项目团队在给定时间内完成的故事点和另一个项目团队是不同的。
图2-30 燃起图示例
迭代进度通过使用燃尽图、任务板和每日站会进行跟踪。这三个工具结合起来提供了一个清晰的画面，说明项目团队正在做什么，完成了什么，将要做什么，是否会及时完成，以及什么可能阻止项目团队实现其Sprint和/或发布目标。无论使用的是燃尽图还是燃起图，项目团队都可以在迭代过程中看到已完成的工作。在迭代结束时，项目团队能够根据此迭代中完成的内容来衡量下一个迭代周期的工作量（有多少个故事或故事点）。这使项目团队可以估计下一次迭代更有可能交付哪些功能。速度，是指项目团队在过去迭代中的工作量，即实际完成的功能的故事点大小之和，让项目团队能更准确地规划其下一个迭代的工作内容。
发布计划是一种由多次迭代组成的长期的计划方法。通常每3～6个月进行一次发布，结果不需要向客户发布，但可以进行内部发布，用来确认系统集成和进行验证。项目团队并不直接将待开发的功能分配出去，相反，项目团队先进行总体估算，以确定在哪些迭代中可以完成哪些功能，以及总体可以完成多少功能。发布计划可以是功能驱动的、时间驱动的或成本驱动的。图2-31显示了产品愿景、发布计划和迭代计划之间的关系。
图2-31 产品愿景、发布计划和迭代计划之间的关系
敏捷依赖燃尽图、燃起图、任务板、待办事项列表、迭代计划、发布计划、路线图和其他度量指标来正式传递关于项目进度、状态和预测的信息。所有其他形式的文档由项目团队自行决定。敏捷的经验法则是，如果文档增加了价值，并且客户愿意为此付费，那么就应该编制该文档。治理（审计、会计等）所需的相关文档可能仍然需要进行编制。