记一次CRM敏捷认证培训学习总结

前言

最近公司组织了一次关于CRM敏捷认证的培训和考试活动。为了加深记忆和留待以后回顾复习，也为了想要了解敏捷的同学提供一定的帮助，特此写了一篇关于敏捷培训的总结。
学习链接：
Scrum指南2020版本下载地址：https://scrumguides.org/download.html
敏捷产品负责人简介：https://www.bilibili.com/video/BV1o64y1f7Vw/
如何进行敏捷认证(认证老师博客)：https://www.bobjiang.com/csm/
敏捷认证考试流程：https://www.bobjiang.com/csm-exam.html
less大规模敏捷各大公司结构案例图：https://less.works/zh-CN
CRM敏捷升级考试CSP方式：https://www.bobjiang.com/apply-pdu-for-csm/

What is Agile(什么是敏捷)

敏捷是什么？敏捷不仅仅简单只是一个形容词，敏捷更是一种思想，一种态度，倡导简单设计，快速交付，价值导向，响应变化，价值一定是用户能感知到的。

敏捷是一种思维方式：由价值观定义，由原则指导，通过许多不同的实践体现。

敏捷更多的是一种态度而不是一个流程，是一种氛围而不是一种方法。从上图也可以看出，敏捷是个人、团队和组织，持续学习、持续反馈的过程。敏捷不是快，敏捷是反馈快

传统开发模式与敏捷

迭代与增量开发

interative迭代开发(如上图)，在每一次的迭代中对作品进行一次次的优化，最后给出一个完美的作品。

incremental增量开发(如上图)，每一次完成作品的一部分，最后给出一个完美的作品。

什么是价值驱动(Value Driven)

价值驱动包含：公司、客户、商业等，敏捷就是为了更好的创造价值。

小结

综上所述，敏捷软件开发的特点：

1. 反馈快（fast feedback）
2. 迭代（iterative）
3. 增量（incremental）
4. 价值驱动（value driven）

敏捷软件开发宣言

使用二分法，我们要在敏捷宣言的左侧和右侧之间找到一个平衡点

敏捷的原则

下面我们来看看敏捷的原则有哪些？

以上就是敏捷的大概介绍，下面我们来了解下敏捷的一个轻量型框架Scrum

Scrum Overview （Scrum概述）

Scrum的定义：

Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。

Scrum 理论:

Scrum基于经验主义和精益思维。经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。
Scrum采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。
Scrum让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。Scrum将4 个正式事件组合在一起以在一个容器型事件Sprint中进行检视和适应。这些事件之所以起作用，是因为它们实现了基于经验主义的Scrum的三个支柱：透明、检视和适应。

1. 透明：涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。在Scrum中，重要的决策是基于其3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。透明使检视成为可能。没有透明的检视会产生误导和浪费。
2. 检视：Scrum工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问题。为了帮助检视，Scrum 以5个事件的形式提供了稳定的节奏。检视使适应成为可能。没有适应的检视是毫无意义的。Scrum事件旨在激发改变。
3. 适应：如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差。当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。在通过检视学到任何新东西时，Scrum Team 会做出相应调整。

Scrum遵循3355规则，即下图：

角色之间的关系图
PO(产品负责人)：主要的掌舵人，负责划船的方向。
SM(敏捷教练)：主要负责团队的协作，服务于PO,DT,ORG等。
DT(团队)：划船的具体人员。

• 3个角色-Product Owner(产品负责人)

1. Product Owner 负责将Scrum Team的工作所产生的产品价值最大化。如何做到这一点可能在组织、Scrum Team和个体之间存在很大差异。
2. Product Owner还负责对Product Backlog 进行有效管理，包括：
   ●开发并明确地沟通Product Goal ；
   ●创建并清晰地沟通Product Backlog 条目（items）；
   ●对Product Backlog 条目进行排序；
   ●确保Product Backlog是透明的、可见的和可理解的。
3. Product Owner可以自己做上述工作，或者也可以将职责委托他人。然而无论如何，Product Owner是负最终责任的人。
4. Product Owner是一个人，而不是一个委员会。在Product Backlog 中，Product Owner可以代表许多利益攸关者的期望要求。那些想要改变Product Backlog的人可以尝试去说服Product Owner来做到这一点。
   
   敏捷产品负责人简介：https://www.bilibili.com/video/BV1o64y1f7Vw/

• 3个角色-Scrum Master(敏捷教练)

