敏捷到底是个什么鬼？

大家都知道，敏捷虽然是由一群软件开发高人通过《敏捷宣言》提出，但敏捷思想早就已经破圈了，甚至成为一种企业管理的思想。

不管你的公司是否从事软件开发，如果你在公司里面每天都开十几分钟的站立会议，或者总是从领导的嘴里听到要快速迭代，又或者一个产品还在创意阶段，负责人总是要求先把最小可用产品做出来，这就说明你和你的团队已经被敏捷思想深深地影响了。

说一千道一万，到底如何用一两句话说清楚敏捷到底是个什么鬼呢？

我们溯本求源，来看看《敏捷宣言》的创始人是怎么说的。

《程序员修炼之道》被一代代开发者奉为圭臬。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。

这本书的书名虽然有“程序员”三个字，但既然敏捷思想已经破圈，书中提到的原则也适用于各行各业。

作者大卫·托马斯和安德鲁·亨特，作为《敏捷宣言》17位创始人中的其中2位，也借此书道出了敏捷的两大本质——先完成再完美 和 ETC (Easier To Change)。

先完成再完美

有一句话贴在Facebook的墙上：“完成大于完美”。

在《程序员修炼之道》里面，作者们也一直在强调应该交付“够好即可的软件”，并强调“你无法写出完美的软件”，要放弃对完美的执念。

今天，需求发展变化很快。如果按照原来瀑布的方法开发，需求分析、设计、开发等等一套流程下来，一两年过去了，市场的需求早就变了，做得再完美也已经过时了。

更要命的是，用户自己往往说不清楚自己需要什么。你可以想想，微信做出来之前，你会想到自己需要这么一个软件吗？是不是觉得短信和QQ完全就可以满足自己需求了？

需求不清，是软件开发的最大挑战。《敏捷宣言》重新定义了交付软件的价值到底是什么？每次开发出来的软件交付给用户，它的价值不再只是把实现了某个功能的软件产品交付给用户，它更是探寻用户真实需求的催化剂。催化剂是什么，它虽然不是我们需要的结果，但它却是促成结果的关键要素。

举个例子，和朋友们聚在一起，到了饭点，想约着一起去吃饭。可是到底去吃什么，大家都说不知道，一直僵持着。只要在这个时候，有一个人提出“要不还是吃汉堡包吧”，局面马上就打开了。有人就会接话说，汉堡包不好吃了，还是吃川菜吧，然后又有人说，最近就是想吃辣，最好还是肉多一点。于是很快就能定下来，去吃了火锅。

这里第一个人提出的汉堡包，就是那个不完美的产品，它的价值给了所有人一个靶子，让人以它为基础，提出自己的需求。

软件开发也一样，当面对的是一个不确定的市场时，越早喊出“汉堡包”，就可以越早地打破僵局，发现用户的真实需求。

最小可用产品（MVP），其实就是用产品当作催化剂的最佳实践之一。开发一个新产品时，不要只相信创始人的个人经验，也不要相信用户调研。有一个想法之后，要尽快把一个功能最精简、开发时间最短、成本最低的产品做出来，从真实的用户那里获得反馈。

“先完成再完美”让我们别把目标放在结果上，只想着结果要完美，更重要的是过程，别光想着要做什么，还要知道怎样才能做到。高手，不是放弃了完美，而是用更快的速度、更少的成本先完成，用真实的产品让用户反馈。

这个原则其实对我自己的影响也很大。我的第一本书《猎豹行动 硝烟中的敏捷转型之旅》的初稿只花了一个月就完成了，把编辑都惊到了，她说不少作者写一本书要花好几年的时间。我的做法就是一直写一直写，先保证每章、整书的完成度，再不断优化。

我写公众号文章也是这个习惯，一开始可能写得很烂，但会坚持先把内容写完，达到一个可发布的状态，再修改、完美。

很多伟大事业的完成，并不是建立在完美的计划和构思上，而是及时行动，边行动边修正。

ETC

在“先完成再完美”的思想指导下，快速完成最小可用产品，用它获得了真实反馈，然后肯定还想持续地变更和改善。每一次完成，其实都是实现最终目标的一小步。

在《程序员修炼之道》里面，作者强调了一个编写代码的核心原则——ETC（Easier To Change），让变更更容易。可以这么说，所有的编程技巧本质上都是在实现ETC原则。

