敏捷已死,“工程化”永存

2020 年 8 月 04 日

敏捷已死,“工程化”永存

摘要:


Poppendieck 夫妇是精益软件开发的先行者和倡导者。在敏捷 的 CI/CD 等模式主导软件开发的当前,敏捷逐渐偏离了其工程化的本质,沦为“软技能”。在 Poppendieck 夫妇看来,一个好的理念最终会被更优秀的理念所超越。而新的理念并非抛开敏捷另起炉灶,而是敏捷理念的延伸和拓展。


正文:


本文最初发布于 builtin,经原作者 Tatum Hunter 授权由 InfoQ 中文站翻译并分享。


“我们注意到,一些已被其它领域抛弃的方法,依然被软件开发领域视为标准。”


这 句话引用自《精益软件开发:敏捷工具包》( Lean Software Development: An Agile Toolkit)一书的引言。该书是由 Mary 和 Tom Poppendieck 夫妇在 2003 年撰写完成的。


当时,软件开发正受困于错误的理念, 认为快速构建和高质量的构建在本质上是存在冲突的。Mary 通过自己在产品开发和制造工作的实践,指出这一理念是不对的。当时,日本汽车制造厂商所推行的“精益”实践正在全球广为传播,并居于统治地位。


软件领域 彼时已经落后了 。Mary 和 Tom 是 17 年前写的这本书,当时敏捷 这套新兴的原则 和对精益制造的思考 正初露锋芒,它们可以提升很多事情的效率 。


时至今日,Mary 的认知也发生了改变。她告诉我,尽管敏捷的最初形式和意图并没有问题,但这一称法已不合时宜了,“后浪”正让敏捷严重落伍。所有《精益软件开发》一书的读者 应该都很熟悉这个理论 。


在明尼苏达州的起居室,Mary 通过 Zoom 会议阐明:“我们永远不会听到有人说,‘我们帮助机械工程师变得敏捷。’这种说法很不明智。我是说,这样的表述非常不好。”


的确如此。从技术产业的角度看,敏捷已经存在了很长时间。但是敏捷没有成为百宝囊,而是成了杂货铺(译者注:在此将原文 AltaVista 和 Amazon 分别译为“百宝囊”和“杂货铺”)。 在 敏捷宣言正式发布 19 年后,敏捷仍然只是从日常开发人员到公司高管 的人们 挂在口头的一个提法。


但 Mary Poppendieck 的目光已瞄向未来。



图 1:敏捷在本世纪初大行其道(图片来源:Shutterstock)


敏捷是如何崛起的?


Mary 在一篇博客 热门文章中提出,一个组织中的软件开发,或者是成本中心,或者是利润中心。对于成本中心,其业务目标是降低支出,而对于利润中心,目标则是收益最大化。


大多数 前数字时代的 公司 将 软件成本中心 打造成了 IT 部门的形式 。这意味着,软件并未被视为业务增长的组成部分,并且软件团队的管理人员通常对技术工作了解甚少。尽管越来越多的公司开始使用软件即产品(SaaS),但这种短视行为并未消失 。


Mary 指出,敏捷就是要减少此类环境中的一些繁文缛节,让开发人员的手中能掌握更多的权力。敏捷主要是一种沟通工具,它通过测试驱动开发(TDD)厘清与客户间的沟通, 并 通 过全面调整 瀑布式开发流程以简化团队间的沟通。


“敏捷中最大的错误,根源来自于上世纪90年代。那时的企业软件就是 要去尽力完成用户对开发人员的述求。”


包括程序员、商业人士和理论家在内的敏捷社区是拥护各类创新的,例如单元测试、极限编程,以及 Poppendiecks 夫妇提出的,意在降低耗费的精益编程。但是,和高科技世界中许多其他事物一样,好的理念最终会被更优秀的理念所超越。


就敏捷而言, 这种更好的理念来自于商业模式。当今顶级的高科技公司并没有专门的软件部门,公司本身就是软件部门。高管可使用技术人员的语言,公司将开发团队视为收入的主要驱动因素,而不是削减成本 的工具 。Mary 指出,客户当然需要功能和特性,但除此之外,客户还需要 针 对自身问题的解决方案。


