\t\t敏捷项目的工程特性

敏捷项目迥异于使用传统方法的软件项目，其中包括：

1.设置开发环境

在传统项目中，团队可以投入充分的时间来设置开发环境；而在敏捷团队里面，他们需要从第一刻时间起就能产出。根据我们的经验，我们认识到缺乏设置开发环境的相关文档是设置环境如此耗时的一个关键原因。第二个关键原因是在设置过程中涉及的手工步骤数。在第0次sprint，我们必须记录每一件开发人员必须做了才能开始编写代码，并集成团队其他人工作的小事。

2.自动构建

让我们尽早失败！我们领悟到，手工构建可能既脆弱，又特定于某一台机器，而且当时间耗费在手工构建的基础工作上面时，开发和测试的时间就被挤占掉了。除去最小的项目，自动构建过程对于每一个项目都是必不可少的。我们认识到，即使需要抽出时间来创建自动构建的环境，你以后是能把这些时间赚回来的。这也使得我们更易于确保项目有一个人人共有的标准化构建。我们曾经使用过的主要工具包括Ant、Maven和Nant。

3.持续集成

根据我们过去的经验，我们领悟到，等到最后的几个星期才去把不同团队成员的代码集成到一起是一个灾难。如果你已经拥有了自动构建，接下来的事情就是持续集成。当然，版本控制（或者软件配置管理——另一个更为正式的和令人印象深刻的名字）是自动构建和持续集成环境的前提。我们学到的一个重要教训是，你越快识别出集成的错误，你就能越快地解决这些问题。我们曾经使用过的主要工具包括 CruiseControl、CruiseControl.Net和Bamboo。

4.单元测试

在高度流动的环境中，随着多个开发人员一起工作、需求的变更和优先级的不断变化，确保昨天可以运行的东西今天也能运行，这是至关重要的。此外，我们还要与集成出现的错误为战。一种方法（我们从艰难岁月中学习得来）是使用单元测试，这样代码的更改不会破坏现有的功能。我们也开始在开发编码之前编写单元测试用例。我们曾经使用过的主要工具包括JUnit（以及其他的xUnit工具如NUnit、HttpUnit等）和MockObjects。

5.重构

在传统的项目中，通常有一个人保护他们的代码库，直到代码集成阶段。但是在敏捷里面，我们持代码集体所有制的观点——所有的代码属于所有的开发人员，只要开发人员认为有必要，每个人都能不受约束地去改善代码。在一段时间里面，我们的代码库开始出现奇怪的行为——解决办法就是重构（感谢Martin Fowler在他的同名著作中把重构一词推广开来）。重构的本质归结为修改代码以改善代码的结构和清晰度，但不改变代码的功能。我们学到的一个重要教训是在重构代码之前使用单元测试作为安全网，我们曾经使用过的一些主要工具包括Eclipse、NetBeans、IntelliJ IDEA的和Visual Studio.NET。

敏捷项目的工程实践中有一些独特的东西，这是显而易见的，所以团队需要针对这些实践做好准备，并以之为导向。