SOA是部署在网络上的，网络是无国界的。许多SOA项目成了分布于全球不同地方的专业人员共同协作、完成的项目。如今管理全球各地的人员和项目已经非常普遍。尽管如今这似乎司空见惯，但并非易事。有三条主线要牢牢抓住：制订基于系统的明确的里程碑、明确每次移交的标准、建立相互信任的关系。

　　在过去的15年，我参与了多个全球化项目。在基于SOA的全球化项目管理方面，我总结了确保这些项目成功的三个办法。

　　制订基于系统的明确的里程碑

　　全球化SOA项目面临的最大问题之一就是，知道谁依赖系统的哪个部分。有时，系统的几个部分相互关联，而项目不知道是怎样一种关联关系。如果你和你的项目队伍确定了基于开发过程的明确的移交内容，就可以大大提高知道能否按计划完成项目的可能性。

　　我往往会看到这样的重大里程碑：“需求完成”，或者屡见不鲜的“代码完成”。我认为自己还没有见过哪个项目达到“需求完成”这个里程碑。不过见过以需求为基准的一些项目，或者是确定最重要的需求、以便继续开展下去的项目。

　　因为我往往采用比较敏捷的工作方法(甚至对全球性项目也是如此)，所以很少定义像“需求完成”这样的里程碑，而是定义“为某某场景(或者用户类型)定义的初期需求。”

　　有时，我会丢弃基于需求的里程碑，特别是项目队伍在按照特性进行实施时。这种情况下，我会定义诸如“第1项特性完成”此类的里程碑。一旦我们完成了所有特性，系统测试就可以开始了，哪怕这不是非常完善的系统。

　　按照特性实施的优点在于，作为项目经理，我在项目的早期阶段就能尽早知道大家有没有问题。如果实施(或测试)第1项特性的时间超过我们所预计的，我就得审查剩余进度，看看需要与项目队伍讨论什么。

　　你仍可以使用表明“代码完成”或“全部特性完成”的里程碑——只要你定义了“完成”指什么。因为这一般意味着列出所有特性，我更喜欢定义体现每项特性完成情况的更多个里程碑。

　　但不管你怎么来定义，要确保项目计划表中的里程碑能够体现每支队伍在系统方面何时取得了进步、取得了怎样的进步。那样，如果你对不同地区安排了设计诸多特性，那么你和项目队伍仍能够知道项目的当前状况。

　　明确每次移交的涵义

　　一般而言，我不喜欢标明“完成” 却没有定义完成是指什么的里程碑。我发觉，即使我要求开发人员对其代码进行单元测试。

　　我为全球化项目队伍确定项目计划表时，往往会列出里程碑及衡量里程碑的标准。譬如，我说“第1项特性完成”时，可能会列出这样的标准：

• 　　第1项特性的代码编译，所有平台上没有出现警告;
• 　　第1项特性的单元测试启动及运行(如果我管理的队伍采用测试驱动的开发，会删去这项标准);
• 　　对冒烟测试区启动第1项特性的冒烟测试(smoke test);
• 　　第1项特性开发完毕，冒烟测试运行成功。

　　在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其他模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为冒烟测试。在很多情况下，冒烟测试是开发人员在试图解决一个问题的时候，造成了其他功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略了其他的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。