第Ⅰ部分　精益产品开发的原则

第 I 部分介绍精益产品开发的基本原则。我们将从传统到敏捷开发方法的演变讲起，引出精益产品开发要解决的核心问题以及对应的方法和原则，从而构建出一个完整的精益产品开发体系。

第 1 章　从传统向敏捷软件开发的演进

第 2 章　精益产品开发的核心原则 ( 上 )：聚焦价值流动效率

第 3 章　精益产品开发的核心原则 ( 下 )：探索和发现有用的价值第 4 章　精益思想和精益产品开发实践体系

第 5 章　经典天文学演进对产品开发方法学的启示

第1章

从传统向敏捷软件开发的演进

在产品开发中，“敏捷”和“精益”这一对热词如影随形。精益产品开发离不开对敏捷软件开发的深入理解，所以我们的精益之旅也将从敏捷软件开发开始。本章讲述软件开发从传统进化到敏捷背后的业务动因以及敏捷软件开发实践体系。

传统软件开发方式面临的挑战

传统软件开发方法是与软件工程的概念一同诞生的（图 1-1）。1968 年，北约（NATO）召开全球第一届以“软件工程”命名的会议，这次会议通常被视为软件工程诞生的标志。会议上提出了“软件危机”的概念。随着软件复杂度的不断提高，软件项目普遍出现预算超支、质量低、性能差、不符合实际需求和延期等问题，造成所谓的“软件危机”。

图 1-1　传统开发方法的产生历程

当时，业界普遍认为，软件行业应该借鉴工程领域的经验，“系统地应用工程管理方法”，以此来应对软件危机。这是软件工程诞生的背景，在这一思路下产生的软件开发方法就是传统软件开发方法。它们共同的特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。

相比作坊式的开发，传统方法开发方法进步明显。它让产品开发有矩可循，让项目和产品的成功可以重复，让组织的能力可以被评估，这些当然是好的。图 1-1 是传统开发方法的大致发展历程，到了上世纪 90 年代初，CMMI 和 PMI 项目管理知识体系 ^[1] 成为传统产品开发管理方法的典型代表。

然而，传统方法并没有从根本上解决软件危机，软件项目的失败率依然居高不下，甚至越来越糟糕。在这方面被引用得 多的是 Standish Group 定期发布的 IT 项目起时才又被人们重新提起。

人们认识到，遵循严格生命周期的概念，把开发分割为顺序阶段构成的过程，实施起来不现实，造成了以下直接的危害。

•         希望通过对各个阶段设置关卡，严格控制，以期更早地发现问题，却滞后了集成和测试，让错误的发现延迟到 后，这是很多项目失败的根源。

•         希望一开始就能设定完整和正确的需求，这对软件产品越来越不可能，因为用户也不知道或说不清楚自己想要什么。事实上，对需求的挖掘和理解，应该是一个持续的过程，需要不断的反馈。

•         把成功定义为“遵循 初的计划和范围”。为了确保项目的“成功”而避免或拒绝进行合理的变更，却忽略了“达成商业目标才是真正的成功”。这已经成为业务成功的一个严重障碍。

另一方面，传统产品开发方法强调控制，所以一旦流程出现问题，自然的应对就是进一步加强管控，流程本身有自我复杂化的趋势，反而会压制关键软件开发人员的主观能动性。

面对以上问题，对传统软件开发方法的反思，几乎与其本身一样悠久。比如，瀑布模型的提出者 Wiston Royce 1970 年在他的论文 ^[3] 中，只是把瀑布模型作为一个理论模型提出，并警告人们它绝对不适合用来进行大型软件开发。在论文的后半部分，Royce 提出了一个包含原型和各阶段之间反馈的修正模型。遗憾的是，业界当时渴望的是一种建构式工程方法，瀑布模型迎合了这一要求，导致反对瀑布模型的 Royce 反倒被业界称为“瀑布模型之父”。至于 Royce 的忠告，也只有等到 30 年后敏捷运动兴起时才又被人们重新提起。