官方《Scrum指南》中定义：Scrum Master在Scrum团队中属于服务型领导，负责践行和支持《Scrum指南》中定义的Scrum，要帮团队的每个人理解Scrum理论、实践、规则以及价值观。

最近我们进行了一次调查，其中92％的受访者表示他们正在实践的scrum是按需定制的，而非"按章办事"。这让我们想知道，这对扮演训练和帮助团队理解scrum角色的scrum master来说意味着什么？ 这些scrum master是如何适应不断发展的且有别于官方规定实践的敏捷世界的？

为了回答这些问题，我们对敏捷行业的无名英雄——scrum master的角色和责任进行了深入研究。

Scrum Master是什么？

Scrum Master是scrum的推动者。scrum是一种轻量级敏捷框架，专注于实现固定时间的迭代，也被称为sprint。作为推动者，scrum master充当团队其他成员的教练，在《Scrum指南》中被称为"服务型领导"。优秀的scrum master致力于构建scrum的基础和价值观，同时保持一定的灵活性和开放性让团队有机会改进工作流程。

1.Scrum Master的职责

在理想的敏捷世界中，团队可以管理自己的流程和工具。然而，我们发现许多团队通常需要依赖scrum master作为其流程的主导者才能实现敏捷的飞跃。要实现对团队的掌控，并履行职责，scrum master需要花费大量的时间。在这种变革性的背景下，scrum master的工作可以很轻松，如仅安排scrum相关仪式；也可以很繁重，像团队的其他成员一样深度参与整个过程。尽管《Scrum指南》列出了scrum master应该如何为其他角色提供服务，但关于scrum master的责任义务并没有详细列出来。事实上，我们发现，scrum master通常需要执行下面部分或全部并没有在scrum中定义的工作：

1. 站会——根据需要促成每日站会（或每日scrum会）。

2. 迭代/sprint规划会——确保团队不会承担过多或超出能力范围。帮助团队进行估算及子任务的创建。

3. sprint评审会——参加会议并记录反馈。

4. 回顾会议——记录需要改进的领域和后续sprint的行动项目。

5.委员会管理——承担Scrum委员会的管理工作。并且保证信息的即时性及Scrum工具（Worktile或其他工具）运行良好。

6.一对一谈话——根据需要与团队成员和利益相关者单独谈话。化解团队对在流程和工作方式等方面的分歧。然而许多scrum从业者都反对一对一谈话，因为他们认为这些交流应该在每日站会上进行，一些团队，特别是新团队，更倾向于请scrum master与个别团队成员定期进行面对面交流。scrum master则认为这些单独的交流互动对于团队发展和成员之间的彼此了解至关重要。

7.内部协商——scrum master应该与团队成员和内部利益相关者进行协商，就如何更好地与Scrum团队合作达成一致。

8.报告——定期分析燃尽图和其他投资组合规划工具，以了解团队正以什么样的节奏构建产品。

9.护航者——scrum master通过消除外部障碍和改进过程或工作流管理内部障碍等方式为团队提供支持。

10.代劳杂务——如果scrum团队没有处于忙碌的状态，那就是scrum master的问题。因为这意味着团队可能在修理坏掉的电脑、挪动周围的桌子甚至调整恒温器。Scrum master应该随时准备好做任何可以帮助团队的事。如果团队真的需要的话，scrum master甚至需要为成员准备咖啡和零食，以确保成员不需要在此类杂事上浪费时间或趁机磨洋工。

2.你的团队是否需要一个scrum master？

任何一个scrum培训师都会告诉你，每个scrum团队都应该有一个scrum master。如果没有，那么你们的scrum就算不上真正的scrum，经常被叫做scrum-but。

在团队刚开始尝试scrum的时候，有一个具备scrum工作经验的scrum master可以带来很大的帮助曾，当然，曾经见证过很多scrum成功案例者更佳。也正因为这个原因，很多scrum master经常被聘用来担任顾问，而非全职员工。

但每个scrum团队都是独一无二的。很多经验丰富的团队承担前面列出的所有关于scrum master的责任，享受由团队成员共同管理的流程并为此感到自豪。这种情况下，scrum master的角色将由团队成员轮流承担，并轮流组织召开每日站会和回顾会议。

而对于一些团队来说，正确的做法就是请一个专业人员来担任scrum master。

不幸的是，由于对scrum master角色存在误解，所以经常导致现任管理者认为scrum master是他们岗位职责的一部分。为了更好的理解为什么这样做会造成问题，以及为什么要在组织中单独设立scrum master的角色，我们将scrum master的角色与组织中现存的非scrum角色来做一个对比。

Scrum Master和产品经理

正如我们在《敏捷产品管理概述》中提倡的那样，产品经理与开发团队之间的互动越多越好。这种互动应该与产品负责人的想法保持一致：支持客户需求且清楚为什么开发这款产品。但如果这种互动模糊了任务-即团队该怎么实现功能，那就说明互动存在问题。尽管出发点很好，但这种利用型心态会导致问题被隐藏或掩盖，如：缺陷、交接和未知问题等。交错范围和进程很容易锁定范围、进度和质量，而这注定导致失败。

这就是为什么scrum master和产品负责人在scrum团队中分别满足两个不同需求的原因，但这两个角色在传统软件管理中通常是由一个人来担任。规模较小的团队也很容易就为了节约支出而省掉scrum master这个职位。只是，一旦有障碍出现或变动发生，团队就需要在流程管理和产品方向之间进行明确划分。

| 团队中如果有scrum maser就可以帮助团队实现因改变产品方向所带来的消耗和由效率提升所带来的收益二者之间的平衡。一个优秀的scrum master通过赋予团队权利，让他们自行决定如何通过自组织的方式以最好的方式实现目标。

Scrum Master和项目经理

在非技术（或非敏捷）领域与scrum master角色对应的是项目经理的职位。这两种角色都专注于"如何"完成工作并通过过程和建导解决工作流程的问题。那么我们是否同时需要这两个岗位呢？大多数情况下是不需要的。

传统的项目经理和scrum master都有责任帮助他们的团队完成工作，但他们的方法却截然不同。项目经理设定时限和里程碑、报告进度并协调团队沟通。从控制的角度实施工作，扮演一个比较传统的管理者角色。

Scrum Master则旨在帮助团队强化和精简实现目标的流程。理想状态下，他们是以团队成员或协作者而不是控制者的身份开展工作。最好的Scrum团队是自组织的，因此自上而下的管理不会取得好效果。

这只是一些Scrum团队管理的一些建议配置。有些团队配备所有角色，有些组织设置一个或根本没有。

Scrum Master能为组织带来更大收益

在考虑是否聘请scrum master的时候，有一个考量因素优先于其他任何因素，即：只有在您的组织致力于scrum并愿意投资这个流程时才聘请。以上提到的各类管理角色都可以通过多种方式管理开发团队，但scrum master只有在100%投入scrum时才有效。

通过scrum master帮助每个团队管理他们的流程，整个组织可以获得一些重大收益。除了定期向客户提供交付价值（scrum的主要目标）外，团队成员和经理可以自由地专注于他们擅长的事。产品经理专注于战略、开发人员专心写代码，而销售人员则全身心的开发客户。这像什么？这就是高效运作的scrum团队该有的样子，也是我们最期待的场景。

点此↓↓↓获取scrum工具