感言

敏捷教练这个坑真大啊……感觉至少搭进60%的时间和团队一起才可以。而且教练远比单做Master来的复杂，好在找到一篇好文，可以反复研读和深入学习。整理了排版格式后分享给大家。

原文 敏捷教练 V 形六步法实战：从布朗运动到深度协作

敏捷教练 V 形六步法

敏捷教练 V 形六步法

• 调查与方案
• 实施与反馈
• 问题解决
• 共识培养
• 深度问题解决
• 沉淀好模式

看团队如何从布朗运动状态到深度协作，获得干系人的良好反馈，取得业务上的成功提升和团队的快乐成长。

六阶段的前三阶段（调查与方案、实施与反馈、问题解决）偏于产品和流程管理，属于相对浅层的套路。后三阶段（共识机制培养、深层问题解决、沉淀好模式）偏于人和组织管理，属于深层共识与合作。

前三阶段相对容易，后三阶段相对难，没有后三阶段的固化，前三阶段易于流于形式，慢慢失去作用。前三阶段与后三阶段由浅入深的转折，呈现出一个 V 形。

能否跨越拐点，也是Doing Agile 和 Being Agile 的分水岭。Doing Agile 和 Being Agile 都不是个人的事，不能简单归结为行为或态度，而是考验一个组织的管理能力。

本文按六阶段的线索介绍该方法在一个项目中的具体运用。每个阶段首先是介绍通用的做法，然后介绍案例中的项目在这一阶段的具体呈现。

六阶段是一种逻辑思路，在实际运作中，每阶段的具体做法之间会有所穿插进行，甚至六阶段之间也会循环往复。根据项目和团队的实际情况，每阶段对应的时间是一到两个迭代（主要针对两周一迭代的情况）。

案例中的项目背景是金融 IT 产品，但其中介绍的方法具有通用性，而不会与特定的行业和产品特征绑定。本文的介绍是以一个团队为主，也融合了部分其他团队的素材。为防止任何侵权和隐私侵犯，照片也做了处理。请勿对号入座。

敏捷教练 V 形六步法与自组织团队五阶段

一个团队所处的阶段，我们可以大致做个划分：

无组织状态：团队成员缺乏统一的方向，各自为政。团队活动纪律散漫，缺乏聚焦，各说各话，像小班的小朋友，呈现出布朗运动状态。团队的绩效相对低下，且不稳定，可预测性差。质量和客户满意度都不高。这种团队没有受过 Scrum 的洗礼或者受过错误的 Scrum 的洗礼。

有条件的自运转：团队已经建立了流程，但更多作为一种外化的规则，需要在 ScrumMaster 的引导下运行。团队绩效有所提升。但如果没有引导，各项团队活动也很难开展起来。按相对规范的 Scrum 运行一个迭代即可达到这种状态。

自运转状态：即使没有 ScrumMaster 参与，各种团队活动也能按既定流程自发运转起来。规则虽没有完全内化，但已变成团队习惯和条件反射。团队绩效有所提升且相对稳定。具有靠谱的迭代承诺，和良好的发布可预测性。团队已经能够接受 Scrum 工作方式，回退的动力和可能性比较小。Scrum 从形态上已经成功。团队共同参与问题解决，共识机制开始涌现。

有条件的自组织：团队成员之间有相对深入的合作，也能产生一些改善，但不够自主和深入。团队中会自发涌现出一些好模式。团队需要更多的授权、赋能和激励。这些是需要深度解决的问题。

自组织状态：团队能够自我定义和优化产品和流程，自主持续改善。团队精神饱满，士气高涨，凝聚力好，战斗力强。团队成为组织的扎实基石。

真正的自组织团队需要组织的整体设计，具备三个特征：

从组织层面来说是低耦合。至少包含三层含义：

• 一是管理者在为团队制定使命和目标之后，把具体的管理和实施完全授权给团队。
• 二是组织内部不同团队之间减少耦合，采用特性团队而不是职能团队，团队内部是跨职能的，具备完成使命和目标的全部能力，使命和目标的范围可以由小到大扩展。
• 三是管理者充分支持自组织的工作方式，从组织层面为自组织设立轨道，制定边界，培养能力，排除障碍。管理者成为组织中的统一支撑平台，团队在其上愉快玩耍。

从团队层面来看是高内聚的。团队得到高度授权，有共同的目标，共同的规则，同甘共苦，亲密协作。敏捷的价值观（个体与互动、可工作的软件、客户合作、响应变化）和 Scrum 的价值观（勇气、承诺、专注、开放、尊重）作为团队规范之母在团队中得到贯彻。

从个人层面看是充满活力的。个人要能感受到意义和奔头。团队被激励，有成长。这些都需要系统地设计。

自组织是敏捷的灵魂。敏捷继承了精益。精益鼻祖大野耐一是世界上最痛恨浪费的人，他的这种痛恨把丰田从一个资源贫乏岛国的后起之秀带到了 50 年持续盈利的汽车界一哥。

大野耐一 50 年现场观察和思考，总结了制造业的八大浪费（为方便记忆，缩写为 TIM WOODS）：

• Transportation：运输；
• Inventory：库存；
• Motion：移动；
• Waiting：等待；
• Over Production：过度生产；
• Over Processing：过度处理；
• Defect：缺陷；
• Skill Unused：未尽之才。

八大浪费之中，未尽之才最大，后工业时代更是如此。大野耐一说：没有人喜欢自己只是螺丝钉，工作一成不变，只是听命行事，不知道为何而忙，丰田做的事很简单，就是真正给员工思考的空间，引导出他们的智慧。员工奉献宝贵的时间给公司，如果不妥善运用他们的智慧，才是浪费。

激活个体，善用人才，是自组织的重中之重。有满意的员工，才会有满意的客户，和公司的绩效。也有人把这种自组织、有目标、有活力的团队称为高维团队，把听命行事的团队称为低维团队。

在需求和技术变化加剧的时代，高维团队是那些处在变化环境中企业的必然选择。

经过敏捷教练六阶段之后，一个团队可以达到有条件的自组织状态。而要达到完全的自组织状态，需要 CEO 和管理层的认知，需要组织管理和文化的支撑。关于这一点，在深度问题解决一节也有所探讨。

在这个六阶段中，贯穿着三个思路：

• 敏捷产品管理。以 Backlog 这个物件统摄产品及背后的各方干系人；
• 敏捷项目管理。以 Scrum 或 Kanban 作为管理框架；
• 敏捷组织管理。提升员工的综合满意度，打造自组织团队。

前两者体现在前三阶段，后者体现在后三阶段。

阶段一：调查与方案阶段一的定义

这个阶段的开始以收到教练需求邀请为标志，以制定出敏捷实施方案，并能够开始第一个迭代的敏捷导入为标志。这个阶段包括调查与方案两个环节。

真实地了解现状，系统地思考问题，是这一阶段的关键。
经过第一阶段，就具备了开始第一个迭代的敏捷导入的条件。

阶段一的做法

教练的准备

教练需要做四个方面的准备。

一是教练行为涉及到关系和做事两个方面。

关系是指教练要与被教练对象之间建立信任。不能建立教练与被教练的关系，就不能产生教练与被教练的行为。做事主要是以精益和敏捷思想为指导，按 PDCA 循环展开教练行为。在一些框架和思想的指导下，与干系人和团队一道协商有无，共识合作，解决问题。

