图解 Scrum 精要，一看就会！

Posted 2021-04-25 真北敏捷

互联网时代，商业环境急剧变化，客户要求越来越高，竞争对手不断涌现，企业所处理的问题越来越易变、不确定、复杂、模糊。传统管理模式不再有效，敏捷管理模式应运而生。全球市值四大的苹果、微软、亚马逊、Facebook 都不约而同地采用了不同形式的敏捷。敏捷帮助企业在复杂多变的商业环境中快速交付价值，实现企业目标。

企业需要产品竞争力、技术竞争力，还需要工作方式的竞争力。敏捷的工作方式通过敏捷的价值观、原则和实践，来指导和激励个人、领导者和组织，从而创建高效、可持续的工作场所。

本文给大家介绍的就是敏捷管理的核心思想 Scrum。我们力求把方法论介绍到可操作的程度。从方便理解和记忆的角度，Scrum 方法论可以被概括为 3355。

3 个角色

• PO（产品负责人）
• SM（Scrum Master）
• 团队成员。

3 个物件

• Product Backlog（产品列表）
• Sprint Backlog（迭代列表）
• Product Increment（产品增量）

5 个会议

• Product Backlog Grooming （产品列表精化）
• Sprint Planning（迭代计划会）
• Daily Stand（每日站会）
• Spring Review （迭代评审会）
• Sprint Retrospective（迭代回顾会）

5 个价值观

勇气，承诺，专注，开放，尊重。

Scrum 由上述四种要素及背后的规则粘合起来。

3 个角色各有担当又通力合作。3 个简单的物件统摄产品层面与迭代层面的交付物。5 个会议贯通产品层面与迭代层面的计划与执行活动。5 个价值观作为方法论的一部分，体现了 Scrum 以价值观为方法论的特色。

3 个角色的职责

Scrum Master 的职责最难讲得清楚。有一个思路是参照卡诺模型。日本教授把产品需求分为三类：

• 必备型需求：这类需求没有满足，客户不会购买这个产品。
• 多多益善型需求：这类需求的实现程度与客户付钱的愿望呈线性关系。
• 喜出望外型需求：这类需求是区别于竞争产品的分水岭，客户愿意付出溢价。

按照这个思路，我们可以把 Scrum Master 的职责分为三类：

• 必备型职责：协助管理 Scrum 的 3 个物件和 5 个会议。
• 多多益善型职责：与各方沟通和协调问题解决。
• 喜出望外型职责：系统思考，发现流程和团队工作中的改善点，并推动改善。

产品负责人职责

管好产品列表。理解了什么是好的产品列表，也就理解了产品负责人的职责。后面会讲产品列表。

团队职责

与传统团队职责不太一样的主要有两点：

• 跨职能：个人不一定是全能的，但团队要是全能的，具备把产品列表变成产品增量的全部技能。团队成员之间，不受角色和头衔的制约，只要具备能力，每个人都可以认领所有任务。
• 自组织：团队自行决定自己的工作方式，只要团队有共识。原则上是全员参与估算和计划，全员进行项目进度的监控和调整。

在现实的团队中，有专职人员，也可能有浮动人员，不管是专职人员还是浮动人员，几个共同的基础是：自动化与及时化，每个人都做好本职工作，彼此之间良好配合；每个人都理解团队的产品目标和迭代目标；每个人都了解团队的工作方式和节拍。

浮动人员的类别

一类浮动人员，例如架构师和设计师，有全局影响，但又不是全职参与。有两种变通的参与方式，一是跟专职人员一样，参加 Scrum 会议，二是在团队中指定他的影子，与他密切协作保证他能及时贡献到团队的目标。

二类浮动人员，如固定在两个团队之间共享的测试人员。

1. 减少共享的人数，尽量把测试人员固定在其中一个团队；
2. 由有能力多任务的资深人员在两个团队之间浮动领任务，以缓解对其他人员的共享需要；
3. 在极端情况下，才让（1）中的人员也在两个团队之间浮动。

