分布式软件开发

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

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

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

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

　　快速启动(Inception)

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

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

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

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

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

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

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