Tom 指出,“敏捷中最大的错误,根源 来自 于上世纪 90 年代。那时的企业软件就是 要 尽力完成用户对开发人员的述求。敏捷非常擅长于交付特性,但这对公司意义不大。交付特性的快慢,并不能区分公司的优劣。重点不应是功能,不应是输出,而是产出,以及员工所做工作的影响。”


Mary 指出,换句话说,软件开发人员需要的是正本清源,去真正地成为一名工程人员。



图 2: 敏捷常侧重于软技能,而忽视了工程技术(图片来源:Shutterstock)


软件是否偏离了工程学?


软件编程自诞生以来,就 经常用来自动化处理一些任务 。这些任务通常包括 两个要素: 电气系统,以及操作电气系统的女性。Mary 在上世纪 60 年代曾任职于贝尔电话实验室(现为贝尔实验室), 负责对 计算机 编程 以取代全球 范围内 电话系统的 人工交换总机 。此后操作过这些总机的女性失业了,而 Mary 和她的两个姐姐则步入了程序员职业。


之后,Mary 在 3M 从事过程控制编程工作,那时她的工作职责非常类似于电气工程师。


“我当时在工程部门,职位是工程师,也是做工程师的活。”她说。“我操作电子管,而其他人则操作电线。我和他们所做的工作并没有太大区别,只是计算机在以一种有趣的方式处理过去由电路和继电器完成的工作。”


“敏捷的主要关注 点 并不在于技术,而是在于具体的人和事的管理,并不一定会正确完成所需的工作,而 只是要完成任务而已 。”


但时至今日,许多人并不将软件开发视为一个工程问题,或者更可能是由于组织上存在的障碍而无法视其为工程问题。工程就是发现问题、了解问题,并使用所擅长的技术尽快去解决问题。在 Mary 看来,软件 开发 已经变为“项目、简报,以及 对 用户友好”。


Mary 说:“敏捷的主要关注 点 并不在于技术,而是在于具体的人、事管理,并不一定会正确完成所需的工作,而 只 是要 完成任务而已——这和工程的关注点是不一样的 。 什么事都可以敏捷 , 唯独 实现好的软件工程所必需的基本、底层的技术能力 是例外 。 ”


那么为什么在上世纪 90 年代的乱麻般的软件市场中,敏捷 却凭借 软技能 脱颖而出呢 ?这可能是因为硬技能很难 推销出去吧 。



图 3:敏捷认证依赖于大量的软技能训练(图片来源:Shutterstock)


敏捷是如何变成“软技能”的?


如果 Google 搜索“敏捷教练”(agile coach)或“敏捷顾问” (agile consultant),就会给出大量有偿帮助团队使用敏捷实践进而从中获益的人士。公平地讲,Mary 和 Tom 本身也参与一些收费培训课程,讲授根源于敏捷的精益软件开发。


但在 Mary 看来,一些敏捷培训机构为扩展潜在的受众范围,规避了所有的技术和技能相关问题。Mary 给出了她的主要反对理由。


一个原因在于,这类做法将敏捷定位为一种适用于依然在努力实现数字化或 主要 将软件视为成本中心的企业的快速解决方案, 这是 存在隐患 的 。


她说:“企业需要的是一种能确保软件正确实现功能的过程,而不是去考虑他们对软件本身的基本认知是否存在错误。如果一家真正的技术公司在对敏捷夸夸而谈,会令我很震惊。”


“如果一家真正的技术公司在对敏捷夸夸而谈,会令我很震惊。”


Mary 反对的另一个原因在于,那些施行 技术无关的 敏捷的组织会专注于所谓的软技能,而非实际的工程能力,最终会将女性工程师搁置于 Mary 称为“外围”的角色。


“女性最终会处于何种敏捷角色?她们最终成为了 Scrum Master 等。这类角色并非工程职位,而是将女性置于一个“女性”的职位,并不是让女性去从事工程工作。我认为那真的很糟糕,”Mary 说。