三类浮动人员，如在一段时间之内有部分时间花在该 Scrum 团队的人员。与一类浮动人员相比，这类人员的全局影响相对小，更多是因为技能或资源问题而导致的安排。其变通的参与方式与一类浮动人员类似。

四类浮动人员，如尚不能独立工作的新员工。变通的方法是由其导师协助领取任务。

团队之要

• 在 Scrum Master 的引导和辅导下理解 Scrum 框架，特别是从事情角度的严密的 PDCA 循环，和从人的角度的紧密合作。
• 以严密的纪律性使 Scrum 能良好运转，达成业务上的目标，并收获高效快乐的团队。
• 在纪律的支撑之下，技术上精益求精，更好地发挥创造性，包括在技术领域，并适当参与产品探索领域。

Team 在 Scrum 中的活动

• 梳理
• 计划
• 执行
• 每日检查和适应
• 迭代检查和适应（评审与回顾）

Team 特征

• 自组织：自组织不能来自命令与控制，而是简单规则支持下的群游。
• 跨职能团队：多样性，跨职能，不同背景，不同的思考角度，造就更好的产出，更快更好的解决方案、更棒的创新。
• 一专多能
• 火枪手精神（互助）
• 宽带宽沟通（沟通带宽递减：面对面 > 电话 > 即时消息 > 邮件）
• 透明
• 团队大小 5~9 人
• 专注与承诺
• 可持续步伐
• 长期稳定的团队

3 个物件

产品列表（Product Backlog）是产品列表项（Product Backlog Item，简称 PBI）的列表。PBI 包括特性、故障、技术工作和知识学习。

好的产品列表要满足 DEEP 原则：

• Detailed Appropriately 细节得当。越是马上要做的 PBI，越是要有足够的细节。很久以后才做的，可以粗略一点。
• Emergent 涌现式的。PBI 可以根据实际情况随时插入。
• Estimated 有估算的。同样是近期要做的 PBI，估算要较精细，可以采用费波纳契序列的故事点估算，即 1，2，3，5，8 …对于远期要做的 PBI，估算可以粗略，可以采用粗略的T恤尺寸估算，即 XS，S，M，L，XL 等。
• Prioritized 排好优先级的。近期要发布版本中的 PBI 的优先级要明确排列，中期的可粗略排列，远期的可不必排列。

迭代列表由从产品列表中选出当前迭代要完成的 PBI，及由 PBI 分解产生的任务构成。对于任务的估算，可以采用天或小时估算，也可以不估算。采用哪种方式，以团队能够做出靠谱的迭代承诺，以及在迭代工作的每一天方便监测趋势为标准。

产品增量是一个迭代结束时，输出的用户可用的新功能。产品增量要达到潜在可交付状态，即如果用户需要，可以快速部署给用户使用。

5 个价值观

5 个价值观的落实与否，是 Scrum 团队形成的重要标志。

对于 5 个价值观的运用，可以由团队一起讨论，每个价值观分别意味着什么，并进而把价值观转化为可执行的团队规范。利用迭代回顾会议，审视团队规范的执行情况。

5 个会议

对于 5 个会议，主要讲述每个会议的目的、流程和辅助物。

产品列表精化会

目的：准备好。准备好的意思是，经过精化，PBI 达到可估算可计划和可执行的状态。开发人员可以对之进行开发工作了。

流程：

主要是围绕 DEEP 标准

• 细节得当。产品负责人讲解每个 PBI，达到团队成员理解需求的程度。
• 涌现式。在精化的过程中，根据产品负责人与团队的互动，可能会产生新的 PBI。
• 估算。在产品负责人讲完每个 PBI 时，团队可以用估算纸牌进行估算。通过纸牌对话，也可以保证每位团队成员都理解了需求。
• 优先级。优先级主要由产品负责人排列，但团队的估算和实现的难易程度，也会影响产品负责人重新考虑优先级的排列。

辅助物件：

为了保证产品列表精化达到准备好的标准，可以制定一个叫做准备好的定义（Definition of Ready，简称 DoR）的检查列表。DoR 列表示例如下：

