丰田在使用瀑布式开发？

作者 Amr Elssamadisy 译者 石永超 发布于 2010年4月7日

领域

过程 & 实践

主题

精益 ,

敏捷技术 ,

敏捷 ,

丰田生产系统

分享到

精益软件开发的灵感来自精益制造，而丰田是这一领域的开拓者。现在得知丰田的软件开发部门一直在用传统的瀑布式开发，而他们刚刚才开始采用精益软件开发，这着实让人非常吃惊。Henrik Kniberg在一篇描述他去年精益参观考察的博文中公布了这一点。Henrik和他的小组成员借机访问过丰田汽车公司及他们的软件开发负责人：

我们非常荣幸地会见了Satoshi Ishii，嵌入式软件开发事业部的经理——给汽车用的软件是他们的产品的一种。他的英语有点儿结结巴巴，我没有记录详细的笔记，所以下面有些引述和谈话是意译的。

他首先开口说道：“关于精益软件开发，我想你们知道的比我们多”，这让我们一开始就很意外。之后的谈话变得越来越有意思。

Henrik对丰田的访问充满了意外。当他问及丰田是否考虑过敏捷软件开发方法时：

我们问Ishii-san他是否考虑过敏捷软件开发。他有敏捷方面的知识，同时喜欢敏捷的想法，并表示他们可能会朝那个方向发展。但他们会按丰田的方式去做——以耐心而有条不紊的方式，敏捷本身不是目的。我非常赞同这点。

他说“我们正在尝试学习如何把TPS（=在西方我们称之为精益）应用到软件开发上”。可以想象我们脸上的表情。我们到那里，从我们认为是精益软件开发的圣地学习，此前我们大多数人预期那里会让人眼花缭乱、印象深刻。

丰田团队已经发现的很多东西与敏捷世界中的想法是非常匹配的，而其中有些是相反的：

最大的障碍之一是他们目前的软件架构。他没有给出细节，只是提到要使用精益或敏捷软件开发的话，他们要对现有架构做很大的改动。我相信应该倒过来——精益和敏捷软件开发提供了一种迭代和增量式的方法，可以实现架构的改动。

他强调了在早期进行测试以及修正缺陷的重要性。修正在生产阶段发现的缺陷，比修正在做原型期间发现的缺陷的成本高大约50倍。如果缺陷是在生产阶段后发现的，修正成本大约高1000～10000倍。我见过其他调查给出了类似的数字。他给我展示了一些数据，直观地用柱状图表示。

Israel Gatt，也写下了我们可以从丰田目前困境中学习的三件事情：

无论你们实践的是何种敏捷方法——Scrum、精益（Lean）、看板（Kanban）、Crystal等等——你们应该从上面提到的丰田经历中认识到3点：

• 就像丰田的生产系统，你们的软件方法就是“一辆车”，受上层战略决策的支配。但是，它无法弥补决策失败。
• 如果你的公司追求不断地增长，带来的质量/技术债务很可能轻易超过增长带来的好处。考虑增长潜力的收益时，要跟技术债务可能导致的损失进行比较。在适当情况下，可以使用《收支平衡表中的技术债务》这篇文章中的方法用金钱计算技术债务。
• 除了用金钱计算技术债务外，还可以使用《行政套房中的视角》这篇文章中的方法去评估不同的风险。丰田自身的经历表明了灾难性的后果会是什么样子。

考虑到丰田目前在其软件开发中存在的问题，我们不得不想：如果他们用不同方式去开发软件，他们会像今天这样吗？

查看英文原文：Toyota Using Waterfall?

译者 石永超 是Irdeto BSS软件工程师，CSM，敏捷爱好者，《User Stories Applied中文版》译者之一。

1. 返回顶部

   有点意思！杀向了精益的圣地。被雷了一下。

   发表人 Li Johnny

   有点意思！杀向了精益的圣地。被雷了一下。

   回复