读《丰田生产方式》——联系敏捷开发的思考

平时工作和同事讨论敏捷,曾多次听到丰田的精益思想,说是很多敏捷的想法都是从丰田的精益思想中得来的,后来在Kent Beck的《解析极限编程》里看到有这样一本书是讲丰田的精益思想的,找来看了一下,发现书中讲的一些思想或者实践和敏捷开发很相似,下面我就讲讲我对于丰田生产方式和敏捷开发的一些联系。

一、逆向思维,由生产的最后一道工序为起点,从后往前推进。

丰田生产方式的两大支柱是准时化和自动化。准时化(Just In Time)是指通过流水作业装配一辆汽车的过程中,所需零部件在需要的时刻,以需要的数量,不多不少的送到生产线的旁边。如何达到这种不多不少的状态呢?丰田的做法是由生产的最后一道工序为起点,从后往前推进。这样以最后要生产的汽车数量,就可以推测所需的零部件各是多少,从而达到降低浪费的目的。

在敏捷开发中,我们如何做到准时化?从相关的敏捷实践来看,测试驱动开发(TDD)就是达到这一目的的过程。先从原始需求上面得到一个个的Story,Story规定了需求的入口和出口,然后再驱动出测试案例,最后由测试案例驱动出产品代码,这样就能保证产品代码的功能是包括了原始需求所要求的功能,但又避免产生过渡设计。这个也是减少浪费的一种过程。

二、每个工人都有一根警报线,在生产过程中发现产品有问题,随时拉线让整个生产线停止,等待解决问题后再恢复生产。

丰田生产方式的另外一个支柱是自动化。丰田使用了很多自动化机器,但自动化的标准不是简单的去使用机器,而是实现人的自动化。丰田几乎所有的机器设备都装有自动停止装置,平时机器自动运转的时候用不到人,如果生产过程中发现问题,人会去停止机器,然后修复问题,重新启动机器。如果在生产过程中发现问题没有及时停止生产,那就可能生产出大量的残次品,这些残次品无法装配到汽车上,是一种很大的浪费。

在敏捷开发中,持续集成体现的就是这种自动化思想。在持续集成的过程中,一旦发现问题(比如单元测试跑失败了),服务器就会马上停止构建,并通知相关的开发人员进行问题修复,等问题修复完成后,再重新进行构建。这样每当问题出现,我们就可以以最小的代价找到问题的根源,然后修复它。如果等问题遗留到后面的测试阶段或者生产阶段,再去找问题的根源,所需的代价就要大的多得多。

光有持续集成的服务器还不行,服务器不会自己去编译、测试、部署,所有这些行为都需要人去开发出相应的脚本,然后在服务器上运行,这就是所谓的“人的自动化”。开发人员应该将所有可以自动化的东西都做成自动化,让单元测试自动化,集成测试自动化,部署自动化,总之一个目的,减少浪费,这也是丰田生产一直追求的目标之一。

三、看板

看板在丰田生产中是一种工具,在生产中起到一个传递情报和指令的作用。

敏捷开发很好的运用了看板。有过敏捷开发经验的同学应该知道,敏捷中的看板就是整天摆在你跟前的那块白板,白板上将开发过程分成好几个阶段,每个阶段上面贴着该阶段下的开发任务,通过白板可以随时了解项目的进展。

其他思想和实践

除了和敏捷开发有这些联系外,丰田生产方式还有一些思想和实践适合软件开发。

一人掌握多种技能,每个人都是多面手。

由于历史和文化的原因,美国的的制度是,车工始终是车工,焊工永远是焊工;日本的制度是,工人既能操作车床,也能开钻床,而且能焊接,能够学会和掌握多种技能。

两种制度孰优孰劣很难确定,但个人认为,在软件开发高速发展的今天,开发人员应该要有更高的要求。开发人员所掌握的技能不仅仅是会编写产品代码,还要会写单元测试,会部署,会搭建环境等等。比如在缺少测试人员的情况下,开发人员可以自己测试,依靠开发的编程技能可以写出更好的测试代码。要能够快速学会和掌握多种技能。

反复问5个为什么

比如一台机器不转动了,你就要问:

  1. 为什么机器停了?——“因为超负荷,保险丝断了。”
  2. “为什么超负荷了呢?”——“因为轴承部分的润滑不够。”
  3. “为什么润滑不够?”——“因为润滑泵吸不上油来。”
  4. “为什么吸不上油来呢?”——“因为油泵轴磨损,松动了。”
  5. “为什么磨损了呢?”——因为没有安装过滤器,混进了铁屑。”

通过问5个为什么就可以知道需要安装过滤器了。如果问题问的不彻底,可能是加上润滑油,或者换上油泵轴了事,这样等过了一段时间后问题还是会出现。丰田生产方式可以说是丰田人反复问5个为什么才创造出来的。

拥抱小团队,不要大块头

团队合作高于一切,由于合作或其他种种原因,人少的团队反而容易取胜。小船容易转舵,大船步履阑珊,小团队的灵活性更强,这也符合敏捷开发的原则——要做到简洁。

Comments