敏捷是慢的艺术

是的，你没有听错，我说的确实是“慢”，但如果敏捷关注的是慢，我为什么还要用敏捷呢？  要解答这个问题，首先需要回答，为什么你需要“快”。

客户需要软件，是因为要获取某些价值或者利益，而这些价值当然是越早获得越好，特别是在有竞争对手的情况下，“慢”就意味着价值的流失，甚至无法得到价值。正是因为这个原因，通常我们就会追求“快”，以便满足客户的要求。敏捷在某些方面确实迎合了这种需求，它比传统方法能够更快的提供可工作的软件，从而为客户更快的提供价值，并通过快速的反馈和有效的沟通提高开发效率。

但是，再经过了几个项目的开发，以及在网上看到很多人的观点之后，我发现有不少人认为这种“快”是通过项目进度快，或者写代码快而产生的。这就导致了客户或者开发人员认为，敏捷应该能更快速的产生代码，更快速的完成项目。因此在敏捷项目中，如果不能比传统的方式更快的生产代码和实现需求，客户就会不满意，项目经理就会坐立不安。在这种环境下，开发人员也很容易受到影响，想当然的认为敏捷就是不写文档、快速的写代码、快速的交付。 事实上，这是完全不对的。

从敏捷实践来看，TDD，重构，持续集成……都要消耗更多的时间，甚至迭代本身也比瀑布模型有更高的成本。Pair Programming是一个非常好的例子，很多人一开始接触时，不免都会有“这会浪费一个人，降低一半生产效率”的想法。实际上不管我们如何说这不是浪费，但如果单单从写代码的速度来看，Pair的生产率确实要比分开写更低，虽然不会低到一半，但也绝对不会更快。种种迹象都表明，敏捷开发是要更慢的，但这种慢是值得的。

如果从一个客户的角度来看软件，客户对于软件的投资可以分为开发成本、维护成本和运行成本。开发成本指的是项目开发过程中需要付出的成本，维护成本是指在软件上线后，对其进行添加功能，修改功能的成本；运行成本则包括运行软件所需要的软硬件、环境以及人力成本。对于一个长期运行的软件系统来说，开发成本只会占到很小的比例。比如一个计划使用十年的系统，开发时间可能只有一年，而维护确需要九年。正是这个原因，从中可以看出，如果能够通过增加一些开发成本，来降低维护成本，从总体上来看是会降低成本的。因此，对于长期运行的系统来说，开发质量比开发速度更重要。

前面说到敏捷能比传统方式更快的提供价值和可工作的软件，这又是怎么通过“慢”来实现的呢?

对于客户来说，每一项需求所带来的价值或者说回报，是不一样的。有些需求的回报多一些，有些则少一些。如果我们能够识别出这些价值高的东西，先实现出来，客户就能更快的或者更高的回报。但是在现实中，客户往往并不确切知道，哪些是价值高的，甚至不知道他们想要的究竟是什么，因此我们需要通过迭代的方式，来获取客户的反馈，和客户一起找出究竟应该做什么才是正确的。如果忽略了价值，一味追求开发“快”，最后开发出价值比较低的需求，却忽视了系统的核心价值，就得不偿失了。

因此，敏捷的关注点应该是质量，而不是速度，通过提高软件质量和识别核心价值，来降低成本。所有的敏捷实践都是为了能够用更有效率的办法，用尽可能快的方式提高质量，消除浪费。最终结果的“快”是通过过程上的“慢”来实现的。