原文地址: https://www.tasktop.com/blog/end-manufacturing-line-analogy/ 本文翻译仅供学习交流之用。原文作者 Mik Kersten 出版了《Project to Product》
- 02 《价值流动》从项目到产品：生产线类比的终结|IDCF
- 03 《价值流动》从项目到产品：到底是什么应该流经软件价值流？|IDCF
- 04 《价值流动》从项目到产品：软件时代需要价值流架构师|IDCF
我最近参观了宝马集团在莱比锡的工厂。我的目标是和宝马集团的 IT 领导人一起头脑风暴，探讨如何将生产线与软件生命周期无缝集成在一起。我也有兴趣了解更多关于宝马如何处理汽车生产，因为我正在为我即将出版的新书《Project to Product》定义流框架。参观包括沿着工厂的生产线走10公里，工厂领导解释每个涉及汽车生产的系统、流程和工具。那次访问比我读过的所有关于精益流程的书籍更深刻地影响了我对精益生产的理解。该工厂是一个令人难以置信的设施，在技术和可持续性方面领先于业界，每70秒生产一辆宝马1系或2系汽车。它还拥有令人惊讶的创新型 i3和 i8生产线。走进中央大楼(参见图1) ，你会有一种观看星际飞船建造设施的感觉，同时也会有一种大型科技创业公司的感觉。开放式办公室位于生产线露天部分的下方，生产线将汽车从汽车修理车间移动到工厂的瓶颈地带，然后再移动到装配大楼。图1: 宝马集团莱比锡工厂的中央枢纽大楼。该工厂每70秒生产一辆宝马1系或2系汽车。(来源: 宝马集团，经许可使用。)当我向工厂领导层提出数以百计的问题时，我的大脑急速地想把汽车和软件的制造方式进行比较。机器人和人类协同工作的结合，让我们得以窥见未来人类技能将如何与人工智能和自动化相结合。但给我印象最深的是工厂的架构，它展示了任何软件架构师都会羡慕的优雅和模块化。在图2中，装配线的关键阶段清晰可见，五个“手指”的“指关节”向右生长。每个手指都是生产线架构中的关键固定点，随着制造步骤的增加，以及技术和客户需求的演进，建筑向外逐步扩展。我从来没有想到我与软件架构联系在一起的原则会以如此物理的、不朽的形式出现。
图2: 宝马集团莱比锡工厂的无人机照片。生产线的关键阶段清晰可见，五个“手指”的“指关节”从工厂中间向右生长。(来源: 宝马集团，经许可使用。)访问结束后的几个月里，我一直在思考如何将工厂的制造性创新，应用到软件，重新思考该如何构建。 - 我们如何像莱比锡工厂那样将我们的软件架构与价值流结合起来，从建筑的结构到每个阶段和工具的放置？
- 而且，最重要的是，我们如何使软件过程的关键瓶颈像工厂那样让我们的员工看得见？
然后我和 Tasktop 的产品开发副总裁 Nicole Bryan 进行了长时间的交谈，她让我确信我的想法是错误的。莱比锡工厂最令人印象深刻的事情之一是大规模实施准时生产（Just In Time）。更有趣的是，这些汽车是按顺序生产的: 汽车从生产线上下来的顺序与客户订单进来的顺序相同。许多阶段都令人印象深刻，但当看到端到端过程中的优化时，令人兴奋不已。
拉动的概念是任何精益系统的核心。对于制造业来说，“拉”是物理部件的客户订单序列。在宝马集团，小部件（widgets）是满足市场需求的汽车。以“纯粹的驾驶乐趣”满足客户，这个短语张贴在整个工厂，以便让工作人员看到。如果更多的1系列比2系列汽车取悦用户，更多的1系列汽车下线，生产线的工具和流程适应新的需求。当我走在工厂的地板上时，我脑海中的禅意心印（Zen koan ，译者注：查了一下，这是一个佛教用语，禅宗的心印是“如人饮水，冷暖自知”的不可思议禅境）正试图弄清楚，在一个模糊的软件交付过程中这些“流动单元”是什么。从宝马集团对“纯粹的驾驶乐趣”的强调中获得灵感，我们可能会得出这样的结论: 这些流动单元应该是让我们的最终用户感到高兴的东西。然而，我们知道，随着压缩打包（Zip）和刻录CD的日子远离我们，开发人员不会因为一次又一次地发布同样的软件而感到高兴。精益思想是让客户从生产者那里获取价值。因此，软件中的小部件应该是流向客户的业务价值单位，产生某种愉悦、无烦恼和收入的组合。这些“流动条目”（Flow Items）的完整定义在 《Project to Product 》中有所涉及; 可以把它们看做新添加的特性、待修复的缺陷、需解决的技术债务和安全漏洞，以及客户希望拉动的类似业务价值单元。然而，这些流动单元中没有两个是相同的。这里我们看到了一个核心差异。汽车制造厂的目标是以最高的速度、可靠性和质量，以不同的配置生产出相同的小部件，而软件开发组织则生产出每个功能都不同的小部件。决定这些功能应该是什么样子的工作，类似于宝马集团对下一辆汽车的设计工作。在高效率的软件商店里，这种情况每周或每小时发生一次，而不是每年一次。- 如果您的输入受到限制，并希望生产高质量的小部件，那么您最好的选择是，创建一个完全线性的批处理风格的流程，最终的例子是汽车生产线。
- 但是如果你每次都要制作一个不同的小部件，并且定义这个小部件的大小和形状是一个创造性的过程，那么线性过程就是一个错误和误导性的模型。
作为科学家、工程师和技术专家，我们通过把复杂的问题简化为简单的问题，从而做得很好。但是，回顾一下我们在过去改进大规模软件交付的尝试中，所采取的一些错误步骤。
瀑布开发在理论上看起来很棒，因为它使软件交付中连接所有利益干系人的复杂性，转变成线性的。
敏捷开发拯救了这个问题，但是它过于简化了交付视角，将上游或下游的利益相关者排除在外，比如业务分析师和运营人员。
DevOps 通过包含运维、自动化和部署过程的可重复性来解决这个问题。但是我现在担心，由于过分关注线性过程，而不是 DevOps 的端到端流程和反馈原则，组织将会犯类似的错误，采用过于狭隘和过于线性的DevOps 观点。
以自动的、可重复的方式应对频繁发布的能力，可以成为 DevOps 转型的一个很好的起点。但这只是优化端到端软件价值流的一小步。《限制理论》（theory of constraints）告诉我们，只投资于价值流中的一个部分不会产生结果，除非这个部分是瓶颈。但是我们怎么知道这是瓶颈呢？更重要的是，如果我们是在一个非线性过程中寻找一个线性瓶颈呢!!
软件开发包括一系列类似制造的过程。单独来看，每个都可以被认为是批量流，其中自动化和可重复性决定成功与否。例如，在20世纪70年代，我们掌握了软件汇编，使用编译器和 GNU Make 之类的系统，为构建非常大的代码库提供了批量式的可重复性。在接下来的十年里，GUI 生成器和代码生成成为了自动化手段，我们现在在构建Mobile UI时认为这是理所当然的。现在，我们正处于掌握代码部署、发布和性能管理的过程中，使频繁发布成为一个可靠和安全的过程。然而，这些都只是端到端软件价值流的单个构建块，类似于成型、焊接和组装汽车的各个阶段的机器人。但是在软件方面，这些不同的阶段并不足以组合起来形成简单的单向批量生产流程。从核心关键点来看，端到端软件生命周期是一个向最终用户提供价值的业务流程。因此，詹姆斯 · 沃马克和丹尼尔 · 琼斯在他们的《精益思想》一书中总结的精益思想5个原则非常适用:当我们将流程从装配线转移到网络时，许多精益理念都是相关的，比如小批量和单件流，以尽量减少正在进行的工作。然而，为了避免过度使用制造业的类比(或者更糟，继续沿着错误的心智模型的道路前进) ，我们必须更清楚地界定管理迭代式、基于网络的软件开发价值流与管理线性制造价值流之间的关键区别:- 可变性。对制造业而言，什么将出现在生产线的末端，有一个固定的、定义良好的变化集，而新的软件功能是开放式的。制造业需要最小化可变性; 软件开发需要拥抱可变性。
- 可重复性。制造是关于最大化相同部件的生产能力; 软件是关于最大化驱动创新的迭代和反馈循环。在目前，我们在软件交付的每个阶段，都在追求可重复性，比如可靠的自动部署，但是我们应尝试更多地优化流和反馈，而不是可重复性。
- 规划频率。汽车是在瀑布式跨越年的周期内进行前期设计，现代软件组织通常使用两周的 sprint 节奏来规划交付。这意味着我们必须为频繁的计划和变化，来设计我们的价值流。
- 创造力。制造过程旨在实现最高可行的自动化水平，这是通过从生产过程中移除任何创造性和不确定性的工作来实现的，创造性的工作转移到定义和调整生产过程本身。而我们在软件交付过程中，看到了一些这样的例子：例如，定义从规划到部署的价值流可能比编写新特性更具技术挑战性。同时，在自动化方面，即使人工智能即将取得重大进展，我们仍将在软件价值流的每一步需要创造性的工作和协作。
- 可视化。软件之所以如此有趣，是因为它不受物理制造的限制，这使得它具有无限的可塑性。这意味着，能够以一个戏剧性的节奏适应一个市场的需求。然而，物理比特的缺乏，使得流和产出物的可视化，成为一个非常有趣的挑战；相比之下，在汽车制造厂，这是非常明确的。正如我们必须发明显微镜，来理解肉眼看不到的物理世界的内部运作一样，我们现在需要一套新的工具来理解和管理无形的软件价值流。
如果你接受软件价值流会形成网络，这和飞机交通相类似，我们也必须考虑是什么造就了健壮、高效的网络，从路线优化到流量控制。例如，为了优化网络，我们必须考虑以下几点:- 吞吐量。我们可以用吞吐量来衡量一个网络的有效性----例如，某些路线可以运送多少乘客。在一个 IT 组织中，我们应该在哪些方面进行投资，以获得总体吞吐量的最大增长？
- 延迟。在线性流程中，延迟很容易处理，但是在前端和后端团队都必须协作才能实现一个特性的场景中，情况又如何呢？外包到遥远的时区会增加延迟吗？我们如何衡量总体网络延迟和端到端的前置时间，以及上市时间？
- 弹性。一个健壮的网络可以让在一个节点不工作的情况下，让流动保持不变。这与失败的产品或无法偿还的技术债务有什么关系？
最后，梅特卡夫定律（Metcalfe’s law）告诉我们，网络的价值随着其连通性而增长。如果我们的价值流网络连通性不足，那么优化任何特定阶段还有意义吗？例如，假设运维人员和服务台（Helpdesk）工作人员之间没有正式的反馈循环，他们使用的是 IT 服务管理工具，如 ServiceNow; 开发人员使用的是敏捷工具，如 Jira 和 Microsoft Project 中的规划发布。在这种情况下，投资数百万美元到持续交付能产生任何可衡量的商业效益吗？当一家公司的市场竞争力岌岌可危时，对这些问题的一般性答案是不够的。我们需要一个更健壮的软件价值流网络模型，这是从项目到产品的一个关键主题。当我走出莱比锡的工厂时，我的观点被宝马集团已经达到的独创性、创新性和管理成熟度所改变。现在是我们打下基础和建立新的心智模型的时候了，这些心智模型将使我们达到这种精确性、完美性和流程性，以衡量软件是如何构建的。如果我们继续把软件交付视为一个线性的制造过程，我们就会停留在飞行前的时代。注：本文的一个版本最初发表在2017年11月 / 12月出版的 IEEE 软件(版权 IEEE，2017)。“生产线类比的终结” ，软件 IEEE，卷。34，no. 6，pp. 89-93,2017.11-原文
这里截取一张原文作者 Mik Kersten 一次演讲的照片，可以对比一下汽车生产与企业IT研发的区别。
这是一系列来自于Mik的博客，这是我筛选出来的第二篇，这些核心内容可以认为是 《Project To Product》的起源。对Mik来说，从项目到产品，是一个20年的旅程，开始于作为一个开源开发者的十年学习，并将这些学习应用到他过去十年与 不同行业IT 领导者的合作中。这些帖子代表了他一路上最有趣的学习和合作历程。这些文章最初发表在 IEEE 软件杂志的“ On DevOps”专栏中，目标读者是对软件体系结构进化感兴趣的读者。如今，这本书的中文版《价值流动：数字化场景下软件研发效能与业务敏捷的关键》由张乐、姚东、李淳、吴非四位译者翻译，王勇审校出版问世了，让我们国内的读者也能在数字化转型的路上借鉴米克.科斯腾的流框架成功转身。#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。
2022年10月29-30日将在深圳举办，36小时内从0到1打造并发布一款产品。
企业组队参赛&个人参赛均可，赶紧上车~👇