1. Scrum Master 负责按照Scrum指南的游戏规则来建立Scrum。他们通过帮助Scrum Team 和组织内的每个人理解Scrum理论和实践来做到这一点。
2. Scrum Master对ScrumTeam 的效能负责。他们通过让ScrumTeam 在Scrum框架内改进其实践来做到这一点。
3. Scrum Masters 是真正的领导者，服务于Scrum Team 和作为更大范围的组织。
4. Scrum Master以多种方式服务于ScrumTeam ，包括：
   ●作为教练在自管理和跨职能方面辅导Scrum Team 成员；
   ●帮助Scrum Team专注于创建符合Definition of Done的高价值Increment;
   ●促使移除Scrum Team 工作进展中的障碍；
   ●确保所有Scrum事件都发生并且是积极的、富有成效的，并且在时间盒（timebox）内完成。
5. Scrum Master以多种方式服务于Product Owner，包括：
   ●帮助找到有效定义Product Goal 和管理Product Backlog的技巧；
   ●帮助Scrum Team 理解为何需要清晰且简明的Product Backlog 条目；
   ●帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）;
   ●当需要或被要求时，引导利益攸关者协作。
6. Scrum Master 以多种方式服务于组织，包括：
   ●带领、培训和作为教练辅导组织采纳Scrum；
   ●在组织范围内规划并建议Scrum 的实施；
   ●帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法（empirical approach）；
   ●消除利益攸关者和Scrum Teams 之间的隔阂。
   
   Scrum Master核⼼技能:目标、现状、选项、行动
   

• 3个角色-Scrum Master(团队)

1. Developers是Scrum Team 中致力于创建每个Sprint可用Increment的任何方面的人员。
2. Developers 所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。但是，Developers 始终要负责：
   ●为Sprint创建计划，即Sprint Backlog；
   ●通过遵循Definition of Done来注入质量；
   ●每天根据Sprint Goal 调整计划；
   ●作为专业人士对彼此负责。

• 3个工件-Product Backlog(产品待办列表)

1. Product Backlog是一份涌现的和有序的清单，它列出了改进产品所需的内容。它是ScrumTeam所承担工作的唯一来源。
2. 能够被Scrum Team在一个Sprint中完成（Done）的Product Backlog 条目被认为准备就绪，在Sprint Planning 事件中可供选择。它们通常在精化活动后获得这种透明度。Product Backlog精化是将Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为Product Backlog 条目增添细节，例如描述、优先顺序和规模。这些属性通常随工作领域而变化。
3. 将要做这项工作的Developers负责使其适当的大小。Product Owner可以通过帮助Developers理解和权衡取舍来影响他们。
   
   内容：
   
   产品待办列表到团队开发每一次的细化
   

• 3个工件-Sprint Backlog(每一个sprint的待办列表)

1. Sprint Backlog 由Sprint Goal （为什么做）、为Sprint选择的Product Backlog 条目（做什么）以及交付Increment的可执行计划（如何做）组成。
2. Sprint Backlog是Developers为其制定的计划。它是Developers在Sprint期间为实现Sprint Goal 而计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多，Sprint Backlog在整个Sprint期间会进行更新。它应该有足够的细节，以便他们可以在Daily Scrum(站会)中检视其进展。
   个简单的Sprint Backlog通常可用看板的形式
   

• 3个工件-Increment(完成符合定义的增量)

1. 一个Increment是迈向Product Goal 的一块坚实垫脚石。每个Increment 都是之前所有的Increment累加起来的，并经过彻底地验证，以确保整合在一起的所有Increment都能工作。为了提供价值，Increment 必须是可用的。
2. 在一个Sprint中可以创建多个Increment。Increment的总和在Sprint Review 中展示，从而支持经验主义。但是，Increment可以在Sprint结束之前交付给利益攸关者。Sprint Review决不应该被视为发布价值的关口。
3. 一项工作除非符合Definition of Done ，否则不能将其视为Increment的一部分。

• 5个事件-Sprint(固定时间盒)

1. 它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个Sprint结束后，下一个新的Sprint紧接着立即开始。
2. 实现Product Goal 所需的所有工作，包括Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective，都发生在Sprint内。
3. Sprint通过确保至少每个日历月一次对达成ProductGoal的进展进行检视和适应，来实现可预测性。当Sprint的长度拉得太长时，Sprint Goal 可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的Sprint来产生更多的学习周期，并将成本与工作投入（effort）的风险限制在更短的一段时间内。每个Sprint都可以视为一个短期的项目。

• 5个事件-Sprint Planning(冲刺计划)

1. Sprint Planning通过安排在Sprint 中要做的工作来启动Sprint。最终的计划是由整个Scrum Team协作创建的。
2. Product Owner要确保与会者准备好讨论最重要的Product Backlog 条目，以及它们如何映射到Product Goal 。Scrum Team还可以邀请其他人参加Sprint Planning以提供建议。
3. Sprint Planning是有时间盒限定的，以一个月的Sprint 来说最多为8 个小时。对于更短的Sprint，Sprint Planning 所需时间通常会更短。
   

