图解敏捷教练和 ScrumMaster

[运营专题]零预算引爆个人和企业品牌【原文链接】
Selenium 自动化测试从零实战【原文链接】
原来这样做，才能向架构师靠近【原文链接】
Cordova App 打包全揭秘【原文链接】
TensorFlow on Android：物体识别【原文链接】
TensorFlow on Android：训练模式【原文链接】

说在前面：达人课是GitChat的一款轻阅读产品，由特约讲师独家发布。每一个课程你都可获得6-12篇的深度文章，同时可在读者圈与讲师互动交流。GitChat达人课，让技术分享更简单。进入我的GitChat

温馨提示：本篇文章较长，点击原文阅读

作者介绍

GlenWang，敏捷教练，致力于打造卓越个人和组织。经历过三个行业：通信，电子制造，金融 IT。三个职业：开发人员，经理，精益和敏捷教练。译著有《特斯拉：电气时代的开创者》。敏捷之旅讲师，认证 Scrum Master 课程 Co-Trainer。

虎头锤，旅居墨尔本的程序猿，十年 Coding，区块链比特币ing，手绘进阶ing。

课程介绍

在互联网时代快速变化的今天，传统管理方式已经失效并且逐渐被社会淘汰，我们需要全新的方法来适用于不同规模的团队。敏捷教练和 Scrum Master 是一种专业的职业。其职责是帮助团队和组织做到更好（本课程视 Scrum Master 和敏捷教练为同一职业的不同发展阶段）。敏捷能力的培养并不是简单了解后就可以速成的，但如同任何其他职业一样，成为一名敏捷教练是有一套可以刻意练习出来的基本功。

本课程按“目标-储备-技巧-实战”四部曲，介绍敏捷教练和 Scrum Master 的基本功：

对精益敏捷框架和基础知识的扎实理解
对团队在敏捷应用过程中所处阶段的理解
模式及 Scrum 中的各种子模式
敏捷教练的内在修养、教练方法和自我提升方法
持续改善与系统思考方法
敏捷教练需要了解的技术实践
敏捷教练在团队中一个典型的教练周期

第01课：敏捷教练和 ScrumMaster 基本功四部曲

概述

敏捷教练是一个职业。Scrum Master 和敏捷教练是同一职业的不同阶段。当一个人能带好一个 Scrum 团队时，他是一个 Scrum Master。当他能带各种不同类型的团队，并持续追求更好，他就是一个敏捷教练。

Scrum Master 职责的范围和边界相对确定，敏捷教练职责的范围和边界相对不确定。但从学习的角度，他们所需要的基本功是一致的。本课程中对这两个角色，在大多数时候不太区分。鉴于这两个角色既有相似处又有区别，大家在使用时对这两个名称的理解上又有变异，所以课程的名称中就把这两个名称并称，以求相对准确地表达这个课程所要服务的角色。就算是您所采用的敏捷方法不是 Scrum，依然可以从本课程中受益。

如同任何其他职业，敏捷教练有它的技能，也需要并且能够通过练习达到精通。我们可以通过四部曲的结构理解敏捷教练这个职业及其技能：

• 目的：任何一个职业，都有它存在的目的。这个目的包括职业产生的背景，工作的环境，以及所承担的职责。
• 储备：即敏捷教练所必备的基础知识。
• 技巧：即如何运用基础知识履行职责。
• 实战：即在一个典型完整的工作周期中，如何利用储备和技巧取得成功。

本章会介绍：

• 敏捷教练这个职业产生的背景
• 敏捷教练的工作环境
• 敏捷教练的职责
• 体系化的参考书目
  

敏捷教练职业产生背景

“追求更好”旅途的守护者

我们从敏捷的历史来看一下，敏捷教练这个角色是如何诞生的、这个角色对组织意味着什么。

敏捷方式可以追溯到1620年弗朗西斯·培根（Francis Bacon）科学方法的发源时期。更合理一点的起点可能是在20世纪30年代，那时候贝尔实验室的物理学家和统计学家沃特·阿曼德·休哈特（Walter A. Shewhart）开始使用计划-执行-学习-调整（PDSA）循环对产品和过程进行改善。

