亨利·福特的幽灵正在毁掉你的开发团队

人们经常谈论“精益”。也许他们读过《改变世界的机器》，并被精益生产如何改变汽车行业所启发。他们读到日本公司如何变得极其高效，并彻底击败竞争对手，然后就把这些经验运用到他们的软件开发团队中。

这听起来不错，但我常常觉得人们错过了精益生产的真正精髓，仍然沿用臃肿的命令控制结构来管理组织；唯一的区别在于不断强调……

提高效率！别浪费！李

敏捷、DevOps 和其他流行词显然从精益生产中汲取了很多灵感，这些工作方式通过赋予开发团队权力并赋予他们责任，从而获得效率（以及其他更大的好处） 。

大规模生产入门指南

在亨利·福特发明流水线之前，汽车都是由工匠按订单生产的。制造过程耗时很长，而且只有富人才能买得起。

流水线生产使得汽车的生产成本大大降低，从而使汽车能够进入更广泛的市场。

如何？

这是一个很大的话题，但以下是一些简明扼要的要点。

• 为了降低成本，他需要用低技能工人（而不是工匠）大规模生产汽车。
• 装配线是由昂贵、缺乏灵活性的机器组成，可以按规模扩大生产，并且可以由廉价劳动力操作，完成非常简单的任务。
• 强调标准化，能够以低成本、易操作的方式替换一名工人。

问题

装配线对干扰的容忍度非常低。

• 为了平稳生产，不得不增加许多缓冲措施，例如储备物资、空间和额外工人。
• 与其停产，不如在汽车制造完成后接受缺陷并进行修复。

这份工作非常令人沮丧。福特甚至将部分节省下来的资金和利润通过大幅提高员工工资的方式返还给了他们，但人们就是不愿意每天重复数百次同样的枯燥工作。

由于装配线采用昂贵的专用机器进行大规模优化，因此其灵活性很差，制造不同的汽车是一项非常困难且成本高昂的工作。

在设计新车时，它采用了我们现在所熟知的瀑布式方法，项目在许多部门之间流转，由于反馈循环不畅和所有权结构不完善，问题往往在为时已晚时才被发现。

精益生产

日本汽车制造商研究了生产线，并尝试了一种不同的方法。当你在敏捷开发领域听到看板和改善（Kaizen）时，它们都源于此。

摘自维基百科

对许多人来说，精益生产是一套“工具”，可以帮助识别并持续消除浪费。随着浪费的消除，产品质量得以提高，同时生产时间和成本得以降低。

并没有一种标准的“精益”工作方式，但我最认同的是“丰田之道”。

丰田之道注重提升工作流程的“顺畅度”，从而逐步消除系统中的“不均衡”（mura），而非单纯追求“减少浪费”。顺畅的工作流程能够揭示已存在的质量问题，进而自然而然地减少浪费。这种方法的优势在于它自然而然地采用了系统性的视角，而以减少浪费为导向的做法有时会错误地忽略这一点。

精益生产是如何减少浪费的？

这是另一个大话题，谷歌上有很多相关资源。从我的角度来看，它的主要驱动力在于积极主动地识别浪费并加以解决。精益生产描述了三种类型。

• Mura：指因需求变化而造成的浪费。精益生产提倡“拉动式”生产系统，而非“推动式”生产。也就是说，只有在有需求时才生产汽车，而不是试图预测需求——预测需求往往很困难，而且会导致供应不稳定。在软件开发中，这类似于在投入更大项目之前，先制作一个低成本的原型来验证想法。
• 过载（Muri）：指试图同时处理太多事情而造成的浪费。这就是为什么如果你在使用看板却不遵守在制品限制，那就不是在真正使用看板。有时，减少工作量反而能加快速度似乎有悖常理，但你可能也遇到过这样的情况：团队非常努力地工作，但一切都显得混乱不堪，难以掌控。这也是为什么通常来说，小团队更受欢迎的原因。
• 浪费（Muda）：指那些不增加价值的工作。软件开发中的一个典型例子是，开发人员不断疲于应对不稳定的构建版本，却不去解决其根本原因。

精益生产强调“流程”的概念，优化交付流程并减少生产过程中的中断。（可以想想主干开发和拉取请求的区别）

质量

为了保证质量，你要采用精益求精的改善方法（Kaizen），力求完美，找出问题的根本原因并加以解决。你要在整个价值链中建立质量文化，而不是在产品“完成”之后才开始关注质量。

命令与控制 vs. 自主与授权