软件的持续改善，很可能是上午发布的内容下午就有反馈，需要进行改善。如果程序员写的代码不能应对这样的变更，或者变更成本很大，风险很高，那就无法持续满足新的需求和反馈意见。

所以，先做一个最小可用产品，赶快投放市场获取真实反馈。这只是做对了一半，还有另外一半是这个最小可用产品的实现，要符合ETC原则，容易变更。

其实ETC不只是实现持续改善的一个简单原则，它本身就是一个实现持续改善的解决方案。如果给程序员最深恶痛绝的事情排个序，需求变更绝对可以排在前三。

每当产品经理提出需求后，他们恨不得让产品经理签字画押，承诺一定不改需求了。可是，需求不是产品经理说了算的，真正决定需求的是用户。要想对用户负责，那就要允许需求变更。

在《敏捷宣言》提倡的价值观里面也有一条，响应变化高于遵循计划。只有先具有了灵活的意识，才能有灵活的解决方案。

一个高手程序员，面对需求变更，想到的不是让产品经理签字画押保证不变，而是利用ETC原则，让变更更容易，为变更做好准备。

要满足ETC原则，就要在软件设计和编程过程中遵循六字真言“高内聚，低耦合”。高内聚的意思就是说设计代码模块的时候，内部功能的聚合程度要尽可能地高，低耦合的意思是说模块和模块之间的耦合程度要尽可能地低。

实现了高内聚低耦合，就能保证代码模块有良好的设计。万一需求变更了，那就会出现两种情况：要么是代码模块本身可以不变，变的是模块互相之间的拼接，就像是乐高积木一样；要么是某个模块性能跟不上了，那只需要更新这个模块里面的程序，不会影响其他模块里的代码。

不论需求是不是会发生变化，当我们按照高内聚低耦合编写自己程序的时候，其实就已经在为变更做准备了。解耦，也就是把系统内的各模块从高耦合状态变成低耦合也是一个必不可少的优化过程。

近年流行的微服务架构，就是解耦的极致。这种架构配合云计算的弹性，更能轻松应对像购物节这样的流量激变。

除了高内聚低耦合，还有一个原则要遵守，就是代码模块要尽可能地复用。

比如说，你用一个代码模块实现了搜索功能，可以快速地把符合条件的内容找出来，那么不论是在做电子书内容的搜索，还是网页内容的搜索，就别再重新发明轮子了，需要搜索的时候调用同一段代码就可以了。

对复用来说，节省成本只是附带结果，它更重要的功能是管理一致性。

还是以搜索功能为例，如果这个功能没有被复用，而是程序员很“勤快”地把它复制了两份，一份用在了电子书搜索功能里面，一份用在了网页搜索功能里面。那要是遇到了变更，比如这个搜索模块的技术落后了，需要用更好的技术增加搜索速度，那最开始的“勤快”就会给变更带来麻烦，必须把两个复制的模块都做同样的修改才行。

但如果这部分代码是被复用的呢，就没有这个麻烦了，只需要一次修改，全部调用这个模块的代码都可以用到最新的搜索技术。而且这还不是麻烦不麻烦的问题，现在普普通通一个软件产品，都可能会有几十万行的代码，需要上百人的协作，如果没有把复用原则执行好，那么就是一个小更改都可能让整个产品出现bug，导致崩溃。

近年流行的中台，便是复用的另一种体现形式。

除了以上原则，敏捷开发实践像测试驱动开发、持续集成、持续部署等，都是为了ETC，都是软件实现持续交付的关键。

这些原则不光对软件开发有效，对各行各业来说，面对瞬息万变的市场，谁的应变能力更强，谁就是强者。特别是在疫情这样的大考中，应变能力更强的企业就更容易存活下来并得到新的发展。

总结

通过解读《敏捷宣言》17位创始人中的其中2位——大卫·托马斯和安德鲁·亨特的大作《程序员修炼之道》，我们重新梳理敏捷的两大本质：

1. 先完成再完美——不是放弃了完美，而是用更快的速度更少的成本先完成，用真实的产品让用户反馈。

2. ETC (Easier To Change)——面对需求变更，想到的不是让产品经理签字画押保证不变，而是利用ETC原则，让变更更容易，为变更做好准备。

本文部分内容摘自得到每天听本书——王木头解读《程序员修炼之道》。