敏捷时代必须终结

图0: 敏捷开发敏捷时代必须终结

30 年前，科技行业试图引进精益实践，但以失败而告终。他们没有“持续改进”，而是就此停了下来。敏捷与 UX 研究、设计和可扩展开发并不相容，而且会一直如此。是时候制定一个新的作业标准了。

本文最初发布于 UX Collective。

鉴于初创公司重新开始关注“运营效率”，我们需要强调一下，效率是一种工作方式，而不是数人头。

毫无疑问，20多年来，敏捷开发一直是科技领域的头号作业原则。然而，它的根本性缺陷也一直对我们虎视眈眈。

缺陷 1：人不是机器。
缺陷 2：设计不是库存。
缺陷 3：产品不能由任意数量的拥有任意技能和经验的人在两周的冲刺中所能完成的工作来定义。

让我们回顾一下各个阶段：

2001 —— 敏捷
1995 年 —— Scrum
1988 年 —— 精益
20 世纪 60 年代 —— 丰田生产系统（TPS）

初起

从 20 世纪 40 年代到 70 年代，TPS经历了几十年的发展，使丰田得以实现并保持其在世界汽车制造商中的主导地位。这个令人印象深刻的早期阶段主要聚焦于消除 muda（浪费）、mura（不一致）和 muri（负担过重）。

关于消除浪费的记录最详尽。在这 8 种浪费中，危害最大的是库存过剩——包括成品和原材料，以及闲置不用的机器。换句话说，你花钱买的东西没有为你赚钱。本质上，丰田的解决方案是物流方面的，后来被称为“准时生产”。

及时接收材料，以便流水线可以及时处理材料，生产出满足客户需求的成品。“丰田之路”是 TPS 的一个卓越的合作伙伴。这一理念要求持续改进，包括：克服挑战，实现长期愿景；kaizen（运营创新）；以及我个人最喜欢的现地现物（genchi genbutsu）——意思是“真实的地方，真实的东西”，这个原则是说要“自己去看看”，并据此做出决策。它还鼓励采用自下而上的改进方法，了解每名员工的见解，而不管他们是什么级别。

美国人发挥了它的魔力，把丰田之路变成了他们的 Cup Noodles。好吧，也许我这样说并不公平。准时制造在美国本土制造业中得到了很好的应用。1988 年，在一篇题为“精益生产系统的胜利”的文章中，它被重新命名为精益——清晰的传承。

在流水线上生产的汽车（图片来自Unsplash，由Carlos Aranda提供）

精益及其前身非常适合实物产品的制造，特别是当市场已经建立、产品已经成熟时。它依赖于需求和供应链的可预测性。当研发新产品时，制造商则依赖于研发部门的各种流程。无论是基因泰克公司（Genentech）研发合成胰岛素，还是宝洁公司（Proctor & Gamble）研发 Swiffer，这都是一个漫长的线性过程。其中包括在产品开发之前进行深入的研究和市场分析。

瀑布成了替罪羊

在很大程度上，蓬勃发展的软件业遵循了这些流程；在应用于数字产品时，它们被称为瀑布式方法。术语“瀑布”已经成为描述以发布完全实现的产品为终点的线性开发过程的统称。然而，这个又大又昂贵的产品发布可能并没什么用，说实话，人们在这方面的批评是合理的。因此，瀑布被作为证据，用来证明迭代、测试和在更短的时间内对市场做出反应的必要性。

20 世纪 90 年代，科技行业的从业者们探索了将精益应用于数字产品的方法。遗憾的是，从一开始，他们就误诊了问题。上市时间很重要，但我认为从现金流的角度来看更重要，尤其是对初创公司而言。精益的支持者把婴儿和洗澡水一起倒掉了。请注意，Scrum 和敏捷文献很少或根本没有提到研究或战略。在瀑布中，设计这个冗长的阶段被认为是浪费时间。精益框架都是关于构建和发布的。

大约是在这个时候，精益开发的支持者和瀑布开发的践行者之间爆发了一场怪兽对机甲的战斗。不管是怪物，还是机器人，它们都没有考虑用户的需求，而是踩着他们毁灭了世界。

如下图所示，它们之间的区别在于，敏捷代表一部分，而瀑布代表整体。

敏捷错误地假设功能会被修改。瀑布错误地假设产品不会被修改。（基于Asana的图片修改）

