摘要：众所周知，ScrumMaster 是服务型领导——其本身不参与日常的研发工作，写代码、改 Bug 的工作都让团队干了，Scrum Master 到底干了啥？ScrumMaster 工作的好坏应该如何衡量？

本文分享自华为云社区《Scrum Master们每天都在摸鱼么？》，作者：敏捷的小智 。

1、前言

众所周知，ScrumMaster 是服务型领导——其本身不参与日常的研发工作，写代码、改 Bug 的工作都让团队干了，Scrum Master 到底干了啥？ScrumMaster 工作的好坏应该如何衡量？

2、Scrum Master 的职责

衡量 ScrumMaster 工作的好坏，首先应该了解 Scrum Master 平时都干什么。

全职的 ScrumMaster 需要观察、辅导并引导团队按照 Scrum 框架进行日常的产品交付工作，作为 Scrum Master，往往有如下职责：

• 教练：Scrum Master 本身也是一种敏捷教练，需要观察团队的日常工作，并且对开发团队和产品负责人（Product Owner）进行辅导，确保整个团队能够按照 Scrum 流程开展各项活动。

• 服务型领导：Scrum Master 不同于职能经理或者项目经理，不会去命令团队做什么任务或者怎么做，也不掌握团队成员的“生杀大权”，Scrum Master 为 Scrum 团队提供服务，确保团队产品交付中的必要需求得到满足。

• 过程权威：Scrum Master 要确保团队理解敏捷的价值，同时确保团队在此基础上遵循 Scrum 的原则，帮助团队定义自己的敏捷流程并进行实践；并且在后续帮助团队持续改进，实现交付业务价值最大化。

•  “保护伞”：Scrum Master 应该保护团队免受外部干扰，让团队集中精力在价值交付上。比如：产品经理想在迭代中插入新的需求，Scrum Master 需要衡量需求是否应该插入，插入后哪些需求应该置换等等，而不是坐视不管。

• “清道夫”：Scrum Master 要帮助团队扫清交付过程中遇到的障碍，比如团队新的开发环境要一组集群，而团队本身对资源没有创建权限，可由 Scrum Master 拉通相关人员，进行集群的创建。

• “变革代言人”：Scrum Master 要积极推动敏捷，尽管这可能会很困难，但作为 Scrum Master 应该让团队乃至组织意识到转型的重要性和必要性，并需要让团队看到 Scrum 为团队带来的收益。

3、Scrum Master 日常工作的劣势

通过上文对 ScrumMaster 职责的描述，不难看出，Scrum Master 主要工作就是推动敏捷在团队中的进行，其本身不写代码，也不写项目所需的各种文档——没有什么输出。

看过足球的应该都知道，哪怕教练有能力、有权力，也很难保证带队出成绩，教练取得的成绩通常和球员分不开。再看看 Scrum Master，其本身是服务型领导——没权力，Scrum 的具体实践者是团队，所以要做到“指哪打哪”就更难了。

以上因素会导致 ScrumMaster 工作的好坏很难衡量，甚至会让人产生一种 ScrumMaster 每天啥也不干的错觉。那 Scrum Master 工作的好坏到底如何衡量呢？

4、如何衡量 Scrum Master 的价值

衡量 ScrumMaster 工作好坏的方法还是有的，虽然并不能衡量的那么准确，本文介绍的方法主要有三种：通过工具衡量、通过改善效果衡量、通过团队主观评价衡量

4.1 通过工具衡量

有句话叫：“度量什么，就一定会得到什么”，那为什么还要用工具去衡量？

其实这里说的并不是用一个工具去记录、管理 Scrum Master 的日常工作，所谓工具是指团队日常工作使用的各项工件，比如看板、用户故事、燃尽图等，通过团队对各项工具的使用情况，来侧面反映出 Scrum Master 对团队的辅导效果。

比如，正常情况下，Scrum Master 会主持团队的站立会议，会上团队成员互相分享项目进展及阻碍。往往在会议前或会议中，看板上的工作项会有价值流动，比如某些工作项进入开发、某些工作项进入测试、某些工作项进入评审等，工作项状态更新的同时，还会伴随着消耗工时的更新，以便于后续类似任务的估算。如果 Scrum Master 很好的引导团队，让团队严格按照 Scrum 流程来开展日常工作，那一个工作项往往会经历频繁的状态变更，以华为云DevCloud的工作项为例，工作项的操作历史中可以看到工作项状态、处理人以及工时等字段的变更，如下图：

而如果 Scrum 对平时的工作敷衍了事，或者很难推动团队践行 Scrum，工作项的价值流动往往会很有跳跃性，如下图：

再比如，ScrumMaster 需要去辅导产品负责人如何编写用户故事承载需求，并且按照价值优先级对需求进行排序，我们可以通过用户故事的好坏，比如是否满足三段式，故事粒度拆分是否合理等，来衡量 Scrum Master 的工作效果（华为云DevCloud专家服务平台提供了“用户故事 ”能力评估功能，可在线对用户故事编写水平进行自动评估，有兴趣的读者可以来评估一下）。

4.2 通过改善效果衡量

除了工具外，还可以通过团队交付情况来判断 Scrum Master 工作的好坏。这里说的交付情况不是指人均产出代码行、千行代码 Bug 率等指标，用这些指标衡量的话，往往还是之前提到的——“度量什么，就一定会得到什么”，起不到啥衡量作用。

敏捷的本质是通过迭代的方式，小步快跑同时对产品进行及时的调整，以提高产品研发效率和质量。所以笔者认为可以从用户故事交付周期、项目整体按时交付率、产品用户满意度等改善效果来从侧面衡量 Scrum Master 的工作的好坏。

敏捷转型初期可能很难看到明显的进展，在这个过程中 Scrum Master 要帮助团队发现问题，比如为什么项目上线后会有很多 Bug，什么原因造成的，后续应该如何改进，跟踪改进状况等。走过几个迭代后，如果 Scrum Master 对团队引导是有效的话，产品的用户满意度应该是有所提升的；同时各方面的交付周期也会逐渐缩短且有一个相对稳定的速率。

如果团队经历几个迭代，一直很挣扎——加班加点、项目按时上线后一直有一堆改不完的 Bug，那 ScrumMaster 的工作多半是失败的。

4.3 通过团队评价

Scrum Master 辅导过的团队通常会有很好的团队氛围，Scrum Master 辅导的如何可以通过访谈或者问卷的形式，让被辅导的团队评价 ScrumMaster 的工作，往往也会得到答案。

5、结尾

敏捷不是短期内就完成的工作，更不是银弹，敏捷转型是一个漫长且复杂的过程，在这个过程中，Scrum Master 需要观察团队，引导团队去实践敏捷方法，思考怎么解决实践中遇到的问题，最后总结经验。当一个团队趋于高度敏捷的状态，Scrum Master 的工作可能会轻松，否则 Scrum Master 要做的事情还是很多的。

点击关注，第一时间了解华为云新鲜技术~