休哈特把这种反复渐进的开发过程教给了他的学员戴明（W.Edwards Deming），后者在二次大战后的日本大量使用了该方法。戴明将 PDSA 改造为 PDCA。丰田公司雇用了戴明来培训公司中数百名经理，并在他的经验之上创立了著名的丰田生产体系——这也是如今精益思想的最初由来。这种反复渐进的方式对于20世纪50年代的 X-15 超音速飞机的制造也是贡献巨大。

丰田模式的关键，以及使丰田有杰出表现的原因并不是任何个别要素，而是一个由各要素组成的 4P 体系：

• 长期理念（philosophy）：重视着眼于长期的思维，公司高层注重为顾客及社会创造与提升价值，这个目的主导了该公司的长期方法——建立学习型组织，投资于人员、产品与工厂，以及绝不松懈地坚持质量，以适应环境的变迁，成为高效的组织。

• 正确的流程（process）：正确的流程方能产生优异成果，流程是以低成本，高安全性与高昂的士气达成最佳质量的关键。

• 借助员工与合作伙伴（people and partner）的发展，为组织创造价值：丰田公司管理层的看法是，他们打造的是“人”，不是汽车。尊重员工的智慧和能力，并不断激励他们做得更好。

• 持续解决根本问题（problems）是组织型学习的驱动力：丰田模式的最高境界是组织型学习，丰田的持续学习制度重心在于辨识问题的根源，并预防问题的发生，持续改善。

此体系必须每天以贯彻一致的态度实行，而非只是一阵旋风。这个体系成功的秘诀是，经理即教练。培养深谙公司理念的领袖，使他们能教导其他员工。这是我们今天思考敏捷教练职责的最重要参照物。丰田的 4P 模式，也能帮助我们从根本上去思考什么是敏捷。

大野耐一是将丰田生产方式体系化的重要人物。大野耐一退休后，与其弟子创建了 NPS（New Production System），为其他企业服务。精益教练诞生，教练与经理分离。这也预示着在今天敏捷教练和管理者通常是分离的职位。

Scrum 的另一根植于日本的基础，是1986年野中郁次郎和竹内弘高在哈佛商业评论上发表的名为《新的新产品开发游戏》的文章。通过研究那些比竞争者更快发布新产品的制造商们，比如富士-施乐的复印机，本田的摩托车引擎，佳能的照相机，定义了以团队为基础的新的产品设计和研发过程。这种过程不是通常在产品开发中的“接力赛”——一组专家完成产品部分功能并将项目传递到下一组专家手中。这种方式被野中郁次郎和竹内弘高称作为“橄榄球”方式，“团队试图作为一个整体完成所有任务，将球传来传去。”

在1993年，Jeff Sutherland 面临一项似乎是不可能完成的挑战：Easel 是一家软件公司，需要在半年之内开发一款新产品来替代它的传统产品。Jeff Sutherland 通晓很多方法，比如快速应用程序研发，面向对象设计，PDSA 循环，专案工作等等。他希望在公司总部建立一个类似于专案工作的文化氛围，将组织分割和合并的好处结合起来。他开始学习任何和提高组织效率相关的知识。通过阅读上百篇研究报告和顶尖的产品管理专家面谈，他脑海中逐渐有了一些有煽动力的想法。

这中间有一个想法来自于贝尔实验室的关于 Borland Quattro Pro 团队的文章。该文章主张，每天短的团队会议能显著增加团队效率。而 Jeff Sutherland 的核心概念则来自于竹内弘高和野中郁次郎的“橄榄球”方式，虽然该方法更关注制造过程而不是软件开发过程。通过借鉴哈佛商业评论文章中的关键想法和进行一些特别的试验，Jeff Sutherland 创建了一种新的软件开发方法，归功于橄榄球带来的灵感，Sutherland 将这种方法称为“争球”（Scrum）。Scrum 方式最后确保了他准时完成了似乎不可能的任务，也没有超出预算，程序漏洞比之前版本还要少很多。Sutherland 随后就长时间和 Ken Schwaber 对该方法进行长期研究，并在1995年两人首次在公众面前发布 Scrum 的方法。

