写点什么

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

发布于: 7 小时前

摘要:众所周知,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 要做的事情还是很多的。


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

发布于: 7 小时前阅读数: 3
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
Scrum Master们,难道每天都在摸鱼