分布式软件开发

发表于:2014-05-26来源:博客园作者:李响点击数: 标签:分布式开发
作为 ThoughtWorks 的一名咨询师,我曾不止一次的被问到 ThoughtWorks 的交付项目和一般意义上的外包到底有何区别。要区分差别,首先要对外包加以定义,外包从最传统的 IT 外包到业务流

  作为 ThoughtWorks 的一名咨询师,我曾不止一次的被问到 ThoughtWorks 的交付项目和一般意义上的外包到底有何区别。要区分差别,首先要对外包加以定义,外包从最传统的 IT 外包到业务流程的外包,以及最近几年新兴的知识流程外包,其本身的定义也在不断的演化。每种外包有其不同的诉求,传统的IT外包和业务流程外包追求成本的降低,而知识流程的外包则更着眼于客户 知识能力的提升以及团队的成长。

  ThoughtWorks 的交付项目更多的是一种知识流程外包的高端服务。交付项目的成功不仅是交付卓越的软件,还需要在交付卓越的软件的过程中, 深刻理解客户的市场需要和业务模式,并通过自己的努力去影响客户,最终和客户以一个团队的模式一同交付高质量的软件。 而怎样去影响客户的行为,进而鼓励他们去尝试更多最佳实践呢?是否只能通过咨询项目达到这个目的呢?一般来说,咨询是需要长期在客户现场进行持续的影响,才能产生效果。但交付项目如同很多外包项目一样,通常是离岸的。那么隔着十万八千里的距离,再加上几个小时的时差,如何才能真的像一个团队一样紧密合作,并且持续的影响客户尝试更多最佳实践,一步步实现交付卓越软件这一目标呢? 沟通,就是基于知识流程外包的分布式开发中,最大的挑战。

  正如前面所说的,我们有着地理上的距离,这就意味着我们会有巨大的文化差异。客户说“还可以”,可能意味着其实有些问题。如果说东西方的文化差异可以通过了解当地的风俗民情去理解的话,那么企业的文化差异就需要一些同理心了。作为一家“不创新就会死(Innovate or Die)”的先锋企业,我们的咨询师通常是勇于尝试,热衷创新的;而我们的客户却很有可能是拥有庞大的组织结构的传统企业,做任何一点改变都需要考虑所有部门利益,甚至很长时间都难以做出一个决定,这和我们的快速反馈原则往往都是不相容的。

  所以沟通毫无疑问会成为分布式开发最大的挑战。经过多个分布式开发项目,我们总结出以下几个最佳实践:

  快速启动(Inception)

  快速启动中, 所有的项目干系人通常会聚集到一起,在两周左右的时间中进行一系列的愿景分享、业务探索、产品设计、需求收集以及计划发布等活动。

  快速启动的目的首先是让大家聚到一起。作为可能要合作上几个月甚至几年的队友,虽然之后很长一段时间大家天各一方的工作,但在启动阶段能够认识彼此,通过面对面的沟通对对方的工作有感性的认知,无疑对于后面工作的展开会起到重要作用。

  快速启动通过两周密度较大的活动,让每个团队成员,在尽可能短时间的内,达成共识。这其中包括了解战略愿景,进而理解项目的机遇与挑战;通过和市场人员的沟通去理解客户需要;和产品部门一起设计出符合客户体验需要的产品原型,进而拆分出可开发的需求;根据优先级排列并发布计划。

  在两周的时间里,团队将一个商业概念转换为形象的原型,并制定可供开发使用的发布计划,快速启动的交付物无疑对于后面的开发阶段非常重要,而更重要的是快速启动的交付物是整个团队一起工作产出的。每个人都参与了产生的过程,分享了相同的上下文,这对于后面的开发阶段的有效沟通会非常有帮助。

  在快速启动之后,团队一般就可以开始进入迭代0的开发了。在迭代0中,所有团队成员能继续一起工作,在这个较短的迭代搭建好环境,对架构都形成共识,试着在迭代0里去完成一个基本的需求。

  快速启动和迭代0这段时间中,所有团队成员紧密合作,不光对于交付软件有所帮助,也能更好地让咨询师理解客户团队的工作习惯、技术水平和代码风格,进而评估哪些最佳实践是适合客户团队的。比如我曾经参与过的一个项目中,在快速启动阶段,我们发现客户团队的很多基本实践,如TDD,已经做的很好,代码水平也很娴熟,但部署的方式却很落后。同时,业务部门的需求明显需要持续交付来支撑,于是持续交付就成了重点尝试的实践。每个项目都具有自己的独特性,所以通过快速启动的方式,用最快的速度了解客户的知识流程上需要改进的地方,这样跟客户沟通的时候,才会让客户更加认同知识流程外包的高附加值。

原文转自:http://kb.cnblogs.com/page/158996/