您的位置:首页 > 其它

外包能“敏捷”起来吗?

2016-02-02 17:00 281 查看



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

这个问题也是Taskcity一直致力于解决的课题。下面是我们的一些理解。

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

 
方法恰到好处

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

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

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

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

 
质量保证,真的吗?
听起来像是玩笑。敏捷开发这种快速交付,还能保证质量,象是天方夜谭。其实不然。快速交付,让用户能够尽快试用你的功能,尽快发现问题,就整个开发周期而言,整体质量一定会得到提升。在传统开发模式中,我们都会或多或少遇到这样的情况,因为开发时间的拖延(总是会拖延,这不可是玩笑!),测试时间永远是第一个被压缩的阶段。结果可想而知。更多的迭代引入了更多的测试周期和时间。

 
一起来“敏捷”吧!

当然,在具体执行的技巧中,在外包行业或国际外包项目中引入敏捷的开发思想,还有一些需要注意的地方。但是,远隔重洋的地理分离,如果再加上在开发流程中的用户与开发方的长期“分居”,结果就会是这样 :没有一方会满意。所以我们从一开始就确定了在我们的在线项目管理工具和协同工作工具中引入敏捷的思想和原则。

 
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: