【IT168 技术文章】

    敏捷意味着什么

    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把它放在了最为重要的位置上。

    要想有效地达到上面所说的效果，除了需要一些技术方面的技能外（比如：重构技能，TDD技能等）。我们还需要一个能够对上面这种形式的活动进行有效支撑的环境，这个环境应该是所有想取得成功的项目的基础，也就是一个持续集成环境。持续集成为有效地达到Agile提供了基础。那么什么是持续集成呢？

    什么是持续集成

    从技术层面上来讲，"持续集成"的含义是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中，并且还要验证新合入的变化没有造成任何破坏。这里的库指的是受版本控制工具（比如：ClearCase或者CVS）管理的软件源代码储存地。这里的频繁程度和团队所开发的软件类型有关，但是一般来说频度应该不大于1个小时。

    请注意，持续集成的概念和大家以前曾经听说过的"每日构建"和"每晚构建"的概念有所不同。按照Martin Fowler的话来讲，这个不同主要体现在三个方面：

    持续集成在一天之中要频繁地发生，而每晚构建却每天发生一次。

    每晚构建的目的是为了产生一个稳定的可用发布，而持续集成除了达成这个目标之外，还对集成的成功与否提供了快速的反馈。

    每晚构建并没有规定开发者应该check in的频度，而持续集成为了达到快速反馈的目的，鼓励高频度的check in。

    大家可以看出，持续集成的高频度check in和快速提供反馈的特性为有效地达到Agile提供了一个坚实的技术基础。可以这么说，如果没有一个好的持续集成环境作为基础，要想高效地进行团队软件开发几乎是不可能的。那么，如何构建起一个这样的环境呢？在本文的后面，我将给出了一个详细的教程为你提供一步一步的详细指导，但是在这之前，我们先来了解一下构建一个有效的持续集成环境所需要的工具。