• 业务价值清晰。
• 团队了解需求细节，能够做出是否能完成的决定。
• 依赖被清楚地识别和管理，没有妨碍完成 PBI 的依赖。
• 团队具备完成 PBI 的技能。
• PBI 被估算，并且足够小，能够装到一个迭代里。
• 验收标准清晰和可测试。
• 性能指标清晰和可测试。
• 团队知道在完成后如何演示。

迭代计划会

目的：在计划会结束时，给出靠谱的迭代承诺。

流程：

• 产品负责人建议迭代目标和要完成的 PBI。
• 团队把 PBI 分解成任务。
• 团队决定是在计划会上就把所有任务分配到个人，还是在迭代过程中动态分配。分配的方式是团队成员认领。要不要分配的标准是，团队是否能对迭代计划进行承诺。
• 评估计划的工作量与团队容量是否平衡。
• 从迭代计划中提炼出迭代目标，把 PBI 粘合在一起，把团队团结在一起。
• 团队对迭代目标和计划进行承诺。

辅助物件：

为了对完成有统一的标准，需要完成的定义（Definition of Done，简称 DoD）检查列表。DoD 检查列表示例如下：

• 设计有评审。
• 代码完成，包括：代码有重构，代码符合标准，有注释，有签入，有评审。
• 用户文档更新。
• 测试完成，包括：单元测试，集成测试，回归测试，平台测试，语言测试等。
• 零已知故障。
• 验收测试完成。
• 部署到生产环境。

可以用 A1 纸和便利贴辅助计划会议：

Scrum 的两个要点是：人的有效参与，做事的有效轨道。这个计划会的设计，是以有效的轨道辅助人的主动参与。

贴出一张 A1 大白纸。

左边第一列是故事，由 PO 用同一种颜色的便利贴书写和表达。字要大，用白板笔写，保证不用站得很近也能看清楚。故障，新特性或任何要交付的事情统称故事。

故事右边，用另一种颜色的便利贴列出任务。任务是为完成故事所要做的事，由团队书写。可以写上任务的执行人与估算。

整个会议，一次围绕一个焦点，即当前讨论的故事。以故事为单位流动起来。

PO 的注意事项：清晰讲述。随着会议的焦点流动，把故事讲得让团队明白。

SM 的注意事项：适度引导。控制焦点与流动，一个故事充分讨论完并分解成任务，再进行下一个。保持紧凑的节奏和整体时间盒。

团队注意事项：主动参与。一是对故事不清楚的主动提问，而是主动参与任务分解、估算、认领。

全部故事讨论完和分解成任务后，统计每人工作量，看工作量与容量是否平衡，个人之间工作是否能置换以达到每个人的工作相对均衡。

最后是团队决定是否能对迭代计划和目标承诺。

每日站会

目的：围绕目标同步进度，掌握对于完成目标的趋势。

流程：

• 准时开始。每天固定时间和地点。
• 每人回答三个问题：为了帮助团队达到迭代目标，昨天完成了什么，今天打算完成什么，遇到了什么障碍。
• 总结趋势和风险。
• 15 分钟之内结束。

站会中细颗粒度的协作：

• 利用站会，促进细颗粒度协作。
• 故事和任务拉动按优先级进行。
• 需要协作的任务，其所有者勇于发起协作请求。
• 被请求者以协作的任务先于本人可独立承担的任务进行。
• 在回顾会议中明确讨论该模式，并贯彻。
• 模式可以由任何一人发现。

关于站会中的发散讨论：

• 站会中发散讨论的度以全部团队成员觉得爽为标准。
• 15 分钟时间盒不必严格遵守。
• Scrum Master 需要对站会之后团队成员的日程有了解，以便判断站会延长一点是否产生影响。
• Scrum Master 可以观察对于发散讨论是否全部或大部分团队成员沉浸其中，如果是，暂不打断。
• 如果出现较多分神现象，打断讨论，并提议会后安排讨论。
• 或者根据站会的剩余时间，询问团队，这种发散的讨论是否会影响团队成员的后续日程。
• 按以上原则，打断可以由任何一人提出。
• 在回顾会议明确探讨这种情景中的模式。

