远程客户、远程开发人员和危机项目

作者 Vikas Hazrati 译者 金毅 发布于 2010年7月2日

领域

过程 & 实践

主题

协作 ,

离岸 ,

分布式团队 ,

敏捷技术 ,

商业模式 ,

团队工作 ,

商业 ,

敏捷

分享到

尽管集中办公是敏捷的主要建议之一，越来越多的项目却以分布式方式进行。Safari Asad在Scrum开发组中发起了一个有趣的讨论，针对的是既有远程客户、又有远程开发人员的危机项目。

Asad描述了项目由好转衰甚至更糟的褪变。当团队由于预算限制从客户那里搬回来，问题就开始了。据Asad描述，从那时起，他们一直在尽心尽力地发布软件，但客户总是会列出一长串的错误和再次发现的缺陷。Asad提到：这个项目的另一个大问题是远程开发。他手下的所有开发人员都是在家工作的，他无法确定分配的bug在新的代码库里是否被修复了。

客户把bug列表发给我，我再把这些bug发给开发人员。开发人员解决（或貌似解决）了他们的bug，随后把新的源代码发还给我。我来做编译，生成补丁。

虽然经过讨论得出：团队要么没遵循敏捷，要么没按正确的方式遵循，但Asad依然希望寻求拯救项目的建议。

Mark提出：写大量验收测试，并在软件发布给客户之前运行这些测试，是拯救当前项目的一种方式。这将很大程度上依赖于系统的技术负债，但这却是确保即将发布软件有质量保证的最佳途径。

Roy Morien认为：测试软件以及确保缺陷被修复的职责归属似乎是这种情况下的一个基本问题。如果开发人员不必负责任，他们可能会提交代码而不用保证缺陷都得到修复。

如果有专人负责测试，开发人员就没有真正的动力去确保他们的代码写得正确了。他们显然可以依赖测试人员去发现问题，随后就说‘该死，我以为没问题呢。明天我会搞定它的！’。他们什么时候开始通过修复自己的bug来获得报酬了？

Roy同时建议Asad应该集成新软件、进行测试并在客户现场做演示以得到及时有效的反馈。

Bachan Anand强调了坦诚沟通的重要性。他认为，如果团队想拯救项目，就应该现在开始以积极方式向前迈进。

过去的已经过去了，在我看来，唯一的出路是首先接受已经发生的，随后寻找解决方案。所以第一步就是和客户清晰地交流项目当前的情况，接下来的首要任务是找出一个他们可接受的项目拯救方案。

Pete Ruth概括了一个拯救项目的全攻略。Pete认为，客户必须要相信软件能够以快速、经济的方式修复。他推荐了下列技巧，这些技巧让他在过去的工作中受益良多。

• 在客户现场指定一个“关键用户”。
• 安装远程访问设备，以便于你查看客户那里的软件状况。
• 考虑修改下你的软件，让它包含特殊的测试功能，通过快捷键或者软件开关即可触发执行测试。如果远程访问不可用，这种方法对识别问题很有帮助。
• 考虑你和你的远程开发人员之间使用远程访问软件。
• 考虑模块化你的软件，以分离和集中重要模块。
• 尽可能重用代码，使你的软件复杂度最小化。

Jeff认为：指责远程客户和远程开发人员的种种只是在找借口。他提到，他已经完成了几个分布式开发模式的项目，而且都完成得不错。真正的解决方案是由团队和组织双方共同为成功尽职尽责。

因此，讨论中的多数成员认为：问题不在于分布式开发。他们多数人的观点是，有远程客户或者做远程开发不是问题。分布式开发的痛苦是方法执行不正确的症状表现。远程项目通向成功的关键，是使用正确的工具、加强运用恰当的敏捷实践，并为成功尽职尽责。

查看英文原文：Remote Customer, Remote Developers and a Project in Crisis

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。