二是分析问题解决问题的思路，主要是对做事这一方面的展开。

教练要精通精益敏捷，融会贯通，心中有标准，并能根据每一具体情况制定出对策。清晰地呈现和理解现状、问题和目标。尽可能亲自看现场，多方验证，确保识别的是真实的问题。对问题进行归类，是偏管理的问题还是偏技术的问题。

对于偏管理的问题，再根据实际情况，决定采用哪种敏捷管理框架，例如 Scrum（适用于新产品新特性开发）或 Kanban（适用于维护性质的项目）。本文重点讨论的是管理方面的问题，对技术方面的问题略有涉猎。

三是调查的思路。

一方面是理清要了解的事项，包括现状、问题、目标和团队结构等。二是调查所采用的具体方式，包括与项目发起人的初始会议，与主要干系人的启动会议，与主要干系人的一对一交流，参加和观察团队已有的会议，和其他了解问题的方式如即时沟通和协作工具，和项目已有的报告等。

四是目的感、逻辑和勇气。

教练的目标是帮助提升业务成果和团队成长。在这个目标之下，依据现实，尽可能调度逻辑链条，找出问题的原因，从源头上解决问题。秉持目标和逻辑，有勇气面对各种不同地位不同兴趣不同思维的人。发掘人与事当中的亮点和正面力量。

关于建立信任关系：

尊重与真诚。从初始会议到整个教练过程，都对被教练对象充分尊重。一是尊重是 Scrum 的价值观之一，是一切合作的基础。二是团队和干系人才是最了解真实情况的人，只有对此给予尊重，教练才有可能了解到真实情况。教练要保持真诚，一是对于更好的工作方式和更好的团队的坚定信念，二是愿意为此信念与团队共同努力，把自己当做团队的一员，与团队共同进退。

成功案例。教练被邀请，相信是项目发起人对于教练以往的成功案例有所耳闻。还可以在初始会议和启动会议上介绍成功案例。介绍成功案例的主要目的不是为了宣传，而是激发干系人的兴趣和信心。

展示专业度。可以介绍教练思路和方法，让被教练对象了解教练工作过程，并提供反馈意见。

与项目发起人的初始会议

收到咨询邀请后，与项目发起人交流，了解项目背景、现状、团队、问题和目标。介绍教练思路，成功案例，建立共同愿景和合作伙伴关系。介绍调查阶段所要完成的事项，要求由项目发起人发起与主要干系人的启动会议。

项目发起人有两种情况，一种是对项目拥有完全的权力，而更常见的是项目发起人只是众多干系人中较重要的一个。需要了解清楚项目发起人的影响范围，以及教练和咨询的范围，和需要影响的其他干系人。

教练是在既定的范围，既定的管理制度和既定的规则之下工作，但也保持对相关人员发挥影响力和改变规则的灵活性。

与主要干系人的启动会议

主要干系人包括部门经理、项目经理、产品负责人、Scrum Master、开发 Lead、测试 Lead、架构师和设计师等。搞清楚每个人及其角色，建立第一印象，彼此认识，也是启动会议的主要内容。

启动会议的主要目的是建立 “咨询合约” 和教练关系。咨询合约更多是一种心理契约，其两个支柱之一是主要干系人与教练的开放连接与信任，之二是咨询的 PDCA 循环方法。教练与团队是共同进退的关系。

启动会议还需落实后续安排，即本阶段所要做的事，如一对一交流等。

如果团队较小，启动会议也可包含全体团队成员。如团队较大，在第一阶段的交流暂不包含全体团队成员。盲目追求交流的全面覆盖，反而容易迷失在信息的海洋里，也无法把握每个人的诉求和想法。

与主要干系人的一对一交流

深入了解每个人和每个角色看到的现状、问题和目标。不同角度多方拼图和印证，了解和把握真正的问题。

在与干系人一对一交流之前，需要把从项目发起人哪里了解到的信息先梳理一下。梳理的结构可以是：

• 基本现状：项目、团队、背景等；
• 基本问题：人员、技术、流程、管理等；
• 基本目标：项目管理治理、效率、质量等；
• 涉及到的角色：产品管理、业务分析、项目管理、技术 Lead、测试 Lead 等；
• 调查方法：即本阶段所用的调查方式。

访谈的思路可以采用 GROW 模型：

• Goal：目标是什么？
• Reality：现状是什么？
• Opportunity：其中有什么机会？
• Way：从现状达到目标的方法和途径是什么？

而对于某一具体问题的澄清可以保持小学生的心态，采用 5W2H 思路：

• Who：涉及到的人和角色有哪些？
• What：是什么情况或问题？
• When：事件相关的时间是？
• Where：事件涉及到的地点？
• Why：事件发生的原因是什么？
• How：事件是如何发生的？
• How Frequently：事件发生的频次如何？

交流是结构化与创意的组合，不能为了结构化而结构化。当很多想法自然涌现时，也就不需要框架和结构了。

参与和观察团队已有的会议

现场现物，现场了解团队现有的工作方式。尊重现实，尝试了解现有工作方式的来源历史和背后原因，了解所涉及的各种内外人员背后的系统动力。

在没有深刻的理解和共识的方案之前，不急于改变现状。在参与会议之前，确保团队了解教练参与的目的，而不造成负面干扰。教练第一次出现在团队面前时，需要由主要干系人做个引荐介绍。

其他了解问题的渠道

方案制定与沟通

在充分了解问题和分析问题之后，制定敏捷实施方案，例如采用 Scrum 或 Kanban 等，本文介绍的方案是基于 Scrum。方案包含两部分，一是在启动第一个迭代前所要做的事。二是第一个迭代的启动计划。启动计划会包含在第二阶段的介绍中。

在启动第一个迭代前所要做的事是为 Scrum 的实施铺平道路，可能有：

• 如果产品列表和用户故事的管理不能达到启动第一个迭代的条件，需要与产品负责人一起工作，打磨产品列表和用户故事，使之达到准备好的状态；

• 如果团队规模和技能配备妨碍了团队自组织和跨职能工作，需要先解决这部分问题；

• 如果 Scrum Master 对敏捷和 Scrum 的知识不够，需要先补足这部分知识。

在方案实施前，需要向干系人和团队沟通清楚，获得反馈，对方案进行调整。教练要以被教练对象的日程为日程，方案的实施要考虑不要对项目进度有负面冲击。

---

案例中的问题识别与方案制定

案例中的问题与观察

（1）团队与角色
　　1. 团队太大，超过 15 人，共同负责类似功能的新旧两个产品，且又没有坐在一起，会议和日常沟通不畅；
　　2. 人员技能备份不够，有些技能只有少数人掌握，成为瓶颈。团队中有新人不熟悉系统。测试人员相对不足；
　　3. PO 带的团队太多，没有足够的时间投入；
　　4. ScrumMaster 也是临时的；
　　5. 团队成员精神面貌和氛围好。具有良好工作方法的潜力和基础；
　　6. 管理者支持团队的敏捷实施。但变化的范围主要是在团队层面。

