什么是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
SAFe请不要篡改Scrum！ 我们爱Scrum。 我们反对 SAFe（大规模敏捷框架）创建和推广的对于 Scrum 的误解。
当前的SAFe描述明确承诺可以在SAFe中使用Scrum。许多类似的陈述如下：
大多数敏捷团队都将Scrum用作基于团队的主要项目管理框架。
规模化敏捷框架-ScrumXP
此外，当前的SAFe描述使用称为Scrum Master的角色，从而再次直接引用了 Scrum：
Scrum定义了敏捷团队中由具有特定职责的两个角色： 产品负责人（PO）和 Scrum Master 。SAFe文章中用该名称进一步描述了每个角色。
规模化敏捷框架-敏捷团队
当前的SAFe描述包含有关Scrum的误导性信息： 1. 如这里所描述的，SAFe中描述的 Scrum Master 角色与其在Scrum中的实际含义存在严重偏差。 2. 如这里所描述的，SAFe中描述的产品负责人角色，与其在Scrum中的实际含义存在严重偏差。 3. 如这里所描述的，SAFe中描述的开发团队角色，与其在Scrum中的实际含义存在严重偏差。 4. 如这里所描述的，根据SAFe当前描述，在SAFe的实施当中不可能采用真正的Scrum。
许多组织相应地实施SAFe，并具有各自的角色和过程。由于当前SAFe描述中的声明，他们可以合理地期望能够在此结构内采用 Scrum。相反，它们受SAFe角色和过程的约束而使用大量 Scrum 反模式并造成严重的功能障碍。
但是，这些组织假定这正是 Scrum 框架，并且他们基于此学习了 Scrum。SAFe引入了对Scrum的完全错误的理解，并剥夺了组织实现其目标的机会。
此外，对于决定在SAFe中发展Scrum Master技能的人来说，这会带来严重的职业伤害。他们学习了错误的理论并采取了功能障碍的行为。之后，他们很难理解真正的差异，以便能够有效地帮助组织正确地采用Scrum。
我们呼吁SAFe的所有者尊重人员和组织，并停止承诺可以在SAFe中使用Scrum和Scrum Master角色！ 因此，以下是在SAFe的描述中需要进行的最低限度修正：
从SAFe描述中删除所有有可能采用Scrum的声明。 在SAFe描述中重命名Scrum Master的角色，以排除其与Scrum有关的实际Scrum Master角色的关联。 * （*）如上所示，SAFe中的产品负责人和开发团队角色与真正的Scrum角色存在严重偏差。但是，只有Scrum Master角色与Scrum不可分割。 为了在该异议下“签名”并在下面显示您的姓名，请访问原文链接。
Index | Scrum Master | Product Owner | Dev Team | Scrum
Scrum - SAFe请不要篡改Scrum！ 这里我们将解释，根据SAFe的描述实施的话，不可能采用Scrum的观点。
Scrum是用于开发、交付和维护复杂产品的框架 源自《Scrum指南》
Scrum（名词）：一个框架，人们可以用其解决复杂的适应性问题，同时以富有创造力的方式交付最高价值的产品。 源自《Scrum指南》
Scrum专为产品开发而设计。产品是为客户而生的。整个Scrum团队旨在产生最大的业务价值，始终专注于客户的需求和整个产品。
敏捷团队 – 负责定义、构建、测试以及在适当情况下部署解决方案价值部分的一组人 源自《规模化敏捷框架SAFe - 敏捷团队》
取而代之的是，SAFe描述表明，敏捷团队仅处理部分功能是可以接受的。在现实生活中，这通常会使团队专注于系统组件。 无论如何，每个敏捷团队仅提供功能的一部分，就无法为真正的客户带来任何价值。由于拥有自己的产品待办列表和产品负责人，他们既不关注客户需求也不关注整个产品，而是被迫在系统组件级别上进行本地优化。
如果按照SAFe描述规定，那么甚至还可以所有参与共同产品开发的开发团队都拥有一个产品负责人和一个产品待办列表。这将有机会在Scrum中进行适当的扩展。但是，SAFe的定义给出了完全不同的方案 - 每个敏捷团队都有自己的团队待办事项列表和自己的产品所有者。 根据SAFe当前的描述来实施敏捷，敏捷团队本身不是开发一个产品，所以没有理由去关注客户的需求。取而代之的是，这迫使团队在系统组件级别上进行本地优化。
在下面来自 SAFe 描述的图片中，我们可以看到一个程序板示例，其中显示了不同团队之间的众多功能依赖关系。这不是设计Scrum和规模化Scrum的方式，但这恰恰是完全错误的Scrum方法及其在SAFe中规模化的结果。 框架中的每个组件都有特定的用途，对于Scrum的成功和采用来说至关重要。 源自《Scrum指南》
Scrum是一个框架 - 如果缺少任何元素，对于具有特定上下文的特定公司而言，它可能行不通。但是，在这种情况下，这不是Scrum。
然而，由于如此处所述， SAFe中描述的 Scrum Master 的角色与其在Scrum中的实际含义有严重的偏差。而且，作为如此处所述和[此处所述]((/remove-scrum-from-safe-devteam/)，SAFe中描述的产品所有者和开发团队的角色与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!
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指南履行上述职责。
Index | Scrum Master | Product Owner | Dev Team | Scrum
产品负责人 - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述引入产品负责人角色的观点，该角色与其在Scrum中的真实含义有重大差异。
根据《Scrum指南》中有关产品负责人角色：
…整个组织必须尊重他的决定。产品负责人的决定体现在产品待办列表的内容和顺序中。 源自《Scrum指南》
在SAFe描述中，团队待办事项类似于Scrum中的产品待办事项。团队待办列表的工作部分由计划待办列表（Program Backlog）工作填充，而计划待办列表工作是由敏捷团队外部的独立角色 - 产品经理来管理。实际上，在这种设置中，产品负责人并不是团队待办事项列表的唯一决策者。 而且，即使在规模化的情况下，Scrum也会规定：
多个团队经常在同一产品上一起工作。一个产品待办列表用于描述该产品的即将进行的工作。 源自《Scrum指南》
另外，只有一个产品负责人管理共同的产品待办列表，这才是Scrum中合适的规模化的解决方案。
相反在SAFe中，多个敏捷团队以及其各自的产品负责人和团队待办列表的工作是通用的解决方案 - 产品或产品的一部分。在以下视频中，将这种情况清楚地解释为规模化Scrum的主要功能障碍之一。
观看Youtube视频 - https://youtu.be/cr2rjaGmUzo
此外，在SAFe中：
PO在质量控制中扮演着重要的角色，是唯一有权接受完成故事的团队成员。 源自《规模化敏捷框架-产品负责人》
这是Scrum反模式。由于以下原因，PO无法承担这些责任： 1. 开发团队有责任确保交付高质量的增量。 2. 在这种情况下，PO控制着开发团队的工作成果，从而像经理一样被定位在更高的位置。它通常会引入合同游戏（contract game），并导致团队功能障碍，破坏团队合作精神。
本文链接
本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 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!
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!
English Version
敏捷词汇表 A Acceptance Criteria (AC)接收标准（验收标准） 产品负责人从业务或干系人角度定义的外部质量特征。接收标准定义期望的行为并用于判定PBI（产品待办列表条目）是否开发完成。 为了让用户、客户或其他权威机构认可，组件或系统必须满足的退出标准 Acceptance Test 接收测试 验证是否满足接收标准的测试过程。 一种测试，定义每个PBI必须交付的业务价值。接收测试可以验证功能需求或非功能需求，如性能或稳定性。这种测试用来帮助指导开发过程。 针对用户需求和业务流程的正式测试过程，执行此过程以确定系统是否满足接收标准，并且使用户、客户或其他授权的实体能够决定是否接受此系统。 Acceptance Test Driven Development (ATDD) 接收测试驱动开发 一种技术，在开发过程开始之前，参与者使用实例讨论接收标准，然后将其分解成一组具体的接收测试。与“实例化需求(Specification By Example)”同义。
Accountability 责任担当 教练信任教练对象，并通过双方从开始就共同设计的架构和方法，以不带主观臆断和责备的态度，使教练对象在思考、学习或行动的过程中对自己的发展进程和目标负责。教练以“每个人都要对自己的发展b负责”的心态来协助教练对象建立起对自己的责任担当系统。建立责任担当的问题包括：“你会怎么做？”“什么时候？”
Adaptation 适应（调整） 经验式过程（Empirical Process）的三个支柱之一；适应是一种反馈，用来对正在开发的产品或产品开发过程进行调整。另外可以参阅“经验式过程”、“检视”和“透明”。
Agile 敏捷 敏捷宣言中表示的一组特定的加个管和原则。参见敏捷宣言网站。 泛指，用于指代一组相关的增量式迭代开发方法。Scrum是一种敏捷开发方法。另请参阅“极限编程”、“看板”和Scrum。 Artifact 工件 在产品开发过程中产生的实际附属物。如产品待办列表、冲刺待办列表和潜在可交付的产品增量都是Scrum的工件。
B Boy Scout rule 童子军原则 离开营地时，总是做到比发现时更干净。如果地上脏乱，不管是谁弄脏的，都清理干净。 每次在一块代码区工作，离开时总是要把代码整理得比你动手时更干净，而不是弄得更乱。 burndown chart 燃尽图 一种曲线图，横轴是时间（如迭代内的每天），纵轴上是迭代内剩余工作量。随着时间的推移，剩余的工作量越来越少，图表上的一般趋势是工作量燃烧到0.通过计算趋势线，可以在燃尽图上显示对应的产出，从而了解工作什么时候可以完成。如下图： burnup chart 燃烧图 和燃尽图相对。一种曲线图，用来显示逼近目标的工作进度，纵轴上标有目标值。随着时间推移，工作逐渐完成，进度线条逐步上升并接近于目标线。在燃烧图上，我们可以通过计算趋势线显示对应的产出，从而了解什么时候可能完成。如下图： C cadence 节奏 规则的、可预测的节律或心跳。具有一致持续时间的冲刺，为每一次开发工作建立节奏感。
chaotic domain 混乱域 需要快速响应的一种情况。我们深陷危机，需要立即采取行动，以防止损失扩大化并至少需要重新建立一定的秩序。 Cynefin框架中域的一种。请参阅“繁杂”、“复杂”、“简单”域。 commitment 承诺 把自己和行动过程绑定在一起的行为。Scrum鼓励承诺。承诺意味着无论顺利与否，每个团队成员都专注于达成团队的共同目标。
We are looking for the translators please contact bob@bobjiang.com
中文版
Glossary Agile