她的担心并非杞人忧天。计算机职位自从上世界 40 年代创立以来直至 60 年代,女性一直居于主导地位。但是随着计算机的用途范围越来越明晰, 这些工作逐渐被男性占领。女程序员在 80 年代卷土重来,在 1984 年曾占计算机科学专业毕业生的 37%。但是 此后随着第一台个人计算机的问世,女性程序员的数量就稳步下降。当前, 女性约占计算机科学专业毕业生的四分之一


伴随着编程学习者数量差距的是职业收入上的差距。35 岁以上的女性程序员担任初级职位的可能性是男性的 3.5 倍。在晋升时,女性有时会被 排挤到一些注重软技能的非技术职位。在许多组织中,这些角色 被视为无足轻重,缺乏吸引力


Mary 认为,如果敏捷方法论创造了更多的非技术角色,转移了解决技术问题的焦点,那么敏捷的持续流行可能并不利于女性开发人员。



图 3: SpaceX 等企业具有值得软件厂商学习之处。


我们可以从 SpaceX 学到什么?


Mary 提出,相比软件开发在上世纪 90 年代的状况,敏捷看上去要好很多。敏捷在本世纪初运行良好,直至持续交付出现,并在很多方面使敏捷开发方法不再适用。


现在,人们期望 的是 持续交付,并且行业已经为下一步做好了准备。但 Mary 指出,下一步并不会在方法上另起炉灶。


Mary 说:“我所在的软件工程领域,并没有一种方法会持续超过五到八年。所有十年以上的方法都是过时的。二十年以上的那就成了古董。”


她还说,方法是需要进行编纂的。在上世纪 90 年代能力成熟度模型出现时,采用软件开发方法意味着开发人员必须证明他们是有一套标准的,并且在遵循这套标准,而不是证明他们的标准是不断地根据消费者需求的变化而变化的。这就是最初日本的质量标准精益生产从业人员对此的定义,它并不兼容方法 论 ,而完全是与学习相关的。


由此,Mary 非常看好支持软件工程师更好、更快学习的各种人工智能方法。Mary 和 Tom 一致认为自动化测试、持续部署和跨功能协作已成为当务之急。前沿企业将通过工程思维和学习意愿,发现下一个伟大的方法。


“今天,我最喜欢的词是“工程化”。即让工程人员去做工程上的事情。”


一些情况下, 这种 学习可能源自于神经网络等高级人工智能模型。还有一些情况下,学习是来自于良好的、传统的试错方法。


Tom 问我,“你去过火星吗?”


“我没有。”


Tom 说,在我到了他的年龄时,SpaceX 将能成为送我去火星的企业。Mary 说,SpaceX 能处于航空航天业的前沿地位,就是采用了经典的工程模型,即试错方法。


举例而言,SpaceX 公司在开发可重复使用的轨道火箭助推器中,经历了 助推器的一次又一次的坠毁。尽管看上去失败 了很多次 ,但 SpaceX 通过 试水以前从未做过的事情,相比其他 NASA 承包商还是将火箭发射的成本 降低了三分之二


Mary 说:“他们的做法就是快速地迭代和实验,并对所有一切进行测定,以从每笔投资中获得尽可能多的经验教训。虽然他们并未将这种做法称之为敏捷,但他们在此方面确实做得很好。”


做成事情,这看起来是 Mary 目前的信条。在 Mary 看来,对概念的表述会变来变去,但是聪明的、工程上的问题解决方案是永远不会过时的。


“我并不在乎是称为“精益”或是“敏捷”,并不存在能让一个人按部就班就能解决所有问题的银弹解决方案。”Mary 说。“所以今天,我最喜欢的词是“工程化”,就让工程人员去做工程上的事。”


原文链接:


https://builtin.com/software-engineering-perspectives/lean-agile-methodology-software-engineering


2020 年 8 月 04 日 18:157928

评论 11 条评论

