精益软件开发一词起源于Mary Poppendieck 和Tom Poppendieck写的一本同名书籍。这本书将传统的精益原则以一种新的方式呈现—作为22种敏捷开发实践工具之一，并且和其他工具进行了比较。
精益软件开发七项原则：
消除浪费
内建质量
创建知识
推迟决策
快速交付
对人尊重
整体优化
敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。敏捷软件开发又称敏捷开发，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于”非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。敏捷方法有很多具体实践或者框架，如Scrum，XP，FDD等。
精益和敏捷软件开发的共同之处
目标都是要提高客户所感知到的软件的质量，以及软件开发过程的生产力。
都肯定和欢迎贯穿项目过程中几乎一定会发生的需求变更
都将交付满足客户真正需求而不是初期认为的客户需求的软件作为最高价值
敏捷软件开发主要的聚集点：和客户密切协作，尽早地迅速交付可用的软件。
精益方法看到这些都是有意义的，但其主要聚集点是：在对客户有价值的上下文环境下消除浪费。
基本观点与哲学上不同
敏捷：和客户密切协作，尽早地迅速交付可用的软件
精益：在对客户有价值的上下文环境下消除浪费
角度不同
敏捷的关注重点稍窄些
主要关心的是围绕软件开发的具体开发实践和项目管理
一般不太关心在其中进行软件开发的商业上下文环境
精益采用比较宽泛的视角，偏好一体看待软件开发和它的整个业务环境
敏捷开发有相当一批正规的方法学，而精益开发则没有正规的方法学。在实施精益软件开发时，通常的一个选择便是选择一个轻量型敏捷方法学作为起点，并从那里开始应用其他精益工具（如价值流图）。
精益被应用的范围要广的多，尤其是其在部门、组织及产业链上推广的思路有助于敏捷向部门、组织及合作伙伴间推广时借鉴。
关于看板
从客户角度出发进行拉动，运用看板来实现拉动，这一流程设计思路在很多行业均被证实卓有成效，是实施精益的重要步骤之一。但即使如此，把实施精益看做应用一系列工具是片面甚至危险的。精益意味着交付方式的变革，很多公司在尝试精益的时候都没有准备好按需调整自己的组织架构、管理方法和行为习惯，甚至认为这些是不可动摇的，搞不清它们和交付方式之间谁为主导，谁为支持。这也是早期大部分的精益变革被认为“不适合我们”、“应用场景局限”、“太过理想”，并以失败告终的重要原因。实施精益是项系统工程，而且最终会反映到个体和团队能力与观念的改变上来，工具始终只是工具。
看板和敏捷中的故事墙总得来说是服务一个目的。但是在故事墙的基础上有几点改进：
（1）给故事附加了一些元信息，把以前项目经理关心的一些额外信息也可视化出来。
（2）强调限制“在制品数量”，也就是各个“泳道”中故事的数量，让瓶颈更容易暴露出来。
（3）引入拉动概念，只有一个卡（故事）被验收（或集成了）才可以依次移动前面的卡，让一个卡在流动过程中的“阻塞现象”成为要解决的大问题。
（4）没有清晰的迭代概念了，以前的“迭代启动会议”按需召开，会议的时间也大大压缩。由围绕“一组故事”进行的迭代开发变为围绕“一个个故事”的持续流开发。这消灭了迭代开发中的各种“不均衡”现象，比如前松后紧，迭代快结束时为了完成更多故事，项目经理积极“干预”，确保开发人员没做故事之外的内容，重要的Bug能被修正，甚至还会执行不同的标准。
（5）大小尽量一致的故事，简化了评估的工作。
编辑整理了目前对于敏捷与精益的关系的主流看法，供读者学习与甄别，不代表本站看法。如有跟多问题需要咨询，请拨打本站客服电话或联系我们的顾问。
