| 软件开发 |
| --- |
| 
核心行动 |
| * 过程
* 需求
* 设计
* 工程
* 构造（英语：）
* 测试
* 偵錯
* 部署
* 維護
 |
| 
范式与模式 |
| * 原型设计（英语：）
* 净室（英语：）
* 增量建模（英语：）
* 瀑布模型
* 敏捷软件开发
* 螺旋模型
 |
| 方法论与框架 |
| * 快速應用程式開發
* DevOps
* 极限编程
* 团队软件流程（英语：）
* 個人軟體程序
* 动态系统开发方法（英语：）
* MSF（英语：）
* Scrum
* 看板
* V模型
* FDD（英语：）
* MDD
* 迭代式开发
* 精實开发
* 统一流程（英语：）
 |
| 
支持行为 |
| * 配置管理
* 文档
* 质量保证
* 项目管理
* 用户体验
 |
| 
实践 |
| * ATDD（英语：）
* 行为驱动开发
* 持續整合
* 持續交付
* 領域驅動設計
* 结对编程
* 站会
* 测试驱动开发
 |
| 工具 |
| * 編譯器
* 偵錯器
* 性能分析
* GUI设计器（英语：）
* 建模（英语：）
* 集成开发环境
* 組建自動化
* 发布自动化（英语：）
* 测试
 |
| 
标准与知识体系 |
| * 能力成熟度模型集成
* IEEE标准
* ISO 9001
* ISO/IEC标准（英语：）
* SWEBOK（英语：）
* 项目管理知识体系
* BABOK（英语：）
 |
| * 
* 论
* 编
 |

  

**精益软件开发**是精益制造原则和实践在软件开发领域的变体。它基于丰田生产方式（TPS），由敏捷社区引入并发展。

起源
--

**精益软件开发**一词源于Mary Poppendieck和Tom Poppendieck的同名书籍。这本书将传统的精益原则重新阐释，提供了22种开发实践"工具"，并与敏捷开发的实践做了比较。
通过Poppendieck夫妇在敏捷软件开发社区中的努力，包括在敏捷开发会议上的几次演讲，精益软件开发已经被敏捷开发社区广泛接受。

精益原则
----

和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：

* 消除浪费
* 增强学习
* 尽量延迟决定
* 尽快发布
* 下放权力
* 嵌入质量
* 全局优化

### 消除浪费

消除浪费（或者叫muda（英语：）（日语：），是丰田管理词典中的一种特殊的浪费）原则，最初是由大野耐一（丰田生产方式之父）的理念所采用的。他将如下行为视为浪费：

* 储存的等着被使用的汽车零配件
* 生产任何不是马上就需要的产品
* 不必要的配件移动
* 等待其他配件被生产
* 制造过程中多余的处理步骤
* 缺陷（质量差）

换句话说，按照精益思维，任何不能为客户增加价值的行为即是浪费。包括：

* 不必要的功能和代码
* 软件开发过程的延迟
* 不明确的需求
* 繁文缛节
* 低效的内部沟通

为了消除浪费，首先必须能够识别、认识到浪费。如果某项活动可以被跳过或者取消也能达成最终的结果，那它就是浪费。在开发过程中作成但最终被废弃的代码是浪费；客户不经常使用的额外的处理和特性是浪费；令人员在多个任务间切换是浪费；等待其他任务是浪费；缺陷和低品质是浪费；不产生实际价值的、过度的管理也是浪费。

价值流（英语：）方法可以用来识别浪费。指出浪费的根源并消灭它。消除浪费的活动应该迭代进行，最终甚至可以消除一些看似必要的流程。

### 增强学习

面对开发团队以及最终的产品大小的额外挑战，可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示，并听取他们的反馈来完成。

使用短周期的迭代（每个迭代都应包括重构和集成测试）可以加速学习过程。在决定当前阶段的开发内容并对未来改善的努力方向进行调整时，在客户端帮助下通过简短的反馈会议来增强反馈。通过这些简短的反馈会议，客户代表和开发团队会更多地发现在进一步开发时会遇到的主要问题及可能的解决方案。从而，基于已开发出的原型，客户可以更好地理解自己的需求，开发者也能了解到如何才能更好地满足客户的需求。另一个关于和客户沟通、学习的想法是"基于组的开发"，这种方法聚焦于未来解决方案的约束限定而不是各种可能的解决方案，因此通过和客户的对话加速了解决方案的产生。

### 尽量延迟决定

因为软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。

### 尽快发布

在一个技术发展非常迅速的时代，尽早的发布产品有助于更快的获得用户的反馈来改善当前产品的质量，从而更快的完成下一次迭代。如果每一次快速的发布都能满足用户的需求，那么这个产品就可以视为成功的。每一次迭代的时间越短，团队内部的学习和交流就会变得更好。拥有了速度，决策会被延迟。拥有了速度，就可以更好的满足客户当前而非昨天的需求。

### 下放权力

传统的团队里都是由团队的领导者来决定和分配每个人所要完成的任务。但是精益开发主张将这种权利下放到团队的每个人手里，从而使开发人员有权利来阐述自己观点并提出建议。

### 嵌入质量

质量的管理在精益软件开发中尤其重要。在这里，质量的保证一开始便被贯穿在开发过程中的每一个阶段，而不只是在测试阶段来发现质量问题。

### 全局优化

全局优化使得每个部门之间的联系更紧密。相对于努力降低每个部门内的成本，消除部门之间的隔阂和浪费会产生更显著的效果。在DevOps成为一大趋势的今天，开发部门，质量管理部门和运行维护部门之间的协同变得越来越重要了。

參看
--

* Scrum (development)

外部連結
----

* Interview with Mary Poppendieck （页面存档备份，存于）
* Mary Poppendieck, Tom Poppendieck *Lean Software Development: An Agile Toolkit for Software Development Managers*
* Lean-Agile Straight Talk A podcast hosted by author Jim Trott and featuring author Alan Shalloway about Lean Software Development and Agile Software Development.
* Lean Software Institute （页面存档备份，存于）
* Improving Agile through Lean, or The Essence of Lean Software Development Insights into Lean Software Development from projects, and implementation notes around extending Agile through Lean.
* InfoQ.com / Agile (includes Lean) （页面存档备份，存于） - Tracking change and innovation in the enterprise software development community (News, Articles, Books, Video)
* Lean-Agile-Scrum - a discussion group for those interested in how Lean, Agility, and Scrum work together
* Lean Programming - a discussion group for those interested in programming in Lean Software Development environments
* Training in Lean Software Development （页面存档备份，存于） Net Objectives training in Lean Software Development
* develop software by using the principples in Lean. We have written a book about it. "Lean in software development´"


1. ↑  Yasuhiro Monden.. Engineering & Management Press. 1998. ISBN 0-412-83930-X.
2. ↑  Mary Poppendieck; Tom Poppendieck.. Addison-Wesley Professional. 2003. ISBN 978-0-321-15078-3.
3. ↑  Mary Poppendieck、Tom Poppendieck、朱崇高.. 清华大学出版社. 2004-02. ISBN 9787302078678.