敏捷是慢的艺术

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

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

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

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

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

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

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

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

posted @ 2010-01-31 06:26 Nick Wang (懒人王) 阅读(...) 评论(...) 编辑 收藏