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

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

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

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

方法恰到好处

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

沟通的威力

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

迭代是趋于完美的过程

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

勇于面对改变

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

质量保证,真的吗?

相关推荐