敏捷开发-Scrum介绍
更多请关注微信公众号 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
Spring的目标是完成可潜在可交付的产品增量
- Scrum的核心，也是Scrum开发方法中的基本单元
- 固定的时间盒
- Sprint是一个容器，以冲刺计划开始，以冲刺评审和冲刺回顾结束
冲刺计划 - Sprint Planning
- 确定当前冲刺所要完成的工作范围
- 从Product Backlog中选择当前冲刺需要完成的PBI
- 确定Sprint Backlog，以支撑所选的PBIs
- 以两周的冲刺为例，建议会议时间为4小时
每日站会 - Daily Scrum
- 开发团队成员必须到场，PO 和SM可选参加
- 欢迎其他人参加每日站会，但只允许开发团队成员发言
- 每天同一时间、同一地点
- 准时开始，即使有开发团队成员缺席
- 控制在15分钟以内
- 会议模式基于三个问题：
- 昨天完成了什么
- 今天准备完成什么
- 遇到了什么障碍阻碍了自己或团队达成冲刺目标
冲刺评审 - Sprint Review
评审的目的并不在于评价已完成产品增量的好坏，更不是在没有达到既定要求时的批判和追责。评审的本质在于通过现场的交流和演示，获得利益相关者对产品增量的反馈！反馈！反馈！
主要内容：
- 审视已经完成的工作以及已经计划但是没有完成的工作
- 向利益相关者展示已经完成的工作（Demo）
- 与利益相关者协作，进一步明确后续要做的工作
冲刺回顾 - Sprint Retrospective
回顾会议的精髓在于检视和调整，以期持续改进：
- 回顾已经过去的冲刺
- 识别持续改进的行动项并达成一致
典型的会议内容： - 三个主要问题：
- 在当前冲刺中，哪些做的好？
- 在当前冲刺中，哪些做的不好？
- 为了提高生产力，在下一个冲刺中哪些需要改进？
- 以两周的冲刺为例，建议时间为一个半小时
- 回顾会议由SM负责推进
Scrum工作流
Scrum的工作流以Sprint为核心，通过迭代和增量的方式逐步完成最终产品的交付。
- 产品需求被汇总到Product Backlog，PO依据业务价值、重要性等对PBI进行排序。
- 冲刺会议标志着Sprint的正式开始，团队对输入的PBL进行选择，确定本次冲刺所需要完成的PBI。DevTeam基于所确定的PBI进行任务拆分，形成Sprint Backlog。
- DevTeam执行开发过程，交付潜在可发布的产品增量。
讨论
Scrum不是具体的敏捷方法，它通过价值观、角色、工件和事件等要为我们搭建了一个骨架，但骨架内填充的内容就需要具体情况具体分析了。
同其他敏捷开发方法不同的是Scrum更具有普适性，它不仅仅适用于软件开发领域。
本文主要是对Scrum框架的核心元素进行了总结和记录，理论看戏去简单，但落地Scrum却不容易，尤其是结合不同行业的工程实践更加导致Scrum落地的复杂性，而这也恰恰是Scrum实践者所需要攻坚的问题。
写在最后
这已经是关于敏捷的第二篇博文了，基本上对敏捷和Scrum做了基本的介绍，后续的博文我们更关注如何在汽车行业中实施敏捷。
