CSM 学习记录

Agile 是指导思想，Scrum 是其中一个实践框架。

Scrum is a framework for managing a process not a methodology
因为 Scrum 并没有指导你怎么去做，它只是一个迭代和增量的产品开发框架。在此框架中，我们可以使用各种不同的过程和技术，来优化对未来的预测和控制风险。

Scrum 不是银弹，而是一面“银镜”，一方面能看到团队的现况、暴露团队所遭遇的障碍，另一方面能让团队快速接收到外部反馈。
—— Scrum 暴露问题，Team 解决问题。

Scrum ≠ 快速交付，Scum 是快速获取反馈。

1. 通过 DevOps，团队能获得代码质量的反馈；
2. 通过 Review，团队能获得优化产品的反馈；
3. 通过 Retrospective，团队能获得改进工作的反馈。

同样是两个月后上线，Scrum 会分解出 4 个 Sprint（2 weeks length），每个 Sprint 都可以接收 Stakeholders 和 Customers 的反馈，而且团队定期回顾检视，能及时优化产品，改进开发过程，以更高的效率和质量交付更有价值的产品，所以快速交付是成果，而且需要学会与时间做朋友，不能操之过急，要给团队成长的时间，而不是压力。

敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

尽管右项有其价值，我们更重视左项的价值。

其中有一个需要平衡的地方，例如，当团队缺少好的流程与工具时，此时工作重点是解决流程与工具的问题，当有了基本的流程和高效的工具后，精力则稍微倾斜到个体和互动。

扩展阅读：敏捷宣言 & 敏捷原则

Scrum

出处：指英式橄榄球次要犯规时在犯规地点对阵争球，团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。

Scrum

• 1993 年 Jeff Sutherland 年首次定义了用于了软件开发行业的 Scrum 流程
• 1995年 Jeff Sutherland 和 Ken Schwaber 规范化了 Scrum 框架
• 2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum 是其中一种敏捷方法

敏捷团队

Focus on the right things and do things right and fast.

• Product Owner：Build the right things
• Scrum Master：Build at the right speed

• Development Team：Build in the right way

  
  Scope and Mindset

适用场景

1. Complex Product：复杂的产品（业务复杂 / 实现复杂）
2. Stable Team：稳定的团队（半年的磨合期）
3. Long Term：产品周期长（3 月以上）
4. Empower：授权（团队有评估、计划的自主权）

刚开始使用 Scrum 不会立竿见影，效果会随着时间与积累而提升。

Cynefin

3355

• 3 个角色
  • Product Owner（PO）
  • Scrum Master（SM）
  • Development Team
• 3 个物件
  • Product Backlog
  • Sprint Backlog
  • Prodcut Increment
• 4 个 Event + 1 Activity
  • Sprint Planning / Daily Scrum / Review / Retrospective
  • Prodcut Refinement
• 5 个价值观
  • Focus
  • Openness
  • Commitment
  • Respect
  • Courage

注

1. Timebox 时间固定，不延长也不缩短 Sprint（保持节奏、习惯与固定的时间安排）
2. 3355 必须全部执行，否则就是 Run Scrum, but…（这样就收获不到最大的成效）
3. 有长远的目标，但仅规划一个 Sprint（不然如何保证专注与适应变化？）
4. Product Refinement 时间与形式不限制

Scrum Framework

3 个拆分

—— Henrik Kniberg

1. Split your product：需求条目化，每个需求尽可能小
2. Split your organization：大团队拆成小团队，组织端到端跨职能的小团队（3~9 人）
3. Split your time：固定的时间盒子 Sprint（1~4 weeks）

2 个优化

—— Henrik Kniberg

1. Optimize business value：优化价值，对 Product Backlog Item 进行排序、拆分
2. Optimize process：通过回顾会，不断优化流程（流程是进化出来的）

Scrum vs Walterfall

Processes

• Defined processes：强计划（预测）、重执行（过程控制），例如：Waterfall
• Empirical processes：信息透明下，不断检视和调整，拥抱变化，例如：Scrum

Waterfall vs Agile Risk Management

知识扩展

Mob 编程

团队同一时间，在同一个地方，在同一台电脑上工作于同样的事情，其中由一个“司机”掌握唯一的键盘。

Mob编程是一种软件开发方式，是结对编程的扩展，整个团队从事同一段代码编程。这类似于两个人坐在同一台计算机上，同时对一个任务或一个问题上进行结对编程。

https://www.agilealliance.org/glossary/mob-programming/

Mob 编程实际也是某种头脑风暴，可以用于 DDD 等事件建模活动中。

Product Backlog

Prodcut Backlog Item（PBI）

• Requirement
• User Story
• Feature
• Use Case
• ...

PBI

ODDE

• Ordered (Prioritized) ：排序的，优先级、价值大小
• Detailed Appropriated：详略得当的，例如：原型图、高保证、验收标准
• Dynamic (Emergent) ：动态的（涌现），Item 随着项目、产品的进展动态变化
• Estimated：已估算的，被充分地理解，PO 与 Team 可在 Refinement 时评估（相对估算）

拓展阅读：Make the Product Backlog DEEP

5 C 原则

• Card：卡片记录，简单方便，促进交流
• Conversation：交流，对话，促进团队与客户之间的沟通
• Confirmation：用户故事确认，明确验收标准
• Construction：构建，实现用户故事
• Consequence：结果，可交付的内容

Product Backlog Refinement

Refinement

User Story （用户故事）

站在用户角度审视需求本身，以用户视角写故事：简洁、直白。

• 用户故事强调对话而不是书面沟通
• 故事更容易被客户和开发人员理解
• 用户故事大小适中，适合做迭代计划

格式：As a <Role>, I want to <Activity>, so that <Business Value>.

作为一个<角色>，我想要<活动>，以便于<商业价值>。

User Story

INVEST 原则

INVEST

• 独立性
• 可协商
• 有价值
• 可估算
• 小粒度
• 可测试

扩展阅读：https://www.pentalog.com/blog/write-effective-user-stories

DoD（完成的定义）

Definition of Done：https://less.works/less/framework/definition-of-done.html

基于当前团队的交付能力与增量交付

完成的定义就像是一道门槛

团队一起设好了门槛，能跳过去的 PBI 就是完成了，否则，就是没完成。没有完成一半或者完成 90%。

所以对于这道门槛我们要设多高，就看团队现有的能力与对质量的要求。

• 迭代 DoD
  • 用户故事 DoD
  • 开发 DoD
  • 测试 DoD
• 发布 DoD
• 文档 DoD
• ...

Undone（Beyond “Done” Work）：团队能完成以外的工作，增加延迟的风险

扩展团队的技能，提升自动化的覆盖，不断减少 undone（让 DoD 能完全由团队自己负责）

DoD vs AC

Dod vs AC

扩展阅读：再次强调完成的定义（DoD）