敏捷软件开发基础: 持续集成环境的构建

　　敏捷意味着什么

　　Agile可以说是近几年来软件工程界最"热"的一个单词，关于它的文章、书籍、讨论不计其数。尽管如此，却仍有大量的从业者对Agile存有误解和困惑。Agile到底意味着什么呢？仅仅是一些漂亮、时髦的宣传吗？到底怎样才算是Agile呢？做到了Agile能为软件开发团队带来什么好处呢？类似的问题还有很多。

　　Agile其实根本不是一个什么新鲜、时髦的东西，它已经存在了数十年之久了。在这数十年中，那些取得成功的软件开发团队无一不是敏捷开发团队。他们在自己的软件开发过程中大量应用了Agile的思想，只是没有把他们的工作方式、价值观念以及指导思想正式表述出来而已。到了2001年初，这种状况得到了改善，一批在软件开发领域奋战了数十年的领袖和开发大师们（尤其是面向对象社团和Smalltalk社团的领袖）再也无法容忍由于对软件本身的误解以及官僚主义所造成的软件开发方面的混乱，他们把自己数十年来对软件以及团队软件开发的理解和经验总结成了一份"Agile Manifesto"，以呼吁软件从业者们应该以怎样的态度来开发和认识软件。Agile的所有思想基础和价值取向全都包含在这份宣言之中。

　　但是这份宣言对于大多数人来讲，仍然显得有些缺乏可实践性。作为一个软件开发团队，我们可以接受敏捷宣言中的价值观念，但是怎样做才是Agile呢？？？换句话说，Agile如何落实到团队每天的开发工作中呢？几乎每个试图尝试敏捷软件开发的团队，都曾经被这个问题所困扰过。从团队日常的开发活动的角度来看，Agile就是：

　　"Short Cycles that are test-driven and feedback-driven, yielding constant improvement."

　　其中，short cycle是核心。整个软件开发活动应该被划分成一系列短的迭代过程，每个迭代完成一定数目的features。迭代的周期应该尽量得短。更为重要的是，迭代应该是由测试和反馈驱动（TDD和沟通）的。只有这样，我们才能为持续地改进（通过refactoring）提供一个良好的基础和安全网络。请注意，这个过程和一般所说的code-and-fix的本质不同在于：这里的每个迭代周期产出的都是一个经过验证的可用产品，只是可能功能不全，并且这是一个有意识的、持续的基于反馈的改进过程，而不是简单的fix。其实所有成功的项目开发活动都是接近这个标准的，只不过Agile把它放在了最为重要的位置上。