在2001年，17位自称“有组织的无政府主义者”在美国犹他州的雪鸟滑雪场会面，分享他们的想法。Jeff Sutherland 和其它 Scrum 的先驱也在其中。参与者们分享了互相竞争的几种方式：极限编程（XP）、水晶方法、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发方法（DSDM）。所有这些方式都是“轻量版”的框架，因为这些方法使用更少、更简单的规则来适应快速变化的环境。不少与会者都觉得“轻量”这个术语挺适用的。

虽然与会者不能在方法上达成一致，但是他们还是为这个运动取了个名字：敏捷。这个词是一位参与者提出的，他当时正在读《敏捷竞争者和虚拟组织：给客户更多的策略》一书。书中列举了100家公司的例子——包括 ABB， 联邦快递，波音，博士和哈雷戴维森，这些公司正在创建适应动荡市场的新方法。有了这个名字，参与者达成一致，发布了“敏捷软件开发宣言”，该宣言中突出了每个人都同意的4个关键价值。稍后在会议中，以及之后的几个月中，他们发展了12个原则，被称为“敏捷宣言背后的原则”。 从2001年开始，所有的开发框架，以及与之匹配的价值观和原则就被称作为敏捷技术。

同时，敏捷方法继续演化。在20世纪80年代后期和90年代前期，MIT 的研究学者们开始研究日本的制造体系，特别是丰田生产体系。他们借用了名词“精益”来描述改善效率的这套体系，包括消除浪费（muda)， 减少波动（mura）和降低负荷（muri）。虽然精益方法并没有在雪鸟会议上被表述成敏捷方法，但是精益和看板软件开发系统在后来被并入敏捷系统。在开始时候，一些纯粹的敏捷主义者拒绝承认精益方法。 但是精益宣传该方法能关注客户协作，最终更多的敏捷践行者开始接受精益，看板，还有混合方法（比如 Scrumban 和 Lean scrum），作为敏捷价值和原则合法的应用。

这些新方法论的创始人们是精通技术的管理者，和管理者中的思想者。敏捷宣言的17位创始人，是敏捷思想的传道者，可以被认为是最早的敏捷教练。他们所创造的这些方法的本质，不是一些死板的规定，而是在追求“更好”的旅途中，作为承载“更好”的载体。这些方法论的落地，以及作为这些方法论内在精神的追求“更好”，不会自动发生。

一种可能的逻辑是，由管理者来承担落实新方法论的责任。管理者可以转型为教练，重拾作为精益鼻祖的丰田的精神。对于管理者无法承担教练职责但又想追随敏捷潮流的组织，则需要专职的敏捷教练。

敏捷教练工作的环境

守破离的概念来自日本，大致可以理解为遵守、突破和脱离。这个概念在敏捷界被广泛运用，含义也会有所变迁。下面这个关于组织所处阶段的守破离，来自于 Scrum 之父 Jeff Sutherland。

组织的守的状态

• CEO 没有敏捷思维。以命令和控制的文化为主。
• 依据传统的管理层级结构产生项目组。
• 即使采用敏捷，也是跟风，流于形式，无法深入。
• 在这种状态之下的效率提升通常只能做到20%~30%

组织的破的状态

• CEO 改变管理者的角色。教练和支持的文化浮现。
• 管理者教导团队自组织和自管理。管理者成为领导者。
• 领导者为团队提供有挑战的排好优先级的目标。
• 消除组织债，创建可行的商业和组织计划，提供团队所需的资源。
• 识别和移除障碍，消除浪费和技术债，确保团队速率最大化。
• 确保产品负责人对交付的价值负责。
• 确保 Scrum Master 对流程改善和团队快乐负责。
• 确保团队对质量提升和技术债修复负责。
• 团队依据排好优先级的产品列表自我形成。
• 领导者在组织内驱动不同技能的虚拟实践社区，为组织提供能力建设。
• 领导者按需重构组织。
• 在生产力方面会取得200%~400%的提升。
• 示例公司：Spotify，SAP，Salesforce，Microsoft。

