我们如何被流程剧场困住，又该如何找回技术卓越？

译自：Process Theater vs. Technical Excellence: A Recurring Software Crisis [1]
作者：Steve Fenton

深夜，屏幕的光是房间里唯一的光源，映照着一张专注的脸。眼前的代码编辑器开着多个标签页，旁边的笔记本电脑屏幕亮着模糊的光。这是无数开发者熟悉的场景，我们在这样的环境中，不断与各种“最佳实践”和“银弹方案”搏斗。

“江湖郎中（snake oil salesman）”一词常用于描述从事欺骗性营销行为的个人。像克拉克·斯坦利[2]这样的狂野西部人物曾将他们的蛇油宣传为神奇的万能药。但在1916年，美国政府化学局对这种擦剂进行了检测，发现其价格过高且价值有限，斯坦利因此被罚款20美元。然而，故事并未就此结束。

你可能正在使用蛇油

蛇油并非完全无用。虽然它确实与瓶子上的宣传不符，但某些成分，如辣椒素和樟脑，在用于正当目的时被证明是有价值的。

辣椒素来源于辣椒，现在被用于皮肤外用止痛产品中，以缓解肌肉和关节疼痛。它是一种FDA批准的治疗方法。樟脑也常被用作反刺激剂，帮助缓解昆虫叮咬引起的瘙痒。它也是胸部擦剂制造商的首选成分，你可能在感冒时将其用作减充血剂。

因此，尽管蛇油未能达到其推销者们夸大的宣传，但它并非完全没用。在软件行业中也是如此，因此能够将有价值的成分与被证伪的软件交付方法区分开来，是一项至关重要的技能。

瀑布模型：被误解的奠基者与流程剧场的开端

“瀑布模型”一词通常作为分阶段软件交付的统称，其中任务按类似瀑布的顺序依次执行。当轻量级革命推翻了当时的重量级模型时，它造成了一种错误的观念，认为分阶段的软件模型[3]是完全错误的。

但这些旧模型的创建者受到了委屈，因为他们一直告诉我们以这种新方式工作。

事实上，早在1956年，赫伯特·本宁顿（Herbert Benington）在其论文《大型程序的生产》中，就描绘了一个并非僵化、而是包含反馈循环的软件开发流程。这个流程可以概括为以下主要阶段与两条并行的路径：

1. 设计路径（实线）：从运营计划（OPERATIONAL PLAN）开始，依次经过机器规格（MACHINE SPECIFICATIONS）、运营规格（OPERATIONAL SPECIFICATIONS）、程序规格（PROGRAM SPECIFICATIONS）、编码规格（CODING SPECIFICATIONS），最终到达编码（CODING）阶段。
2. 测试路径（虚线）：与编码阶段衔接，依次进行参数测试（PARAMETER TESTING）、组装测试（ASSEMBLY TESTING）、系统调试（SHAKEDOWN），直至系统评估（SYSTEM EVALUATION）。

关键的是，在系统评估之后，存在一个明确的反馈回路指向最初的运营计划，形成了一个闭环。这远非后世刻板印象中那种单向、不可逆的“瀑布”。本宁顿在文中甚至谴责了在编写代码之前就完成所有规范的自上而下编程思想，并讨论了我们现在称之为平台工程的概念。

温斯顿·罗伊斯（Winston Royce）在1970年的论文《管理大型软件系统的开发》中，也建议人们以小增量更改的方式工作，因为这会降低复杂性，并允许组织在方向错误时回滚到以前的版本。这些思想后来在巴里·玻姆（Barry Boehm）的螺旋模型中再次出现。

敏捷的成功，很大程度上归因于轻量级软件交付的倡导者如何巧妙地从1990年代主导行业的流行重量级“蛇油”方法中提取了好的成分。他们保留了强调反馈、迭代和适应性的核心洞察，而丢弃了大量僵化、繁琐的有毒流程部分。理解这一“提取精华，剔除糟粕”的过滤过程，是我们摆脱行业中反复出现的危机的关键。

