Codeweavers的丰田模式

丰田 极限编程 持续交付

摘要

Codeweavers在开发中将丰田模式与极限编程、持续交付相结合，支持频繁的小版本发布。关于丰田模式的运用，Paul Boocock提出的建议是，从阅读开始，理解理念，并开始教别人。

正文

Codeweavers在开发中将丰田模式与极限编程、持续交付相结合，支持频繁的小版本发布。关于采用丰田模式，Paul Boocock提出的建议是，从阅读开始，理解理念，并开始教别人。

Paul Boocock是Codeweavers的学科带头人，他在Agile Cambridge 2017大会上介绍了Codeweavers如何运用丰田模式的原则。InfoQ正以Q&A、概述、文章的形式对此次大会进行报道。

InfoQ采访了Boocock，了解他们为什么决定使用丰田模式、他们如何持续集成、如何将丰田模式应用于支持服务、他们运用丰田模式的经验教训以及丰田模式给他们带来了什么好处。

InfoQ：在Codeweavers，你们为什么决定开始使用丰田模式？

Paul Boocock：我们从2007年开始就一直在践行敏捷技术，在短暂使用Scrum后，我们很快转向了极限编程（XP）和持续交付（CD）。随着敏捷之旅的继续，我们开始采用各种理念，包括精益和看板，它们把我们引向了丰田生产体系。虽然表面上看，那全是和生产汽车有关，但是，如果深入研究一下，尤其大野耐一的著作，你很快就会看到，如何将这些原则应用到各种各样的生产中，我们在阅读有关丰田生产体系的内容时，发现许多与我们的软件交付方式类似的东西。后来，丰田模式采用了丰田生产体系提出的指导方针，为我们确定工作方式提供了14条可以视为指明灯的原则。我们采用的仍然是一种极限编程的方法，但在我们遇到复杂的问题需要做决策时，丰田模式可以为我们提供帮助。

不久之前，我们遇到了一个问题，生产环境服务器出现了更多的异常。问题并不明显，只是偶尔会在我们没有料到会以那种方式被使用的代码路径中出现。从表面上看，我们可能会想到由一个开发小组来处理这个问题，或者在会上制定一个行动方案，把它指派给某个人来做进一步的研究。那种想法对我们没用；丰田模式教给我们两件事，我们不会把这些作为可行的选项。首先，“通过不断的反省（hansei）和持续的改进（kaizen）变成一个学习型组织”告诉我们要深入研究；我们必须找出问题的根本原因，以便可以改进。看到异常增加，一种做法可以是修复空引用和超时，但是我们一开始为什么留下了这些东西？为什么有这些缺陷的代码会进入生产环境？为什么我们没有第一时间停下来修复这些问题？这样“问五次为什么”可以帮助我们发现问题的根源，而不只是考虑最初的问题。第二，“团队精神胜于一切”；因此，我们不能将这个责任推给某个人或某个开发小组来解决。我们必须让整个团队协调一致，从而保证我们将来不会再犯同样的错误，实际上，一个人的速度比其他人快通常会导致系统变慢。在这个例子中，根本原因让我们了解到，我们的团队已经对异常和超时出现时监控屏幕上的噪音“免疫”了，它们慢慢地增加，通过监控并不能明显地觉察到问题日益严重以及它们有什么影响。我们做出了调整，使用新方法设计了我们的在线监控屏幕（增加了颜色和声音），这样，我们不仅能够更清晰地看到平台哪个地方出现了错误，还能通过声音更清晰地了解问题得不到解决可能产生的后果（监控并显示从本地向线上部署的次数、每小时部署次数以及HTTP错误代码应答）。

InfoQ：是什么让丰田模式的原则这么有价值？

Boocock：每天，我们都需要做出各种选择，如果没有任何帮助，那么我们可能被那些模棱两可的事情弄得不能正常工作。这就是类似丰田模式这样的思想给我们提供帮助的地方，我们把这些理念作为指导方针和基本原则。我们非常倚重的一种理念是，当我们遇到问题时，“问五次为什么”，我们希望找出根本原因；在使用这项技术之前，我们发现自己处于那种典型的情景中，我们寻找问题的解决方案，而不是找出并消除根本原因。我们把这项技术用在了各方面的业务上，不管是查找当前流程中存在的问题，还是探究生产环境的服务故障，或者思考为什么某个东西按照预期的方式执行。另外一个核心理念是“消除浪费”，我们主要是将这个理念应用在软件的持续交付方式上——从减少构建时间和开发项目库存到不在数月之前做一次性计划。还有其他的理念，比如，“团队精神胜于一切”以及“接力棒之妙”改变了我们的协作文化，避免因为特定团队成员的速度是其他人的两倍造成翻船（这是一个很棒的类比，一个团队在划船，如果其中一个人比其他人划的快就会降低到达目的地的速度，因为那样船会跑偏，其他人得设法保持前进方向或为此作出补偿）。