组织的离的状态

• 层级仍然存在，但主要是为技能培养服务。
• 团队自组织负责产品方向和组织重构。
• 领导者支持团队所需的技能。
• 群游使组织在压力之下更强壮。
• 产生500%~1000%的生产力提升。
• 示例公司：Valve，Zappos，Morning Star，Gore，Grindr。
  这三种状态，跟建国方略中的军政、训政和宪政暗合，可参照理解。

瓶颈通常在瓶子的上部，一个公司最大的瓶颈是 CEO。作为一个敏捷教练，针对所处的组织形态，可以采取运用敏捷基本功加上变通的方法来开展工作。

至于团队，也会有三种形态。

无组织团队

• 从团队绩效方面看，是相对不高和不稳定的，时好时坏。迭代计划预测的靠谱度较差，速度也不高。
• 从团队动态和互动看，呈现出一种各自为政的状态，沟通不畅，合作困难。从会议看，目的不明确，流程不清晰，效率低，参与者沮丧。

自运转团队

• 从团队绩效看，呈现出相对稳定的状态，迭代目标承诺靠谱度较好，迭代目标基本能完成。
• 从团队动态和互动看，团队成员目标一致，有良好的沟通合作，在各项活动中，团队成员都能主动参与。会议的目的和流程清晰，没有 Scrum Master 的情况下，会议也能按照打磨好的流程自动运转起来。

自组织团队

• 从团队绩效看，在稳定的基础上，呈现出阶段性的持续提升，生产率和质量不断提高。
• 从团队动态和互动看，团队有更多高质量的互动，团队除了关心共同的目标，还关心持续改善和从根本上解决问题。呈现出上文中所说的丰田 4P 的一些特征。
  敏捷教练所要做的，就是把团队从无组织状态带到自运转状态，再进一步带到自组织状态。这个使命的履行，本课程中敏捷教练和 ScrumMaster 的基本功可以帮到您。

敏捷教练的职责：流程与人两手抓

在设计本课程之前，针对一部分敏捷从业人员和经历者做了一个小调查，想了解他们对 Scrum Master 职责的理解。这个调查虽然样本较小，不具备统计意义，但依然可以帮助我们了解跟我们处在同样角色的人对这个问题怎么看。调查结果如下：

• 精通管理规则，精通业务梳理，极强的沟通协作能力，技术熟练，懂业务管理。
• 敏捷教练确保 Scrum 被正确的运用和贯彻，同时保护团队和引导新的想法落地。
• Scrum Master 是牧羊犬的作用，让团队在一个迭代中不受打扰，同时他应该对敏捷的流程、理念有深入的了解，具有较强的管理能力。
• 引导团队进行效率的提升，通过各种工具的导入，来实现项目目标。但是，究竟是否要像传统团队一样，也要引导团队进行项目交付，并解决依赖问题，这个要商榷。
• 保证团队资源，保证各个角色及职责协作，解决团队开发中的障碍，协调解决沟通问题，保证开发过程按计划进行。
• 指导 Scrum 小组成员理解为什么、知道如何参与 Scrum 实践的每一个环节，把控好 Scrum 实践的产出，为整个小组的 Scrum 迭代/计划结果负责。
• 基于对 Scrum 角色的了解，以及对项目和资源的认识，帮助 stakeholder 决定最佳的按照 Agile 路线来实施项目的教练。
• 培训和指导团队践行敏捷实践；关注项目的度量数据，及时带领团队调整，加速或稳步前进；关注成员的状态，激励督促团队前进；带领和辅导团队按照敏捷和精益的方式做事，打造优秀自组织团队。
• 牧羊犬守护团队，流程；教练，培训，引导团队，PO，相关人知识，技能；推动过程改进，促进变革；提升团队，组织效能。
  在敏捷团队中推进敏捷开发模式和流程，是团队的组织者，保证团队资源，协调内外部关系，解决出现的问题。
