精益软件开发的灵感来自精益制造，而丰田是这一领域的开拓者。现在得知丰田的软件开发部门一直在用传统的瀑布式开发，而他们刚刚才开始采用精益软件开发，这着实让人非常吃惊。Henrik Kniberg 在一篇描述他去年精益参观考察的博文中公布了这一点。Henrik 和他的小组成员借机访问过丰田汽车公司及他们的软件开发负责人：
我们非常荣幸地会见了 Satoshi Ishii，嵌入式软件开发事业部的经理——给汽车用的软件是他们的产品的一种。他的英语有点儿结结巴巴，我没有记录详细的笔记，所以下面有些引述和谈话是意译的。
他首先开口说道：“关于精益软件开发，我想你们知道的比我们多”，这让我们一开始就很意外。之后的谈话变得越来越有意思。
Henrik 对丰田的访问充满了意外。当他问及丰田是否考虑过敏捷软件开发方法时：
我们问 Ishii-san 他是否考虑过敏捷软件开发。他有敏捷方面的知识，同时喜欢敏捷的想法，并表示他们可能会朝那个方向发展。但他们会按丰田的方式去做——以耐心而有条不紊的方式，敏捷本身不是目的。我非常赞同这点。
他说“我们正在尝试学习如何把 TPS（= 在西方我们称之为精益）应用到软件开发上”。可以想象我们脸上的表情。我们到那里，从我们认为是精益软件开发的圣地学习，此前我们大多数人预期那里会让人眼花缭乱、印象深刻。
丰田团队已经发现的很多东西与敏捷世界中的想法是非常匹配的，而其中有些是相反的：
最大的障碍之一是他们目前的软件架构。他没有给出细节，只是提到要使用精益或敏捷软件开发的话，他们要对现有架构做很大的改动。我相信应该倒过来——精益和敏捷软件开发提供了一种迭代和增量式的方法，可以实现架构的改动。
他强调了在早期进行测试以及修正缺陷的重要性。修正在生产阶段发现的缺陷，比修正在做原型期间发现的缺陷的成本高大约 50 倍。如果缺陷是在生产阶段后发现的，修正成本大约高 1000～10000 倍。我见过其他调查给出了类似的数字。他给我展示了一些数据，直观地用柱状图表示。
Israel Gatt，也写下了我们可以从丰田目前困境中学习的三件事情：
无论你们实践的是何种敏捷方法——Scrum、精益（Lean）、看板（Kanban）、Crystal 等等——你们应该从上面提到的丰田经历中认识到 3 点：
- 就像丰田的生产系统，你们的软件方法就是“一辆车”，受上层战略决策的支配。但是，它无法弥补决策失败。
- 如果你的公司追求不断地增长，带来的质量 / 技术债务很可能轻易超过增长带来的好处。考虑增长潜力的收益时，要跟技术债务可能导致的损失进行比较。在适当情况下，可以使用《收支平衡表中的技术债务》这篇文章中的方法用金钱计算技术债务。
- 除了用金钱计算技术债务外，还可以使用《行政套房中的视角》这篇文章中的方法去评估不同的风险。丰田自身的经历表明了灾难性的后果会是什么样子。
考虑到丰田目前在其软件开发中存在的问题，我们不得不想：如果他们用不同方式去开发软件，他们会像今天这样吗？
查看英文原文： Toyota Using Waterfall?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论