最近重新翻开了一本 10 年前买的书，它叫做《程序员之禅》，这篇文章我暂时不打算写这本书的读后感，我们展开讲讲它里面提到的关于敏捷的话题。

书中有一个篇章劝我们，不要变成一个极端主义者，它提到，敏捷工作流容易让每个问题都变成钉子。它反问我们：如果毕加索用 scrum 进行工作，你很难想象他的作品会变成什么样子。

不可否认的是，敏捷工作流是一个很优秀的工作流。如果从投资的角度讲，他可能是把事情做对的好工具，然而并不一定有利于使用者找到对的事情去做。

请允许我用自身的经历谈谈它，从大学开始我就是敏捷的忠实信徒，那时候我对于很多大厂，大设计的瀑布流工作方式嗤之以鼻（那时候也是有点太无知了）。

所幸，毕业之后去的两家公司都比较崇尚敏捷工作方式（回流是第三家企业），我也在这些公司获益良多。

在前几年的工作中，我唯一想的一件事情就是变强，我希望能成为一个优秀的开发者，我深信敏捷工作方式能够帮我达成这个目的。

我深信，只要我足够敏捷，我就能最大化自己的工作产出，我能把自己的工作效率“压榨”到极致，觉得只要自己效率最大化，就距离优秀的程序员更进一步了。

来了回流之后，由于后端代码都由自己负责，相当于所有东西都自己掌控了，我把以前的遗憾全都补足了。比方说我为项目引入了单元测试，引入了 CI 工作流，给团队制定了每周一个版本的迭代节奏。

早期我们每周都能交付功能，我对自己的效能很满意，然而也会有瓶颈。那时候我感觉见超的输出完全不如我，还很傲慢地想，怎么就不学学我呢？怎么就不像我那样敏捷呢？可见那个时候我已经成了一个敏捷的极端主义者了。

那时候我对所有人都很苛刻，包括对老板们（这点很不可思议）。我觉得只要自己足够敏捷，效率足够高，一切都会好的。

真正让我转变，可能还是扩招之后。那时候可能要一个人对接好几个开发，还要对接产品经理。一个人的效率达到极致已经没有任何意义了。

当一个团队人员多起来之后，沟通变得越发重要。比起自己效率最大化，不拖团队的后腿更为重要。

我可以选择有一定敏捷思维的人才，然而我不可能让所有人都如自己一般把敏捷做法视为圭臬，然后都把效率提升到极致。就如同书中劝导的：毕竟我们都是人，并不是机器。

我发现自己变得越来越不够敏捷了，比起写更多的代码，我可能会花更多时间去正确传达一个需求。我花了更多时间去识别一件事情对不对，而不是如何去把事情做对。如果是一件不对的事情，那么效率越高，灾难越大。

以前的我以为，只要自己足够敏捷，效率足够高，就能成为一个优秀的程序员。然而我从来没想过，当自己变得不那么敏捷，效率稍微有点降低之后，我反而成了个“更好”的程序员。

这是一件很反直觉的事情。因为考虑问题的视角不一样，我会花更多时间去识别一个需求的意义，而不是埋头苦干。我们排除了很多没有意义的需求，这也让我能写出更精简的代码。

写的代码虽然少了，但你很难说这不是一种效率的提升，以前公司要试验一个新的场景，我们都要花一个星期以上做开发才能投入业务试运行。

后面自己想的却是，到底有没有必要做，没必要做的话，是不是就省了一个星期的时间？真的有必要做的话，有没有可能只要花一个小时做一个小功能就可以让一部分业务跑起来，而不是一上来就开发大功能？

这次严选的整改，强哥已经设计好整个流程了，开发量大概 1 ～ 2 个月。后面我们反复讨论，有没有可能以现有的流程跑起来先，发现是可以的，大流程完全就不用开发了。

虽然强哥的工作有点白费，然而最终节省了一个多月的开发量，也不会耽误业务工作，何尝不是一种双赢？然而你说这种算不算敏捷，我也说不准。

这么看来，自己似乎成了敏捷的叛徒，然而成了敏捷叛徒之后，我似乎成了一个让自己更满意的程序员了，虽然我的代码量并没有早年夸张。其中还有个最大的好处，我对身边的人也没这么苛刻了。

我曾经为了成为一位优秀的程序员，坚守敏捷信条，然而只有别那么苛责自己去坚守敏捷信条的时候，反而成为一个自己满意的程序员了。

这点很有意思，有些时候，我们坚信的方法论，并不是通往目标的唯一方式。芒格经常劝导我们：“反过来想，总是反过来想”。

• 原文链接： https://step-by-step.tech/posts/agile_believer_or_traitor
• 公众号：CTO 成长记