摘自

软件行业至今已经有超过40年的历史，很多在软件工程中的管理方法都是在不断摸索中改进而来的。早期的软件行业由于规模有限，绝大多数属于作坊型，几个人在一起靠着自己的聪明才智创造出软件产品；但是当团队规模不断扩大的时候，开发人员开始需要一种模型来组织越来越庞大的团队，满足越来越复杂的需求。因为没有经验可循，软件开发团队将很多传统工业工程的方法借鉴到软件行业，因而出现像“瀑布式”的模型。[1]“瀑布式”模型要求我们在实际的开发工作开始之前进行很多非常细致的设计和计划，力图将不可控的开发过程细化成可以控制的颗粒，以达到对复杂项目的总体控制目的。但是“瀑布式”模型忽视了软件项目的一个本质特点，那就是需求的不确定性；我们不可能像造汽车一样在上生产线之前把所有的零件都设计好，所有的流程都规定好，再进行装配；因为任何软件在实际进行编码之前都没有人知道这些代码应该如何实现，而且每一个开发人员的水平不同，习惯不同，写出的代码也是不同的；再加上客户对于软件的需求也是在不断变化的，一年之前的业务流程很可能在一年之后就产生的变化，如果还按照之前的需求进行开发，那么交付的时候肯定是无法满足要求的；更重要的事，在客户没有看到或者实际操作软件产品之前，他们永远也不能明确地告诉你他们要的到底是什么。因为这种种原因，造成了软件开发不可能采用传统的工程方法进行组织，因为其本身是一种需要依赖于开发人员智慧的探索性行为，也造成了我们的软件项目中有很大一部分是失败的。

Scrum模式的出现正是基于对于软件开发行为本质的认识，提供了一种松散的框架，让我们使用一种探索性的流程方法来组织本来就是探索性的开发过程；从根本上满足了软件开发本身对于流程的需求。这种方法论实际上是基于爱德华.戴明所提出的戴明环的管理方法；戴明环理论提出：人类在进行任何复杂活动时，获得成功的最有效过程要经过：Plan 计划– Do执行 – Check 检查– Act改进，四个子过程，并不停的迭代以便找到最佳的方法来解决问题。这个理论不是针对软件开发提出的，但是软件开发本身其实就是最典型的复杂活动。

这里我们再回头看看Scrum的流程，Scrum的流程主要包含以下内容：

(P) Release/Sprint Planning：发布/迭代计划

(C&P) Daily Scrum：每日回顾

(C&A) Sprint Review：迭代产品检查

(A) Sprint Retrospective ：迭代流程检查

我们可以看到，Scrum模式的流程与戴明环仅仅相扣。有很多认为敏捷模式会弱化计划的作用，其实不然，敏捷模式更加强调计划，而且强调更加频繁的计划，比如：每日回顾这个流程就要求我们的团队每个成员每天早上用15分钟的时间来回答3个问题：

你昨天做了什么？

你今天计划做什么？

有什么问题阻碍你的开发进程？

其实这正是对于之前开发内容的检查，同时也是对后续开发内容的计划过程。

注1: 敏捷也与工业有关，比如说著名的《精益思想》一书。