所有这些典型的敏捷佳实践让瀑布模型在满足客户需求方面更具有操作性。

　　传统java EE项目能够从下面的这些敏捷开发实践中受益。

　　吃人的项目

　　利用项目场景是揭示瀑布模型弱点的简单的方式。看一个包括150-200人的典型java企业项目。这个项目被分成很多功能模块，从个体来看，每一个都是一个更小的项目。大体上，项目包括10-15个EAR和WAR文件。为了测试整个应用，全部安装是必须的。SVN是这个项目所用的源代码控制工具。

　　现在让我们来看一下每天开发人员和构建经理的活动，来看看它们所面临的风险。

　　开发人员角度

　　第一步是从svn中检出代码安装开发环境。但是每次我从svn上检出新的代码后，我的开发环境都会崩溃。原因是很多同事提交的代码不能够编译。我认为是一些提交的代码文件存在没有解决的编译问题。当一些内部库类的方法签名突然被改变的时候我也陷入了麻烦，没人通知我！！更坏的情况是你所依赖的一个库被改变了，但是没有提交到svn。那只能在运行时出错。更坏的是即使这个库被提交了，也可能出现版本不一致的情况。

　　哈，这麻烦了，不是吗？作为一个卑微的开发人员，我只关心我的模块而不担心其他模块的错误。不幸的是，我的模块依赖于其他模块。我只是一个开发人员，我却不得不面对应用安装、类路径、库等等其他信息。不管相信与否，有很多时候安装问题会耗费一整天时间，接下来便是很少时间的开发，这给我带来很大的压力。

　　另一个问题对我来说简直是地狱：我的模块功能是位于整个应用的后面，测试我的模块需要其他模块提供的数据支持。在到达我的模块之前有9个步骤，只要其中任何一步出现问题，到不了我这个模块。经常需要花费我6-7个小时来解决其他问题，然后才能测试我的业务case！

　　你可能说“哦，可怜的家伙”，而我担心的是我到底在做什么？不是集中精力在开发和修改我自己的模块功能，反而是花费了大量的时间在本不应该属于我的问题上。更坏的是，项目中的每个人都很忙，要修复这些问题意味着需要很多的帮助，这也意味着很多的时间。

　　我需要什么

　　我的需求非常简单：每次我检出代码时，能够安装和构建。对于这个应该被满足的基本需求，在svn中的代码首先是应该在任何时间都是可以编译的。应该有近的库文件并且应该有很少的手工步骤来构建整个系统。

　　我也应该能测试我的功能，即使在孤立的环境中。我只是想能够在集成之前构建和测试我自己的功能。

　　构建经理角度

　　看看上面的问题，我的情况也差不多。目前，每个应用组件（EAR/WAR）都是独立的构建，每个组件都是一个java项目并且依次在一个文件夹中有自己的jar依赖。如果其中一个jar改变了，我的职责是更新其他依赖于这个jar的组件。这是手工的。

　　有时团队成员更新这个jar文件失败，事情会变得很糟。这导致运行时错误，并且在这样一个复杂系统中很难调试。一个jar中的改变然后更新到项目的其他lib目录下面是一种痛苦。每个组件有自己的一套库和构建脚本，构建整个系统是耗时的并且需要不停的人工干预。

　　正常情况下，仅需要30-45分钟来构建和在服务器上部署应用，但是如果编译问题出现了（经常出现），我不得不找相关人员解决，然后才能部署。这让很多人不高兴。开发人员不能在整个环境中进行测试，测试人员不能及时地获取应用进行测试，这即浪费了时间又浪费了公司的money。人们因此idle，测试经理和项目经理开始抱怨，然后我又陷入了麻烦。我需要一个更容易的方式来解决这些问题！

　　等等 -- 我还没完成！经常负责项目的多个构建环境是我的职责：开发环境、测试环境、性能测试环境。三个构建环境/机器意味着三套应用，每套在应用配置上都应该有所变化，并且 -- 你猜对了 -- 我需要修改属性配置文件。

　　现在，想象一下15个ear手工的来配置其属性文件，只是make a build，太可怕了。那是体力活？ha，我恨这个，我的同事更加憎恨。

　　我需要什么

　　我应该能够通过一个简单的点击来完成系统构建，需要很少的或者根本不需要人工干预。我也需要一种方式来跟踪在不同模块中的代码是否是可编译的和可部署的。因为从一个库里面创建不同的环境构建，我需要一个仅修改配置属性文件可以准备一个新环境的机制。我也需要一种更新jar文件到整个项目的方式。本质上，我需要能够将一个地方的改变自动应用到所有的关联项目中。

　　一般需求

　　在上面的场景中开发人员和构建经理的需求，你也许很熟悉。很容易理解工作在一个指定模块的开发人员不应该担心项目的更大的技术架构。同样，我们也能理解构建经理在如此大的项目上的需求：少一点人工并且专注于重要的任务。我总结了对于这个项目开发人员和构建经理的需求，如下：

　　能够检出代码、手工配置越少越好并且可以在"裸机"上进行构建

　　提交到svn的代码应该是可编译的并且准备好随时被构建

　　新的库文件应该随时在所有项目中可获取

　　能够跟踪所有项目环境是否可被构建，并且任何人都可以随时查看这个状态

　　能够通过修改配置来为任何环境创建build

　　能够更新一个地方的jar，可以影响到其他独立的组件。

　　下面我们将看一下如何采用敏捷实践来满足这些需求，即使是在一个基于瀑布模型开发的项目。