InfoQ：你们是如何做持续交付的？

Boocock：我们在整个代码库中只提供一个trunk流（没有分支）；这使得我们的集成更频繁，库存更少。每次提交到trunk，都会构建和测试受影响的应用程序，然后放入部署队列。我们不创建分支，我们倡导频繁的小版本发布，经常只发布一行代码。我们之所以能够这么做，是因为我们遵循丰田的自动化理念，即具备人类智慧的机器。我们的整个交付管道几乎都是自动化的，本地开发机器上的一次提交10到15分钟就可以进入到生产环境。然而，如果有什么出了问题，我们的交付平台也能立即突出显示，停止所有工作，帮助我们消除所有缺陷，不让他们到达生产环境。这就是丰田生产体系中经常提到的Jidoka。

InfoQ：在Codeweavers，你们如何将丰田模式应用于支持服务？

Boocock：我们的支持团队在很大程度上是受客户驱动的，而生产平准化一直都是挑战。最近，我们在考虑通过运用丰田生产体系的理念提升我们的客户支持水平。在过去的12个月里，我们的支持团队有一个有趣的发展，已经从3个人的团队发展成了8个人的团队；这种增长提出了新的挑战，因为我们相信，员工的成长会提升组织的价值，在Codeweavers，这会给那些理解我们的理念并且能够教给别人的人造成压力。增长为团队带来了其他的挑战，在客户支持方面，要敢于和通常是常识的传统思想做斗争，我们知道并且一直是这样做的。客户支持很容易陷入专业化，专门有人做某个领域的支持，其他人做其他领域，但是，如果每个人都具备所有领域的技能，那么团队的整体工作就会容易许多；在一个汽车制造厂里，对于汽车生产而言，一个学过如何喷漆的电焊工比一个只学过电焊的人更有用。我们设法把这个理念宣贯给我们的支持团队，确保他们有一个广泛的知识面，熟悉平台的所有方面，这样，团队成员就可以互相帮助。专业化仍然很重要，但团队协作更重要，就像许多体育运动一样。尝试一些新东西，帮助支持团队均分工作，这真得很重要；这有助于提升整个团队的速度，让团队更有凝聚力。

InfoQ：你们在运用丰田模式时有什么经验教训？

Boocock：我了解到，西方传统的工作方式并一定是最好的，分批作业（增加库存）和大规模生产非常浪费，显然，频繁的小版本发布（想下XP和CD）是正确的前进方向。我已经采用了让我可以更好地与团队共事的工作方法，确保我的工作负担是可持续的。对我而言，一个重大的变化是关注单件流，就是一次只做一件事，直到把这件事做完；我觉得这样效率更高，而且，当我把卡片移到完工栏时，我获得了更大的动力。

InfoQ：丰田模式为Codeweavers带来了什么好处

Boocock：Codeweavers交付高质量的可工作软件的速度一直让我吃惊。让这一切成为可能的其中许多想法都是从来自丰田的那些原则中产生的。关于交付工作，那是一种很棒的思维方法，而且最终使Codeweavers成为一个很棒的工作场所。《丰田模式》一书中有这样的描述“丰田一直都能生产出质量最好的汽车，缺陷比任何竞争对手都少，而他们所用的工时更少，库存更低，占地面积是竞争对手的一半。”Codeweavers似乎也从采用丰田模式的实践中获得了这种好处。

InfoQ：如果有组织希望使用丰田模式，您有什么建议吗？

Boocock：开始时先读下相关著作。一旦你开始理解这种理念，就把它教给别人。对我而言，有三本著作很重要：艾利·高德拉特的《目标》、大野耐一的《丰田生产方式》和杰弗瑞的《丰田模式》。阅读这些著作并不是银弹，有时候，这些理念可能看不上并不鲜明，难以理解，但是，Codeweavers已经证明，这些理念和原则可以帮助企业转型，从一年向客户发布几次软件，转变成一天发布一百多次。

查看英文原文：The Toyota Way at Codeweavers