BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Scrum Master:职位还是角色?

| 作者 Brian Lawrence 关注 0 他的粉丝 ,译者 徐涵 关注 3 他的粉丝 发布于 2014年1月31日. 估计阅读时间: 8 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

几个月前,我在一次本地敏捷用户组聚会上,加入了关于Scrum Master的同行交流。我在会上的发言造成了一些小骚动,我问的第一个问题是“各位所在公司采用全职Scrum Master的有多少?”出席的公司代表们表示,他们都有全职Scrum Master。于是我接着问了第二个问题“他们做些什么工作?”也许我的提问方式已经暗示了雇佣全职Scrum Master比较奇怪,因为当时我在现场经历了几次鸦雀无声的片刻。除了我的同事,其他大部分人都奇怪地看着我,好像我有三只脑袋一样。最终,他们还是迁就了显然没有好好学习的我,用《Scrum指南》里关于Scrum Master的描述来回答我。当我说我们已经用不着全职Scrum Master时,他们都震惊了。其实我还没说,我们从来就没有用过全职Scrum Master。

《Scrum指南》对Scrum Master的角色做了一般性的描述:负责指导、训练、指引和消除障碍。对刚出道的Scrum团队,这些事情要耗费一些时间。还不熟悉Scrum的团队要通过书本来学习Scrum,需要有一个人来负责指导、训练、指引和消除障碍等工作。可是,交付团队成长起来之后呢?指导减少,训练减少,尽管仍然需要在持续改进方面加以训练。指引还是必需的,不过这只占用很少的时间。随着团队学会了自己处理障碍,障碍也会减少。如果某个团队成员的全职工作是负责指导、训练、指引和消除障碍,而所有这些工作的工作量只占用他们10%到25%的时间的话,那他们多余的时间干什么呢?

所以,我们是这样操作的。我们也从Scrum起步,但并没有严格照搬书本。我们的项目经理同时负责好几个项目,所以要与多个项目团队协作。我们首先对项目经理进行敏捷培训。他们中有些参加的是高阶课程,有几个甚至拿到了Scrum Master和PMI的Agile Project Managers认证。于是,这些项目经理成了我们第一批Scrum Master。因为资源有限(我们的项目经理还没有团队数量多),或许也是有点先见之明,我们没有立即让Scrum Master去负责单个团队。没错,我们从一开始就违反了Scrum原则。一般来说,每个项目经理负责两个团队,他们承担着Scrum Master的角色。所以他们很忙,但是还能应付。正如大家能想象到的,他们的职责就是对团队进行Scrum指导训练、指引Scrum仪式并消除障碍。在前九个月甚至一年内,我们一直都是这样运作的。

很幸运,在这种运作方式之下,我们的Scrum团队成长起来了。当我在与员工的一对一谈话中不断被问到项目经理(注意,他们没被称呼为Scrum Master)在团队中的作用时,我意识到,我们将项目经理作为Scrum Master的做法开始出问题了。交付团队成员觉得他们被不同的人过度管理了。他们已经有自己的职能经理(functional manager)了,现在又多一个Scrum Master,而且后者不是交付团队中的成员。

因此,我们在架构上做了一些改动。我们允许各个交付团队在内部选择自己的Scrum Master。这个Scrum Master仍然作为全职的交付团队成员,不过他同时还要负责指引Scrum仪式,并在出现障碍时作为第一联络人。那项目经理怎么安排呢?首先,他们还是项目经理,负责一些项目管理工作,譬如进行跨团队协作等。不过他们还被委以敏捷教练的职责。这样一来,敏捷训练不再是我们强加给交付团队的任务,而是成为一种应要求提供的支援。这样效果还不错。那些在敏捷方法和思想上已经成熟的团队,不再有被过度管理的感觉;而那些仍处于成长中的团队,他们也有人可以请教。

在我们继续成长的道路上,还有一个小小的转变。我们把项目经理(Project Manager)提升为程序经理(Program Manager)。所以,他们现在要负责跨团队协作的行动,比如那些跨产品以及涉及多个交付团队的项目。我们还在管理汇报上做了调整,我们把“职能经理/上级”改为“交付团队经理/上级”。后者我们称之为交付经理(delivery manager)。另外,现在是由交付经理来负责敏捷训练与指导了。我们现在仍然这么做,尽管想法古怪,但团队一直交付正常,所以似乎效果还不错。

对我们来说,Scrum Masters刚开始是个职位,然后随着我们在敏捷上的成长,演变成为一个角色。我们将Scrum Master的职责分成两个部分,一是训练与指导,另一个是指引与消除障碍。让团队进行自我管理,允许他们可持续成长,这样运作很有效,因为训练不再是强加给他们的任务,而是应要求提供的支援。而且,很多团队采用轮流担任Scrum Master角色的办法,这有利于让更多团队成员体验这个角色。此外,我们发现,交付团队里的所有成员都可以担任Scrum Master。比如,我们的业务分析师、开发人员、QA测试都当过Scrum Master。我们还发现,Scrum Master还时常在交付团队内部兼任着敏捷训练与指导的角色,因为那些有兴趣担负Scrum Master角色的人,往往也对学习敏捷原则感兴趣,他们愿意在团队里分享学习所得。

最后,让管理层高兴的最重要一点是,用较少的人完成同样的工作量。我们有16个交付团队。不采用专职Scrum Master,让我们腾出了16个人及其相关预算。正是这样,我们才得以拥有16个交付团队,而不是13个,我们需要这些多余的人员去填充真正有意义的角色。

实际上,我这篇文章是想提醒正在走向敏捷的各位。如果你雇佣一大把全职Scrum Master(就像圣路易斯这里一样),你需要有一个应对方案,以便在交付团队成熟以后知道该怎么做。至少在这里,大部分受雇的Scrum Master具有项目管理背景。这没什么错,但正如我一再提到的,要准备好回答“现在如何安置这些曾经作为Scrum Master的项目经理呢?”这个问题。

关于作者

Brian Lawrence目前是密苏里州圣路易斯TriZetto Provider Solutions公司IT总监,他负责若干敏捷和看板产品开发团队与应用架构。自爱德华·尤登(Edward Yourdan)时代起,他就醉心于流程。他在职业生涯中,曾对开发组织进行过若干方法论改革,包括统一软件开发过程(RUP)、精炼统一过程(EssUP)和敏捷。他热爱过程改进,寻求更好、更快、代价更低的软件开发方式。他目前正热衷于敏捷环境中的管理方式。

原文英文链接:Scrum Master: Position or Role?


感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

程序经理(Program Manager)----应该翻译成项目集经理 by Xiaochuan Zhou

程序经理(Program Manager)----应该翻译成项目集经理。。。。。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT