我讨厌说说而已的敏捷

现在总有人说“敏捷死了”，然后又说“我们是开玩笑的”。他们想表达的意思是，敏捷本身并没有死，是我们的敏捷实践方式出了问题。那么怎么做才是对的？或许真正的敏捷只存在于理论之中？有时候我也会这么说，但现在已经感到厌倦了。

网上有很多替敏捷辩解的观点：“有问题的是瀑布式scrum，而不是《敏捷宣言》中所宣扬的敏捷……”但 Bob Marshall 却直言不讳地指出：“《敏捷宣言》已经是老黄历了”。然后他说了一些令我信服的观点，经过一番思考之后，我写下了这篇文章。

知道《敏捷宣言》第一行写的是什么吗？不知道吧？没关系。它是这么说的：“我们正在探索更好的软件开发方法……”请注意，这里说的是“软件开发”，并没有说“如何让组织变得更精益”、“如何偿还向敏捷转型而欠下的债务”、“如何专注结果”、“如何修复老旧的预算系统”，或者其他任何可以增值的东西。

另外请注意，它说的是“我们正在探索……”，并没有说“我们已经……”。从 2001 年发表《敏捷宣言》以来，我们就没有学到什么东西吗？有是有，但大部分企业的状态似乎仍然停留在 1987 年。

《敏捷宣言》自然有它的用意，但不会把你送到你想要去的地方。所以，继续学习吧。我们的知识是有保质期的，而且这些保质期比我们认为的要短得多。我们的同事（通常是领导）经常会说“没时间学习”，可能是因为他们对自己所知道的东西太过于自信了。所以，列一个书单吧。如果你还没读过这些书：“Sense & Respnd”、“Lean Enterprise”、“A Seat at the Table”和“Everyone Is a Change Agent”，那么开始读起来吧，让你的领导也读一读。

你也可以看看这些大师的博客，比如 John Cutler、Melissa Perri、Bob Marshall、Allen Holub、Laura Klein、Erika Hall、Neil Killick，等等。他们的观点会一样吗？或者会和我一样吗？不会。但他们都是聪明人，看他们的博客也会让你变聪明。《Fast Company》杂志说，企业 CEO 平均每年会读 60 本书，那么你的领导会读几本？为什么要让他们读书？因为如果他们的知识不更新，总以旧眼光看待 scrum，那么你也会被死死地禁锢在 80 年代或者 90 年代。

所以，我们要持续学习，不断更新知识，不要把敏捷当成万灵丹。可以这么说：敏捷只为整个系统提供局部优化。敏捷所做的只是把软件开发团队放在一个局部空间，并不会提升整个组织的敏捷性。Ken Schwaber 说，敏捷试图“收拾瀑布开发留下的残局”，但却从未提供全盘可行的替代方案。毕竟实践和理论之间是有差距的。当我们抱怨“AINO”（Agile In Name Only，名义上的敏捷）时，我们要先扪心自问。

我们要面对这样的事实：实践中的敏捷大部分都只是名义上的敏捷。这看起来好像是敏捷运动的错，不是吗？但不管怎样，我们还有很多重要的东西需要学，比如精益用户体验（Lean UX）、精益企业（Lean Enterprise）、超预算（Beyond Budgeting）、约束理论（Theory of Constraints）、产量会计（Throughput Accounting）、设计思维（Design Thinking）、DevOps 和组织治疗（Organizational Therapy），等等。

你可能会问，为什么精益用户体验会排在最前面？因为精益用户体验强调的是结果。如果你不知道要做出怎样的转变，也就不知道该做些什么。如果没有明确的方向，你就无法变得“敏捷”。敏捷的核心就是要快速转变。可能有人会说，“除了这个，还有自省和调整”。话是这么说，但在实践当中，我并没有看到有人进行自省和调整。我只看到敏捷团队不断地从积压待办的任务列表里领取任务，倒腾Jira和 Rally，就像搬砖工人一样一块一块地往上砌墙。

敏捷通常会把缺乏垂直信任的核心问题隐藏起来。等敏捷教练离开之后，事情会变得更糟糕。管理层和开发团队之间的沟通变成了鸡同鸭讲。开发团队认为管理层什么都不懂，管理层则认为应该把精力集中在任务范围、截止日期和效率上，却不曾想这些截止日期都是拍脑袋决定的，而预估时间什么的其实是一种浪费。