• 帮助团队进行敏捷实践落地，梳理流程，减少外部干扰，鼓舞士气，提高团队作战能力。提高工作效率。
• 传播敏捷思想，指导团队，指导 PO，组织敏捷会议，排除团队干扰。
• 指导团队按 Scrum 方式运转，传播 Scrum 思想，指导敏捷实践，提高效率。
• 保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织 Daily Scrum，Sprint Review and Sprint Planning meetings。
• Scrum Master 是 Sprint 的负责人，Sprint 做得好不好的终责者。负责计划，执行 Sprint，并使团队团结及有自主创造能力。
• 搭建 team 架构，分配各个角色成员，开展 scrum 常规的事项，并让敏捷的理念深入人心。帮助团队更好的按照 Scrum 框架有效的运行，对团队遇到的问题和障碍提供帮助，协助扫清研发过程中的障碍，打造高效能的团队。
• 组织项目团队，承诺项目开发，回顾项目过程，总结项目经验教训，组织每日站会，制定 Sprint 计划。
• Facilitate everything and eventually retire，留下一个自组织团队，悄然离去，深藏功与名。激励团队，coach，team lead，life tutor。
• Scrum Master 应该是作为团队初步接触敏捷时作为流程与套路教授和规范。在团队逐步成熟后，Scrum Master 的职责可以旁落，而专职 Scrum Master 可以取消。

那么敏捷教练的职责到底是什么呢？

《敏捷教练》一书的作者之一，瑞秋·戴维斯（Rachel Davies）对敏捷教练的观点：

概括地说，敏捷教练帮助团队在工作中应用敏捷实践，从而帮助团队发展的更健壮。接受这些变化需要时间，所以没法通过“点到即止”的方法立即让它们生效。你需要与团队长时间呆在一起，并帮他们，让他们更加关注工作流程、关注如何更有效地协作。你对团队的目标是在你离开后，让他们能“自我指导”并且擅长应用敏捷。这样不会限制敏捷教练向组织引进敏捷，以及建立新敏捷团队。

< Coaching Agile Teams > 的作者 Lyssa Adkins 对敏捷教练的观点：

敏捷教练确实非常重要，因为现在有许多人在运用一堆蹩脚的敏捷工作方式。即使运用了，它们只是更快地产出了平庸的结果，我知道，那并不是他们运用所谓“敏捷”工作方式的主要意图。我认为教练是帮助团队取得惊人成果所不可或缺的组成部分，因为所有的成果都是人互相交互所产生的。敏捷框架中没有说明如何处理人与人交互的部分。为了使敏捷框架良好运作，它当然会提供可让其正常运行的结构和容器。但是在敏捷框架之外，还有很多事情要做，还有很多东西需要带给团队，针对不同的规则，需要给团队很多建议——如冲突管理、敏捷促进、教导及指引人、专业指导等等。

本文给出的敏捷教练的职责定义是：

• 贯彻一种工作方式，包括精益、敏捷和系统思考。
• 打造自组织团队，特别是要面对人（包括自我与他人）这个最复杂的实体。
• 以此来消除浪费，增加价值，达到组织的目标。

要履行这些职责，需要理解敏捷，这是本课程基本功的储备部分；要能够在组织中用敏捷影响他人，这是基本功中技能的部分；要体会真实环境中的敏捷运用，这是本课程基本功中的实战部分。

体系化的参考书目

敏捷是敏捷教练的代码

敏捷的历史是一场不断追求更好的历史，在这个过程中，先行者们为我们留下了众多可供参考和让我们无须重新发明轮子的书籍。

本节以类库、框架、架构，和编辑、编译、链接、运行的视角解析敏捷和敏捷教练，以及如何运用先行者们留下的书籍。

