scrum回顾_敏捷，Scrum框架入门一篇文章就够了

Scrum是一种敏捷框架，不同于其他敏捷开发方法，Scrum不仅仅适用于软件开发领域。

Srum 的目标

Deliver the highest business value in the shorttest time

Scrum的目标是“交付最高的商业价值，通过尽量短的时间”。用英文表达可能更准确一些，中文的语义比较容易混淆。Scrum强调的不是最短的时间，而是价值。我们关注的是如何在交付最高价值的前提下花费更少的时间。

Scrum价值观

勇气：面对难题团队成员都有勇气做正确的事情和工作

专注: 团队成员要专注于冲刺要完成的工作以及团队目标

承诺: 团队成员对完成Sprint目标做出承诺

尊重：团队成员之间都尊重对方是有能力的、独立的人

开放：Scrum团队以及利益相关者对所有的工作以及完成工作所面临的挑战的开放性一致认同。

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

Scrum角色

Scrum核心框架包含三个角色，即PO、SM、DevTeam。与传统的开发方法不同，Scrum的研发团队不再有细分的例如系统架构师、后端工程师、前端工程师、UI工程师等角色，而是将整个开发团队统一在了“Development Team”这一Scrum角色下。

PO关键职责

• 为Product Backlog负责
• 为投资回报率负责

PO关键属性

• 是利益相关者和客户的代表
• 只能由一个人担任
• 有绝对的决策权
• 随时能够被团队找到
• 决定产品发布日期和内容
• 不能兼任Scrum Master
• 根据业务价值和重要性为PBI排序
• 能够决定Sprint是否取消

Scrum Master职责:

促进Scrum的进行，为开发团队移除障碍

Scrum Master特征

• 没有权利
• 服务型领导

DevTeam的职责

实现Sprint目标，在每个Sprint结束交付可潜在发布的产品增量。

DevTeam关键特征：

• 自组织
• 跨职能：团队是跨职能的，具备交付产品所需要的所有能力
• 同地协作
• T型人才，成员具备“一专多通”的特点
• 没有头衔，大家都是平等的团队成员
• 开发团队的成员必须是全职参与
• 人数范围3-9人：人数不宜过多或过少。过少的团队无法具备跨职能的要求，过多的团队降低沟通效率
• 没有子团队：团队是平级团队，子团队增加了沟通的成本

Scrum工件

产品清单 - Product Backlog

Product Backlog是已排序的产品需求列表，它定义了最终要交付什么(What)

PO对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的总和，在冲刺结束时作为产品增量交付。增量是稳定的、可工作的产品组成部分。冲刺中没有完成的部分不纳入增量。

Scrum事件

冲刺 - Sprint

Spring的目标是完成可潜在可交付的产品增量

• Scrum的核心，也是Scrum开发方法中的基本单元
• 固定的时间盒
• Sprint是一个容器，以冲刺计划开始，以冲刺评审和冲刺回顾结束

冲刺计划 - Sprint Planning

• 确定当前冲刺所要完成的工作范围
• 从Product Backlog中选择当前冲刺需要完成的PBI
• 确定Sprint Backlog，以支撑所选的PBIs
• 以两周的冲刺为例，建议会议时间为4小时

每日站会 - Daily Scrum

1.开发团队成员必须到场，PO 和SM可选参加

2.欢迎其他人参加每日站会，但只允许开发团队成员发言

• 每天同一时间、同一地点
• 准时开始，即使有开发团队成员缺席
• 控制在15分钟以内

3.会议模式基于三个问题：

• 昨天完成了什么
• 今天准备完成什么
• 遇到了什么障碍阻碍了自己或团队达成冲刺目标

冲刺评审 - Sprint Review

评审的目的并不在于评价已完成产品增量的好坏，更不是在没有达到既定要求时的批判和追责。评审的本质在于通过现场的交流和演示，获得利益相关者对产品增量的反馈！反馈！反馈！

冲刺评审的主要内容：

• 审视已经完成的工作以及已经计划但是没有完成的工作
• 向利益相关者展示已经完成的工作(Demo)
• 与利益相关者协作，进一步明确后续要做的工作

冲刺回顾 - Sprint Retrospective

1.回顾会议的精髓在于检视和调整，以期持续改进：

• 回顾已经过去的冲刺
• 识别持续改进的行动项并达成一致

2.典型的会议内容三个主要问题：

• 在当前冲刺中，哪些做的好？
• 在当前冲刺中，哪些做的不好？
• 为了提高生产力，在下一个冲刺中哪些需要改进？

3. 以两周的冲刺为例，建议时间为一个半小时

4. 回顾会议由SM负责推进

Scrum工作流

Scrum的工作流以Sprint为核心，通过迭代和增量的方式逐步完成最终产品的交付。

• 产品需求被汇总到Product Backlog，PO依据业务价值、重要性等对PBI进行排序。
• 冲刺会议标志着Sprint的正式开始，团队对输入的PBL进行选择，确定本次冲刺所需要完成的PBI。DevTeam基于所确定的PBI进行任务拆分，形成Sprint Backlog。

• DevTeam执行开发过程，交付潜在可发布的产品增量。

写在最后

Scrum不是具体的敏捷方法，它通过价值观、角色、工件和事件等要为我们搭建了一个骨架，但骨架内填充的内容就需要具体情况具体分析了。

参考：Scrum Guide: https://www.scrumguides.org/scrum-guide.html