精益这个词儿最开始来自于制造业，日本的丰田汽车，精益管理的思想帮助丰田汽车成为全球销量最多，盈利能力最强的车企，这两项纪录，丰田保持了10多年。
上世纪八十年代开始，丰田的效率震惊了美国车企，他们老早就研究丰田的 方法，给它取的英文名叫作 Lean Production。后来他们发现这套方法不光能管生产，也能管公司整体经营，就延伸成了 Lean Management。这就是 “精益管理”这个词的来源。
Lean 的英文原意是精瘦的、没有脂肪。这个词语凸显丰田生产方式的精髓。精益管理最终达到效果，就像是一个人去健身，减脂增肌。对应制造业和软件研发来说就是消除浪费。
下图是制造业和软件研发分别对应的7种类型的浪费，特别是第4个，任务切换在研发里面不可见且极易造成浪费。
组织里面我们通常说，能者多劳，对于团队来说也是这样的，当一个团队能承接的任务比较多的时候，往往需要应对更多的需求，但是当需求数量超过一定程度后，团队的管理者就会发现极易造成系统的质量下降，员工的士气低迷。
Partially Done Work：
部分完成的软件开发有一种过时的趋势，并且它会妨碍可能需要完成的其他开发。但是，部分完成的软件最大的问题是，你可能不知道它最终是否会工作。当然，你有一堆需求和设计文档。您甚至可能有一堆代码，这些代码甚至可能进行了单元测试。但是，直到软件集成到环境的其余部分，您才真正知道可能潜伏着什么问题，并且直到软件实际投入生产，您才真正知道它是否能够解决业务问题。在软件开发中我们常需要定义DOD，也就是一件事情的完成的真正定义，当开发说他完成的时候并不仅仅是编码完成。
Extra Process：
你有没有问过，有些文书工作真的有必要吗?文书工作消耗资源。文书工作减慢了响应时间。文书工作掩盖了质量问题。文书工作丢了。文书工作退化，变得过时。没有人愿意阅读的文书工作没有任何价值。
许多软件开发过程需要客户签字的文书工作，或者提供可追溯性，或者获得变更的批准。你的客户真的觉得这会让产品对他们更有价值吗?仅仅因为文书工作是必须交付的，并不意味着它增加了价值。如果你的文书工作对客户几乎没有任何价值，那么你要记住以下三条规则:让它短小，让它保持高水平。离线完成。
对安全至关重要的系统经常受到监管，并且经常需要编写可追溯到代码的需求。在这种情况下，对需求进行格式化，以便可以轻松地评估和检查其完整性，这可能是一种增值活动。寻找表格驱动或模板驱动的格式，将需求减少为用户和开发人员都能快速理解和验证的压缩格式。
Extra Features：
在系统中添加一些额外的功能似乎是个好主意，以备不时之需。开发人员可能希望添加一个新的技术功能，只是为了看看它是如何工作的。这看似无害，但恰恰相反，这是严重的浪费。系统中的每一段代码都必须被跟踪、编译、集成，并在每次触及代码时进行测试，然后在系统的生命周期内对其进行维护。每一点代码都增加了复杂性，是一个潜在的故障点。额外的代码很有可能在使用之前就过时了;毕竟，一开始就没有真正的需求。如果现在不需要代码，那么将其放入系统是一种浪费。抵制诱惑。
Task Switching：
将人员分配到多个项目是浪费的来源。每次软件开发人员在任务之间切换时，当他们集中思想并进入新任务的流程时，就会产生大量的切换时间属于多个团队通常会导致更多的中断，从而导致更多的任务切换。这种切换任务的时间是浪费。
完成使用相同资源的两个项目的最快方法是一次只做一个。假设你有两个项目，每个项目都需要两周的时间。如果你开始其中一项，应该在两周内完成。当它完成后，你可以开始第二个项目，它应该在两周内完成。如果你同时开始两个项目，并期望人们在它们之间切换呢?首先，这两件事都不会在两周内完成，但这两件事都能在四周内完成吗?如果加上转换时间，他们可能需要近五周的时间
同时开始几个项目是很难抵制的诱惑，但是向软件开发组织发布太多的工作将会造成大量的浪费，因为它实际上会减慢工作的速度。
组织管理者会有把个人资源都利用到极致的冲动，但是给个人布置太多的任务反而会导致整个事情完成的低效。
Waiting：
软件开发中最大的浪费之一通常是等待事情发生。项目启动的延迟、人员配置的延迟、过多需求文档的延迟、审查和批准的延迟、测试的延迟以及部署的延迟都是浪费。延迟在大多数软件开发过程中是常见的，将这些延迟视为浪费似乎是违反直觉的。在最坏的情况下，延迟似乎是中性的。
那么等待有什么错呢?延迟使客户无法尽快实现价值。当一个关键的客户需求到达您的开发组织时，您的响应速度直接关系到您的开发周期中的系统延迟。
在某些环境中，延迟可能没有其他问题那么严重。然而，如果您正在为一个不断发展的领域开发软件，那么开发延迟就会更加严重。一个基本的精益原则是把决定推迟到最后一刻，这样你就可以做出最明智的决定。这是一种基于选项的软件开发方法，它是处理不确定性的最佳方法。
Motion：
当开发人员有一个问题时，需要多少动作才能找到答案?有人在你身边帮助你解决技术问题吗?客户或客户代表是否可以随时回答有关功能的问题?开发人员不走到大厅就能知道测试结果吗?
开发是一项需要高度集中注意力的活动，所以走在大厅里比你想象的要花更多的时间。开发人员可能需要花费数倍的时间来重新确定焦点，而不是回答问题。正是由于这个原因，敏捷软件开发实践通常建议团队在一个单独的工作室内工作，每个人都可以访问开发人员、测试人员、客户或客户代表。
人并不是唯一会移动的东西——各种各样的文物也会移动。需求可能从分析人员转移到设计人员，然后设计文档从设计人员转移到程序员，然后代码从编码人员转移到测试人员，等等。每个工件的移交都充满了浪费的机会。文档交接中最大的浪费是文档没有——也不可能——真正包含下一个人需要知道的所有信息。大量的隐性知识留在文件的创建者那里，永远不会被移交给复写者。
Defects：
由缺陷引起的浪费量是缺陷影响和未被发现的时间的乘积。在三分钟内检测到的关键缺陷并不是一个大的浪费来源。几个星期不被发现的小缺陷是更大的浪费。减少缺陷影响的方法是在缺陷发生时尽快发现它们。因此，减少由于缺陷造成的浪费的方法是立即测试，集成，并尽快发布到生产中。
文中大部分观点来自于《lean software development 》
