(Lean)精益开发原则和起源
精益起源
精益软件开发一词起源于Mary Poppendieck 和Tom Poppendieck写的一本同名书籍。这本书将传统的精益原则以一种新的方式呈现---作为22种敏捷开发实践工具之一，并且和其他工具进行了比较。Mary 和 Tom's 在敏捷软件开发社区中提出的改进，包括在敏捷开发会议上的几次演讲，已经形成了被敏捷开发社区广泛接受的概念。例如：咨询公司NetObjectives 和C.C. Pace 就使用了“精益-敏捷”以及其他一些列入的概念。
精益7条原则
尊重一线人员
工作在一线的人最了解实际情况，他们知道现在发生了什么，知道当前情况下的最佳应对方法；
他们熟知每天使用的工具、流程、规则，因而完全具备足够的知识提出改进意见；
要充分尊重一线人员的意见；
消除浪费
消除浪费（或者叫muda,是丰田管理词典中的一种特殊的浪费）原则，最初是由Taiichi Ohno（丰田生产方式之父）的理念所采用的。他将如下行为视为浪费：
储存的等着被使用的汽车零配件生产任何不是马上就需要的产品不必要的配件移动等待其他配件被生产制造过程中多余的处理步骤缺陷（质量差）换句话说，按照精益思维，任何不能为客户增加价值的行为即是浪费。包括：
不必要的功能和代码软件开发过程的延迟不明确的需求繁文缛节低效的内部沟通为了消除浪费，首先必须能够识别、认识到浪费。如果某项活动可以被跳过或者没有这些活动也能达成最终的结果，那它就是浪费。在开发过程中作成但最终被废弃的代码是浪费。客户不经常使用的额外的处理和特性是浪费。等待其他活动、团队、处理是浪费。缺陷和低品质是浪费。不产生实际价值的、过度的管理也是浪费。以价值流来区分的方法被用来区分识别浪费。第二步就是指出浪费的根源并消灭它。持续不断的消除浪费直到一些甚至看起来必不可少的过程和步骤被清除。
增强学习
面对开发团队以及最终的产品大小的额外挑战，可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示，并听取他们的反馈来完成。
使用短周期的迭代（每个迭代都应包括重构和集成测试）可以加速学习过程。在决定当前阶段的开发内容并对未来改善的努力方向进行调整时，在客户端帮助下通过简短的反馈会议来增强反馈。通过这些简短的反馈会议，客户代表和开发团队会更多地发现在进一步开发时会遇到的主要问题及可能的解决方案。从而，基于已开发出的原型，客户可以更好地理解自己的需求，开发者也能了解到如何才能更好地满足客户的需求。另一个关于和客户沟通、学习的想法是“基于组的开发”，这种方法聚焦于未来解决方案的约束限定而不是各种可能的解决方案，因此通过和客户的对话加速了解决方案的产生。
尽量延迟决定
因为软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。
嵌入质量
质量是在过程中产生的；
如果在开发流程的每一个阶段，都能保证产出物的质量，最终产品的质量就能以最低的代价实现；
过程中保证质量能大量减少浪费，质量是过程的一部分；
快速交付
快速交付的好处数不胜数，譬如能够使客户更早地得到产品价值，能使产品更快地投入市场；
整体优化
局部的优化，若不能带来整体的改善，将是没有价值的；