发布
用户头像
大环境在不断变化,用户的商业环境也随之变化,所以跟得上变化的服务才能带来及时价值。赞同文中说的快速迭代,快速试错,可能比按部就班做了n长时间后做了一个不符合时代要求的东西要好很多。
2020 年 08 月 13 日 13:04
回复
用户头像
敏捷开发也好,工程也好,都是职责分工,让专业人做专业事。如果团队人力有限,资源有限,你让一人兼多职再催进度赶工,怎么可能做出一个好的产品。商业模式就是更少成本更多业绩,实际会遇到的情况比想的复杂多,开发不是理想态
2020 年 08 月 11 日 09:39
回复
用户头像
无所谓“生”或“死”,只存在于“适合”与“不适合”;只有管理层的官僚才会在概念上争论,满足于概念上的所谓“自洽”。正像克鲁格曼说的,不要跟我谈经济概念,把你的经济模型给我看,show me your model!
2020 年 08 月 10 日 13:08
回复
用户头像
机器翻译?
2020 年 08 月 10 日 10:38
回复
用户头像
这个文章的作者只怕当时语文考试严重不及格 。提炼文章中一个比较认可的观点:敏捷如果只是解决交付的敏捷,而脱离了服务的业务,那么其实也是一个失败的玩意。
2020 年 08 月 07 日 11:32
回复
用户头像
看了前面的评论,我感觉你们似乎被文章灼伤了,话说你们今天撸码了吗?哈哈~~
2020 年 08 月 06 日 11:46
回复
用户头像
敏捷只是工作方式,为了更有效的沟通和推进项目,它解决不了人的问题,再好的流程也不能让不会编程的人完成编程工作,也无法解决工程难题。但这并不是说流程,工作方式不重要。
2020 年 08 月 06 日 00:29
回复
用户头像
抛了几个问题,文章自己又不回答,给出的方案又不摆依据,目的只是发牢骚嘛
2020 年 08 月 05 日 14:41
回复
用户头像
的确,片面的谈论敏捷而忽视实际工程实践问题往往会打造出一个交付效率低下而无法持续进步的组织
2020 年 08 月 05 日 13:13
回复
用户头像
用学生时代的语文知识评价这篇文章:找不到中心思想。
2020 年 08 月 05 日 09:43
回复
这胶不扣题
2020 年 08 月 05 日 14:26
回复
没有更多评论了
发现更多内容

第十周 模块分解作业

钟杰

极客大学架构师训练营

第六周作业总结

hunk

极客大学架构师训练营

架构师训练营第2期 第六周课后练习

月下独酌

极客大学架构师训练营

CAP原理

幸福小子

分布式 CAP原理

架构第十周作业

Geek_Gu

极客大学架构师训练营

10 模块分解课后练习

ABS

架构师训练营2期 第六周总结

月下独酌

极客大学架构师训练营

9 性能优化(三)课后练习

ABS

week6 技术选型(二) 作业和学习总结

杨斌

git 在未保存,add,commit,push下撤销的方法?收藏后再也不用找了

小松漫步

第十周 模块分解总结

钟杰

极客大学架构师训练营

面试被问Mybatis底层实现:你连这个知识点都说不明白?

小Q

Java 编程 程序员 架构 mybatis

架构师训练营第六周总结:

xiaomao

CAP原理

皮蛋

CAP CAP原理

架构师训练营第六周作业

xiaomao

第 6 周作业

Steven

极客大学架构师训练营

架构师训练营 - week10 - 作业

lucian

极客大学架构师训练营

第十周作业

熊桂平

极客大学架构师训练营

模块分解

wing

极客大学架构师训练营

与前端训练营的日子 --Week05

SamGe

学习

学习总结之分布式数据库

幸福小子

架构师训练营第 10 周课后练习

叶纪想

极客大学架构师训练营

架构第十周总结

Geek_Gu

极客大学架构师训练营

Week_10 总结

golangboy

极客大学架构师训练营

第十周作业 (作业二)

Geek_83908e

架构师一期

模块分解-微服务,组件设计原则,领域驱动开发

garlic

极客大学架构师训练营

架构2期-第六周作业(1)

浮生一梦

极客大学架构师训练营 2组 第六周作业

CAP 原理简述

jorden wang

第十周学习总结

熊桂平

极客大学架构师训练营

【架构师训练营 1 期】第十周作业

诺乐

【架构师训练营 1 期】第十周学习总结

诺乐

敏捷已死,“工程化”永存-InfoQ