异地分布式敏捷软件开发

异地分布式敏捷软件开发 (Distributed Agile Software Development)

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。

异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。

但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位 置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离 岸，通常在时差8小时以上）。如下表。

offsite	on shore	near shore	off shore
Distributed Development	北京办公室 - 西安办公室之间	印度分公司 - 中国分公司	硅谷总公司 - 中国或印度分公司
Outsourcing Development	北京某公司 – 广州另一公司	东京某公司 - 大连另一公司	欧洲某公司 - 中国另一公司

异地分布式开发的组织方式

异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。

有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。

各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。

基本原则：极尽交流之能事

异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。

为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。

交流频度和价值图，Vincent Massol，2004

每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问 题。如果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。

如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更 是经常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每 日的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。

交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会谈。尽量减少陌生感，使交流效果提升。

任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许， 公司应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。

敏捷开发过程的改进

般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一 端，一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员 到场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。

日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。

项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。

一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持 续集成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽 搁。

基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。

每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条件不允许，可以分别进行，并互相通报回顾结果和改进方法。

离岸团队的参与度

多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派 需求和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。

解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果 都处于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目相关的技术决策等等。

不要忽视offsite团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励offsite团队决策和发起讨论，这样可以提高他们的参与度。

实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。

近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。

呵呵，介绍的情况和我现在所在的Team现实很有些相似，也解答了我的一些疑惑，找到了一些有用的方法，谢谢^_^

确实很好，我现在就要搞这些off-site的事情。。郁闷着呢。

异地分布式敏捷软件开发会有时差的问题。在我们的团队中开发经理充当了弥补时差的角色。他通常晚上工作的晚（在家中）和外国的团队交流，第二天早上把交流结果给我们。

国内承包欧美的项目，敏捷的头条我看还是提高英语交流能力

要能和客户谈笑风生了，需求挖掘起来就轻松多了。

前两年领导一个团队， 和美国中部的团队共同维护一个产品， 美国的经理天天加班和我交流， 最后他受不了， 逃回印度去了。
现在有得和美国西部共同开发一个产品， 准备用scrum, 具体合作细节未定。
个人以为， 两个团队多对多交流很难，光英语就是个大问题， 还有跨越大洋，成员也不能熟悉。 还是有两个代表主要负责沟通会更有效率点。 当然这取决于项目的独立程度。

估计现在这种模式使用的不多
最有趣的是异地测试，提高效率
另外是资源的复用

不过异地决定了交流的成本，这是最需要解决的
帖子里提出了很多异地交流可能存在的问题及可行方案，看起来的确很不错
开眼界了 呵呵

我们这还不存在时差问题, 一个在上海, 一个在成都.测试/同步问题都很令人头疼. 没有自动化的测试, 发布版本前全靠QA那边赶班赶点. 同步也头疼, 一个属性文件的问题, 整了2天, 才搞定, 崩...

冰云 写道：


这么说是不是意味着一个迭代应该由on-site和off-site团队一起完成，所以双方一起参与演示会议？

离岸外包，沟通最重要