（2）物件
1. 需求来源杂乱，没有很一致的管理方法。存在需求插入和没有经过产品负责人直接给团队成员分配工作；
2. 用户故事没有在计划会前准备好，甚至是在计划会时头脑风暴和创建用户故事。用户故事没有清晰的边界和验收标准。用户故事在迭代中会发生范围蔓延；
3. 没有站会任务板。无法知道每日进展趋势；
4. 没有清晰的产品愿景和产品路线图。

（3）会议与流程
1. 会议没有清晰的目的和流程，没有焦点，人员沮丧疲惫，会议效率低。迟到现象严重，会议中团队成员缺乏专注。站会在三分钟之内都很难开始，人员总是不齐。会议中人员站位散漫不聚焦；
2. 从迭代整体看，没有很好的可预测性和承诺靠谱度，迭代结束时，还有不少未完成事项；
3. 没有产品列表精化会议。计划会时技术方案不具备。估算和承诺不靠谱；
4. 回顾会基本荒废；
5. 迭代评审被压缩到计划会中；
6. 计划会重点是工作分配。且没有系统化的方法。没有聚焦在会议本应的目的和流程。

（4）产出与目标
1. 迭代计划完成率不高，只有 60~70%。延迟交付突出；
2. 需求理解不清晰，造成返工和质量问题；
3. 客户反馈处理速度不能适应市场推广的需要；
4. 目标是加快反馈处理，提升效率和质量。

图 3：布朗运动式的站会

案例中的方案

（1）团队与角色　

• 缩小团队规模，按产品将团队分为两个 Scrum 团队，一个负责新产品，一个负责旧产品，相对独立运作。Tech Lead 和 QA Lead 需要参加两边的 Scrum 会议，他们充当缓冲器，平衡两组的工作不平衡。
• 其他团队成员尽量固定在一个团队，只有当一边团队工作出现紧急峰值时才做一些临时调拨。这个调拨需要在迭代计划会上确定，而不是在迭代中间；
• 根据 Scrum 指南，理清三个角色的职责边界。产品负责人负责产品与客户相关事项，输出合格的产品列表和用户故事，团队负责技术事项，包括技术障碍和风险的管理，ScrumMaster 协调与团队内外沟通协作事项。
• 回归本质，各个角色专注于本应的职责，而不是什么都管，又什么都不专注；
• 建立跨职能的工作模式，在能力许可的情况下，打破职责边界，例如开发也可以做测试的工作。体现在迭代计划的工作认领中；
• 制定人员备份计划和结对工作计划。先从开发人员内部的技能备份做起，然后扩展到开发和测试人员之间的技能备份；
• 辅导产品负责人的敏捷产品管理。包括用户故事写作，产品列表管理，产品愿景和路线图的建立，产品列表梳理等；
• 辅导 ScrumMaster 的 Scrum 运作；
• 辅导非专职人员如架构和 UI 设计人员在 Scrum 中的运作；
• 建立高绩效和高标准的文化。主要是在第五阶段的探讨。

（2）物件

• 按 INVEST 原则书写用户故事，用户故事要有清晰的验收标准。用户故事和产品列表在计划会前完全准备好；
• 建立和沟通产品愿景和路线图；
• 建立可视化的团队任务板。

（3）会议与流程

• 按 Scrum 指南重塑五个会议，每个会议有专属的目的和流程；
• 在业务梳理之外，增加技术梳理，确保在计划会之前有技术方案，以便计划会能产生靠谱的承诺；
• 制定故障处理流程。确保故障处理中合适的人以合适的顺序参与；
• 经过第一阶段，获得了对现状、问题和目标的基本清晰的认识，和各方一致同意的方案。

阶段二：实施与反馈阶段二的定义

这一阶段的目标有两个。

• 一是为首次 Scrum 的导入做准备，主要包括对产品负责人的指导，和合格的产品列表和用户故事的输出。

• 二是进行敏捷和 Scrum 工作方式的首次导入，并获得团队的反馈。对于已经使用 Scrum 的团队，是一种重新导入。

已经使用 Scrum 的团队，有可能受制于团队已有模式的影响，只是在形式上采用了 Scrum，而丢掉了本质和核心的东西，重新导入需要以正确的敏捷修正受到侵蚀的敏捷。

阶段二的做法及案例中的方案实施与反馈

迭代前的准备

第一是基本角色就位。

这个问题需要逐步解决。在案例中存在产品负责人投入的时间不够的问题。

经过与产品负责人交流，确定该产品是他负责的重点产品，采取的措施是把他负责的其他产品逐步移交给他人，以及让团队中的测试人员部分协助书写用户故事等。

案例中 ScrumMaster 是临时代理，且只有很少时间投入，解决方案是由敏捷教练指导一位团队成员充当 ScrumMaster。

第二是对产品负责人的指导和输出合格的产品列表和用户故事。

帮助产品负责人了解敏捷产品管理。经过与产品负责人的多次指导交流，输出了合格的产品列表和用户故事，达到了按 Scrum 指南运作迭代的标准。在此之前，团队的运作按之前的模式。

第三是如果有条件的话，可以做一个全体团队成员参与的一到两天的启动仪式：

• 与 Scrum 建立连接：探讨已有工作方法中好的地方，不好的地方，建立改善的愿望，把 Scrum 当作好的工作方法的载体，建立良好使用 Scrum 的决心；
• 介绍精益敏捷、Scrum 和用户故事的核心和实践；
• 让团队成员深入了解彼此，制定团队的价值观和团队规范；
• 刷新产品愿景、路线图、发布计划和产品列表。

如果不能进行一到两天的启动仪式，则可以在每个 Scrum 仪式前分别用 10 分钟左右时间介绍该仪式及相关物件：

• 在产品列表精化会前介绍产品列表精化的目的和流程；
• 在迭代计划会前介绍计划的目的和流程，及每日站会；
• 在迭代评审前介绍评审会议及回顾会议的目的和流程。
• 在每个会议的介绍之后，协助该会议的进行。对于会议中偏离目的与流程的行为，进行指导。指导可以以在每个会议结束时发表评论的方式进行，可以在会后进行个别谈话，也可以拿到回顾会议讨论。

我们实际中采用的是后一种做法，即把对 Scrum 的介绍分解到各个会议中。

迭代实施

迭代实施是以 Scrum 指南为指导，重塑五个会议，为每个会议建立清晰的目的和流程。

五个会议的核心目的摘要如下：

• 产品列表精化会：一方面是个爬坡的活动，为迭代计划和执行做好充分准备；另一方面为发布规划和产品规划做好准备；
• 迭代计划会：做出可执行的计划和一个靠谱的承诺；
• 每日站会：团队围绕迭代目标进行同步，共同管理趋势和风险；
• 迭代评审会：检查本迭代的工作是否达到目标，演示产品并获得反馈；了解来自市场和用户信息更新；预测发布和产品计划的调整，及下一迭代的内容。是产品学习会；
• 迭代回顾会：团队共同就人与流程方面进行改善；同时增进人与人之间的连接。是工作方法学习会；

Scrum 这个小小的框架提供了敏捷产品管理和项目管理的轨道，同时也部分涉及到了组织管理。

图 4：近忧远虑的迭代计划与产品列表精化

上图是全面理解 Scrum 的双轨两耳模型。

在 Scrum 中其实存在两条轨道，一条是远虑的发布和产品轨，一条是近忧的迭代轨。团队对远虑和近忧两个方面都要关注，才能既有方向感也有执行力。同时我们可以虚拟出助跑团队或产品探索团队，开发团队或产品交付团队。这两个虚拟团队的成员大部分是重合的。

