从项目到产品:生产线类比的终结

译者:无敌哥
原文地址: https://www.tasktop.com/blog/end-manufacturing-line-analogy/ 本文翻译仅供学习交流之用。
原文作者 Mik Kersten 出版了《Project to Product》


本系列共四篇文章,分别是



我最近参观了宝马集团在莱比锡的工厂。我的目标是和宝马集团的 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 转型的一个很好的起点。但这只是优化端到端软件价值流的一小步。《限制理论》(theory of constraints)告诉我们,只投资于价值流中的一个部分不会产生结果,除非这个部分是瓶颈。但是我们怎么知道这是瓶颈呢?更重要的是,如果我们是在一个非线性过程中寻找一个线性瓶颈呢!!


软件开发包括一系列类似制造的过程。单独来看,每个都可以被认为是批量流,其中自动化和可重复性决定成功与否。例如,在20世纪70年代,我们掌握了软件汇编,使用编译器和 GNU Make 之类的系统,为构建非常大的代码库提供了批量式的可重复性。在接下来的十年里,GUI 生成器和代码生成成为了自动化手段,我们现在在构建Mobile UI时认为这是理所当然的。现在,我们正处于掌握代码部署、发布和性能管理的过程中,使频繁发布成为一个可靠和安全的过程。
然而,这些都只是端到端软件价值流的单个构建块,类似于成型、焊接和组装汽车的各个阶段的机器人。但是在软件方面,这些不同的阶段并不足以组合起来形成简单的单向批量生产流程。

从线性批处理到价值流网络


从核心关键点来看,端到端软件生命周期是一个向最终用户提供价值的业务流程。因此,詹姆斯 · 沃马克和丹尼尔 · 琼斯在他们的《精益思想》一书中总结的精益思想5个原则非常适用:



当我们将流程从装配线转移到网络时,许多精益理念都是相关的,比如小批量和单件流,以尽量减少正在进行的工作。然而,为了避免过度使用制造业的类比(或者更糟,继续沿着错误的心智模型的道路前进) ,我们必须更清楚地界定管理迭代式、基于网络的软件开发价值流与管理线性制造价值流之间的关键区别:



如果你接受软件价值流会形成网络,这和飞机交通相类似,我们也必须考虑是什么造就了健壮、高效的网络,从路线优化到流量控制。例如,为了优化网络,我们必须考虑以下几点:



最后,梅特卡夫定律(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”专栏中,目标读者是对软件体系结构进化感兴趣的读者。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2685935/


该文章对你有帮助吗,打开微信扫码打赏哦,谢谢! 求分享转发: 分享到QQ空间 分享给QQ好友

 

 

粤ICP备19116230号
友情链接: 码农藏书阁 天天链