ScrumMaster的教练职责

ScrumMaster是Scrum团队的敏捷教练。Ken Rubin说,“类似于运动团队的教练,ScrumMaster观察团队使用Scrum的过程,帮助团队提高工作绩效”。教练不是顾问,不提供解决问题的方案,而是支持Scrum团队自己去发现属于自己的最适合的答案。教练犹如一面镜子,反映Scrum团队的真实现状和局限,同时引发团队看到更多的可能性,鼓励团队尝试变革,不断提高。


ScrumMaster指导团队的日常活动


ScrumMaster指导团队的时候都干啥呢?我们把ScrumMaster指导团队的日常活动概括为如下这五个方面:留意、反馈、引导、教育、和支持。


1. 留意

好的ScrumMaster要眼观六路,耳听八方,注意观察团队的工作方式,仔细思考他们为什么会这样做,想想有哪些诱因。例如,刚导入Scrum的团队经常会出现这样的问题,开发团队不及时更新看板上的任务状态,在站会上说某个任务已经完成了,但看板上的任务状态还是To-Be。如果留意开发团队的工作环境,就会发现团队使用软件工具(例如JIRA)实现看板的功能,开发者需要登录到这个系统上,才能看到看板的状态。不像物理看板,一直竖在开发团队的座位旁。平时这个Scrum管理工具没人去看,也就没人记得要去更新它。简单的说,是可视化出了问题。


2. 反馈

注意观察是第一步,看到问题以后要反馈,这是第二步。ScrumMaster要把自己观察到的情况反馈给团队,帮助他们利用这些反馈改进工作方式。继续上面的例子中谈到的问题,应该怎么改进呢?引用一个案例。在开会前,ScrumMaster Linda请开发者Jack登录到这个软件系统中,在他的计算机上把团队的开发任务的状态显示出来,请大家在这台计算机前围成一个半圆,让大家都看到当前的状态。然后说:“昨天站会,我听到这个任务已经完成,但看板上它的状态还是To-Be。”那几个没有及时更新看板状态的开发者就说:“我马上更新。”上过导入Scrum的培训课以后,开发者知道怎样做是正确的,教练不用批评或指责,只需要告诉团队自己看到的现象,团队就知道该怎样改正了。这就是反馈的作用。


3. 引导

ScrumMaster需要促进有建设性的沟通和协作,帮助团队走向敏捷。《敏捷教练》这本书里有很多关于教练怎样引导会议的案例。这里引用其中一个。有一次在规划会议中,项目经理颇为沮丧地对开发团队说道:“别扯了!我只是想拿到这些故事的数字而已。”项目经理给团队造成一种错觉,以为规划会议就是完成项目管理的工件。他没有抓住要点,召开规划会议的目的是弄明白要做什么,而这必须得先搞清楚它需要多长时间。团队不可能在讨论清楚需要做的事情前就“给故事弄个数字”,而这种讨论往往会涉及软件设计方面的交流。会后,敏捷教练跟项目经理分享了观察到的情况,项目经理很高兴敏捷教练指出了问题。随后那次会议,设计议程的时候,项目经理就预留出时间来进行技术讨论。


4. 教育

ScrumMaster要想方设法鼓励团队学习敏捷,方法包括演示Scrum中的一些实践;分享其他团队使用Scrum的经验;还可以开设培训课程。例如,在一个团队刚刚导入Scrum的时候,可以给全团队做一次集中培训,讲解Scrum价值观,原则和各个实践,演示怎样使用Kanban,怎样用估算扑克估算用户故事点,并分享其他团队的案例供大家参考学习。在运用Scrum的过程中,如果遇到什么特殊情况,也应该开设一些有针对性的专题培训,例如代码重构。还可以在组建了微信敏捷讨论组,分享一些敏捷相关的资讯,提高大家对敏捷的认知水平。


5. 支持

当团队遇到困难时,要鼓励他们,帮助他们保持动力。讲个案例。Amy是一位敏捷教练,他指导的开发团队中有一个小伙子叫David。有一段时期,开站会的时候,轮到David发言,David一直低着头抠他的手指头,说话声音也非常小,几乎听不见。Amy心里纳闷儿:“David以前并不这样,最近这是怎么了?”后来Amy约David在一起吃中饭,并告诉他,自己注意到他抠手指头、说话声音很小。David打开话匣子,说了他的迷茫:继续干下去没动力,换岗或离职又不知道要到哪里去。David问了Amy几个问题,Amy回答了David,帮助David了解到一些信息,包括他当前所从事的技术领域在组织内的重要性,和在行业中的领先地位;其他岗位的工作内容和挑战;离职的补偿政策和风险。Amy又引导David重新认识自己,看到自己的强项,鼓励他在当前这个技术领域坚持下去。最后David说:“我明白了,我要留下来,干出成绩。我该早些找你谈谈的。谢谢你Amy!”


