共计 3233 个字符，预计需要花费 9 分钟才能阅读完成。
官方《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 团队该有的样子，也是我们最期待的场景。
作者：MAX REHKOPF
翻译 / 校对：Worktile
文章来源：Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。
