“三条绳”拴住全球化这只虎.docxVIP

PAGE 1 PAGE 1 “三条绳”拴住全球化这只虎  SOA是部署在网络上的，网络是无国界的。很多SOA项目成了分布于全球不同地方的专业人员共同协作、完成的项目。如今管理全球各地的人员和项目已经特别普遍。尽管如今这好像司空见惯，但并非易事。有三条主线要牢牢抓住：制订基于系统的明确的里程碑、明确每次移交的标准、建立相互信任的关系。  在过去的15年，我参与了多个全球化项目。在基于SOA的全球化项目管理方面，我总结了确保这些项目成功的三个方法。  制订基于系统的明确的里程碑  全球化SOA项目面临的最大问题之一就是，知道谁依靠系统的哪个部分。有时，系统的几个部分相互关联，而项目不知道是怎样一种关联关系。假如你和你的项目队伍确定了基于开发过程的明确的移交内容，就可以大大提高知道能否按计划完成项目的可能性。  我往往会看到这样的重大里程碑：“需求完成”，或者屡见不鲜的“代码完成”。我认为自己还没有见过哪个项目达到“需求完成”这个里程碑。不过见过以需求为基准的一些项目，或者是确定最重要的需求、以便连续开展下去的项目。  因为我往往采用比较机敏的工作方法（甚至对全球性项目也是如此），所以很少定义像“需求完成”这样的里程碑，而是定义“为某某场景（或者用户类型）定义的初期需求。”  有时，我会丢弃基于需求的里程碑，特殊是项目队伍在根据特性进行实施时。这种状况下，我会定义诸如“第1项特性完成”此类的里程碑。一旦我们完成了全部特性，系统测试就可以开始了，哪怕这不是特别完善的系统。  根据特性实施的优点在于，作为项目经理，我在项目的早期阶段就能尽早知道大家有没有问题。假如实施（或测试）第1项特性的时间超过我们所估计的，我就得审查剩余进度，看看需要与项目队伍争论什么。  你仍可以使用表明“代码完成”或“全部特性完成”的里程碑——只要你定义了“完成”指什么。因为这一般意味着列出全部特性，我更喜欢定义体现每项特性完成状况的更多个里程碑。  但不管你怎么来定义，要确保项目计划表中的里程碑能够体现每支队伍在系统方面何时取得了进步、取得了怎样的进步。那样，假如你对不同地区支配了设计诸多特性，那么你和项目队伍仍能够知道项目的当前状况。  明确每次移交的涵义  一般而言，我不喜欢标明“完成”却没有定义完成是指什么的里程碑。我发觉，即使我要求开发人员对其代码进行单元测试，但是有些人还是认为，单元测试就是指代码编译。我还发觉，过去我要求测试人员“测试”一部分应用程序时，他们认为，只要测试了明显要测试的部分就够了。因为我期望的是进行多种测试，所以假如没有争论过我期望进行哪几种测试，我就不会轻率地说“测试完成”。  我为全球化项目队伍确定项目计划表时，往往会列出里程碑及衡量里程碑的标准。譬如，我说“第1项特性完成”时，可能会列出这样的标准：  ●第1项特性的代码编译，全部平台上没有出现警告；  ●第1项特性的单元测试启动及运行（假如我管理的队伍采用测试驱动的开发，会删去这项标准）；  ●对冒烟测试区启动第1项特性的冒烟测试（smoketest）；  ●第1项特性开发完毕，冒烟测试运行成功。  在测试中发觉问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其他模块造成影响，就需要针对此问题进行特地测试，这个过程就被称为冒烟测试。在许多状况下，冒烟测试是开发人员在试图解决一个问题的时候，造成了其他功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽视了其他的问题，这就可能引起了新的Bug。SmokeTest优点是节约测试时间，防止build失败。缺点是掩盖率还是比较低。  至于冒烟测试这个名称的来历，也许是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，假如板子没有冒烟在进行其他测试，否则就必需重新进行。类似的假如冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必需首先通过冒烟测试的考验。  从这份列表中明显可以看出，除非全部代码检查完毕、运行正常，并且运行了一些单元测试和冒烟测试，以证明该特性是否正常，否则我和项目队伍不会说“第1项特性完成”。  假如你管理同一地方的小队伍，可以找开发人员谈话，就这类标准达成共识。不过队伍越浩大，队伍越分布在多个地区，你和项目队伍需要就越详细的方面达成共识，那样才能知道项目的实际状况。  建立相互信任的关系  但经理或者项目经理在全球化开发方面采取的最重要的一项措施就是，在全部队伍之间建立相互信任的关系。几年前，我为一