调查显示分布式开发影响软件质量

2008 年九月份由 Reg reader 做的一次投票结果显示，“由于各方的技能水平的参差不齐而引起的软件质量问题”是最有趣的发现之一。有 369 人参与该调查，其中 80% 有分布式软件开发的经历。其中，44% 的人在英国，36% 在美国。

尽管在分布式软件开发中“交流与协作的问题”仍毋庸置疑地占据首位，但根据这一调查，身处第二位的是“由各方技能水平不同而引起的质量问题”。另一个与之相关的问题是“在执行某些实践与过程中体现出来的水平差异”。而这些问题也反映出其与组织类型与管理方法的无关性。在分布式软件开发过程中，被调查者所使用的三种主要方法有：

• Hub and Spoke – 核心开发功能由物理分布的团队完成
• Peer to Peer – 所有的任务被平等地分发给所有团队
• Ad-Hoc – 使用混合方法，且没有严格的区分

调查显示，当使用混合方法时，分布式开发的挑战尤其显著。前五项目挑战分别是：

1. 交流与协作问题
2. 各方技能水平参差引起的软件质量问题
3. 组织结构引起的政策性问题
4. 过程或实践的不同引起的质量问题
5. 由于分布式开发的复杂性而引起的项目管理问题

相比成本而言，分布式开发的主要动机可以说是资源的灵活性和公司战略决策。这可能说明，关注成本意义不大，因为得到廉价的资源的同时，也可能得到了较低的经验和技能。

另一个有趣的发现是那些可以分布进行的活动所带来的结果。那些使用第一种方法（Hub and spoke）的人倾向于将开发与测试交与一方，而将那些关键活动（比如定义规格说明书，分析及设计）放在另一方。而那些使用第二种方法（peer to peer）的人却并不是那么在意这个。

在一个相似的分析报告中， Scott Ambler 根据 Dr. Dobb 的 2008 敏捷采纳情况调查总结了项目成功与地理距离成反比。

• 在一起工作 – 83%
• 相距比较近 – 72%
• 相距比较远 – 60%

依 Scott 所述，在分布式开发中，有助于沟通与技能开发的关键点是：

• 在项目一开始，所有成员在一起工作；
• 做最初的预前建模，以便得到相应的技能；
• 高层次上的计划，以便识别主要依赖关系及里程碑日期；
• 根据架构组织团队的结构，以便减少不同子团队之间的沟通需求；
• 使用比 on-site 团队使好的工具．因为对于距离来说，索引卡和白板等根本不起作用；
• 进行互访问，并设置边界接洽人。

还有一些成功的案例，如 Martin Fowler 的离岸开发（Offshore Development），以及 Jeff Sutherland 的通过外包团队提高生产效率，其中有一些针对分布式开发的好的实践。

虽然分布式开发要面临一些特定的挑战，但这是现实。关键是有效地工具化和更好的协作实践来帮助团队跨地域的沟通和技能学习。

查看英文原文： Distribute Development and the Quality Will Suffer