【IT168 技术文章】

    我们在ThoughtWorks这样的大型项目中应用XP方法的时间超过了15个月。这个项目开始于三年前，那时它有大量的需求文档和几个独立的功能小组。从2000年1月起，我们决定应用XP，虽然当时我们已经知道XP并不适用于大型项目。那时，我们需要向客户提交功能演示，并要通过提交一个工作子集而不仅仅是原型来赢得他们的信心（我们在团队中有超过25名开发人员和大约15名分析员）。但我们并未准备好功能，各个组都使用自己的代码框架，一个完整的应用无从谈起。简短地说，就是客户想要看到点什么，但我们还没有真正的功能。应该说开发的第一迭代期是成功的：我们给客户提交了一个真正的应用子集。成功的首要原因是我们让来自Asset, AR 和GUI组从事不同工作的开发者融合在一起。当然，其间也有"成长的烦恼"：在分析员和开发者之间发生某些个人冲突，但我们成功跨越了这些障碍。那时一切都很美好：我们以飞快的速度成功地提交了功能演示，但随着时间的流逝和项目的继续，有些事情却不如我们所愿。这就是这篇文章要讲述的内容：我们真正的收获在"蜜月"期后，关于我们如何在一年半中管理一个50人的项目开发并及时完成阶段性的提交（尽管有时并不成功），关于我们经历的痛苦，我们后续的工作，我们最终学到的以及作为改进要用到下一个项目中的经验。

    首先，我们给出我们开始的状况：15个月前我们是如何应用XP的，然后展示我们现在的XP应用情况。也就是说，下面将讨论我们改变技术的原因。这是一个自然选择的过程，它剔除了许多不好的想法，或把它们改造成更有效的方法，使之更适于大型项目。最后我们将总结并给出在大型项目中使用XP的谨慎建议。

    大型项目中XP的元素

    好吧，让我们来进入正题。我们开发和分析的队伍由大约35名开发人员、15名分析人员和10名QA组成。开发人员依赖分析人员作为项目的客户。尽管有实际的客户，分析人员还是要协同工作以便有选择地做出客户决策。下表演示了[1]所讨论的XP基本元素并简要介绍了这些方面如何应用到项目的各个阶段。我们用这个表来分析我们团队自然选择的实践，以及书本上的XP如何应用到一个超过50人的大型项目中。