• 第一个团队中可能会包含一些离客户和业务更近的干系人。
• 第二个团队中可能会包含一些并不直接参与开发工作的技术专家。

助跑团队的职责是把产品列表和用户故事打磨到准备好的状态，以便开发团队在迭代开始后能全速前进。迭代的左耳朵即入口标准是 DoR（Definition of Ready，准备好的定义），右耳朵即出口标准是 DoD（Definition of Done，完成的定义）。

在具体的实施中，我们采用了以下方法。

A1 大白纸计划法

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

贴出一张 A1 大白纸；

• 左边第一列是故事，由产品负责人用同一种颜色的便利贴书写和表达。字要大，用白板笔写，保证不用站得很近也能看清楚。故障，新特性或任何要交付的事情统称故事；
• 故事右边，用另一种颜色的便利贴列出任务。任务是为完成故事所要做的事，由团队书写。可以写上任务的执行人与估算。任务、估算、执行人可以用不同颜色，以方便辨识。任务从左到右大致按执行的顺序排列；
• 整个会议，一次围绕一个焦点，即当前讨论的故事。以故事为单位流动起来；
• 产品负责人的注意事项：清晰讲述。随着会议的焦点流动，把故事讲得让团队明白；
• ScrumMaster 的注意事项：适度引导。控制焦点与流动，一个故事充分讨论完并分解成任务，再进行下一个。保持紧凑的节奏和整体时间盒；
• 团队注意事项：主动参与。一是对故事不清楚的主动提问，二是主动参与任务分解、估算、认领；
• 全部故事讨论完和分解成任务后，统计每人工作量，看工作量与容量是否平衡，个人之间工作是否能置换以达到每个人的工作相对均衡。
• 对于初级团队，需要在计划会上把任务落实到每个人，这样才容易做出靠谱的承诺。随着团队成熟，则除了第一二天的工作，其他工作可在站会上滚动领取；
• 最后是团队决定是否能对迭代计划和目标承诺。

图 5：A1 大白纸计划法

故事泳道 x 人矩阵

在白板 To Do 列中，按故事带任务两级呈现，故事从上到下反映优先级，任务从左到右反映大致的先后顺序。To Do 列其实就是计划会输出的 A1 大白纸。迭代计划会和每日站会无缝对接；

在 Doing 列中，从左到右按人排列。形成故事 x 人矩阵；

每日站会进行的顺序是按故事泳道，故事驱动。按故事泳道，团队成员自动走上去，拉动纸条，向团队同步在相关任务上完成了什么、打算完成什么、有什么障碍和风险；

讲完一个故事的所有任务，再讲下一个故事；

会议在同一时刻只有一个焦点，即当前正在更新的故事和任务。我们可以想象有一个无形的鼠标在移动。一次一个人说话，讨论和对话都围绕着当前这个焦点，有交互的即时自发进行。大家都看着正在讲话的人，不要看手机或其他与站会无关的事，不要两个人私聊与当前焦点无关的任务；

在同一个故事上有哪些人在合作，每个人是否多任务（三个或以上任务），整体上待办、进行中和完成的比例也一目了然。再加上如果任务的切分向一人天的颗粒度靠拢，那么任务完成的数量即可代表迭代完成的趋势。

图 6：故事泳道 X 人矩阵

实践证明，上述两个方法对团队效率提升贡献最大，也广受团队欢迎。

隔离同步与深入讨论

关于这一点，我们最初制定的规则是，站会上的重点是同步，不做深入讨论，深入讨论挪到会后单独进行。

后来根据团队的实际运作，又做了如下调整：

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

随机一分钟项目经理

在每日站会最后，以随机方法产生一分钟项目经理。例如用股指个位数；

• 一分钟项目经理做五点说明；
• 我们的迭代目标是什么；
• 趋势是什么，是否可控；
• 主要风险和障碍是什么，如何管理；
• 团队士气如何。
• 邀请全体团队成员对完成迭代目标的信心点赞，以创造一个再次思考风险的契机。并宣布散会。

随机一分钟项目经理，有的团队能很好地接受和实施，有的团队则接纳程度不是很好。我们需要知道每一方法背后的目的，为了这一目的可以寻求其他方法。另外，一种方法不被接受，也许不是方法不好，只是时机不对。也可在时机具备时再次推出。

引入产品探索和精化 , 建立产品探索与产品交付概念

Scrum 的工作方式，从逻辑上可划分为产品探索和产品交付，在上面的双轨两耳模型中已有所介绍。

当用户故事的数量达到一定程度，用一维的产品列表管理就会捉襟见肘。我们需要增加一些维度。而用户故事地图就是这样一个多维产品列表管理工具。

下图是我们使用的示例，在其中至少有三个维度。水平方向是逻辑组维度。逻辑组可以是不同的功能组，可以是业务流程的不同步骤，可以是用户使用的先后顺序等。要找到一种逻辑，把需求分组。

垂直方向的第一种维度是层级，我们可以采用 Theme Group, Theme, Epic, Story 四个层级。

Theme，Epic，Story 这些术语的使用并没有一定的标准，我们的使用方法是，Theme Group, Theme, Epic 和 Story 四个层次是依次包含的关系，以适应我们的产品管理需要。

垂直方向的第二个维度是版本线。在垂直方向上对用户故事排优先级，结合估算，结合发布周期，画出版本线。

图 7：产品探索和精化

分离业务精化和技术精化

这一点的提出主要是因为在计划会上往往会因为技术方案不具备而难以给出靠谱的估算和靠谱的承诺，使得计划会进行得很艰难。

如果把方案的制定放在计划会，计划会会变得非常漫长而低效。如果与业务精化会一起进行，则使得精化会的目的不够专注，同样效率不高。我们的做法是增加一个技术精化活动。

精化会分两次，第一次是迭代第二周的周一下午，主要讲业务，并识别出需要制定技术方案的用户故事，大致确定 solution owner。周二和周三大家分头制定技术方案。周四为第二次精化会，即技术精化会，汇总和敲定技术方案。

以下是一个具体的时间表：

图 8：分离业务精化和技术精化

建立和沟通产品愿景和路线图

产品负责人提炼出产品愿景，并沟通给大家。

按用户故事地图的骨架，以 Theme Group, Theme, Epic 和 Story 四个层次梳理和展示产品路线图。在首次创建和有更新时，利用精化会中的一小段时间，把产品路线图沟通给团队。

以 Epic 和 Story 为归一化的语言统摄需求，和连接从业务到技术的所有人员，方便沟通。

准备好和完成的定义

为每一会议和活动制定准备好和完成的定义，即活动之前应具备什么状态，活动之后应达到什么状态。

获得反馈

在第一迭代进行到中间的时候，即可以开始了解团队对工作方式变化的反馈，因为这时工作方式的效果已经能发生了。

了解反馈的目的是对工作方式进行修正。在第一迭代中间了解反馈还有一个好处是，鼓励团队把反馈和问题带到回顾会议讨论。

内建团队的问题发现和解决能力是敏捷实施的重要目标，为了达到这一目标，敏捷教练要有意压制自己对观察到的问题的表达，而是把团队推到前面，帮助团队成长。