迭代评审会

目的：了解过去一个迭代完成了什么，并对下一步做出预测。

流程：

• 产品负责人邀请客户和干系人参与。
• 团队总结过去一个迭代的成就和克服的挑战。
• 团队演示完成的产品，获得反馈。
• 产品负责人分享来自用户和市场的信息，预测调整发布计划，预测下一迭代的内容。

迭代回顾会

目的：团队建设，发掘和计划改善。

流程：

• 基调：真诚和有效。排除顾虑，真诚表达。提出有效的问题，落实有效的方案。
• 白板上写两个栏目：感谢，改善。
• 每人（包括 PO 和 Scrum Master）用 Post It 写出要感谢的人，每张 Post It 写一个，数量不限。写完贴在白板。
• 每人（包括 PO 和 Scrum Master）用 Post It 写一个最痛的改善点，只写一个就好。写完贴出来。
• Scrum Master 无需太多发言，只需起一个指针的作用。先从感谢的纸条开始，一张一张拿出来问是谁写的，写的人面向要感谢的人表达感谢，不能太空洞，要谈一下感谢的内容。
• 然后转向改善栏目，Scrum Master 同样不要多说话，一张一张拿起纸条，让写的人讲，其他人可以参与讨论，这个环节焦点放在问题澄清，而不是解决方案，Scrum Master 对这一点要有一定把控。
• 每张纸条讲完后，所有人当场举手或竖大拇指，表达的是认为这个问题是否要尽快即在下一迭代解决。
• 全部问题澄清后，全体针对要解决的问题，讨论方案。Scrum Master 关注一下讨论的流动情况，既不要太乱，也不要冷场。极端情况下，可以点名让大家逐一发言，但尽量不用这一招。
• 产生的方案，形成改善 Backlog。Scrum Master 要跟踪起来，可以在日常或站会中跟踪落实情况。

Scrum Master 要观察团队互动中的交互情况，如果有分歧点，就是改善点。比如说在 Demo 中，PO 对验收标准的理解与团队不一致。这就是需要改善的地方。改善的讨论和进行，可以在日常与相关人员讨论，也可以放到回顾会议。

除了团队的回顾会议，还可以有一对一的回顾会议：

• 一对一 Retrospective 是对团队 Retrospective 的鼓励和驯化。是为了帮助打磨团队 Retrospective。
• 一对一 Retrospective 是对团队 Retrospective 的补充。即使团队 Retrospective 已经搞得很好了，也还需要一对一 Retrospective。
• 一对一 Retrospective 可以由 Scrum Master 发起，也可以由任何人向任何人发起。
• 一对一 Retrospective 的目的，是加强人与人之间的连接，传递改善的信念，和计划和执行改善。
• 一对一 Retrospective 的边界，是围绕改善的基调，就与团队项目工作相关的事进行讨论。
• 一对一 Retrospective 的框架，可以包含探询交流对象对工作方式的反馈、探询痛点和关注的问题，和以 Scrum 实践和角色要求为基准、以观察到的行为为依据向交流对象提供的反馈。还可以包含不同团队之间的经验传递、桥梁和延展。
• 如果希望痛点和问题的探询更封闭一点，可以分解为几个角度：就团队项目工作的上下文而言，您的目标和期望的理想状态是什么？与现状的差距是什么？流程上有什么问题，或有什么妨碍理想状态的达到？团队合作方面呢？团队工作绩效和质量呢？任何其他方面？
• 这个框架的运用要灵活。人的主动参与重于规则。如果人能主动参与改善事项的发掘、计划和行动，框架就可以放下。
• Scrum Master 日常有力的观察是 Retrospective 的重要输入。
• 各个角色的普适标准：专业、尊重、坚持。
• 改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。

---

即日起至 3 月 9 日，专栏《图解敏捷教练和 ScrumMaster》限时特惠！订阅专栏，掌握敏捷管理核心知识，揭秘敏捷教练！

订阅专栏，限时特惠

（3月8日扫码订阅的女读者再手动返现3.8元）