取自Shigeo Shingo的丰田精益制造。与制造业进行对比，是因为比起想象一个软件，我们更容易想象制造一辆汽车。
| 制造 | 软件开发 |
|---|---|
| 在制品库存 | 部分完成的工作 |
| 过度生产 | 额外功能 |
| 额外的过程 | 重复学习和手工动作 |
| 运输 | 任务交接 |
| 移动 | 人员任务切换 |
| 等待 | 延迟 |
| 缺陷 | 缺陷 |
- 部分完成的工作。就像一辆组装了一半的车，还缺个轮子，它是无法上路使用的。借助自动化测试的保护，建立能够容易和安全地修改的软件。这样就能灵活应对变化，及时生产。不用在4S店里停着很多车。
- 额外功能。做很多没人用的镀金功能，求大求全。
- 重复学习。不了解之前的历史，就总是在重复地以前的步骤，于是有了软件考古学。明明可以一步完成甚至自动化手段，非得靠人工来做，或步骤繁琐。明明一个团队公约可以让大家达成一致理解，却一次次犯低级错误。
- 交接。只给一本手册和一部车，别人是学不会开车的，因为很多隐性知识并没有在文档中体现。每次交接都丢失了一些隐形知识，积少成多。2次交接后还剩25%，5次交接后还剩3%。瀑布模式强制了这种交接。比如开发把工作移交给运维，每个人都对整体缺乏责任感。
- 人员任务切换。一种是个人的多任务切换，要不断要记住同时开展的各个事项，而且每件事的完成时间都拉长了。另一种是人员不稳定，经常被调来调去，团队没有机会磨合达到高效状态。
- 延迟。开发人员每15分钟就要做一次重要决定，你无法在文档中找到所有的必要信息。如果程序员不理解代码，基本功缺失，决策就会延迟。另外，不同团队的协作也会导致时间在“找人”中消逝。不合理的依赖与耦合关系也造成延迟。
- 缺陷。缺陷意味着返工，甚至价值损失。我们的目标是预防大于追踪缺陷，这需要纪律性，才能在短的时间段中争取一次性地做对。用自动化测试和面对面沟通来代替需求规格书吧，用持续集成阻止“破窗”效应吧。
在精益思想里有 Muri（过载）, Mura（波动）,Muda（浪费）的说法。精益不只是讲浪费的事情。对于智力型工作，比如IT开发，想要顺畅流动，除了考虑消除7大浪费，要考虑系统过载的比如996加班带来的疲劳和响应力下降；另一方面，别幻想将智力型工作完全地拆分成同样粒度的任务来减少波动，而是要从规范性（代码规范、界面风格、团队公约、DoD、CI纪律等）来减少波动，少出意外，防呆，从而提高规范性。
“Implementing Lean Software Development: From Concept to Cash”, by Mary and Tom Poppendieck