那么这两者谁会赢？他们看问题的视角完全不同，但无奈的是，其中一方的绩效评估是由另一方决定的。开发团队就像是盲人摸象，他们可能摸到不同的部位，然后得出不同的结论。而管理层则是瞎了眼的大象踩在了人身上，他们得出了一致的结论：人是扁的。解决这个问题的唯一办法是要认识到整个团队是一个完整的系统，不要只是做局部优化，而且要把信任放在首位。

开发团队不是工厂生产流水线上的工人，我们不是在生产什么塑料餐具，我们生产的是软件产品。我们不能用经营披萨店的方式来运营团队。做披萨和开发软件是不一样的，做披萨用的是同样的菜谱做出同样的披萨，而开发软件是一项具有创新性的活动，我们要自己设计菜谱。或者说开发软件是一个发现的旅程，不仅仅是按部就班地交付东西那么简单。如果意识不到这一点，就会造成巨大的浪费：开发出来的功能没有人用，开发团队付出的努力得不到相应的结果。这暴露出了敏捷的另一个深层问题：把用户当小白鼠，让他们先把产品用起来，后续再加以改进。但面对糟糕的产品，用户头也不回地走了，后续的产品改进纯粹就是在浪费资源，因为用户根本不买账。

有人会说，敏捷其实也关注创新性的工作。如果你主要从事设计或创新性方面的工作，那么请回答以下这些问题：在跟敏捷团队合作的时候，他们是怎么对待你的？他们认为你会给他们带来价值并帮助他们进行自省和调整吗？或者他们有要你体现出你存在的价值吗？Alan Cooper 说过，如果你被要求体现出存在的价值，那无异于是在告诉你：在这个系统里，你是没有价值的。请注意，他们要开发人员证明自己的价值，而不关心开发人员写了多少可以带来正向结果的代码。换句话说，他们关注的仍然是人，而不是工作本身。他们仍然关注成本，而不是价值，所以有很多价值从指缝间悄悄溜走了。

如果下次还有人要你“证明自己的价值”，你可以问他们：延期交付的成本是怎样的？怎么评估这些成本？具体的目标是什么？达成这些目标所对应的工作量占了总工作量多大比例？如果他们回答不上来，你可以继续问：如果有更好更快的办法可以知道该做些什么，而不是仅仅是机械式地交付代码，他们愿意学吗？他们的工作流效率是怎样的？他们在不必要的会议上浪费了多少时间？如果有一些做法可以在更短的时间内推动更好的决策，他们有兴趣去学习吗？

这是另外一种思维方式，一种元思考，一种战略性思考。Austin Govella 说，敏捷和瀑布关心的是如何构建软件产品。如果他们只是埋头交付代码，关注成本问题，他们就永远都不会意识到他们只能获得更多自己关注的东西（也就是成本）。他们变成了一个交付软件功能的工厂，就像是在生产塑料餐具。但其实你可以有其他选择，你可以做更有价值的事情，而有价值的事情需要去发现。当你发现了更多选择，也就获得了更多可以产生正向结果的途径。想要达到怎样的目标？有没有找到三五种达成目标的方式？当只有一种选择的时候，你没得选择；当有两个选择的时候，你陷入了两难的境地；当有三个甚至更多的选择的时候，你总能选择其中一条路走到你想去的地方。

你有听说过“必要多样性定律”（Law of Requisite Variety）吗？这个定律指出，在一个系统中，具有最多选项的组件将拥有系统的控制权。基于这个定律，我们可以这么想：管理层想要在顶端控制整个系统，而敏捷团队想要向实际的用户交付价值，如果想要结束这种对立局面，就要让处于各个层面的人都有的选择。解决办法不是在敏捷或者瀑布之间二选一，而是要将自上而下的瀑布策略和自下而上的经验驱动策略相结合。

说了这么多，总结一下解决办法：有清晰的目标，不要太过关注产出，用路线图代替里程碑，与可信任的产品团队合作，发现获得价值的最短路劲。

所以，这意味着敏捷要“死”了吗？当然不是，我认为敏捷还没有死，我也不希望它死掉。敏捷运动的价值在于它可以帮助实现文中提到的一些想法。但需要注意的是，敏捷运动和敏捷实践是两码事，敏捷实践实际上比敏捷运动要早出现几十年。

原文链接

Dear agile I’m tired of pretending