获得反馈的途径包括一对一交流和回顾会议。

反馈的内容包括，新方法的导入节奏团队是否能接受，新方法中团队喜欢什么，不喜欢什么。

在这个六阶段的教练过程中，跟主要干系人的一对一交流和跟团队成员的一对一交流呈交替分布，奇数阶段主要访谈干系人，偶数阶段主要访谈团队成员。这种安排，一方面是由于教练的时间有限，另一方面也是减少对大家的打扰。

这种交替分布，也保证了交流的覆盖率。每个阶段的交流对象，也是由阶段的重点和交流的主题决定的。只是各个阶段连贯起来看，刚好呈现一深一浅一张一弛一表一里一呼一应的形态。

根据团队反馈，调整工作方式。对于敏捷的价值观和原则，需要坚持。坚持并不是坚持一种特定的做法，而是在价值观和原则的范畴内，尝试和打磨出团队喜欢的具体做法。也就是在具体做法上，并不固执坚持特定的做法。

比如说随机一分钟项目经理活动，根据团队成员的意见，没有坚持下去。在不违背原则的前提下，要充分尊重团队的意见。假以时日，好东西是会被认可的。

这一轮的一对一反馈收集，也是了解每个团队成员的机会。团队成员中会有热情的、中立的、消极的。只要对新工作方式不抵制的，就无需特别处理。而事实上，这种情况还没有出现过。

通常来说，我们认为一个人不可理喻，是因为我们没有耐心。而对于积极的人员，他们会贡献一些不一样的视角，帮你拓展思路，补充细节。而做加法，是良性沟通的核心。

经过第二阶段，团队初步体会了完整的正确的敏捷，并为工作方式的变化提供了反馈，以帮助后续工作方式的调节。

通常来说，经过一个迭代按正确 Scrum 的运转，团队对更加清晰透明的工作方式会有正面反馈，迭代的完成率等结果指标也会有明显提升。在本案例中，经过一个迭代的实施，迭代目标的完成率即有 20% 左右的提升，且团队成员普遍对新工作方式表示欢迎。

阶段三：解决问题第三阶段的定义

在这一阶段和后续阶段持续要做的事是，继续观察团队的 Scrum 仪式，发现其中违背正确敏捷实践的行为，以及发现团队工作中涌现出的好的模式。

对于观察到的结果，可以在当时即每个仪式结束时现场提出来，可以在个别谈话中进行，也可以留到回顾会议。

依然是两个原则：只要不是影响团队运作的瑕疵，尽量延迟到回顾会议进行讨论；培养团队的问题解决能力重于问题解决本身。

问题发现可以来自观察和交流。这种观察、交流、思考、反馈和调整会延续到整个教练周期，并且以打造按正确敏捷运作、具有自我改善能力的自组织团队为目标。

第三阶段的做法

在这个阶段，除了观察、思考、反馈和调整之外，可以设定另一主题，那就是痛点与问题解决。具体的方式采用一对一谈话。谈话的对象包含产品负责人、Scrum Master、团队 Lead 和其他对工作方式有热情的人。

整个教练计划可以公开给团队，可以发起一对一交流，也鼓励团队成员来发起一对一交流。

这一轮交流的三个主题是：

• 进一步获得他们对工作方式变化的反馈；

• 探询他们的痛点和希望解决的问题；

同时提供对他们本身的反馈。反馈可以来自教练，也可以来自他人。在没有建立起团队成员彼此之间真诚反馈的渠道之前，教练可以充当反馈的桥梁。反馈是一种重要的学习方法。

这种交流是一种一对一回顾，其目的、边界和框架如下：

• 一对一回顾是对团队回顾的鼓励和驯化。是为了帮助打磨团队回顾。是为团队回顾做铺垫、预热和准备；
• 一对一回顾是对团队回顾的补充。即使团队回顾已经搞得很好了，也还需要一对一回顾。一对一回顾可以非正式地制度化，使得掌握情况的方式更立体；
• 一对一回顾可以由 Scrum Master 发起，也可以由任何人向任何人发起。鼓励任何人发起的反思与改进；
• 一对一回顾的目的，是加强人与人之间的连接，传递改善的信念，以及计划和执行改善活动；
• 一对一回顾的边界，是围绕改善的基调，就与团队项目工作相关的事进行讨论；
• 一对一回顾的框架，可以包含探询交流对象对工作方式的反馈、探询痛点和关注的问题，和以 Scrum 实践和角色要求为基准、以观察到的行为为依据向交流对象提供的反馈。还可以包含不同团队之间的经验传递、知识桥梁和最佳实践延展。

如果希望痛点和问题的探询更封闭一点，可以分解为几个角度：就团队项目工作的上下文而言，您的目标和期望的理想状态是什么？与现状的差距是什么？流程上有什么问题，或有什么妨碍理想状态的达到？团队合作方面呢？团队工作绩效和质量呢？任何其他方面？

这个框架的运用要灵活。人的主动参与重于规则。如果人能主动参与改善事项的发掘、计划和行动，框架就可以放下；

• Scrum Master 日常有力的观察是回顾会议的重要输入；

• 敏捷教练的准则，也是各个角色的普适标准：专业、尊重、坚持。了解每个角色的专业角度，尊重每个人，坚持目标与原则；

• 改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。

问题的识别还可采用检查工具，这里介绍两个工具，一个是 Mike Cohn 的敏捷成熟度模型，一个是 Spotify 的敏捷健康度检查。敏捷健康度或成熟度模型的使用，可以每季度或每月拿出一次回顾会议，大家采用类似估算纸牌的形式对其中的每个问题进行评估。

评估本身不是要点，不要纠结于评估和分数本身。评估主要是发现大家对同一问题评估的差异，引发讨论，进一步提出改善建议。

具体可参看：敏捷成熟度健康度模型

案例中第三阶段的问题解决

这一阶段获得的偏流程和管理类问题及解决方案有：

会议效率问题：这个是团队普遍关心的问题。经过两个迭代的实施，会议已经进行的比较规范化，但会议的效率包括纪律还不够完美。

解决之道是在 Scrum 框架之下继续打磨提升，细致地进行会议每个环节的提升，包括会前准备、会中引导、会后跟踪。

比如说在精化会前大家可以先熟悉一下故事，在评审会前需做好演示的准备。在会议中引导促进大家的互动。逐步从靠规则引导过度到建立团队共识；

三个角色的职责问题：这个问题的解决原则是，产品负责人负责与客户和产品有关的问题，Scrum Master 负责与沟通协调有关的问题，团队负责与技术相关的问题。但还要在实践中操练；

提升团队的参与度和对完整故事的关注：这个问题的解决是依托 Scrum 框架做一些操练。通过提升透明性，在计划会和站会上更加清晰透明地呈现工作来提升团队的参与度，通过设置故事 owner 提升和训练对完整故事的关注。

故事 owner 需要端对端负责起跟交付有关的沟通协调包括联测的驱动；

测试积压在迭代后半段：需要团队共创解决方法，比如说，一个原则是，开发优先做需要测试的任务。还可以设置开发任务的检查点。开发与测试结对工作；

团队建设，心理安全与归属感问题：需要与管理者和团队讨论处理。建立产品团队的形态与心态。把定期的庆祝和团队建设活动建立起来；

