Scrum Master们,难道每天都在摸鱼?

作者: 向倚

更新时间:2022-03-26 14:35:29

4381 阅读

摘要:众所周知,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流程来开展日常工作,那一个工作项往往会经历频繁的状态变更,以Cloud 的工作项为例,工作项的操作历史中可以看到工作项状态、处理人以及工时等字段的变更,如下图:

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

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

通过改善效果衡量

除了工具外,还可以通过团队交付情况来判断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要做的事情还是很多的。

 

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

版权声明:本文著作权归作者【向倚 】所有,不代表本网站立场。

侵权请联系:root_email@163.com