什么是Scrum

Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则…
Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。
Scrum 是:

• 轻量级的
• 易于理解的
• 难以精通的

Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。

• Scrum指南

从Scrum指南中我们可以快速总结如下：

1. Scrum是一个过程框架
2. Scrum框架用于开发复杂产品
3. Scrum框架帮助人们解决复杂的自适应难题
4. Scrum能帮助人们高效交付尽可能高价值产品
5. 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回顾组成。

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的描述中需要进行的最低限度修正：

1. 从SAFe描述中删除所有有可能采用Scrum的声明。
2. 在SAFe描述中重命名Scrum Master的角色，以排除其与Scrum有关的实际Scrum Master角色的关联。 *

（*）如上所示，SAFe中的产品负责人和开发团队角色与真正的Scrum角色存在严重偏差。但是，只有Scrum Master角色与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 - 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指南履行上述职责。

与Scrum中的Scrum Master角色没有任何相同的作用，却也被成为Scrum Master。

此外，在Scrum中，Scrum Master的目标是确保Scrum团队和组织的适应性持续改进。Scrum Master的“完美愿景”可以表示为Scrum团队和组织具有足够的适应能力，可以不断改进，同时采用Scrum以适​​应不断变化的情况。在这种完美的愿景中，Scrum Master不再是必须的。

相反，在SAFe描述中的Scrum Master：

1. 与其他团队协调。
2. 积极解决问题，以便团队可以继续专注于实现迭代的目标。
3. 全力帮助产品负责人管理产品待办列表。
4. 与管理层沟通状态

在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)接收标准（验收标准）

1. 产品负责人从业务或干系人角度定义的外部质量特征。接收标准定义期望的行为并用于判定PBI（产品待办列表条目）是否开发完成。
2. 为了让用户、客户或其他权威机构认可，组件或系统必须满足的退出标准

Acceptance Test 接收测试

1. 验证是否满足接收标准的测试过程。
2. 一种测试，定义每个PBI必须交付的业务价值。接收测试可以验证功能需求或非功能需求，如性能或稳定性。这种测试用来帮助指导开发过程。
3. 针对用户需求和业务流程的正式测试过程，执行此过程以确定系统是否满足接收标准，并且使用户、客户或其他授权的实体能够决定是否接受此系统。

Acceptance Test Driven Development (ATDD) 接收测试驱动开发

一种技术，在开发过程开始之前，参与者使用实例讨论接收标准，然后将其分解成一组具体的接收测试。与“实例化需求(Specification By Example)”同义。

Accountability 责任担当

教练信任教练对象，并通过双方从开始就共同设计的架构和方法，以不带主观臆断和责备的态度，使教练对象在思考、学习或行动的过程中对自己的发展进程和目标负责。教练以“每个人都要对自己的发展b负责”的心态来协助教练对象建立起对自己的责任担当系统。建立责任担当的问题包括：“你会怎么做？”“什么时候？”

Adaptation 适应（调整）

经验式过程（Empirical Process）的三个支柱之一；适应是一种反馈，用来对正在开发的产品或产品开发过程进行调整。另外可以参阅“经验式过程”、“检视”和“透明”。

Agile 敏捷

1. 敏捷宣言中表示的一组特定的加个管和原则。参见敏捷宣言网站。
2. 泛指，用于指代一组相关的增量式迭代开发方法。Scrum是一种敏捷开发方法。另请参阅“极限编程”、“看板”和Scrum。

Artifact 工件

在产品开发过程中产生的实际附属物。如产品待办列表、冲刺待办列表和潜在可交付的产品增量都是Scrum的工件。

B

Boy Scout rule 童子军原则

1. 离开营地时，总是做到比发现时更干净。如果地上脏乱，不管是谁弄脏的，都清理干净。
2. 每次在一块代码区工作，离开时总是要把代码整理得比你动手时更干净，而不是弄得更乱。

burndown chart 燃尽图

一种曲线图，横轴是时间（如迭代内的每天），纵轴上是迭代内剩余工作量。随着时间的推移，剩余的工作量越来越少，图表上的一般趋势是工作量燃烧到0.通过计算趋势线，可以在燃尽图上显示对应的产出，从而了解工作什么时候可以完成。如下图：

burnup chart 燃烧图

和燃尽图相对。一种曲线图，用来显示逼近目标的工作进度，纵轴上标有目标值。随着时间推移，工作逐渐完成，进度线条逐步上升并接近于目标线。在燃烧图上，我们可以通过计算趋势线显示对应的产出，从而了解什么时候可能完成。如下图：

C

cadence 节奏

规则的、可预测的节律或心跳。具有一致持续时间的冲刺，为每一次开发工作建立节奏感。

chaotic domain 混乱域

1. 需要快速响应的一种情况。我们深陷危机，需要立即采取行动，以防止损失扩大化并至少需要重新建立一定的秩序。
2. Cynefin框架中域的一种。请参阅“繁杂”、“复杂”、“简单”域。

commitment 承诺

把自己和行动过程绑定在一起的行为。Scrum鼓励承诺。承诺意味着无论顺利与否，每个团队成员都专注于达成团队的共同目标。

Component Team 组件团队

专注于创建组件的团队，这些组件从属于客户想要购买的大型产品。组件团队创建软件资产或组件，其他团队可以重用并组装成有价值的客户方案。与特性团队相对。

