敏捷转型几年了，在开始的喧嚣过后，怎么持续让团队有质的提升？ ——研发经理小A
我的大部分时间都花在开各种会了，一天打 9 小时杂，下班时都不记得自己做了什么。 ——研发主管某乙
做Scrum Master 一段时间了，看外面的 Scrum Master 的职位越来越少，我怎么给自己更多的挑战和成长？ ——Scrum Master 小凉
NO.0 去领导，而不是去管理
上面这些困惑在 Scrum Master 和 管理人员中很常见。要解决这些困惑，首先要找准自己的定位：管理只是我们的表面工作，我们的真实身份是一名领导者。
当你一天到晚被事情追着跑，每天约定俗成的做同样的事情时，你就是体制内的管理者；而领导者主动出击，做该做的事，而不是做被告知要做的事。
管理者维护现有系统的运行；领导者演化出新系统。——那个谁
所以领导就是领导持续的变革。具体怎么做呢？今天就说说我实践并总结的一个框架。
为业务价值负责
识别并反思“开发价值流图”
让价值流动
培育团队的心智模式
制造拉动，营造不舒适圈
NO.1 为业务价值负责
首先你自己要为业务价值负责，不管你是什么职位。
现实中大家不会陌生下面的分工：
Scrum Master 的责任是：保证团队在 Scrum 框架下持续交付。
Dev 的责任是：开发出产品经理给的需求。
QA 的责任是：确保系统的质量在一定水准之上。
产品经理的责任是：这个需求很简单，怎么实现我不管。
大家为不同的价值负责，结果就是容易各种撕。
要领导变革，首先要有个共同的目标，为此要识别团队的共同价值，比如
团队的最终价值是：提升业务的运营效率和客户的满意度。
业务价值是唯一的，意味着大家的最终目标是唯一的。它就是团队的北极星。它让我们每个人每天的工作，都有个明确的指向性。
NO.2 识别并反思“开发价值流图”
“开发价值流图”指的是开发团队为了交付业务价值涉及到的所有活动。
因为我的工作和团队的工作最终都指向业务价值，我们就可以对价值流进行分析和反思：
哪些活动是无用的？
哪些活动是缺失的或者不到位的？
哪些活动的顺序是不对的？
举个例子
比如我曾经一个团队的价值流图，以及我的反思，是这样的：
| 步骤 | 反思/问题 |
|---|---|
| 1. 主 PO 分配项目给团队 | 为什么要等待 PO 分配，而不是我们去挖掘用户的痛点？ |
| 2. BA 做细节的业务分析 | 有没有一个一致的方法去衡量业务价值的大小？ |
| 3. BA 写出 User Story 并跟开发说明 | 怎么确保开发理解了 Story 后面的业务需求？ |
| 4. 开始开发 | 为什么很大的 User Story 没有被拆分？ |
| 5. 开发完毕后QA开始测试 | 自测有没有做？单元测试覆盖率如何？ |
| 6. 开发完毕后 code review | 大的 User Story 少则一周，多则几周。开发完毕后的 code review 面对大量的代码，很费劲。 |
| 7. 根据code review 的结果重构甚至修改 | 有时候需要修改的代码太多，怕影响进度就放弃了，于是留下技术债。 |
| 8. 重构之后 QA 重新测试 | 手动测试反复，费时 |
| 9. 最终发布 | 发布后缺乏对实际产生的业务价值的验证。 |
如上，用精益的眼光去看这个价值流图，它可被改进的空间是非常大的。它让我们有了端到端的全局思维，不再头痛医头脚痛医脚。
顺便说一下：Scrum 是术，精益是道。我认为所有人都应该学习精益。
NO.3 识别系统性瓶颈，让价值流动
识别了价值流，我们的工作就很直接了：让价值流动起来。为此需要不断地识别系统性的瓶颈，并演进“开发价值流图”。
我们都知道 Scrum Master 的一个职责是“移除障碍”，但是，如果不去识别某障碍背后的系统性瓶颈的话，同样的障碍会反复出现。
举个例子
上面说的一个问题，Code Review 费力不讨好，一些代码改起来吧 QA 要重新测试，影响进度；不改吧技术债越来越多。
很多团队都对这个问题感同身受，那怎么办？可以问自己几个问题：
为什么 Story 不拆小一点，拆到 3 天即可完成，这样 一次 Code Review 的代码量就小，要改的话改起来也快。
进一步，就算 Story 要做 3 天或 10 天，为什么不每天 Code Review？
再进一步，既然 Code Review 这么重要，为什么要每天才做？不能每分钟都做吗？（结对编程）
Code Review 出来的问题，有没有去分析和分类？比如，是没有遵循代码规范？还是经常 Review 出 bug？
如果是没有遵循代码规范，是代码规范过时了？还是缺乏工具去静态扫描代码？还是程序员的技能有问题？
如果经常有 bug，是程序员对需求理解有问题？还是缺乏单元测试的覆盖率？
如果是单元测试覆盖率不够，是不是团队对 Story 的各种业务场景理解得不完整？
如果团队对各种业务场景理解得不完整，为什么不在开发前（而不是之后）就把场景列清楚？
这个列表还可以一直问下去。我们看到，一个 Code Review 的问题，非常可能是价值流图里出了系统性的问题，解决问题的第一步就是识别根本性的问题。
NO.4 培育团队的心智模式
前面三步是我的心智模式，或者我“构建”的系统结构。
这些心智模式和系统结构一定不要留在自己的心里，要让它在团队中慢慢生长。
心智模式就是“你相信什么”，所以它会影响团队的行为模式；行为模式就是“遇见什么情况时会默认采取什么样的行为”，它就是团队的文化。
举个例子
代码写好了，QA可以开始测了，是关于测试的心智模式和价值观。
再举一些心智模式的例子：
User Story 是需求，还是方案？
Requirement 和 Need 有什么区别？
小批量和大批量，哪个更节约成本？
软件研发是可以分工的吗？
显然，人们对这些问题的答案越一致，意味着人们的心智模式越一致，他们就越像个团队，而不是团伙。
NO.5 制造拉动，营造不舒适圈
团队的心智模式不应该是静态的，它需要行动和实践的反哺。也就是说，虽然心智模式会影响行为模式，但是往往是先有行动的改变，才会有新的心智模式的形成。
所以，我经常需要做的事情是，设计一个小的实践，微调这个虚拟的系统，让它去拉动更多的实践，去帮助培育和固化团队的心智模式和文化。
说人话，就是“持续改进”。
举个例子
针对手工测试时间长 bug 多这个问题，我们曾经设计了一个小实践：Dev 完成一个 User Story 的开发后，在交给 QA 测试之前，Demo 给 PO 看。
这个实践对很多开发是很不舒适的，他们习惯了写完代码扔给 QA 去测，有 bug 再修。
我们可以看这个实践如何拉动更多的实践：
为了要 Demo （实践一），他们需要做足够的自测（实践二）
自测很烦，就引导他们做更多的单元测试（实践三）
单元测试写起来费劲，就需要把代码写得更可测，SOLID 原则得学起来（实践四）
单元测试的场景覆盖率不够，就得把业务规则的场景先弄清楚，这就可以来个 Spec by Example（实践五）
你都 Spec by Example了，不顺便来个 BDD 吗？（实践六）
当然，这些实践的设计，以及拉动，都需要结合团队的情况，没有标准的套路。
NO.6 留白
以上其实是我对一朋友 Tony 的访谈实录，听下来我觉得他说的有点道理，所以结束的时候我问 Tony：你一研究发型的总监怎么说得这么好？
Tony 微微一笑：哪里哪里，我这是站在三位巨人的肩膀上。
- 一是精益思想
- 二是系统思考
- 三是冰山模型
说完飘然而去，云深不知处。
文档信息
- 本文作者：蔡建斌
- 本文链接：https://johncai.github.io/2020/04/16/save-scrum-master/
- 版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）