ScrumMaster和开发团队之间的关系


ScrumMaster培养团队,提升团队自身的产出能力,提升团队成员的自我判断能力,帮助团队成员顺利度过从不敏捷到敏捷这个转型的困难时期,让他们走上自己的敏捷之路,最终找到自己的路。在处理ScrumMaster和开发团队的关系时,有两个误区要小心。


第一、ScrumMaster不要越俎代庖


例如,开发团队做单元测试不到位,这在很多组织都是个老大难问题。怎么办?ScrumMaster撸起袖子自己上,秒变tester?不要这样做。这样做会导致开发团队以为ScrumMaster就是负责测试的,自己不必测试,这样的想法反而会导致发布质量下降。再讲一个案例。Amanda是一位擅长测试技术和工具的敏捷教练。她找开发团队聊天“为啥不做测试呢?”开发团队说:“手工测试花时间太多。”Amanda就推荐一个测试工具给他们,有人说这工具不好用,Amanda就坐在开发团队旁边给他们演示怎样使用。Amanda运行了一个例子,告诉开发团队只要把例子换成他们产品需要测试的模块就行了。开发团队一看,原来这么简单啊!Amanda早上花了30分钟给开发团队演示,这个开发团队下午就把第一份自动化测试报告发出来了。后来这个团队坚持自动化测试,一直到产品开发结束。


ScrumMaster的职责是培养团队,提升团队自身的产出能力。这就好比,排球比赛,教练能上场替队员打球吗?郎平带的球队也输过球,你什么时候见过郎平把主攻手换下来,自己上场扣球呢?培养团队,功夫在场外,要演示,要辅导,要答疑,就是不要替做他该做的工作。


第二、ScrumMaster不要监控惩罚


还说开发团队做单元测试的问题。有的ScrumMaster是这样做的,设立测试覆盖率KPI,目标值100%,不达标就扣考核的绩效分数。开始开发团队还抱怨,后来被管理层强力压下去了。谁也不敢再抱怨。但口服心不服啊!管理层要看覆盖率100%是吧?开发者用Excel手工填一张覆盖率100%的报告,和工具自动生成的一模一样。开里程碑会议的时候,微笑着告诉经理“我们的覆盖率达到了目标值。”心里说:“一个星期几十个项目结束,我不信你有精力查下去。”ScrumMaster这样处理和开发团队的关系,对开发团队、对产品都没有好处。


ScrumMaster和产品负责人之间的关系


ScrumMaster和产品负责人之间的关系,既是互相制衡的,又是互补的。


先讲制衡。产品负责人的目标是产品,ScrumMaster的目标是培养团队,两个角色的目的不同。雄心勃勃的产品负责人开发产品追求多、快、好、省,难免要对开发团队举起小皮鞭,催促开发团队加班赶工。ScrumMaster要保护团队,使团队可持续发展,要做产品负责人和开发团队之间的润滑剂。产品负责人和ScrumMaster这两个角色设计的初衷就是为了彼此制衡,所以不推荐让一个人兼任ScrumMaster和产品负责人这两个角色。


再讲互补。产品负责人主要负责“目标”--开发正确的产品,ScrumMaster主要负责“方式”--使用正确的方式来实施Scrum,通过使用Scrum帮助产品负责人取得最大的业务成果。只有使用正确的方式来创建正确的产品,才能取得持久的成功。把眼光放长远,优秀的产品背后必须有一直优秀的开发团队。所以,产品负责人和ScrumMaster又是互补的。


以上我用严肃的语言一本正经的讲ScrumMaster的第一个职责:敏捷教练。下面咱们也灌点儿心灵鸡汤,讲点励志故事。我的少年时代,是在学习中国女排拼搏精神的氛围中度过的。在我们那一代人里,没有人不知道郎平。郎平退役后,成为一名职业教练,把美国女排带到奥运亚军,成就了美国女排的奖牌梦,美国女排也成就了郎平作为女排教练的世界知名度。也正是因为郎平执教女排的光辉战绩,中国体委才会邀请郎平回国执教。这才有了当年的“众望所归”。与运动教练类似,优秀的ScrumMaster和优秀产品负责人、优秀的开发团队三者之间互相成就。与之相反,中国某体育运动项目,几十年来,教练换了二十几任,球队就是不出成绩。有网友调侃说:此运动项目的教练可以划分为两种状态:已经下课的,和等着下课的。


小结

ScrumMaster的第一项职责是Scrum团队的敏捷教练。ScrumMaster通过留意、反馈、引导、教育、和支持,帮助团队驾驭敏捷,开发出色的软件。ScrumMaster培养开发团队。ScrumMaster与产品负责人之间既相互制衡,又互补。

你可能感兴趣的:(Scrum敏捷知识,ScrumMaster,敏捷教练)