分布式开发

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

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

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

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

　　快速启动(Inception)

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

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

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

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

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

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

　　站会：

　　相信了解敏捷的人对站会这一实践都不会陌生。在分布式开发过程中，我们不仅开展了团队的站会，还进行了基于角色的站会。一般而言，团队的站会更多的关注故事卡的状态流动，检查路障，而不会关注每个不同角色的具体工作;而在基于角色的站会上，例如开发站会上，开发人员之间可以讨论技术上的某个难点。同样的，业务分析人员也要通过每日的业务分析站会来了解产品经理的思路变化和业务部门的更新。 我曾经遇到过一个项目有来自三地的测试人员，那么测试人员之间的站会就非常重要，测试人员利用角色站会这一机会讨论测试策略。随着项目的演进，测试的重点也不断转移，从一开始关注功能测试到逐渐关注集成测试，角色站会给他们提供了一个契机及时讨论项目碰到的问题和机会。

　　迭代计划会议：

　　迭代计划会议也是常见的实践。在分布式的场景下，迭代计划会议需要更多的准备，要求各方团队成员提前理解下一迭代需要完成的需求，这样大家可以在迭代计划会议的时候着重讨论有疑惑的需求，而不是浪费很多时间在解释需求本身是什么上。在答疑解惑之后，大家对要完成的迭代目标必须形成一致的意见。同时，在分布式的开发中，不同地域方的团队成员会更加关注本地团队所能完成的需求，却忽略了其他地域团队的开发速度。在其他地域团队遇到困难时，更重要的是帮助对方一起完成对方做的需求，而不是只关注自己做的需求。通过一起达成迭代目标，让大家分享共同的责任感。

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