平时工作和同事讨论敏捷，曾多次听到丰田的精益思想，说是很多敏捷的想法都是从丰田的精益思想中得来的，后来在Kent Beck的《解析极限编程》里看到有这样一本书是讲丰田的精益思想的，找来看了一下，发现书中讲的一些思想或者实践和敏捷开发很相似，下面我就讲讲我对于丰田生产方式和敏捷开发的一些联系。
一、逆向思维，由生产的最后一道工序为起点，从后往前推进。
丰田生产方式的两大支柱是准时化和自动化。准时化（Just In Time）是指通过流水作业装配一辆汽车的过程中，所需零部件在需要的时刻，以需要的数量，不多不少的送到生产线的旁边。如何达到这种不多不少的状态呢？丰田的做法是由生产的最后一道工序为起点，从后往前推进。这样以最后要生产的汽车数量，就可以推测所需的零部件各是多少，从而达到降低浪费的目的。
在敏捷开发中，我们如何做到准时化？从相关的敏捷实践来看，测试驱动开发（TDD）就是达到这一目的的过程。先从原始需求上面得到一个个的Story，Story规定了需求的入口和出口，然后再驱动出测试案例，最后由测试案例驱动出产品代码，这样就能保证产品代码的功能是包括了原始需求所要求的功能，但又避免产生过渡设计。这个也是减少浪费的一种过程。
二、每个工人都有一根警报线，在生产过程中发现产品有问题，随时拉线让整个生产线停止，等待解决问题后再恢复生产。
丰田生产方式的另外一个支柱是自动化。丰田使用了很多自动化机器，但自动化的标准不是简单的去使用机器，而是实现人的自动化。丰田几乎所有的机器设备都装有自动停止装置，平时机器自动运转的时候用不到人，如果生产过程中发现问题，人会去停止机器，然后修复问题，重新启动机器。如果在生产过程中发现问题没有及时停止生产，那就可能生产出大量的残次品，这些残次品无法装配到汽车上，是一种很大的浪费。
在敏捷开发中，持续集成体现的就是这种自动化思想。在持续集成的过程中，一旦发现问题（比如单元测试跑失败了），服务器就会马上停止构建，并通知相关的开发人员进行问题修复，等问题修复完成后，再重新进行构建。这样每当问题出现，我们就可以以最小的代价找到问题的根源，然后修复它。如果等问题遗留到后面的测试阶段或者生产阶段，再去找问题的根源，所需的代价就要大的多得多。
光有持续集成的服务器还不行，服务器不会自己去编译、测试、部署，所有这些行为都需要人去开发出相应的脚本，然后在服务器上运行，这就是所谓的“人的自动化”。开发人员应该将所有可以自动化的东西都做成自动化，让单元测试自动化，集成测试自动化，部署自动化，总之一个目的，减少浪费，这也是丰田生产一直追求的目标之一。
三、看板
看板在丰田生产中是一种工具，在生产中起到一个传递情报和指令的作用。
敏捷开发很好的运用了看板。有过敏捷开发经验的同学应该知道，敏捷中的看板就是整天摆在你跟前的那块白板，白板上将开发过程分成好几个阶段，每个阶段上面贴着该阶段下的开发任务，通过白板可以随时了解项目的进展。
其他思想和实践
除了和敏捷开发有这些联系外，丰田生产方式还有一些思想和实践适合软件开发。
一人掌握多种技能，每个人都是多面手。
由于历史和文化的原因，美国的的制度是，车工始终是车工，焊工永远是焊工；日本的制度是，工人既能操作车床，也能开钻床，而且能焊接，能够学会和掌握多种技能。
两种制度孰优孰劣很难确定，但个人认为，在软件开发高速发展的今天，开发人员应该要有更高的要求。开发人员所掌握的技能不仅仅是会编写产品代码，还要会写单元测试，会部署，会搭建环境等等。比如在缺少测试人员的情况下，开发人员可以自己测试，依靠开发的编程技能可以写出更好的测试代码。要能够快速学会和掌握多种技能。
反复问5个为什么
比如一台机器不转动了，你就要问：
- 为什么机器停了？——“因为超负荷，保险丝断了。”
- “为什么超负荷了呢？”——“因为轴承部分的润滑不够。”
- “为什么润滑不够？”——“因为润滑泵吸不上油来。”
- “为什么吸不上油来呢？”——“因为油泵轴磨损，松动了。”
- “为什么磨损了呢？”——因为没有安装过滤器，混进了铁屑。”
通过问5个为什么就可以知道需要安装过滤器了。如果问题问的不彻底，可能是加上润滑油，或者换上油泵轴了事，这样等过了一段时间后问题还是会出现。丰田生产方式可以说是丰田人反复问5个为什么才创造出来的。
拥抱小团队，不要大块头
团队合作高于一切，由于合作或其他种种原因，人少的团队反而容易取胜。小船容易转舵，大船步履阑珊，小团队的灵活性更强，这也符合敏捷开发的原则——要做到简洁。