真北敏捷 | Scrum是关于有效管理目标、行动与异常

管理中的信息流与物流

物流是工件的流动。信息流是工件如何流动。管理就是把信息流拎清楚。信息流的重要要素是目标、行动和异常。

以下首先是把Scrum大卸八块，寻踪上述要点。然后给出在不具备实施Scrum的环境中，如何落实这些要点。

Scrum的前提

Scrum的基础是全功能的小团队：

Scrum 的精髓在于小团队。个体团队具有高度灵活性与适应性。

Scrum 团队是跨职 能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的 人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum 团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。

开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的 产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能 创建增量。 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应 能最大化开发团队的整体效率和效用。 开发团队具有下列特点：

 • 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品 待办列表变成潜在可发布的功能增量；

 • 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；

 • Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人 员）。 

• Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架 构、运维或业务分析；同时， 

• 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工 作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。 过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可 发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。

Scrum中的目标、行动和异常

目标

在Scrum中，团队清晰理解目标，至关重要。

计划会的第一部分是关于目标：

Sprint 计划会议回答以下问题：

 • 接下来的 Sprint 交付的增量中要包含什么内容？

 • 要如何完成交付增量所需的工作？

目标是产品负责人与团队互动共创的：

开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该 目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。 Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的 预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发 团队可以评估接下来的 Sprint 可以完成什么工作。 在 Sprint 计划会议中，Scrum 团队还草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确 开发增量的目的。

目标是坚定而又柔韧的Flag：

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指 引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标 为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供 一个连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使 开发团队一起工作而不是分开独自做。 开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功 能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

每天检视目标：

开发团队籍由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办 列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每 天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结 束时开发出预期中的增量。

评审会（或许叫检视会更好）回顾和调校目标：

Sprint 评审会议包含以下内容： 

• 参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者；

• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”； 

• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决 的；

 • 开发团队演示“完成”的工作并解答关于所交付增量的问题；

 • 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可 能的目标交付日期（如果有需要的话）； 

• 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息； 

• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变； 同 时， 

• 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

产品列表和精化会是迭代列表和计划会之外另一个轨道和级别上的目标一致：

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续 的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精 化过程中，产品待办列表项被重新评审和修改。Scrum 团队决定如何来完成精化以及何时 来完成。精化的工作通常占用开发团队不超过 10% 的产能。然而，产品负责人或者其他 人在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。

以终为始，拉出来溜溜，增量是实现了的目标：

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增 量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并 且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的、 可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否 决定发布它，增量必须可用。

目标要有标准：

当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然 在不同 Scrum 团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什 么有相同的理解以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量 是否完成。 这一定义也同时被用来指导开发团队了解在 Sprint 计划会议时能够选择多少产品待办列表 项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能 增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以 选择立即发布它。如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所 有 Scrum 团队都必须遵守它，以此为最低标准。

行动

目标是通过行动来实现的。

计划会的第二部分是关于行动：

Sprint 计划会议回答以下问题： 

• 接下来的 Sprint 交付的增量中要包含什么内容？ 

• 要如何完成交付增量所需的工作？

行动是团队群创出来的：

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中， 开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。 在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以 一天或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工 作在 Sprint 计划会议和 Sprint 期间按需进行。

每天依据目标和推进调整行动：

在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制 定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化 团队协作和效能。

迭代列表是行动的载体：

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和 实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功 能以及交付那些功能到“完成”的增量中所需工作的预测。 Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确 保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。 Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中 清晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达 成 Sprint 目标所必需的工作时。

异常

没有异常就没事了。管理的核心是异常管理。异常要被管理。

检视：

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要 的差异。

调整：

如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接 受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进 一步的偏离。

站会第三问是关于异常，基于目标和行动：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？ 

• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？ 

• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

异常管理随时消化：

开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨 论，或者为 Sprint 中剩余的工作进行调整或重新计划。

每天：

每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显 并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

回顾是系统化地消除异常：

Sprint 回顾会议的目的在于： 

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何； 

• 找出并加以排序做得好的和潜在需要改进的主要方面； 同时， 

• 制定改进 Scrum 团队工作方式的计划。 

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们 能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，如果适用并且不与产品或 组织标准相冲突，Scrum 团队计划不同的方式通过改进工作过程或调整“完成”的定义来提 高产品质量。 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在 下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然 改进可以在任何时间执行，但 Sprint 回顾会议提供了一个专注于检视和适应的正式机 会。

燃尽图之类的工件帮助管理异常：

在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint 评审会 议中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前 Sprint 评审会议时的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关 者都是透明的。 各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图（burn-downs）、燃 烧图（burn-ups）或者累积流图（cumulative flows）。这些工具都被证实是有用的。然 而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法 预知的。只有已经发生的事情才能用来做前瞻性的决策。

在产品和迭代两个层级燃：

在 Sprint 的任何时间点都可以计算 Sprint 待办列表中所有剩余工作的总和。开发团队至 少在每日 Scrum 站会时跟踪剩余工作的总和，预测达成 Sprint 目标的可能性。通过在 Sprint 中不断跟踪剩余的工作量，开发团队可以管理自己的进度。

建议

在不能直接实施Scrum的情况下：

• 目标可见和管理。

• 行动可见和管理。

• 异常可见和管理。

• 每件事有清晰的范围和标准。

• 陈力就列，每个人在上述系统中有清晰的定位。

• 以上为基本原则，其他原则待补充。

• 以上原则机制化道具化。