敏捷是一种代码，2001年2月，17人在美国犹他州的雪鸟滑雪场，解码和发明了这门语言，并贡献了敏捷基础类库。

敏捷基础类库

• Kent Beck 等的 （《敏捷宣言》）。

敏捷框架类库

• Jeff Sutherland & Ken Schwaber
• Kent Beck （《拥抱变化：解析极限编程》）
• Mike Cohn （《用户故事与敏捷方法》）（《敏捷估算与规划》）
• David Anderson （《看板方法》）
• Mary Poppendieck （《精益软件开发》）
• Craig Larman 的 Large Scale Scrum
• Dean Leffingwell 的 SAFe

敏捷扩展类库

• 野中郁次郎和竹内宏高《新的新产品开发游戏》《场理论》
• Henrik Kniberg （《硝烟中的 Scrum 和 XP 》）
• Kenny Rubin （《Scrum 精髓》）
• Jeff Patton （《用户故事地图》）
• Mitch Lacey （《Scrum 实战指南》）
• Ken Schwaber （《Scrum 敏捷项目管理》）
• Mike Cohn （《Scrum 敏捷软件开发》）
• Eric Ries （《精益创业》）
• Ellen Gottesdiener
• Jezz Humble （《持续交付》）
• 《戴明14条》
• 艾永亮《腾讯之道》
• 何勉《精益产品开发原则、方法与实施》

精益类库

• 大野耐一 《丰田生产方式》《现场管理》
• 新乡重夫《从 IE 的角度看丰田生产方式》
• James Womack （《改变世界的机器》）（《精益思想》）
• Jeffery Liker （《丰田模式》）系列
• John Shook （A3 报告）（价值流图）

引导与心理学类库

• NLP 神经语言程式
• 世界咖啡
• 六顶思考帽
• 管理与变革类库

Chip & Dan Heath （《瞬变》）
Jurgen Appelo

敏捷模式类库

• Scrum 本身就是个模式
• 《用户故事地图》也是模式
• Linda Rising
• 本课程中的 Scrum 子模式，例如故事泳道、一人天任务、随机一分钟项目经理。

敏捷教练方法类库

• Lyssa Adkins

修身类库

• 《大学》《中庸》《论语》《孟子》
• 《王阳明全集》
• 《心经》《金刚经》
• 《圣经》
• 阿德勒《超越自卑》
• 《人生五大问题》
• 斯蒂芬柯维《七个习惯》
• 《红与黑》
• 《基督山伯爵》
• 《悲惨世界》
• 《百年孤独》
• 《活着》
• 《常识》

而在设计敏捷工作方法的架构时，可以基于上面提到的敏捷框架中的一个或多个。可以使用的思维线索有：

• 软件开发的阶段：概念，机会，策略，需求，方案，计划，实施，验证，部署，维护，退役。
• PDCA
• 5W2H

在做敏捷工作方法的实施时，第一步是需求：

• 与关键人员交流，了解问题与目标
• 这一步要放下敏捷的代码，倾听了解问题与目标本身。

第二步是制定解决方案：

• 根据现状，参考敏捷方法，制定关键举措。
• 使用类库和框架，制定架构。

敏捷工作方法的编码就是用上面的各种类库和框架，生成适合组织和团队的可执行的敏捷方法，包括架构和详细实现。执行的环境是团队中每个人的大脑。

编辑，是把方案细化的过程：

• 把敏捷方法动作化，做好剧本。无剧本，不操作。
• 为每一次谈话做好充分准备。

编译，是与团队中所有人交流的过程，使所有人理解敏捷方法：

• 可以是讨论，针对某个具体变化的方案与执行。
• 可以是培训，介绍整体或某个环节的工作方法。
• 可以是一对一交流，让方法切实而不只是形式上发生。

链接，是处理与现状和与已有工作方法的冲突：

• 分析问题，解决问题。
• 调整“代码”

运行，是新方法的执行：

• 落实每一个动作，并检查调整。

编辑、编译、链接、运行会反复多次进行，跟程序员写代码没有区别。

