scrum master

Scrum Master这个角色的职责很多人一直在困惑着，本文从八个方面详细介绍了Scrum Master的职责。作为Scrum提出的全新角色，他和传统的角色不一样，主要包含了以下职责：服务型领导，引导者，管理者，教练，导师，教师，清道夫，变革大师。本文还阐述了几种常见的Scrum Master职责的误区，看看你中招了吗？

随着团队对于Scrum越来越熟悉，Scrum Master的工作也慢慢变少了。所以很多人都会有一个疑问，我们还需要Scrum Master吗？ 尤其是团队成熟之后，全职的Scrum Master是否有用？

Scrum Master这个角色是项目协调人吗？在组织内是多余的人吗？Scrum Master到底是做什么的呢？本文详细解读了Scrum Master这个角色。

有很棒的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是否需要懂技术？ 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懂技术是利大于弊还是弊大于利” 虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。

我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： 什么是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 团队所创造的价值。

什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则… Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。 Scrum 是: 轻量级的 易于理解的 难以精通的 Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。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回顾组成。 Sprint计划。一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的。Sprint计划最主要完成两件事情： 在这个Sprint中要完成什么产品待办列表条目？（What） 如何完成这些条目？（How） 每日站会。开发团队15分钟同步进度并每日调整的一个事件。在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）： 昨天，我为帮助开发团队达成 Sprint 目标做了什么?

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指南履行上述职责。