反复出现的危机：当管理偏爱流程而恐惧技术

危机源于管理层倾向于被流程吸引[6]，并排斥技术和文化实践。他们渴望重新引入那些被专业人士移除的、看似可控的瀑布模型元素（即流程剧场），并且希望丢弃他们不理解（或听起来很费力）的关键技术实践。

增加流程的重量同时降低技术卓越性，是一条毁灭之路。

这种管理错误的典型例子来自敏捷的早期[7]。在《敏捷宣言》时期，领先的轻量级方法是极限编程（XP）。它具有与Scrum相似的流程元素（如站会、迭代），以及一张相互关联的技术实践图谱（如测试驱动开发TDD、持续集成、重构、结对编程），这些实践保持了较低的变更成本，这是长期维持敏捷性的关键。

对管理者来说，Scrum对流程、角色和会议的独家关注是清晰、无害且易于管理的；而XP对工程技能和技术卓越的强调则让他们心生恐惧。结果，Scrum在管理层面成为主导者。我们因此原地踏步了十年，直到戴夫·法利（Dave Farley）和杰兹·汉布尔（Jez Humble）在他们的里程碑式著作《持续交付》中复兴并更新了XP的核心技术思想。

当然，Scrum并没有就此止步。当你缺乏底层技术卓越性时，Scrum的流程元素并不能带来敏捷软件开发[8]所期望的结果（快速、高质量地交付价值）。因此，管理层试图通过增加更多流程来“大规模运作Scrum”或“处理企业需求”。这背后的真正动机，是利用流程对抗现实复杂性[9]的虚假舒适感，而这种复杂性实际上只能通过扎实的社会协作和技术手段来解决。

当DevOps首次出现时，它可以被简化为“打破开发和运维之间的壁垒”。这个想法进一步细化为协调两个团队[10]的目标，听起来人畜无害。每个人都赞同这一点，直到后续的实践揭示了那些令人生畏的技术元素（基础设施即代码、全链路监控、自动化部署）、转型型领导的必要性以及精益产品管理的价值。当DevOps变得过于“真实”和“技术化”时，逃避的愿望就愈发强烈。

从复杂的现实中仓促转向表面化的简化，是我们反复犯的错误。 不客气地说，所有优秀方法的衰落，往往都是因为管理者们对那些他们本应更了解的技术核心，因恐惧而选择了逃避，转而拥抱看似安全的“流程剧场”。

寻找真正的疗法：批判性思维与价值提取

软件行业的“蛇油”问题不在于我们拥有的技术和实践过多，而在于我们真正理解并有效应用的太少。问题在于我们失去了批判性思考它们的能力。我们应该精挑细选时却全盘接受。我们应该实验时却墨守成规。

最有效的软件团队[11]不是找到了某个“完美”框架的团队。他们是那些学会从不完美的框架中提取真实价值的团队，他们理解每种实践都与上下文相关，并且不断质疑他们正在做的事情是否真的对交付可工作的软件有帮助。

蛇油教会了我们重要的一课，但不是我们以为的“旧事物全是糟粕”。真正的教训是：我们需要看穿营销话术，了解真正有效的东西是什么。软件实践也是如此。在每个框架、方法论和“最佳实践”背后，都隐藏着解决特定实际问题的核心洞察。

我们的工作不是盲目追随，或不假思索地拒绝。而是在实践中理解、提取精华，并明智地应用。这要求开发者和管理者都重拾技术好奇心与批判性思维，在拥抱流程规范的同时，绝不放弃对技术卓越的追求。只有这样，我们才能走出“流程剧场”的循环，构建出真正高效、可持续的软件工程能力。

参考资料

[1] 流程剧场与卓越技术：软件开发的永恒危机， 微信公众号：mp.weixin.qq.com/s/yKAN7OdndMEHQ7tEoPShYA

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。