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

摘要：

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