更多请关注微信公众号 SystemEngineeringLab

Scrum Guide: https://www.scrumguides.org/scrum-guide.html
Scrum是一种敏捷过程框架,不同于其他敏捷开发方法,Scrum不仅仅适用于软件开发领域。
1. Srum 的目标
Deliver the highest business value in the shorttest time
Scrum的目标是“交付最高的商业价值,通过尽量短的时间”。用英文表达可能更准确一些,中文的语义比较容易混淆。Scrum的目标并不是“在最短的时间内交付最高的商业价值”,它强调的不是最短的时间,而是价值。我们关注的是如何在交付最高价值的前提下花费更少的时间。
2. Scrum 框架的组成(3-3-5-5 模型)
3 个工件
Product Backlog
Sprint Backlog
Product Increment
3 个角色
Product Owner
Scrum Master
Development Team
5 个价值观
勇气 专注 承诺 尊重 开放
5 个事件
Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective
2.1 价值观

勇气:面对难题团队成员都有勇气做正确的事情和工作
专注: 团队成员要专注于冲刺要完成的工作以及团队目标
承诺: 团队成员对完成Sprint目标做出承诺
尊重:团队成员之间都尊重对方是有能力的、独立的人
开放:Scrum团队以及利益相关者对所有的工作以及完成工作所面临的挑战的开放性一致认同。
2.2 角色

Scrum核心框架包含三个角色,即PO、SM、DevTeam。与传统的开发方法不同,Scrum的研发团队不再有细分的例如系统架构师、后端工程师、前端工程师、UI工程师等角色,而是将整个开发团队统一在了“Development Team”这一Scrum角色下。以上三个角色构成了 "Scrum Team"。
Product Owner
关键职责
- 为Product Backlog负责
- 为投资回报率负责
关键属性: - 是利益相关者和客户的代表
- 只能由一个人担任
- 有绝对的决策权
- 随时能够被团队找到
- 决定产品发布日期和内容
- 不能兼任Scrum Master
- 根据业务价值和重要性为PBI排序
-
能够决定Sprint是否取消
Scrum Master
职责 - 促进Scrum的进行,为开发团队移除障碍
特征: - 没有权利
-
服务型领导
Development Team
职责
DevTeam的职责就是实现Sprint目标,在每个Sprint结束交付可潜在发布的产品增量。
特征: - 自组织
- 跨职能:团队是跨职能的,具备交付产品所需要的所有能力
- 同地协作
- T型人才,成员具备“一专多通”的特点
- 没有头衔,大家都是平等的团队成员
- 开发团队的成员必须是全职参与
- 人数范围3-9人:人数不宜过多或过少。过少的团队无法具备跨职能的要求,过多的团队降低沟通效率
-
没有子团队:团队是平级团队,子团队增加了沟通的成本
2.3 工件
产品清单 - Product Backlog
Product Backlog是已排序的产品需求列表,它定义了最终要交付什么(What)。
Product Owner 对Product Backlog负责,其有权决定产品清单的内容,例如哪些需要纳入产品清单、哪些需要修改、哪些需要删除、哪些PBI(Product Backlog Item)优先级需要调整。大多数的PBI对客户有实际的业务价值,有些可能针对客户来说没有直接的业务价值。原则上PO认为PBI对整个产品的交付是有价值的,那么它也可以放入PBL.
PBI最常见的表述形式是用户故事,但这不是绝对的。用户故事本身不是Scrum框架的一部分,Scrum并没有要求PBI的表现形式,用户可以使用用户故事、用例或其他有意义的格式均可。
好的Product Backlog遵循 DEEP 原则
Detailed appropriately - 详略得当
- PBI的表述要详略得当,近期要做的PBI要足够详细,以便团队能够清晰的认识需求。同时,PBI的粒度要足够小,能够放到一个冲刺中执行。
- 越靠近PBL顶端的PBI要越详细且粒度越小,越靠近底部的PBI粒度越大。
Emergent - 涌现式的
产品清单是动态的,随着对产品认识的深入,以及产品内外部环境的变化,已有的PBI可能会被修改、废弃,新的PBI会被加入到产品清单,因此,PBL是一个会被持续更新动态需求池。
Estimated - 已估算的
Prioritized - 已排序的
Sprint Backlog
SBL是在当前冲刺中开发团队需要完成的工作任务列表,有点像传统开发方法中的WBS,这是DevTeam对实现PBI所做出的承诺。在冲刺计划会议中,DevTeam要对当前迭代所选择的PBI进行任务拆解,细化为具体的工作任务,足以支撑实现这些PBIs。
Spring Backlog的形式有多样,可以采用看板、电子表格或专门的在线系统进行记录和追踪。同时,拆分后的任务和PBI的对应关系也要一同记录
产品增量 - Product Increment
Potentially Shippable Increment,PSI
冲刺中所完成的所有的PBI的总和,在冲刺结束时作为产品增量交付。增量是稳定的、可工作的产品组成部分。冲刺中没有完成的部分不纳入增量。
2.4 事件
冲刺 - Sprint
