Scrum Master：职位还是角色？-InfoQ

几个月前，我在一次本地敏捷用户组聚会上，加入了关于 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）和敏捷。他热爱过程改进，寻求更好、更快、代价更低的软件开发方式。他目前正热衷于敏捷环境中的管理方式。