各种会议的准备好：为了把技术方案在计划会前准备好，增加技术精化会，且在业务精化会时针对需要制定技术方案的用户故事，指定 solution owner。

业务精化会前的准备好包括：产品负责人把资料准备好，放在一处，会议时不再需要到处找资料，团队成员在会前把要梳理的故事浏览一遍，熟悉下上下文，有个印象。

在迭代评审会前的准备好：准备好演示环境和演示要点，演示时按验收标准有序进行。

这些问题大致分布在流程与效率、角色职责、团队感和业务学习方面。

对于收到的问题的解决思路有：

• 按敏捷框架中的原则和实践解决；
• 拿到回顾会议上，由团队讨论解决；
• 对于深层次的组织问题，第一步是清晰的呈现问题，第二步是与有影响力的人交谈；

鼓励学习其他团队的 Scrum 运作。建议 PO 和 ScrumMaster 分别与运作成熟团队的 PO 和 ScrumMaster 交流。

偏技术类问题和解决方案有：

• 建立了制度化的代码和测试用例评审；
• 建立了制度化的单元测试；
• 建立了有计划的结对编程和结对工作；
• 建立了持续集成；
• 优化了发布流程。

在这个阶段，对于团队的 Scrum 仪式，依然会讲授、协助和指导。更多的是以团队为中心的立体双向反馈，了解团队的痛点和问题，并协助解决。

经过这一阶段，团队的敏捷运作已经达到了有意识的状态，会议的目标能够达到，效率有很大提升，虽然还不能完全自运转，但已经会发生一些有意识的提升和改变。另一方面，对于团队的问题也有了更深入的了解，为下一阶段的系统化的改善打下基础。这一阶段是对 Scrum 实施的巩固和优化。

团队的持续改善和学习，提升了迭代目标的完成率，加强了团队的跨职能能力，打破了职责的边界，不同的开发角色之间可以互相备份，甚至开发也可以做测试的工作。

总结这一阶段的思路是：

• 从对团队的观察中发现问题；
• 与主要干系人交流，了解他们的反馈和看到的问题；
• 与干系人和其他相关人员一道解决问题；
• 以 Scrum 框架为指导解决问题；
• 在回顾会议上与团队一道解决问题。

阶段四：共识培养第四阶段的定义

前三个阶段主要涉及产品管理和项目管理的流程方面，新工作方法的实施效果立竿见影。但要产生深入持久的效果和自我优化能力，必然涉及到人和组织管理的方面。第四阶段共识培养主要落实到团队层面，而后面的第五阶段的深层问题解决则涉及到组织管理方面，为 Scrum 方式的持续实施和优化打下广阔坚实的基础。

第四阶段的做法

主要是一对一交流和回顾会议。

一对一交流

一对一交流的目的是探讨共识合作的理念，和为新的回顾会议做铺垫。以前几阶段收集到的遗留问题做引子，与团队成员一对一交流，鼓吹团队共同做决定和共同解决问题的机制，听取他们的想法。介绍将会使用的卓越驱动的回顾会议框架。获得团队成员在回顾会议上积极参与的承诺。

回顾会议

回顾会的一种流程

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

关于感谢的环节，在所有的团队中都受到了欢迎，并能持续执行。而改善的环节，在不同团队中则呈现出差异，主要跟团队已有模式的好坏程度有关。

回顾会议能否持续有效进行，是衡量 Scrum 模式是否成功的重要象征。Scrum 改善力量的来源是团队的持续回顾和改善。如果回顾会议不能坚持下去，可能是对 Scrum 模式不理解，可能是提的改善建议没有真正落实，需要针对各种情况，分析原因，从原因入手解决。

卓越驱动的系统改善

卓越驱动的系统改善即是：

• 团队定义一组卓越指标，即团队认为对于提升团队工作方式最有价值的东西；
• 对于卓越指标，利用每一次回顾会议，进行评估和改善；
• 以这一套卓越指标驱动系统化的改善。

卓越指标示例：

• 卓越指标 1. 跨职能团队
  定义：不要让技能不平衡成为障碍。

  • 子条目：
    • 定义人与技能矩阵，以及理想的技能配置。在理想情况下，每一所需的技能最好有至少两个人精通和一个人了解。找出现状矩阵与理想矩阵的差距；
    • 在迭代工作中，在团队容量容许的情况下，有意识地安排结对工作，以传播技能。结对工作所造成的团队速率下降以不超过 10% 为宜。

• 卓越指标 2. 价值流优化
  定义：移除障碍，让团队所有的努力都指向对客户价值的贡献。

  • 子条目：
    • 制定 DoR （Definition or Ready）准备好的定义，形成高质量的迭代入口；
    • 制定 DoD（Definition of Done）完成的定义，形成高质量的迭代出口；
    • 每迭代的故事分为承诺的故事和可选的故事，可选的故事可以在产品列表精化会或迭代计划会上产生；
    • 识别和移除障碍，帮助工作更好地流动；
    • 会议议程有清晰的结构，每一议程精确到十分钟的颗粒度。

• 卓越指标 3. 团队工作
  定义：团队协作，以最大化团队产出。

  • 子条目：
    • 定期知识分享；
    • 经常庆祝成功；
    • 集体代码所有；
    • 交叉演示工作，例如 Tom 可以演示 Jerry 的工作。
    • 卓越指标的制定，要由团队一起完成。具体可采用团队会议与一对一交流相结合的形式。

这个卓越驱动的系统改善提供了一个结构，充当了一个面。日常点的观察，与卓越驱动的回顾会议的面的结合，让改善更深入地发生。

实际运作中是把感谢加改善的流程和卓越驱动的改善系统叠加起来使用。卓越指标在回顾会议中充当了一个改善的预分类，让大家在提想法时有一个方向和轨道。而当大家本来就有很多想法时，则不需要使用这个卓越指标系统。

案例中培养共识的回顾会议

图 9：卓越驱动的回顾会议

把卓越指标打印张贴起来，作为大家提改善建议的分类模板使用。

Scrum 有科学的一面，也有人文的一面。科学的一面体现在 PDCA 循环和透明的原则等。人文的一面则体现在人的参与、协商、改善等。人文的一面的驱动力量，更多在第五阶段探讨。

除了会议框架和流程之外，我们增加了议事流程：

• 针对当前的话题，每人讲述自己的观察、感受、想法、建议，不打哈哈，也不反驳他人的想法。主持人记录主要观点；
• 第二轮，听了大家的第一轮发言，每人有什么新的想法，或者对其他人第一轮的发言有什么不同意见；
• 第三轮，梳理归类提炼产生大家真正会执行的 action。
• 这次会议主要制定了发布流程的优化，更多结对工作的计划，和落实了一个 team building 的计划。
• 经过回顾会议前一对一的心理建设，和回顾会议上的引导，大家能够真诚开放地做交流。

通过 Scrum 会议的优化、扎实的计划、良好的团队工作、和持续的回顾改善，团队的迭代承诺越来越靠谱，持续稳定地提升，这为市场推广奠定了坚实的基础。这是业务方面的提升。

同时通过结对编程和结对工作、知识分享等，就算在人员请假时工作也能很好地持续。这是在团队成长方面的提升。更重要的是，培养了共识的机制和意识。

阶段五：深度问题解决第五阶段的定义

经过前面几个阶段，团队的 Scrum 运作得比较好了，也建立了改善系统和一定的改善能力，解决问题的意识也建立起来了。

在这一阶段所要解决的，可能是一些深层次的问题，例如：团队中存在层级结构，或者团队成员来自不同的部门，让团队无法真正自组织，产生高质量的互动。

第五阶段的做法

一个团队和组织要想得到深度提升，首先要认可高绩效的文化。一个团队只有认可高绩效的追求，改善才谈得上。这是改善的逻辑起点。

其次是领导力问题。如果技术和业务是同一条汇报线，这个问题相对简单。如果一个 Scrum 团队向上有多条汇报线，怎样让各方产生一致的合力，就是一个需要解决的问题。

第三是员工满意度问题。有了满意的员工，才会有主动的改善发生。

具体做法是就以上话题与干系人和团队成员交流。可以先进行一对一交流，再以会议的形式讨论。

案例中的深度问题解决

首先做一点说明，关于这一阶段的事情，主要是跟团队和干系人做了一些探讨，因为背后涉及到组织的管理制度，还没有很深度的实施。

具体就高绩效文化、联合领导力和员工满意度这几方面跟产品负责人、技术经理、架构师、ScrumMaster 等做了交流。主要话题包括：

1. 对高绩效团队的共识：业务成果，成长的团队；
2. 联合领导力：业务技术等各角色间更好的合力；
3. 业务目标的合理制定与有效沟通；
4. 产品负责人在与其他团队的技术依赖中如何发挥影响力；
5. 技术提升探讨；
6. 业务提升探讨；
7. 个人发展个人兴趣与项目需要的平衡探讨；
8. 绩效管理探讨如 OKR；
9. 员工满意度探讨；
10. 相关讨论的后续交流机制细化：定期 / 事件驱动。

根据行为科学的 B=MAT 公式，B 是行为，由 M 动机、A 能力和 T 触发器决定。

经过前面几个阶段的训练，团队已经具备了运作 Scrum 的能力，而 Scrum 中的各个物件、角色和仪式本身就充当了触发器，所以要想有更深度的提升，动机是着力点。

员工满意度和个人绩效管理是动机的两个重要方面，在这两方面都有一些事情可以做。

关于绩效管理，可以参考一下 Valve 公司（维尔福软件公司）的做法：

每一个项目 / 产品小组都要为自己的组员进行评估。（我们不会让员工对自己进行评估，因此将小组拆散成几个小部分，每一个小部分的人对除自己之外的其他人进行评估。）这一评估分为以下四项指标：

• 技能等级 / 技术能力

你所解决的那类问题有多难，又多有价值？你遇到的问题有多重要？你对解决某一种难度问题是否有独一无二的本领（公司范围内？行业范围内？），例如绘画、设计、写作或者音乐等等？

• 产量 / 输出

你输出过多少可行的、有价值的、完成度高的产品（不一定要发售）？海量的加班加点与你的产量无关，恰恰相反，这倒是与效率低下挂上了钩。我们更鼓励你在保持工作与生活的平衡的基础上，充分利用办公室的时间来完成工作，而不是被时间牵着鼻子走。

• 小组贡献度

你对项目进展、招聘、团结队友、优化工作流程或者为别人编写工具方面的东西有多少？往往当你在为小组做贡献时，要与你自己的个人贡献度做出权衡。站出来扮演带头人的角色会为你的小组贡献度加分。不过成为头儿不一定会提高你的综合评价。因为这个角色谁都会时不时去扮演一下。

• 产品贡献度

你在你的核心能力以外的贡献如何？你的工作对产品有多重要？你对纠正工作优先度有多少影响？有多少资源能和别人交换？你能预测客户对我们正在做出的决定会有何反响吗？在游戏发售前做一个合格的测试者或者挑出很多 Bug 都属于产品贡献度范畴。

凭借这些指标和基于它们的综合评价，公司会明确给出 “这就是你的价值” 的评价。这些指标给你为公司做贡献提供了多种方式。

跟相关人员交流的主要的输出体现在这张平衡计分卡当中。

图 10：平衡记分卡示例

这张平衡计分卡主要回答一个问题：团队怎样才算成功？其评估结果可以用来度量团队绩效，但不会被用来度量个人绩效。更重要的作用是充当一个深层改善的驱动器。

在表格中，我们主要设计了三类指标：

• 第一类是跟产品和业务相关的：

  • 利润，按季度统计。对于独立的产品，这个指标相对容易统计。而如果团队的工作只是产品中的一环，这个指标相对难以确定；
  • 每季度的利润增长；
  • 用户使用情况，包括每一功能的使用次数和停留时间；
  • 每月用户使用情况的增长；
  • 从销售人员那里获得的反馈；
  • 用户净推荐值 NPS（Net Promotion Score）。通过用户调查，了解用户愿意在多大程度上把产品推荐给其他用户，0 为最低分，10 为最高分。计算方法是 9 分和 9 分以上的人数减去 6 分和 6 分以下的人数，再除以反馈的总人数；
  • 价值点 Value Point。这个考虑应用在 Epic 层面，类似故事点，给每个 Epic 分配一个价值点。价值点是价值度量，故事点是成本度量。从某种程度上说，这些都是代理指标。

• 第二类是跟流程和效率相关的：

  • 生产率，用故事点表示。故事点有一定的主观性，但在软件当中，很难有一个完全客观的生产力指标；
  • 质量，即上线之后的故障率；
  • 价值流优化，即障碍管理的情况，也是由团队评估的一个偏主观的指标；
  • 敏捷健康度检查，参考上文相关资料。

• 第三类是跟团队和领导力相关的：

  • 联合领导力，即各个角色之间的合力。一些可能的具体问题是：将 OKR 思想用于产品管理，帮助大家更好地理解产品的目标和全景；产品负责人在跨团队技术依赖管理当中从业务优先级角度的影响力；产品负责人与团队之间更清晰的迭代目标沟通；共识驱动的做决定方式；

  • 员工敬业度和满意度；

  • 团队的职业发展和晋升；

  • 跨职能团队；

  • 团队工作；

  • 个人技术能力提升规划；

  • 个人业务技能提升规划。

针对每一指标，可以制定三个目标：

• 保守的目标；
• 承诺的目标；
• 激进的目标。

每一指标还可制定一个权重。定期收集和评估指标。

这张平衡记分卡后续会尝试使用和打磨，以此来度量团队的成功，并持续优化。这背后需要驱动组织管理的变革。

总结一下上述活动中的主要思路：

1.深入的敏捷运作一定会从项目管理和产品管理拓展到组织管理；
2.高绩效文化是深入改善的逻辑起点；
3.联合领导力是高绩效文化的第一种支撑；
技术与产品的合作。技术帮助产品负责人理解与用户故事非直接相关的技术工作的价值，并统一安排在产品列表中；开发与测试的合作问题，包括自动化测试的分工原则，和开发与测试的跨职能等。
4.综合的员工满意度和动机是第二个支撑；

跟薪酬有关的。更合理的绩效管理，包括 360 度的使用；

跟个人发展有关的；

其他各种跟满意度相关的事项。

各干系人之间已经开始就联合领导力问题做一些探讨。部门经理也开始就员工满意度开始做一些一对一交流和在部门会议上的探讨。