我从《改变世界的机器》这本书中主要学到的是，它在管理方面对比了大规模生产和精益生产。

精益生产承认，对于像汽车这样有成千上万人参与生产的复杂产品，不可能进行精细化的微观管理。

改善（Kaizen）的最佳运作方式是指导和赋能执行者，让他们找到最佳的交付方式。

表明你所在的公司并非精益型公司

那些职位头衔是“经理”或“领导”，但实际上只是协调员的人

在设计新车时，有一个叫做“Shusa”（不是寿司！）的概念，简而言之，就是真正负责项目的负责人。他们可以召集人手协助，做出决策，不必担心被高层管理人员的突发奇想所左右；他们被赋予了充分的权力，确保项目顺利进行。人们会说，这些人确实在项目中留下了自己的印记，“哦，你一眼就能看出这是一辆丹设计的车，因为有XY和Z这些细节”。

相比之下，我曾经工作过的地方，人们拥有非常高的职位头衔，但并没有实际的权力，只不过是实际生产产品的人和实际做决定的人之间的沟通渠道而已。

在我们这个行业，技术主管因为被提拔到他们所谓的“垃圾挡箭牌”岗位而感到痛苦的情况有多普遍？说真的，我们能不能别再把这当成好事了？这明明是个问题。

领导者应该具备领导能力。

开发团队对优先级没有发言权。

精益生产最著名的理念是“改善”（Kaizen），即持续追求完美。在精益工厂里，如果工人发现问题，可以立即停止生产，并且他们会努力确保问题不再发生。

如果你发现某个技术上存在严重错误，并且正在拖慢团队进度，你有多大的权力去修复它？你的 Scrum Master 会迁就你，但可能认为“技术故事”是“浪费”吗？

精益高效并非仅仅意味着每次只开发最重要的功能。它更在于开发者们努力打造一个能够高效工作的系统和环境。这体现在诸多最佳实践中，例如：优化反馈机制、持续交付、易于部署、简化交付流程、编写高质量代码等等。

精益工厂努力减少问题和缺陷，并提高自身的灵活性。这一切的实现，都源于赋予员工自主权，而非自上而下的微观管理。

你们团队的情况如何？你们能否在发现问题时就解决问题（这是最佳时机），还是必须等到“技术债务冲刺”才能解决？

所有团队都有一套标准的、不可更改的工作方式。

丰田并非凭空捏造出精益理念并取得成功，他们通过实践和迭代不断摸索，最终才掌握了精益管理之道。你的IT团队也需要实践并努力做到“精益”。

你还得明白，我们没有资源团队，他们都是各自独立解决不同问题的个体。这意味着，如果你想最大限度地发挥每个人的潜力，就需要给予他们自主权，让他们自己去探索如何才能最有效地合作。

如果团队不能通过回顾总结来收集反馈，并改进工作方式，那么团队如何才能更好地协作呢？

大型组织经常谈论标准化，以便让开发人员能够在不同团队之间流动。这本身并非坏事，但它不如自主性重要。

如果你想赋予团队足够的权力去实践改善（Kaizen），并让他们找到高效工​​作的方法，你就必须接受团队的工作方式会有所不同。

这没问题，以我的经验来看，即使每个人的工作方式都相同，在团队之间转换也始终是一个挑战，因为团队比一套工具和流程要复杂得多。

软件编写人员不负责质量保证或在生产环境中运行软件。

在大规模生产中，装配线为了提高产量而进行优化，并将任何质量问题都推迟到生产线的末端，由另一个团队负责处理和修复。这样做的问题在于，缺乏反馈机制，系统性问题永远无法得到解决，从而造成浪费。

我认为看板墙上的质量保证（QA）栏就像是异味。在精益开发理念中，质量保证是整个开发流程的一部分，而不是最后附加的环节。质量保证是责任，也是优秀团队的固有素质。

来自持续交付网站

如果能立即发现问题和缺陷，修复成本会低得多——理想情况下，最好是在它们被提交到版本控制系统之前，通过本地运行自动化测试来发现。在下游通过检查（例如手动测试）来发现缺陷非常耗时，需要大量的筛选工作。然后我们必须修复缺陷，同时还要努力回忆几天甚至几周前引入问题时的想法。

如果你把软件一股脑儿地扔给运维团队，你又怎么能指望他们写出一个好的系统呢？

无聊

如果你试图将你的开发团队变成一条同质化的装配线，大量生产 JIRA 工单，你可能会开始让一些人感到厌烦（而且很可能会制造出一些糟糕的产品）。

