再谈敏捷开发的好处及敏捷外包的前景

本文是Taskcity（一个提供敏捷管理工具以及为敏捷外包提供支持的公司）对敏捷外包的一些看法，对于理解敏捷的一些基础概念还是有一些帮助的。

Agile，敏捷开发被越来越多的开发企业和团队所接受。敏捷恰当，可以显著提高开发效率和产品的开发周期。问题是，“敏捷”方法是否能适用到软件外包行业，这个争论 由来已久，各有说辞。最典型的争论就是，作为外包的一个显著特点，用户和开发团队是相对远程，甚至开发团队内部也存在远程的问题。如果一个团队不能身处一室，其中强调的沟通和互动是否能够得到有效的执行，是一个大问题。

传统的外包商业环境，是客户和服务提供方达成一个长期的合同，基于一个相对较长的阶段，提供稳定的外包服务支持。现在，越来越多的企业客户开始考虑将外包 项目划分为小的可执行单位。风险可控，操作灵活。而服务提供方相对也达成了这个共识。其实，这两种情况，如果通过敏捷的开发模式，在一个长期的合作过程 中，大家会发现，Agile不仅可行，而且的确能形成一个双赢的局面。一起来看看我们的发现吧。

方法恰到好处

如果我们追求看到一个项目完成的效率和效果，敏捷开发其实优于传统的开发模式，即便对于初次接触这个概念的发包客户亦如此。我们大家都知道，在很多情况 下，发包客户和服务提供方在涉足将项目外包出去开发之前，都拥有自己比较熟悉的开发模式和方法。敏捷开发或者说增量开发，可以让双方很轻易的统一到一个接口。传统的开发方法基本上都是基于一个反复推敲的合同，合同中对于功能设计以及权利义务定义原则上都进行了仔细的定义。但是，根本的问题是，很多用户在项 目开始前，甚至开始的初期都没有一个明确的，或者说准确的描述。这样，很多时候，客户为了保护自己的利益，会尽可能多的添加功能到这个项目书中。而开发服 务提供方考虑的是如何在自己的成本控制内得到尽可能多的盈利。在一开始，其实就为双方日后的纠纷埋下了种子。我们能看到，在传统的开发外包中，相当比例的 项目最后，即便完成交付，完成支付，最后双方的心情都是不太好。敏捷开发强调了阶段性交付，增量开发，用户互动。最后的交付物有时和原始的设计已经有了很 大的出入，但是客户贯穿了整个开发的周期，了解了所有的变动以及缘由，其满意度甚至超过一个100%吻合的交付结果。用户的满意度和开发完成的代码量不是 直接的因果关系。而在软件外包行业中的同行们都知道，一个满意的客户意味着可能的后续项目，而这也是服务提供方最希望看到的结果。

沟通的威力

肖伯纳有一句名言“England and America are two countries divided by a common language。”意思是英国和美国是被一个相同的语言所分隔的两个国家。这里不是指的地理上的分隔，而是文化沟通上的差异，即便他们都说一种语言。英 美尚如此，何况作为一个典型东方文化代表的中国和我们的欧美客户呢？不同的时区，不同的文化，不同的工作方法和原则，导致沟通成为了我们进行海外外包的一 个瓶颈。敏捷开发既强调了沟通，又为顺畅的沟通提供了方法和指导。其中持续的交付实际是在用实实在在的形式进行了项目的沟通，从而降低了最后的交付风险。 想想吧，作为传统开发模式，比如一个瀑布式的开发，六个月后，客户才能第一眼看到自己想要的产品，这里面能产生错愕的概率有多大，大家可以想象一下。

迭代是趋于完美的过程

罗马不是一天建成的。不要尝试对完美的一步到位，除非你的用户愿意牺牲宝贵的进入市场的时机。外包开发不象是一个公司内部的开发团队的 管理模式，对于离岸外包而言，双方远隔万里。所以我们的建议就是，只用尽最大可能不断地从客户那里得到进程中的反馈，进而对开发加以修正，才不会出现最终 和用户意愿的大偏差。在双方可以接受的情况下，定义一个一个短促有效的迭代过程，第一时间发现问题，放到下一个迭代中去解决。一个典型的迭代包括计划-设 计-反馈-执行（PDCA）。

勇于面对改变

需求变更在整个软件开发的生命周期中是一个永恒的话题。也是客户与服务提供方最纠缠不清之所在。改变的导火索可以来自方方面面，既有可 能是一觉醒来后的灵光一现，也有可能是来自客户外部商业环境的改变。既然是现实，就接受它吧。当然，处理得当，这种变化可能协助双方得到一个更优秀的软 件，也能让客户对你的快速应变产生好感。否则，如果固守原始的设计稿件，或者永远作为一个新功能要求追加资金，有可能得到一个Case，却失去一个用户。 另外，我们总是陷在一个自己预设的陷阱里，客户的要求改变永远是对功能的增加。其实，一个过程中的再设计，有可能会降低开发的成本。

质量保证，真的吗？