阶段六：沉淀好模式第六阶段的定义

好的 Scrum 运作中有两种强化的力量，一种是不断回归敏捷价值观和 Scrum 方法论，以此获得强化。另一种是来自团队内部力量的自发深化。团队运行到一定阶段，会自发涌现出好模式。

这些好模式是对 Scrum 的深化、拓展和补充。方法用得好，方法与人可以相互裨益，即人可以为方法带来拓展，并有利于自己和他人的未来使用。

沉淀好模式，则是可视化团队涌现出的好模式，并固化推广。并使之持久化，和扩展到其他团队。

第六阶段的做法

ScrumMaster 是识别好模式的重要角色。ScrumMaster 要主动观察和思考，一旦发现了好模式，可以做出总结，以书面或口头的方式分享。可以在回顾会上探讨好模式。

案例中沉淀出好模式

团队中自发涌现出的好模式示例：

细颗粒度的协作

利用站会，促进细颗粒度协作。例如，一位团队成员拉动一个故事下的一个任务，同时询问另一团队成员是否能与他合作，另一团队成员表示同意，并拉动同一故事下的另一相关任务。两个任务服务于同一功能，但两位团队成员工作于不同的领域，一位是开发，一位是测试；

• 故事和任务拉动按优先级进行；
• 需要协作的任务，其所有者勇于发起协作请求；
• 被请求者以协作的任务先于本人可独立承担的任务进行；
• 在回顾会议中明确讨论该模式，并贯彻；

模式可以由任何一人发现。

Customer engagement & product idea 信息分享的制度化

• Customer Engagement 指的是以各种途径接洽客户并获得反馈，feed & feedback；

• Product Idea 指的是产品负责人在生成用户故事前的各种想法，可能是来自客户反馈，也可能是自己想出来的；

• 团队对这些信息不感兴趣可能是因为不懂，要以能懂的方式分享；

• 促进业务与技术之间的跨领域学习；

• 让团队了解除了开发工作之外的更广泛的公司运作；

• Customer Engagement 部分的分享可以安排在迭代评审的演示与反馈之后，可以考虑使用 10 分钟的时间盒；

• Product Idea 放在产品列表精化会的开头，可以考虑使用 10 分钟的时间盒；

• 把上面两点制度化到会议议程中；

• 要保证会议效率和整体会议长度不增加。

集体庆祝成功

• 在计划阶段，即以终为始，把成功设计出来，比如产品愿景和迭代目标；

• 计划的过程，要全员参与，愿景中有每个人的一份。全员参与，不是机械的全员参与，具体方法可变通。但要做到，让每个人都感觉自己是计划的一部分；

• 在执行过程中，各角色分享信息。比如产品负责人分享来自市场的信息；

• 各角色对其他角色信息的感兴趣这件事，可以磨合；

• 真诚透明是要点；

• 团队全体为了成功愿意付出额外的努力；

• 捕捉可以庆祝的时机；

• 这样当成功到来时，就不会冠盖满京华，斯人独憔悴；

• 以正式的仪式强化成功这种反馈，把庆祝成功这件事本身变成一种资产；

• 不忘初心，砥砺前行，向下一个成功前；

• 让成功成为一种习惯。

众筹式 Knowledge sharing

第一步，定周期。与迭代周期一致，每迭代一到两小时，同时与迭代本身的会议错落来。把时间固定下来比不固定下来好，形成一个轨道，更能保证期望的目标的发生；

第二步，收集话题。收集大家想发表的话题，和想听的话题。工具利用 yammer。ScrumMaster 推进和培养大家的粘性，设计收集话题的机制，包括收集的时机，固定时间提醒大家。话题内容不限，只要对大家有益；

第三步，对话题点赞。点赞之后自动形成话题的优先级和 Backlog。ScrumMaster 在形式上为大家服务，内容由大家决定；

第四步，计划分享。就是把高优先级话题安排到一个分享窗口，当然必须跟分享人落实好，让分享人是以充满热情而不是匆忙的方式分享。分享人可以提前发出分享材料，可以做个规定，比如提前 2~3 天；

第五步，激励分享者。给分享者一个有心思的小礼物，不要偏重物质本身。可以每期拍个照，积累下来就是一个相册，做成团队分享集锦 PPT 或其他展示形式。不只是激励当前的分享者，也是激励大家都来分享。同时也是打造团队。如何激励这件事，也可以交给团队讨论决定。

跨团队学习工作方式

鼓励新团队学习旧团队的工作方式。新旧指的是采用 Scrum 的后与先；

具体方式是鼓励新团队的 PO 和 Scrum Master 主动发起与旧团队 PO 和 ScrumMaster 的交流。教练与双方说好，剩下的事就是他们自己去安排了；

PO 交流的主题可以放在 Scrum 产品管理以及与团队的互动；

ScrumMaster 交流的主题可以放在 Scrum 仪式的运作、团队参与度、团队内外沟通协调，和持续改善上；

交流进行的方式可以放在对具体运作的描述上，越详细越好，也可以谈一下对工作方式变化的感受和洞见。感同身受，身临其境；

交流的基调是以开放的心态学习，排除掉任何对团队的比较和评价；

还可以观摩旧团队的会议。PO 可以重点观摩产品列表精化会，Scrum Master 可以重点观摩计划会，如果只选一个的话；

除了一对一交流，还可以建立实践社区（Community of Practice, 简称 CoP）。可以有产品负责人社区，ScrumMaster 社区，不同的技术人员和测试人员社区。

专职人员与浮动人员

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

浮动人员可以分不同的类别；

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

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

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

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

Plan B 的意识

对于容易出问题的情况，例如发布，要有 Plan B 即变通的方法；

对于其他团队成员报出的障碍，主动提供有价值的资讯。

成功的标准和度量

最后说一下成功的标准和度量：

（1）业务目标的提升达到，包括更高的客户满意度，更高的质量和更好的迭代完成率。案例中迭代计划完成率由６０％提升到９０％以上。赢得由十个客户做评委的产品展示大赛。做到每周发布，快速响应客户反馈。

（2）团队成长，技能提升，更好的合作。更高的团队满意度。团队对新工作方式充分认可。

（3）各方干系人的良好反馈，高度评价。

干系人反馈示例：

我觉得我们应该提名领导力奖。Glen 在这大半年给我们 team 带来了巨大的改变和提升，无数的新观念和新思想，我们能看到咱们团队的行为和产出也非常显著，相信我们团队所有成员这段时间也备受启发。

Glen 不是我们的 technical manager 或者 people manager，更加体现了卓越的 leadership。在我们 team 之外的更广大的范围，也有 Glen 的影响力。

Sharing a video created by team on incorporating design in our products.

This video depicts how all elements of product development can come together for a great outcome.

Agile, design, technology and user understanding have come together to make this squad effective.

Glen Wang, our agile coach, embedded himself in the squad, and would attend all calls with product management and customer engagement team to get a deeper understanding of the user and the business.

This helped him be more effective in coaching. This squad is one of my favorite examples of how a squad should ideally work.

敏捷涉及到几个方面：

敏捷管理与流程，主要是 Scrum；

敏捷技术，主要是 XP 和 DevOps；

敏捷文化和组织管理；

更全局的价值流优化。

本文探讨的主要是第一个方面，对于后三个方面，依然有很长的路要走。