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

中文版 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.

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

今年年初，我曾经写过一篇敏捷认证对比的博客。后来有博友咨询是否有更新，今天特地抽出时间整理了一下最新情况。 本文尽量客观的描述每个敏捷认证（及机构），如有不正确的地方，麻烦留言指出。 全文一共分为三大部分： 1. 敏捷认证大全 2. 敏捷认证的对比（更新版） 3. 如何选择敏捷认证 敏捷认证大全 目前市面上已经有的敏捷发证机构如下： - Scrum联盟成立于2001年，全球超过100万会员。 - Scrum.org成立于2009年。 - PMI-ACP，ACP认证创建于2011年。 - EXIN，敏捷认证创建于2016年。 - LeSS成立于2014年。 - SAFe成立于2011年。 - Scrum@Scale成立于2018年。 敏捷认证对比 Scrum联盟 机构介绍 Scrum联盟成立于2001年，是敏捷行业最早、影响力最大的机构之一。更多Scrum联盟介绍 认证体系介绍 Scrum联盟的认证体系非常完整，按照Scrum中的三个角色划分：Scrum Master、产品负责人和开发团队。 Certified Scrum Master (CSM) –> Advanced CSM –> CSP-SM Certified Scrum Product Owner (CSPO) –> Advanced CSPO –> CSP-PO Certified Scrum Developer (CSD) –> 待定 –> CSP 除了以上三个角色的认证，还有更进一步的晋级，即导师级认证。分别为： - Certified Scrum Trainer (CST) - Certified Enterprise Coach (CEC) - Certified Team Coach (CTC)

如何成为CSM 0. 参加CSM的课堂培训 在这里你可以找到Bob的CSM课堂培训 1. 培训后的操作 首先恭喜你完成了CSM课堂培训，开启一段敏捷之旅。 接下来就是要参加CSM认证考试： 1. 查看邮箱里来自Scrum联盟的官方欢迎邮件。 2. 登录Scrum联盟，点击右上角My Dashboard进入CSM考试。My Dashboard这里可以查看自己的个人信息，管理Scrum Education Units® (SEUs)，以及（如果你是第一次认证的话）申请免费会员资格。 3. 参加CSM考试，50道题目在60分钟内答对37道题即通过。收到邮件后90天内有2次免费考试机会。（我强烈建议学员在收到邮件后的1周内完成考试）。 4. 通过考试后，回到My Dashboard同意License Agreement。 恭喜你，获得了CSM认证。证书有效期是2年，到期前Scrum联盟会发送邮件提醒。为了维护证书，你需要在2年内完成20个(SEUs)，以及缴费100美元。获得SEU的方式点击这里查看。 要获得更高级的证书，请查看下图： 行动 每日问题 证书只是一个证书，更重要的是学习能力。想要成为自由职业者，可以看这里。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！