你之所以付给你的工程师很多钱，可能是因为他们很可能非常聪明，那么你为什么要剥夺他们思考和承担责任的空间呢？

我曾参与过一些项目，说实话，这些项目原本应该相当枯燥乏味，但结果却非常有趣，因为我与一个积极投入、充满活力和乐趣的团队一起工作，他们以“正确”的方式做事并实践改善（Kaizen）而自豪。

这不仅对我们意义重大，而且我们还顺利交付了最初被认为风险极高、难度极大的项目，整个过程几乎没有遇到任何压力。不仅如此，我们在软件交付方面积累的经验也被公司其他团队所借鉴。

改善活动既有趣又有成就感，还能提高你的成果。

 太害怕发布作品并获得反馈

《精益思维：消除浪费，创造企业财富》一书中写道：

从客户角度识别价值

对于软件产品来说，做到这一点是出了名的困难，但如果你没有勇气将软件发布到全世界并收集反馈，那就更加困难了。

软件开发常常被当作一个“结束”的项目来管理（这显然是无稽之谈），而且没有人从客户那里吸取任何经验教训。这正是精益管理力图消除的终极浪费。

变革性的精益技术和方法

我认为思考过去几年出现的变革性技术及其与精益生产的关系很有意思。很多技术看起来规模庞大、具有变革性，但它们真的解决了实际问题吗？它们真的能帮助你实现精益生产吗？

Docker

Docker 是一项强大的技术，它让开发者能够更自由地使用各种技术。无需像以前那样请求使用许可、在生产环境中安装等等，我们可以随心所欲地使用任何技术，因为我们只需交付容器即可。

对我来说，主要好处是它大大缩小了本地计算机和生产环境之间的差距，这使得开发人员能够对软件质量承担更多责任。

与大规模生产领域中摆脱高度专业化、缺乏灵活性的工具是同义词

DevOps

DevOps 的精益之处在于：它旨在缩短反馈循环，提升工具和流程的质量，并对软件负责。读读《凤凰项目》，然后付诸实践。

云计算（例如 AWS）

这又是一项赋能型发展，它使车间工人能够轻松适应技术环境，从而解决问题。这与精益汽车工厂中采用更灵活的机械设备，而非大规模生产中高度专业化的机械设备类似。

总结一下——我们不造车。

敏捷开发和DevOps显然从汽车精益生产中汲取了很多经验。它们都涉及如何利用大量人员打造复杂的产品，这就需要一种不同于大规模生产的思维方式，才能高效地完成工作并保持员工的满意度。

但是，在阅读有关精益的内容时，务必记住，我们软件开发人员的目标各不相同。

• 我们并非试图大规模开发软件。
• 我们正努力兑现软件的承诺，打造可灵活调整、能够快速且低成本地满足用户需求的产品。

精益理念的核心在于从客户角度出发识别价值，并剔除任何与价值无关的因素。软件开发领域也存在类似的问题，人们往往会过度简化那些并非显而易见的功能。

问题在于，这种看待软件利益相关者的方式非常不成熟。“真正的”客户确实能从以下方面受益：

• 使其更易于操作，从而减少停机时间
• 改进测试套件，以便软件能够快速轻松地进行更改，从而满足客户需求。
• 等等

我认为检查“价值流”中的浪费是一件非常好的事情，没有什么比花了几个月时间做某件事却没有任何实际证据表明它会给任何人带来任何好处更令人沮丧的了。

然而，很多时候，产品团队主导开发，技术团队却鲜少参与。团队无法践行持续改进（Kaizen），反而把时间浪费在解决技术债务、缓慢的构建、糟糕的反馈循环、手动测试等问题上。最终，产品变得难以修改，无法长期响应用户需求。这与我们一直以来所追求的灵活、可塑且高效的开发体系相去甚远。

这又回到了我之前写的内容：你的技术主管是否拥有领导权？还是她只是确保你在JIRA工单上填写预估时间？在决定工作优先级时，她是否被平等对待？她是否需要不断争取团队实践改善（Kaizen）所需的零碎时间，同时还要被动地被指责浪费时间，哪怕只是提出一些非功能性的工作建议？

最后一点想法

再次来自维基百科

精益生产的文化和管理层面或许比生产工具或方法本身更为重要。许多精益工具的实施并未带来持续效益，而这通常归咎于整个组织对精益生产的理解不足。

把“精益”换成“敏捷”，我想你会看到很多软件开发人员会心一笑，点头表示赞同。