有人说2007是敏捷到来年，伴随着的是其佳实践，像自动化构建、自动化测试和持续集成。尽管理论上这是真的，但是现实却是很多java企业项目仍然采用基于传统的开发方法，譬如瀑布模型。在这篇文章中，ShriKant Vashishtha从开发人员和构建经理的角度揭示了一些传统java企业开发中的一些“伤痛点”。接着，他为我们展示了一些敏捷佳实践，如何不改变瀑布模型开发流程的情况下容易以及自然的解决这些问题。

　　围绕敏捷开发方法的议题已经非常流行，但是真要将一个传统型企业变成敏捷型却要付出巨大的努力。同传统软件开发相关的范围、时间、产品交付等并不能很容易的转换到敏捷过程中，甚至有些需要完全的丢弃。经理、开发人员甚至客户都必须在敏捷开发的缩短项目周期和强调更大的个人主动性的特性中承担更多的任务。我们必须通过整个企业来管理这些改变并且评估采用一小套标准后的影响。地理上的分布式开发团队面对敏捷开发过程时在保证目标上尤其需要经受挑战，因为敏捷开发更喜欢面对面交流。你难道不诧异敏捷开发为什么实践跟不上理论的脚步？

　　通过 Forrester Research 的研究，2007年，仅仅26%的北美和欧洲企业采用敏捷实践。尽管瀑布模型消亡的谣言四起，瀑布开发模型（上一阶段的输出作为下一阶段的输入）仍然在java企业开发中存在。对java开发人员来说，这是一件令人沮丧的事情：我们想改良开发过程和产品质量，并且我们也相信敏捷是正确的道路，但是瀑布模型仍然是个障碍。

　　或者尝试一下？伴随着一些人简单的在传统模型中采用敏捷，一个渐进的转变也许更加具有实践意义。即使你的公司或者开发团队同瀑布模型联系紧密，采用敏捷佳实践来改良产品和提高效率也是可能的。实际上，很多基于瀑布模型的项目已经支持敏捷佳实践，并且还能够支持更多。

　　在这篇文章中，我将通过一个场景从开发人员和构建经理两个视角来说明在传统项目开发中的一般性问题。然后我会给出敏捷实践像自动化构建、自动化测试、持续集成如何来解决这些问题，即使是在一个瀑布模型开发环境中。同时，我也会介绍很多工具，通过它们你可以在自动化测试和持续集成环境中测试、衡量和改善代码质量。

　　瀑布模型的演化

　　列出瀑布模型的弱点，然后通过敏捷实践克服这些缺点，这是能让人信服的。实际上，瀑布模型已经采用了很多同敏捷开发相似的实践。看看下面这些：

　　经常构建

　　大多数团队知道后一个阶段才进行应用的集成的年代已经一去不复返了。，在很多的周期里面进行开发、单元测试、软件集成已经很普遍了。我曾经看到很多基于瀑布模型的项目每天构建2-3次。

　　迭代开发和经常反馈

　　传统的瀑布模型项目，直到软件开发完成才交付进行系统测试或者验收测试。现在很少大项目或者时间紧急的项目能够承受这种方式。客户经常希望能够通过代码review来看看软件的质量，鼓励在更短的周期内使用更多的迭代。交付的功能依据客户的需求和开发的可行性被排定顺序，同时客户在每一个迭代完成后给出反馈。这些反馈对于项目的下一次迭代有很直接的影响，并且也不会让客户收到终的交付产品时很吃惊。

　　变化控制

　　瀑布模型有一个基本的缺点，需求在开发开始前必须定死。在后面的开发周期中都不允许改变，即使这个改变在后面的阶段是不可避免的。很多瀑布型开发企业已经采用了基于紧急程度和工作量来进行变化控制。像图1描述的那样。

图1 典型的变化控制流程