敏捷教练和 ScrumMaster 的基本功，来自于众多大师的智慧和作者的实践，为我们提供了扩展的大脑。该体系已为您整理好，是按下继续前进按钮的时候了

第02课：储备-Scrum 精要

介绍 Scrum 的书虽然还没有达到汗牛充栋的程度，但已经是著作等身了——所有著作加起来能够等同于一个人的身高了。本文并不是对 Scrum 理论的简单重复，而是立意能做到两点：

• 涵盖 Scrum 中所有重要的概念。
• 所介绍的方法达到说明书的程度，拿过去就能用。

敏捷产生的历史背景

首先简要谈一下敏捷产生的历史背景，以及由 Scrum 及其众多兄弟方法共同抽象出的敏捷宣言。

敏捷产生的历史背景，在于世界变化越来越快。人们不断产生更多更新的需求，技术因此不断进步，两者交相辉映，使得变化越来越快。

以通信行业为例，从 1G 到 5G 呈现出一种升级越来越快的状态。

1986年，作为 1G 标志的使用模拟信号的世界上第一套移动通信系统在美国芝加哥诞生。

1995年，诺基亚崛起，进入数字调制的 2G 时代。

2009年左右，CDMA 大行其道，进入数据传输速率更高的 3G 时代。

2013年左右，伴随移动互联网，移动通信进入网速更高的 4G 时代。

最近一两年，随着 AR、VR、车联网、物联网的诞生，5G 的商用化指日可待。

在这种变化越来越快的环境之下，传统的软件开发方法不再奏效。敏捷先驱们开始探索一些新的方法，对丰田生产方式、组织模式等进行了大量学习，发明了 Scrum、XP 等各种方法论。2001年，新方法论的创始人们聚首一堂，总结了各家方法论的共同点，提出了敏捷软件开发宣言。

敏捷宣言有4个价值观和12个原则，它们也是 Scrum 的基础。对4个价值观要能够背诵下来，对12个原则也要熟悉，以便达到遇到实践情况时能容易对照的目的。我们为您精制了手绘版的敏捷宣言价值观和原则，可以打印张贴备查。

敏捷软件开发宣言

enter image description here

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个体和互动 > 流程和工具
• 工作的软件 > 详尽的文档
• 客户合作 > 合同谈判
• 响应变化 > 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷宣言遵循的原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

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 的重要输入。
• 各个角色的普适标准：专业、尊重、坚持。
• 改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。

最后用十论 Scrum 就是知行合一对 Scrum 作个小结：

1. 人人知行合一：人人计划，人人行动。
2. 时时知行合一：时时计划，时时行动。
3. 团队知行合一：团队决定，团队行动。
4. 敏捷知行合一：快速决定，快速行动。
5. 需求知行合一：接近客户，掌握需求。
6. 支柱知行合一：检验是知，适应是行。
7. 完成知行合一：定义完成，共识目标。
8. 透明知行合一：高度透明，流畅过程。
9. 纪律知行合一：自我纪律，助长能力。
10. 美德知行合一：积极主动，集思广益。

本章首先介绍了敏捷宣言，然后按3355框架介绍了 Scrum 中最核心的东西。下一章介绍伴随 Scrum 的一个重要物件——用户故事。

下一篇

课程内容

第01课：敏捷教练和 ScrumMaster 基本功四部曲

第02课：储备-Scrum 精要

第03课：储备-用户故事精要

第04课：储备-Scrum 的20个子模式

第05课：储备-精益体系精要

第06课：储备-敏捷教练需要了解的技术实践

第07课：技巧-敏捷教练的四种心法

作者撰写中…

第08课：技巧-敏捷教练的六脉神剑（上）

作者撰写中…

第09课：技巧-敏捷教练的六脉神剑（下）

作者撰写中…

第10课：技巧-敏捷教练的提升三式

作者撰写中…

第11课：技巧-持续改善与系统思考方法

作者撰写中…

第12课：实战-典型的教练实战周期

作者撰写中…