详细介绍Scrum Master八大职责（Scrum Master能力说明）
Scrum Master这个角色的职责很多人一直在困惑着，本文从八个方面详细介绍了Scrum Master的职责。作为Scrum提出的全新角色，他和传统的角色不一样，主要包含了以下职责：服务型领导，引导者，管理者，教练，导师，教师，清道夫，变革大师。本文还阐述了几种常见的Scrum Master职责的误区，看看你中招了吗？
Scrum Master
团队还需要Scrum Master吗？ - 在团队成熟之后
随着团队对于Scrum越来越熟悉，Scrum Master的工作也慢慢变少了。所以很多人都会有一个疑问，我们还需要Scrum Master吗？ 尤其是团队成熟之后，全职的Scrum Master是否有用？
Scrum Master是项目协调人？ | Scrum的误区
Scrum Master这个角色是项目协调人吗？在组织内是多余的人吗？Scrum Master到底是做什么的呢？本文详细解读了Scrum Master这个角色。
ScrumMaster也是人 | 敏捷联盟2020年十大博客
有很棒的Scrum Master，也有糟糕的Scrum Master。
还有伟大的经理、开发人员、测试人员、销售人员、邻居，也有糟糕的。人就是人–无论他们的职业或生活角色如何。 Scrum Masters也是人。就像每个职业一样，大多数人会随着时间和经验的增长和进步。有些成长比其他成长更快。
您是否有因为Scrum Master尚未消除障碍而继续困扰您的团队的障碍？还是团队内部或团队外部的沟通不畅，并且阻碍了您完成工作的能力？也许您觉得您的团队陷入了困境，而您的Scrum Master似乎对此无能为力。如果您的Scrum Master不是您希望的那样，您会怎么做？
首先，希望您的Scrum Master不断成长。请记住，您在某些时候也是开发人员的新手或测试人员的新手。早期，您可能编写了糟糕的代码，却错过了关键测试。了解您的Scrum Master最终会更好地指导Scrum的采用和成长，自我组织以及障碍的消除。但是这需要时间，就像您成为当今的开发人员或测试人员需要花费时间一样。
接下来，向他们伸出援助之手。你是怎样做的？这里有六个想法：
在出现问题时大声说出来
在地毯下隐藏问题根本无济于事。透明度是高绩效敏捷团队的主要优点。但是在提请注意问题时要谨慎。有些事情最好私下提出，特别是如果这对于Scrum Master来说是一个缺点。
鼓励您的Scrum Master
优秀的Scrum Master经常鼓励其团队。但是谁鼓励Scrum Master？当您发现Scrum Master为团队提供了帮助时，请让他们知道很感激。是的，这是他们工作的一部分，但我们每个人都需要时时给予鼓励。
与Scrum Master头脑风暴
花一些时间思考可能导致问题的原因，并与他们合作提出创新的解决方案。没有人能回答所有问题。两个头脑总是比一个头脑好。
别装作自己懂
有时沟通不清晰，或者需求没有明确定义。单纯基于假设前进是危险的，并可能造成障碍。Scrum Master可能不得不花费不必要的能量清除障碍。保持谦卑，提出问题，并确认您的假设。
请您的Scrum Master教您特定主题的团队或对其进行更新
促进个人成长的最大动力之一是必须向其他人传授有关该主题的知识。
最后，加紧引导
Scrum团队没有明确的"领导者"，Scrum Master也不是团队的"领导者"。敏捷团队正在自我组织。团队通常需要朝着正确的方向努力，但是让团队成员加强并领导sprint活动的各个方面是可以的（实际上更可取）。
完美的Scrum Master不存在。但是，您猜怎么着 - 您也不完美。因此，下次您要抱怨Scrum Master时，请后退一步，尝试了解他们在Scrum Master旅程中所处的位置，并伸出援助之手，使他们继续前进。Scrum Master将受益，团队将受益，您的工作关系将得到改善。这是双赢的局面。
关于作者
德怀特-金登
这是敏捷联盟社区博客文章。所代表的观点是个人观点，仅属于作者。它们不代表敏捷联盟的观点或政策。
原文链接
作者：Dwight Kingdon
译者：Bob Jiang
Scrum Master是否需要懂技术
这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是：
- Scrum Master是否需要懂技术？
Bob的观点
Scrum Master需要懂技术，而且是一定要懂技术。不懂技术的Scrum Master很难成为一名优秀的Scrum Master。如果你想成为敏捷教练，或许不懂技术还行得通，但是Scrum Master不懂技术是不行的。具体还可以参考之前的博客文章，Scrum Master和敏捷教练之间的区别。
- 原因1： 不懂技术的Scrum Master很难融入团队。
- 原因2： 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展。
- 原因3： 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍。
不懂技术的Scrum Master很难融入团队
开发团队成员之间沟通的时候，多半会使用技术术语，如代码仓库、技术债、重构、vs code等等。如果听不懂团队说的是什么，就很难了解问题或背景，从而很难融入到团队中去。所以作为Scrum Master，至少需要了解：
- 常用技术术语
- 软件开发生命周期
- 常用的技术工具，等等
不需要Scrum Master成为代码管理的专家、重构专家，但一定要知道这是什么。
不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展
如果一名Scrum Master不懂技术，那么他也很难了解或掌握软件开发行业的最新工程实践（开发实践）。那么作为Scrum Master，如何帮助开发团队认识到当下行业有哪些最新的提高效率的开发工具、工作实践呢。
Scrum Master的关注度不仅仅是团队、产品负责人，还需要关注组织和开发实践。参考Scrum Master和敏捷教练之间的区别中Scrum Master关注度一节。
不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍
最后，如果Scrum Master不懂技术的话，他也很难有技术的感觉，从而很难敏感地发现团队内的潜在技术风险或障碍（不一定是真的风险，但有时候一句话就可以点醒团队）。
综上所述，作为一名Scrum Master一定需要懂技术，而且需要是懂大量的技术（不一定需要很深入）。
职场泥石流的分享
以下来自职场泥石流分享的总结，感谢小新同学（谢晓强）的努力。
之前在群里参与讨论过Scrum master与技术间关系的一些问题，从群友那里得到不少启发，其后有机会能在前两天连线Ethan黄老师，直接就这个问题展开了一些辩论，又聆听了黄老师对一些相关问题的分析与解答，让我对问题的认识又深了一些，这篇文字是对之前视频的回顾总结，加上一些我自己的思考。如果我对于黄老师的观点有引用错误的地方，或者大家认为我的观点有何不对之处，欢迎批评指正。
视频的最开始其实是关于SM懂技术是利大于弊还是弊大于利的一场小型辩论，不过我想先不记录这个，先记录黄老师后面回答的几个问题，然后再回到最开始的这场辩论，这样理解起来可能会更好。
问：没有技术背景的SM感觉无法融入团队怎么办？
针对这个问题，黄老师首先指出这种情况非常普遍，感到fear也是正常的，他自己也有过这样的经历。面对这种情况：
- 第一个是要想到每个人的知识面都是有范畴的，要扬长避短，同时你现在不会技术不代表以后不会，这种fear也是你学习的动力；
- 第二个是要弄明白，这个fear是不是有可能是不必要的，因为在这个行业里或技术里你没有积累，并不妨碍你成为一名好的SM或教练，你可以通过学习掌握软技巧，如有效倾听与强力提问、还有学习的能力，来发挥自己价值，融入团队。
问：技术能力非常强的人，他来做SM会遇到哪些问题？
针对这个问题，黄老师回答问题在于他可能忍不住涉入到技术问题中去，反而可能忽视了本来的职责。解决的办法就是要管住手管住嘴。但现实中当你越界时你自己往往是没有知觉的，所以就还有一些实践小技巧，比如你们团队间可以协商出某种方式来提醒你越界的事，如订做一顶大牛帽子，只有当你带上这顶帽子时才能扮演技术专家的角色，如果你不自觉的扮演了技术专家的角色的话，就要予以一些处罚，比如请喝咖啡等等。
总结一下，就是你作为一名SM，如果你很懂技术，你不是不能涉入到技术中去，只是你要有一种边界感，知道什么时候你是在扮演技术专家的角色，什么时候又该回到SM的角色。
记录完这两个问题黄老师的回答后，我想可以回到最开始的小辩论上来了。
“Scrum Master懂技术是利大于弊还是弊大于利”
虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。
比如，大家应该都听过一句话，叫技多不压身，不管这个懂技术里的“懂”和“技术”具体指的是什么，SM懂技术当然都会给他的工作带来优势，具体可以带来哪些优势，这个也比较容易想到，比如可以更好的和团队沟通、融入团队等等。那么相对应的懂技术的优势，就是不懂技术的劣势，针对不懂技术的劣势，如何来补足呢？
这个可以参见前面黄老师对于没有技术背景的SM感觉无法融入团队怎么办的回答。那么SM懂技术除了能带来优势外，有没有可能带来劣势呢？这个之前群里讨论也有群友指出过，一个可能就是瞎指挥，一个就是虽然不是瞎指挥，但是把原来SM的职责给放下了等等。
针对这种情况怎么办，可以参见黄老师对技术能力非常强的人，他来做SM会遇到哪些问题？的解答。对了，黄老师其实还补充了一个SM懂技术对SM本人的劣势，那就是这可能会让SM停留在舒适圈，而没有去扩充自己的能力圈，去打开自己的视野。
更进一步，我认为，当我们在辩论“Scrum Master懂技术是利大于弊还是弊大于利”时，其实是在辩论技术与SM间的关系。借用波士顿矩阵法用两个维度来分析这个问题，首先，懂技术是不是SM的核心能力？其次，我们也都知道，SM他必须还是得懂一些技术，那么这个懂技术的懂的边界在哪里，是知道性的懂还是深入性的懂？对这两个问题，我认为我和黄老师是达成了一致，即，懂技术不是SM的核心能力，倾听、提问、以及学习的能力才是SM的核心能力；SM懂技术需要的懂是知道性的懂，而不是深入性的懂，当然，具体的SM他可以是一名技术大牛，不是大牛的SM也可以去追求深入性的懂，但这并不是对SM的核心要求。
再进一步，虽然没有明说，上文在辩论技术与SM间的关系之间提到的技术的概念默认还是IT技术，但这个概念其实可以替换为更广义的技术，上面的结论依然不会改变，如黄老师举过例的一些传统制造业的例子，还有日语课件的制作例子等等。
又进一步，我认为，上述结论里的SM名词也是可以被替换掉，而结论的框架依然大致不变的（结论里的具体元素要变），比如把SM变为项目经理、产品经理等。站在SM的立场上来看，也可以从一纵一横来扩展自己的视野，一纵是指从团队到组织到公司，一横是指不同的行业，像黄老师举得很多不同层级不同行业的敏捷转型例子。
另外黄老师还回答了几个问题，比如具备管理层背景的人想加入敏捷团队怎么办？还有一个关于考证的问题等等，我这里就不一一记录了，有兴趣的朋友自己再去看视频回放吧。另外，值得注意的是，黄老师在里面的回答时有一些点冒出来，这些点都值得进一步思考，比如黄老师讲的泰罗制到SM的绩效考核，就激发了我许多思考，但这次来不及写下来了，大家可以看一下是哪些点比较能够吸引你。
顺带再插一句，之前连线时因为网络问题，不但我这边的视频信号没有传过去，lisa和黄老师的视频信号也没传到我这边来，我这边是静态的，这次看回放发现，嗯，黄老师果然很帅，lisa也是美丽大方，善良可爱。
敏捷教练和Scrum Master - 敏捷转型中的两个重要角色的对比
这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是：
- 什么是Scrum Master，什么是敏捷教练，他们之间有什么差别？
- 如何转型成为敏捷教练？
本文将重点描述敏捷教练和 Scrum Master 这两个角色，以及他们之间的关系和对比。
Scrum Master
Scrum Master 是一个全新的角色，是在《Scrum指南》中定义的。这个角色（Scrum Master）不是团队领导者，也不是项目经理，更不是经理。请不要把 Scrum Master 与现有的团队（或组织中）的角色进行映射。因为你找不到这种映射。
Scrum Master 在组织中教 Scrum，并可以帮助团队进行 Scrum 落地实践。Scrum Master，顾名思义，精通 Scrum， 对于 Scrum 有深刻理解，能够指导团队成员更好地产出更高价值的产品。
Scrum Master 是反馈环中重要的角色（另外一个反馈环是 Scrum 中的事件），他是一个支持角色，更像是团队的一面镜子，帮助团队识别出现在的问题，从而能够走向“完美”的目标。
想要对 Scrum Master 这个角色有更加深入的学习，可以看一下我讲的 Certified Scrum Master (CSM) 课程，这个课程是 Scrum 联盟的认证课程，可以为你的职业带来突破。
Scrum Master 角色的描述 – 以下摘自《Scrum指南》
什么是Scrum Master
Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。
Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。
7分钟揭晓Scrum的秘密（Scrum框架）
什么是Scrum
Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则…
Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。
Scrum 是:
- 轻量级的
- 易于理解的
- 难以精通的
Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。
从Scrum指南中我们可以快速总结如下：
- Scrum是一个过程框架
- Scrum框架用于开发复杂产品
- Scrum框架帮助人们解决复杂的自适应难题
- Scrum能帮助人们高效交付尽可能高价值产品
- Scrum框架中可以使用各种不同的过程和技术
因此，Ken Schwaber 曾经说过：
Scrum 就像你的丈母娘，不断的指出你的问题。
由此也不难看出，Scrum框架的核心在于不断暴露问题。即它是一个暴露问题的反馈框架。
下面我们来看看Scrum框架中具体包含什么内容。
Scrum 框架
Scrum框架是3个角色，3个工件，5个事件，5个价值观（即3-3-5-5）
3个角色
Scrum的3个角色分别是：
- 产品负责人（Product Owner）。产品负责人负责最大化产品和开发团队工作的价值。对产品负有最终责任，生杀大权。产品负责人可以决定先做什么，后做什么。
- 开发团队（Development Team）。开发团队包含了各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。只有开发团队成员才能创建增量。这里所说的开发团队，和我们平时所说的有区别。这里的
开发指的是产品开发，不是写代码。那么开发团队就会是自组织的跨职能团队。 - Scrum Master。Scrum Master 负责根据 Scrum 指南中的定义来推广和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。这个角色没有翻译的中文。但他绝不是项目经理，也不是
team leader。Scrum Master更像是一个团队的教练。
3个工件
- 产品待办列表（Product Backlog）。产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
- Sprint待办列表（Sprint Backlog）。Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到“完成”的增量中所需工作的预测。
- 增量。产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合。增量必须是符合团队定义的“完成的定义”（Definition of Done）
5个事件
-
Sprint。也翻译做冲刺，是Scrum的核心，也是一个容器。Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日展会、Sprint执行、Sprint评审及Sprint回顾组成。
Scrum Master - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum
Scrum Master - SAFe请不要篡改Scrum！
在这里，我们将解释SAFe描述中引入了Scrum Master角色的观点，但该角色与其在Scrum中的实际含义有重大差异。
如《Scrum指南》中所述，以下内容是Scrum Master的三个重点领域之一：
Scrum Master通过多种方式为组织服务，包括：
- 领导并指导组织采用Scrum。
- 规划组织内的Scrum实施。
- 帮助员工和利益相关者了解并实施Scrum和经验式产品开发。
- 引领变革以提高Scrum团队的生产力。
- 与其他Scrum Master合作，以提高组织中Scrum应用的有效性。 源自《Scrum指南》
指导组织是Scrum Master的一项重要职责。
相反，在SAFe描述中：
- 完全没有Scrum Master负责指导组织（coaching organization）的职责。
- 完全没有Scrum Master负责组织变革（organizational changes）的职责。
据我们所知，文化遵循结构。根据SAFe的描述创建的结构将迫使Scrum Master仅专注于团队，这仅是组织作为系统的一部分。而这通常会导致局部优化，并对整个系统产生负面影响。这是最关键的Scrum反模式之一。
此外，根据《Scrum指南》：
在Scrum指南中定义了，Scrum Master负责推广和支持Scrum。 源自《Scrum指南》
相反，在SAFe中
然而，某些团队（尤其是系统团队、运营和维护团队）选择将看板作为主要方法。 源自《规模化敏捷框架-敏捷团队》
尽管 Scrum Master 角色主要基于标准Scrum， 但敏捷团队（甚至是那些应用看板的团队）都可以建立此职位，以帮助团队实现其目标并与其他团队协调活动。 源自《规模化敏捷框架-Scrum Master》
在这些情况下，Scrum Master可以在完全不需要使用Scrum的团队中工作。在这种情况下，Scrum Master无法根据Scrum指南履行上述职责。
与Scrum中的Scrum Master角色没有任何相同的作用，却也被成为Scrum Master。
此外，在Scrum中，Scrum Master的目标是确保Scrum团队和组织的适应性持续改进。Scrum Master的“完美愿景”可以表示为Scrum团队和组织具有足够的适应能力，可以不断改进，同时采用Scrum以适应不断变化的情况。在这种完美的愿景中，Scrum Master不再是必须的。
相反，在SAFe描述中的Scrum Master：
- 与其他团队协调。
- 积极解决问题，以便团队可以继续专注于实现迭代的目标。
- 全力帮助产品负责人管理产品待办列表。
- 与管理层沟通状态
在Scrum中，这是完全不可接受的：
开发团队 - SAFe请不要篡改Scrum！
Index | Scrum Master | Product Owner | Dev Team | Scrum
开发团队 - SAFe请不要篡改Scrum！
在这里，我们将解释SAFe描述中引入开发团队角色的观点，该角色与其在Scrum中的实际含义有重大差异。
根据《Scrum指南》有关开发团队角色：
他们是自组织的。没有人告诉开发团队如何将产品待办事项转变为潜在可发布功能的增量。 源自《Scrum指南》
在SAFe描述中，有专门的系统工程师和解决方案架构师的角色。他们的职责包括：
- 定义子系统及其接口
- 确定主要组件
- 识别接口之间的协作
- 将职责分配给子系统
- 开发、分析、拆分和实现使能（enabler）史诗故事的实施
- 定义、探索和支持赋能者（Enablers）的实施以发展解决方案的意图，直接与敏捷团队合作实施它们
- 规划和开发“架构跑道”（Architectural Runway），以支持新的业务特性与功能
- 定义并沟通共同的技术和架构愿景
- 与解决方案的上下文沟通交流交互的要求
- 使敏捷发布火车（ART）和解决方案火车上的团队保持一致，以实现共同的技术和架构愿景
如果产品开发需要所有这些，那么这就是Scrum中开发团队职责范围的一部分。但是，在SAFe的描述中，团队以外的其他角色也由开发团队负责。而且，它与开发团队的外部依赖性无关。这与决策有关。
这是一种Scrum反模式，因此开发团队缺乏决策自主权。这通常导致对整体结果缺乏责任感（自主性）。最后，它带来了仅仅对于编码和测试的狭隘关注，并导致缺乏团队合作和实现业务目标的动力。
本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!原文链接
