一文看懂Scrum

上文讨论了敏捷的内涵，以及敏捷开发在实践过程中的常见误区。本篇，我们由迭代和增量的区别入题，再梳理一下最流行的敏捷开发方法-Scrum，并看下Scrum模型中如何对迭代和增量进行结合。

01

迭代和增量的概念对比

大家或多或少都看过这个图，比较形象的给出了迭代和增量的最主要区别。

增量是从部分出发，然后将每一个增量组装成整体。但是在每一个增量产生后，并没有审查和反馈，仅有当最后所有部分组装完成后，才能看到产品的全貌。

迭代中允许试错，不断接受审查、反馈甚至推倒重来，每一个版本都在不断的迭代之前的东西。

所以本质上增量开发仍然是计划驱动的开发，我们要预想这件事情可以做对，再去勾勒增量，增量的开发模式仅在最后一刻才能看到全貌，而过程中缺失对全局风险的预知，这在快速变化的需求背景下有些不合时宜；

而迭代可以快速试错，在不断反馈过程中更新甚至是丢弃之前的东西，但是仅考虑试错中迭代，没有一些预测性的方向或价值，又会白白损失很多资源。

敏捷开发将二者结合了起来，既规避了全局性风险，又增加了对未来的预测性。

02

Scrum模型概述

Scrum的框架非常简单，整个Scrum指南算上封皮、目录和致谢部分才15页，可以总结为“3355”，3个角色、3个制品、5个事件、5个价值观

3个角色：Product Owner、Scrum Master、Developers。

3个制品：Product Backlog、Sprint Backlog、Increment

5个事件：Sprint、通常叫冲刺、或迭代，它包括4个事件，包括Sprint Planning（冲刺计划会议）、Daily Scrum（每日站会）、Spring Review（评审会议）、Sprint Retrospective（回顾会议）

5个价值观：，承诺、专注、开放、尊重和勇气

Scrum对团队的要求是自管理的、自治的，并践行五项价值观，承诺、专注、开放、尊重和勇气，这些价值观指引团队实践Scrum，要求重要的过程和决策要透明、迭代过程中不断复盘和审查，并对过程中的审查结果进行适应和调整，以一种螺旋上升的方式不断进步。

整体的框架就这么简单，下图中给出了Scrum开发模型的工作流程：

一、PO对Product Backlog进行有效管理。

PO负责将Scrum Team的工作所产生的产品价值最大化，对Product Backlog（产品待办清单）进行有效管理，包括开发产品目标、待办条目、确保待办是可理解的。

二、通过Sprint Planning安排工作，启动一个1-4周的Sprint

计划由Scrum Team生成，会前PO准备好待讨论的Product Backlog，会中讨论清楚本次冲刺的价值、制定冲刺的目标，Developer基于对开发团队过往的产能以及对冲刺目标的理解，将Product Backlog中的事项中选择一部分，变成Sprint Backlog，同时Developer自行对事项进行拆解，自组织的安排工作。

三、通过Daily Scrum跟踪和审查冲刺目标的进展

通过每日固定时长（15分钟）的会议，来专注沟通进展情况，并为下一日做出可行性计划。

四、通过Sprint Review来审查冲刺的成果

Scrum Team向关键利益相关方展示工作结果，讨论Product Goal的进展、冲刺过程中完成了什么、环境发生了哪些变化，Product Backlog会根据这些做适应性的调整

五、通过Sprint Retrospective结束冲刺，规划提高质量和效能的方法

审查整个冲刺过程中的沟通交互、过程管理、以及与目标的差距，对这些进行总结反思，并做根因分析，识别出最有用的改变提高效能，并在下一次冲刺中实践

六、开启一个新的冲刺......

整个过程中，Scrum Master帮助Scrum Team和组织内的每一个人理解Scrum理论并实践，对Scrum Team的效能负责，并不断在Scrum框架内改进实践。

03

Scrum内的迭代和增量

通过Product Backlog中识别出高价值的增量特性，转化为Sprint Backlog，使用每个固定时长的适应性迭代，产生可工作的产品增量，而这些增量会在接受反馈后，通过下一次迭代做调整和优化，最终交付，完成Product Goal。

Scrum指南中也提到了这样两句话：

Scrum采用一种迭代的增量方法来优化对未来的预测性并控制风险

Scrum团队以迭代和递增的方式提供产品，最大化反馈机会。完成产品的增量交付。

Scrum简单易懂但很难掌握。Scrum的流程很简单，但对流程中的角色要求极高，比如开发人员除了完成代码开发以外，还要负责规划、评估和管理自己的工作；Scrum强调自适应，需要在实践过程中不断调整和生成最优解。