摘要：众所周知，Scrum Master是服务型领导——其本身不参与日常的研发工作，写代码、改Bug的工作都让团队干了，Scrum Master到底干了啥？Scrum Master工作的好坏应该如何衡量？
本文分享自华为云社区《Scrum Master们每天都在摸鱼么？》，作者：敏捷的小智 。
前言
众所周知，Scrum Master是服务型领导——其本身不参与日常的研发工作，写代码、改Bug的工作都让团队干了，Scrum Master到底干了啥？Scrum Master工作的好坏应该如何衡量？
Scrum Master的职责
衡量Scrum Master工作的好坏，首先应该了解Scrum Master平时都干什么。
全职的Scrum Master需要观察、辅导并引导团队按照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 为团队带来的收益。
Scrum Master日常工作的劣势
通过上文对Scrum Master职责的描述，不难看出，Scrum Master主要工作就是推动敏捷在团队中的进行，其本身不写代码，也不写项目所需的各种文档——没有什么输出。
看过足球的应该都知道，哪怕教练有能力、有权力，也很难保证带队出成绩，教练取得的成绩通常和球员分不开。再看看Scrum Master，其本身是服务型领导——没权力，Scrum的具体实践者是团队，所以要做到“指哪打哪”就更难了。
以上因素会导致Scrum Master工作的好坏很难衡量，甚至会让人产生一种Scrum Master每天啥也不干的错觉。那Scrum Master工作的好坏到底如何衡量呢？
如何衡量Scrum Master的价值
衡量Scrum Master工作好坏的方法还是有的，虽然并不能衡量的那么准确，本文介绍的方法主要有三种：通过工具衡量、通过改善效果衡量、通过团队主观评价衡量、
通过工具衡量
有句话叫：“度量什么，就一定会得到什么”，那为什么还要用工具去衡量？
其实这里说的并不是用一个工具去记录、管理Scrum Master的日常工作，所谓工具是指团队日常工作使用的各项工件，比如看板、用户故事、燃尽图等，通过团队对各项工具的使用情况，来侧面反映出Scrum Master对团队的辅导效果。
比如，正常情况下，Scrum Master会主持团队的站立会议，会上团队成员互相分享项目进展及阻碍。往往在会议前或会议中，看板上的工作项会有价值流动，比如某些工作项进入开发、某些工作项进入测试、某些工作项进入评审等，工作项状态更新的同时，还会伴随着消耗工时的更新，以便于后续类似任务的估算。如果Scrum Master很好的引导团队，让团队严格按照Scrum流程来开展日常工作，那一个工作项往往会经历频繁的状态变更，以华为云 Dev Cloud 的工作项为例，工作项的操作历史中可以看到工作项状态、处理人以及工时等字段的变更，如下图：
而如果Scrum对平时的工作敷衍了事，或者很难推动团队践行Scrum，工作项的价值流动往往会很有跳跃性，如下图：
再比如，Scrum Master需要去辅导产品负责人如何编写用户故事承载需求，并且按照价值优先级对需求进行排序，我们可以通过用户故事的好坏，比如是否满足三段式，故事粒度拆分是否合理等，来衡量Scrum Master的工作效果（华为云 Dev Cloud 专家服务平台提供了“用户故事 ”能力评估功能，可在线对用户故事编写水平进行自动评估，有兴趣的读者可以来评估一下）。
通过改善效果衡量
除了工具外，还可以通过团队交付情况来判断Scrum Master工作的好坏。这里说的交付情况不是指人均产出代码行、千行代码Bug率等指标，用这些指标衡量的话，往往还是之前提到的——“度量什么，就一定会得到什么”，起不到啥衡量作用。
敏捷的本质是通过迭代的方式，小步快跑同时对产品进行及时的调整，以提高产品研发效率和质量。所以笔者认为可以从用户故事交付周期、项目整体按时交付率、产品用户满意度等改善效果来从侧面衡量Scrum Master的工作的好坏。
敏捷转型初期可能很难看到明显的进展，在这个过程中Scrum Master要帮助团队发现问题，比如为什么项目上线后会有很多Bug，什么原因造成的，后续应该如何改进，跟踪改进状况等。走过几个迭代后，如果Scrum Master对团队引导是有效的话，产品的用户满意度应该是有所提升的；同时各方面的交付周期也会逐渐缩短且有一个相对稳定的速率。
如果团队经历几个迭代，一直很挣扎——加班加点、项目按时上线后一直有一堆改不完的Bug，那Scrum Master的工作多半是失败的。
通过团队评价
Scrum Master辅导过的团队通常会有很好的团队氛围，Scrum Master辅导的如何可以通过访谈或者问卷的形式，让被辅导的团队评价Scrum Master的工作，往往也会得到答案。
结尾
敏捷不是短期内就完成的工作，更不是银弹，敏捷转型是一个漫长且复杂的过程，在这个过程中，Scrum Master需要观察团队，引导团队去实践敏捷方法，思考怎么解决实践中遇到的问题，最后总结经验。当一个团队趋于高度敏捷的状态，Scrum Master的工作可能会轻松，否则Scrum Master要做的事情还是很多的。