confidence threshold 信心门限（临界值）

1. 构想（产品级规划）的完成的定义。
2. 为了能有足够的信心来决定是否投资继续进一步开发，这是决策者需要的信息。

Continuous Integration 持续集成

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。持续集成 from o Martin Fowler

We are looking for the translators please contact bob@bobjiang.com

中文版

Glossary

Agile

中文版

Source

Glossary

A

Acceptance Test Driven Development (ATDD)

Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. (see more)

Acceptance Testing

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios. In many cases the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the development team or off the shelf. (see more)

English Version

我要提问 我要回答 加入敏捷社区，限时优惠

目录

[TOC]

问题1

如果Scrum团队中有一个团队成员不愿意认领该Sprint中的任何任务，作为ScrumMaster你会怎么办？

问题2

如果Scrum Master同时兼任团队成员，认领任务，你认为可以吗？如果可以，为什么？如果不可以，为什么？

问题3

下午2点马上要开Sprint计划会议，现在是下午1点50分。产品负责人说他没时间参加Sprint计划会，但他不介意在他缺席的情况下团队自己开Sprint计划会。作为Scrum Master你会怎么办？

问题4

你是团队的ScrumMaster，准备去会议室开会。此时团队的分析师边哭边从你身边跑过，另一位工程师也怒气冲冲的从你身边跑过，他们都跑向经理的座位。你走进会议室，明显感觉到会议室的气氛不对，剑拔弩张。平时分析师负责编写需求并传递给工程师，分析师总是修改需求，埋怨逐步积累并在这次爆发了。在这个时候，作为Scrum Master，你会怎么做？

问题5

如果一个项目需要大量的架构工作，比如需要6周时间来进行基础架构设计，那么是否可以前3个Sprint（假设一个Sprint是2周）用来做架构设计呢？如果可以，原因是什么？如果不可以，原因是什么？

问题6

Scrum Master能不能同时兼任多个团队的Scrum Master？如果可以，原因是什么。如果不可以，原因是什么。

问题7

Sprint进行到一半的时候（比如两周的Sprint，过去了一周），总监要把团队中的一名骨干成员调走到另一个重要的项目。作为Scrum Master，碰到这样的情况，你会怎么办？请列出具体的解决方案以及原因。

问题8

你听说公司内有个团队在用Scrum并且很成功，如果你也想在自己的团队尝试Scrum，你会怎么做？

问题9

每日站会上，团队成员A不关心其他人的内容（和其他人的任务没有交集），也不认为有必要关心。作为Scrum Master，你会怎么办？

问题10

连续3个Sprint团队都只完成了承诺的Product Backlog Item的一部分（即没有完成计划会上的承诺），作为Scrum Master，出现这个情况，你会怎么办？

问题11

假设这是团队的第一次Sprint评审会（Review），客户（或业务方）说他很忙，没有时间参加Review会议。作为团队的Scrum Master，这种情况下你会怎么办？

问题12

敏捷宣言中提到“可工作的软件”高于“详尽的文档”，快速响应变化，那么假设你是一个测试人员，如何在一个scrum团队中快速把握每个需求间的内在联系，更好的覆盖测试对象？

问题13

今天的题目和每日站会有关。假设你是团队的ScrumMaster，在开每日站会的过程中（比如进行到一半的时候），有一名团队成员突然离开（他已经回答完三个问题了）并回到座位上开始他的工作，如果出现这样的情况，作为ScrumMaster，你会怎么办？

问题14

在每日站会上，团队成员A说他完成了任务1，今天计划完成任务2.团队成员B说等一下我有个问题，任务1和我手上的任务3需要做联调测试，任务3我还没完成，任务1不能算完成。为什么会出现这种情况？如果出现这种情况，作为ScrumMaster，你会怎么办？

问题15

假设你是团队的ScrumMaster，你们团队马上要开始一个新项目（公司的重要项目）。整个团队都很兴奋，但是对于团队能够完成多少工作以及什么时候完成，团队搞不清楚如何给管理层一个大致的估算。此时，作为ScrumMaster，你会怎么办？

问题16

你正在参加一个大型的项目开发，产品列表（product backlog）里面大概有200多个条目（需求）。假设你是产品负责人，项目刚刚启动，你需要对着200多个条目进行排序，这个时候你会怎么办？

问题17

实行敏捷之后，工作量很透明，也拆分了任务，大家也都认领。但有一个问题：怎么能让大家认领工作更合理，有些人3天做一个任务，有些人一天做3个任务。如果光靠任务量来统计，也不公平，因为能力不同，任务难度不同。所以，问题是作为ScrumMaster，怎样能更合理的分配工作？

问题18

新来的成员不愿意在早会上吐露心声，总会觉得早会是秀的场合。如果不说出点高大上的就不好意思说，也不维护看板，也很被动。你也找他单独谈过几次，但也没有改变。作为ScrumMaster，你还会怎么办？

问题19

一个Sprint中团队提前3天完成了所有的需求，作为ScrumMaster你会怎么办？如果提前了0.5天完成了所有需求呢，你会怎么办？

赞助

有了你的赞助，Bob会继续更新本页面，以及敏捷词汇表 以太赞助：0x521aacB43d89E1b8FFD64d9eF76B0a1074dEdaF8