地理上分布式敏捷开发-简介

• 介绍

在敏捷开发联盟[1]2010年的一份问卷调查中，90%的受访者表示他们所在的团队不同程度地使用过敏捷研发方法。同一受访人群中，65%的人表示他们所在的团队是分布式，高于2009年时的57%。此外，45%的受访者表示在外包类项目上他们正在采用或者计划采用敏捷研发方法，这一数据高于2009年时的41%。

很显然，分布式开发不仅仅是众多团队面临的现实状况，而且还是一个正在增长的敏捷社区。但事实上,物理上分布团队的理念似乎与敏捷的沟通实践是相冲突的。团队使用敏捷往往依赖于面对面的相互交流来替代冗长而枯燥的文档。而地理位置上的相互分离，自然会干扰到这种交流。

分布式团队的风险与回报

那么既然分布式团队如此阻碍沟通，为何还要冒险拆分团队呢？分布式团队肯定是有好处的，当然前提是需要权衡沟通障碍。采用分布式的三大理由如下：

• 全球性的市场扩张可能需要在不同地区都设立本地驻点
• 能够获得全球的人才资源
• 通过外包降低成本

如果决定要建立分布式团队，我们必须采取相关措施，从而通过其他途径来弥补团队沟通上的损失。最常用的办法是改进需求和功能点的管理。

好的需求和功能点管理不是放在电子表格里的。可以尝试投入一套管理系统，以便为团队提供高度的可追溯性管理和快速的追溯效率。用管理工具来替代一个落后的管理方式，基本不会有什么阻力。在考察这类系统时，还需要关注是否有其他一些不错的功能，比如变更管理、基线、文档和子事件，以及一套稳健的报表系统。

记住，使用较小的用户故事进行工作，然后通过面对面的交流来进一步补充。如果缺少这些交互沟通，我们就需要在功能点和任务描述中添加更详细的内容。此外，使用系统确保了关联性管理，以及执行正确的工作流程，使得功能点顺利转化为开发任务并得到最终测试；带来的好处是，确保了即使出现沟通不畅的情况，也不会导致工作错误而不断地进行返工。这一点非常重要，因为不断地返工重做同样的工作很容易使团队的士气受挫。

根据Conway’s Law提供的信息，任何一个组织在设计一个系统时（这里我们指一个软件系统），都会构建一个符合组织自身沟通结构的设计。[2] 分布式团队自然会倾向于根据团队的分布结构来分配具体的工作。这样的结果是产品设计体系变得特别适应分布式团队。但不幸的是这将形成知识孤岛，使得每个团队认为只需关注完成自己的那一块工作，而忽略了原始的用户故事。用户故事应该始终是开发工作的关注焦点，因为这才是客户真正需要的。客户并不关心产品设计是否适应于研发团队的地理分布。

有效地分布敏捷团队可以将分布式导致的影响最小化。这里特别强调最小化。因为很显然，团队间直接面对面的在白板上相互讨论或者两个开发人员坐在一起共同开发一段代码，这样的优势是无可取代的。我们能做的就是采取措施来改善分布式团队间的沟通效果。

________________________________________
[1] State of Agile Development Survey 2010
[2] Conway’s Law – http://www.melconway.com/Home/Conways_Law.html