Sprint Planning 用来完成3个话题：

• 5个事件-Daily Scrum(每日站会)

1. Daily Scrum的目的是检视达成Sprint Goal 的进展，并根据需要调整适应Sprint Backlog，以调整即将进行的计划工作。
2. Daily Scrum是一个属于ScrumTeam 的Developers 的15 分钟的事件。为了降低复杂性，它在Sprint的每个工作日都在同一时间同一地点举行。如果Product Owner或Scrum Master 正在积极处理Sprint Backlog条目，那么他们将作为Developers参与其中。
3. Developers 可以选择他们想要的任何举行Daily Scrum 的结构和技术，只要他们专注于实现Sprint Goal 的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。
4. Daily Scrum改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。
5. Daily Scrum并不是唯一一次允许Developers调整计划的时间。他们可以在一天中任何时间碰面，详细讨论如何调整适应或重新规划Sprint的剩余工作。
   

-5个事件-Sprint Review(每一个冲刺的评审)

1. Sprint Review的目的是检视Sprint的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展示他们的工作结果，并讨论Product Goal 的进展情况。
2. 在Sprint Review 期间，Scrum Team和利益攸关者将评审在这次Sprint中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。Product Backlog也可能会进行调整以适应新的机会。Sprint Review是一个工作会议，Scrum Team应避免将其仅限于展示。
3. Sprint Review是Sprint的倒数第二个事件，Sprint Review 是有时间盒限定的，以一个月的Sprint来说，最多为4 个小时。对于更短的Sprint，Sprint Review通常所需的时间更短。
   

-5个事件-Sprint Retrospective(每一个冲刺的回顾会)

1. Sprint Retrospective的目的是规划提高质量和效能的方法。
2. Scrum Team检视最近Sprint中有关个体、交互、过程、工具和他们的Definition of Done 的情况如何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设，并探究其起源。Scrum Team讨论在Sprint期间哪些进展顺利，遭遇到哪些问题以及这些问题是如何解决（或未解决）的。
3. Scrum Team识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个Sprint的Sprint Backlog中。
4. Sprint Retrospective 结束Sprint。它是有时间盒限定的，以一个月的Sprint 来说，最多为3 个小时。对于更短的Sprint，Sprint Retrospective 通常所需的时间更短。
   

-5个价值
Scrum的成功应用取决于人们变得更加精通践行并内化5 项价值观：
承诺，专注，开放，尊重和勇气

1. ScrumTeam 致力于达成其目标并且相互支持。他们的主要关注点是Sprint的工作，以便尽可能地向着这些目标获取最好的进展。ScrumTeam 及其利益攸关者对工作和挑战持开放态度。ScrumTeam 成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。ScrumTeam 成员有勇气做正确的事并处理那些棘手的问题。
2. 这些价值观为ScrumTeam 的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用Scrum的方式应强化这些价值观，而不是削弱或破坏它们。ScrumTeam 成员通过Scrum事件和工件来学习和探索这些价值观。当ScrumTeam 和与他们一起工作的人们体现这些价值观时，基于经验主义的Scrum的三个支柱：透明、检视和适应，就成为现实，并在每个人之间构建信任。

Focus 专注
Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
Courage 勇气
Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
Openness 开放
As we work together, we express how we’re doing, what’s in our way, and our concerns so they can be addressed.
Commitment 承诺
Because we have great control over our own destiny, we are more committed to success.
Respect 尊重
As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

Scrum适合的场景

1. ⻓期的产品开发
2. 复杂的、创新的产品
3. 产品开发 vs. 项⽬开发（项⽬团队解散）
4. 可以做计划（预测）
5. 团队内学习成本不太⾼（跨职能团队）

Scrum Framework

Sprints

我们使用Sprints有什么好处：

• 专注
• 节奏
• 试错
• 保持适度压⼒
• 降低沟通成本
• ⻛险⼩
• 频繁获取⽤户反馈

什么是用户故事？

用户故事的定义：

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

关于用户故事，Ron Jeffries用3个C来描述它：

1. 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
2. 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
3. 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事的六个特性-INVEST：

一个好的用户故事应该遵循INVEST原则。

1. 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
2. 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
3. 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
4. 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
   5.短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
5. 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

用户故事拆分结构图：

Definition of Done (完成的定义)

在上面的内容提到过，在一个完整的sprint中会完成许多的增量，那这个完成是如何定义的呢？

需求三次握手

1. product backlog refinement, PO 提出
2. sprint planning, 开发团队讲解，PO澄清
3. ⽇常⼯作，开发团队邀请PO确认

关于认证