对市场上正在使用的产品进行迭代是软件的专利——更新可以在任何时候推送，而且不需要对流水线和工具做任何改造。每个科技产品都应该分阶段构建，但必须围绕最终目标和完全实现的产品。成功需要战略、研究、设计和现地现物（genchi genbutsu），正如“丰田之路”告诉我们的。敏捷与瀑布之争是一个错误的两分法：公司可以有一个长期的战略，并在执行的同时，增量、迭代地发布产品。

存在长达 30 年的错误

当产品负责人和工程师试图将精益生产原则应用于软件开发时，他们找到了模仿流水线的方法。及时确定需求，然后跨职能团队冲刺发布可工作的软件。Scrum 这个词是一个明智的选择——它源于橄榄球比赛，在这项运动中，一排小伙子在球场上穿梭并来回抛球。软件开发方法具有同等的技巧和策略。

所有人都得和 Scrum 打交道，原因如下：

必须限定到冲刺（Sprint）中，以确保软件可以按“迭代”周期投放市场。
“冲刺计划”要在“冲刺”开始前进行，因为那时你可以及时获得所关注事项的最新见解。
每天举行站会，“即时”开展运营改进。（开发者只能发言，不能讨论，因为那比较浪费时间。）
在冲刺结束的时候，会对可工作的软件做一次评审，看看哪些没有完成，哪些需要改进。
还有一次回顾，讨论哪些工作进展顺利，哪些工作进展不顺利，以期增加产出。
待办事项（Backlog）并不是 Scrum 实践的核心，它产生于冲刺的副作用以及这个过程中产生的一些零碎的事项。可以看到，Scrum 已经相当不合逻辑了，但它还会变得更糟。

Scrum 的部分创建者和其他精益开发从业者一起制定了*《敏捷软件开发宣言》*。这个具有马克思主义色彩的标题很可能是有意为之：他们声称工人将拥有生产资料。

敏捷（脆弱）宣言

就宣言而言，这是有史以来最可悲的文件之一。敏捷宣言给出了 4 个“价值观”和 12 项“原则”。它的初衷可能是好的——将开发人员看作是人，而不是机器上的齿轮——但现在，我们已经回到原点。这些原则已经演变成腐蚀组织的东西。现在看来，它们是敏捷团队如何免除责任这个主题的变体。

敏捷宣言的重点（和我的翻译）：

个人和交互高于过程和工具。（是的，我们想怎么做就怎么做）。
欣然面对需求变化，即使在开发后期也一样。（我们也可以随时改变主意）。
激发个体的斗志，以他们为核心构建项目，信任他们。（离我们远点，只管有什么拿什么）。
可以工作的软件是进度的首要度量标准。（事实是，我们创造的任何东西都很重要）。
简洁为本——这是极力减少不必要工作的艺术。（我们会尽量少做）。
最好的架构、需求和设计出自自组织团队。（不要告诉我们该做什么）。

听我说，我这不是对工程师朋友们的攻击。与我共事的大多数开发人员都热衷于把事情做好，但他们感觉受到了限制，只能根据冲刺时间窗口和承诺的交付成果来完成差强人意的工作。尽管如此，一些已经被灌输了敏捷思维的技术领导者仍然心怀崇拜地遵循着上述原则。需求更多的是建议而不是规则，设计需要解释，如果最终结果仍然“有效”，那么任何东西都可以砍掉。

对于初创公司来说，敏捷原则和 Scrum 实践的结合是灾难性的。这些是来自管理层的作业指令；设计师、项目经理和工程师并不是自组织的，这种方式工作不是他们选择的。一切都是以“MVP”和上市时间的名义；这就是一再发生的事情。

研究和设计针对客户的问题提供解决方案，但相比之下，实际构建的产品却总是相形见绌。

产品经理忙着实现路线图上下一个闪亮的目标……而且遵循着越少越好的原则。

工程师就像流水线上的机器一样，总是被期待着生产和交付，为了“完工”而偷工减料。

领导层不明白为什么产品如此不稳定且效率低下。

敏捷和 Scrum 非但没有消除浪费，反而只会产生浪费，留下一个烂摊子：倦怠、技术债务、设计债务、不断增加的待办事项、硬编码的前端逻辑，以及始终存在的完全重构的威胁。

我们怎样才能走出这个怪圈呢？