分布式开发
作为 ThoughtWorks 的一名咨询师，我曾不止一次的被问到 ThoughtWorks 的交付项目和一般意义上的外包到底有何区别。要区分差别，首先要对外包加以定义，外包从最传统的 IT 外包到业务流程的外包，以及最近几年新兴的知识流程外包，其本身的定义也在不断的演化。每种外包有其不同的诉求，传统的IT外包和业务流程外包追求成本的降低，而知识流程的外包则更着眼于客户 知识能力的提升以及团队的成长。
ThoughtWorks 的交付项目更多的是一种知识流程外包的高端服务。交付项目的成功不仅是交付卓越的软件，还需要在交付卓越的软件的过程中， 深刻理解客户的市场需要和业务模式，并通过自己的努力去影响客户，最终和客户以一个团队的模式一同交付高质量的软件。 而怎样去影响客户的行为，进而鼓励他们去尝试更多最佳实践呢？是否只能通过咨询项目达到这个目的呢？一般来说，咨询是需要长期在客户现场进行持续的影响，才能产生效果。但交付项目如同很多外包项目一样，通常是离岸的。那么隔着十万八千里的距离，再加上几个小时的时差，如何才能真的像一个团队一样紧密合作，并且持续的影响客户尝试更多最佳实践，一步步实现交付卓越软件这一目标呢？ 沟通，就是基于知识流程外包的分布式开发中，最大的挑战。
正如前面所说的，我们有着地理上的距离，这就意味着我们会有巨大的文化差异。客户说“还可以”，可能意味着其实有些问题。如果说东西方的文化差异可以通过了解当地的风俗民情去理解的话，那么企业的文化差异就需要一些同理心了。作为一家“不创新就会死（Innovate or Die）”的先锋企业，我们的咨询师通常是勇于尝试，热衷创新的；而我们的客户却很有可能是拥有庞大的组织结构的传统企业，做任何一点改变都需要考虑所有部门利益，甚至很长时间都难以做出一个决定，这和我们的快速反馈原则往往都是不相容的。
所以沟通毫无疑问会成为分布式开发最大的挑战。经过多个分布式开发项目，我们总结出以下几个最佳实践：
快速启动（Inception)
快速启动中， 所有的项目干系人通常会聚集到一起，在两周左右的时间中进行一系列的愿景分享、业务探索、产品设计、需求收集以及计划发布等活动。
快速启动的目的首先是让大家聚到一起。作为可能要合作上几个月甚至几年的队友，虽然之后很长一段时间大家天各一方的工作，但在启动阶段能够认识彼此，通过面对面的沟通对对方的工作有感性的认知，无疑对于后面工作的展开会起到重要作用。
快速启动通过两周密度较大的活动，让每个团队成员，在尽可能短时间的内，达成共识。这其中包括了解战略愿景，进而理解项目的机遇与挑战；通过和市场人员的沟通去理解客户需要；和产品部门一起设计出符合客户体验需要的产品原型，进而拆分出可开发的需求；根据优先级排列并发布计划。
在两周的时间里，团队将一个商业概念转换为形象的原型，并制定可供开发使用的发布计划，快速启动的交付物无疑对于后面的开发阶段非常重要，而更重要的是快速启动的交付物是整个团队一起工作产出的。每个人都参与了产生的过程，分享了相同的上下文，这对于后面的开发阶段的有效沟通会非常有帮助。
在快速启动之后，团队一般就可以开始进入迭代0的开发了。在迭代0中，所有团队成员能继续一起工作，在这个较短的迭代搭建好环境，对架构都形成共识，试着在迭代0里去完成一个基本的需求。
快速启动和迭代0这段时间中，所有团队成员紧密合作，不光对于交付软件有所帮助，也能更好地让咨询师理解客户团队的工作习惯、技术水平和代码风格，进而评估哪些最佳实践是适合客户团队的。比如我曾经参与过的一个项目中，在快速启动阶段，我们发现客户团队的很多基本实践，如TDD，已经做的很好，代码水平也很娴熟，但部署的方式却很落后。同时，业务部门的需求明显需要持续交付来支撑，于是持续交付就成了重点尝试的实践。每个项目都具有自己的独特性，所以通过快速启动的方式，用最快的速度了解客户的知识流程上需要改进的地方，这样跟客户沟通的时候，才会让客户更加认同知识流程外包的高附加值。
站会：
相信了解敏捷的人对站会这一实践都不会陌生。在分布式开发过程中，我们不仅开展了团队的站会，还进行了基于角色的站会。一般而言，团队的站会更多的关注故事卡的状态流动，检查路障，而不会关注每个不同角色的具体工作；而在基于角色的站会上，例如开发站会上，开发人员之间可以讨论技术上的某个难点。同样的，业务分析人员也要通过每日的业务分析站会来了解产品经理的思路变化和业务部门的更新。 我曾经遇到过一个项目有来自三地的测试人员，那么测试人员之间的站会就非常重要，测试人员利用角色站会这一机会讨论测试策略。随着项目的演进，测试的重点也不断转移，从一开始关注功能测试到逐渐关注集成测试，角色站会给他们提供了一个契机及时讨论项目碰到的问题和机会。
迭代计划会议：
迭代计划会议也是常见的实践。在分布式的场景下，迭代计划会议需要更多的准备，要求各方团队成员提前理解下一迭代需要完成的需求，这样大家可以在迭代计划会议的时候着重讨论有疑惑的需求，而不是浪费很多时间在解释需求本身是什么上。在答疑解惑之后，大家对要完成的迭代目标必须形成一致的意见。同时，在分布式的开发中，不同地域方的团队成员会更加关注本地团队所能完成的需求，却忽略了其他地域团队的开发速度。在其他地域团队遇到困难时，更重要的是帮助对方一起完成对方做的需求，而不是只关注自己做的需求。通过一起达成迭代目标，让大家分享共同的责任感。
在实际项目过程中，通常业务分析师会提前将计划的需求故事发给团队成员。运用合适的分布式项目管理工具会让这一过程更加容易，如 Mingle 或者 Jira。在工具中整理出下一个迭代的故事墙，让团队成员提前看到虚拟墙。在迭代计划会议上，主持方将虚拟墙打开并屏幕共享给其他方，这样各方就可以关注在同一个需求故事卡的讨论上。
回顾会议：
由于各种限制原因，分布式团队很容易产生沟通不足现象。而回顾会议创造了必要的沟通桥梁，因而非常重要，一定要保证所有方都能参与进来。远程回顾会议通常利用在线白板，让每个成员提前在在线白板上提交上个迭代里做得好的和值得改进的地方。这样，当回顾会议开始后，每个人都是有所思考的，提出的意见更有深度，而且也可以更好地利用回顾会议的时间一起探讨所有人都关注的问题。通常，通过回顾会议可以发现，处于不同地理位置的多方成员往往关注的事情也不同，而会议上各方成员又可以了解对方在担忧什么，遇到了哪些困惑，并将这些担忧困惑分享，形成大家都认同的改进行动。
结对编程：
结对编程这一实践对于知识的传递非常重要，即便在分布式团队中，结对编程依然是非常重要的实践。合理地利用时差，在各方重叠的工作时间里通过屏幕共享工具远程结对，是保证代码质量的重要手段。
每天合理地利用远程结对不光可以传递知识，同时也是一种有效地影响其他团队成员的方式。远程结对可以让咨询师清楚了解处于不同地域位置的客户团队的代码水平、代码风格和思维方式，从而可以通过每天频繁的结对编程言传身教最佳实践。这种影响行为改变的方式效果显著，而且对于增强团队成员互相了解信任，并形成有统一责任感的“同一个团队”，也非常有帮助。
但不可否认，远程结对会影响开发效率。并且，由于各方工作时间安排以及公共假期等原因，很难保证远程结对的频率。所以，远程的代码评审（Code Review）就显得格外重要。每天各方开发人员在一个固定时段去评审所有提交的代码，能够让团队成员不光关注自己，也了解别人做了哪些代码改动。同时，代码评审对于形成统一的代码风格也很重要。当处于远端的咨询师想去去影响客户的代码风格时，如果无法让所有的人都理解为什么要用某种风格，那么之后的一致性也就无从谈起。而远程代码评审就能在沟通不足的条件下，从分展示好的风格带来的改进（Lead By Example），从而达到提成远程提升客户技能的目的。
在分布式开发中，我们依然遵循基本的实践，同时为了克服远程开发沟通不足的缺陷，并达到整个团队能力提升的目的，我们更关注建立沟通渠道和及时的分享。所有的实践在满足基本的目的之后，都要考虑是否能通过这一实践分享知识以及获取知识的正确方式，客户成员是否能得到能力的提升。
除了沟通这一挑战之外，分布式开发环境下当然还有其他各种挑战，如如何远程的让团队保持足够的凝聚力，让大家不因为距离而产生陌生感？ 所以，经常在工作之余进行些适合远程的团队的游戏，定期邀请各方成员去对方工作的地方工作几周，体会对方的工作环境，能够更好地帮助团队保持一致的目标。此外，分布式团队模式下的项目也有需要关注的特有的风险，如各自国家的成员有不同的公共假期，最后的部署上线如何安排等细节都需要去关注。
由于基于知识流程外包的分布式开发追求交付的成功以及团队的成长，那么面对不同的客户团队就会有不同的挑战。作为咨询师，在关注软件交付本身的同时，更要关注如何提升团队的能力。通过以上这些实践不难发现，虽然依然采用敏捷的基本实践，但在分布式开发的场景下，适当地改进基本实践，才能真正实现高附加值的卓越软件交付。
