经过近四十年的发展，软件工程在支持软件系统工程化开发方面取得了令人瞩目的成绩，提出了大量的理论、方法、技术和工具，但是近年来的研究和实践表明软件危机依然存在，软件开发仍然存在成本高、质量得不到保证、进度和成本难以控制等方面的问题，许多 软件项目被迫延期甚至取消。与此同时，随着网络技术（尤其是Internet 技术）的不断发展， 部署在网络基础上的软件系统的规模和复杂性越来越高，并表现出诸如持续性、自适应性、交互性、动态性、开放性、异构性等特点。因此，如何支持这类复杂系统的开发、缓解和消除现阶段的软件危机是当前软件工程面临的一项重要挑战。为了迎接上述挑战，近年来软件 工程领域的一些学者提出了许多新的方法和技术，包括：敏捷软件开发（Agile Software Development）、极限编程（Extreme Programming，XP）、测试驱动的开发（Test-Driven Development，TDD）、面向 Agent 的软件开发（Agent-Oriented Development）、面向方面的 编程（Aspect-Oriented Programming，AOP）、模型驱动体系结构（Model-Driven Architecture， MDA）等等。与传统的软件工程方法相比较，这些方法和技术为软件工程实践提供了新的 思路，已在许多软件工程实践中取得了积极的效果。

1 敏捷软件开发 软件工程一直以来都面临着一个共同的问题，即如何迅速、高效地开发软件系统，适应用户需求的快速变化，确保软件系统的质量，控制软件开发成本。传统软件开发方法强调软件开发需遵循严格的过程模型以及以此为基础的开发计划，并且在软件开发过程中需产生大量的规范化文档，这一思想和方法很难应对快速、灵活和低成本软件开发所带来的一系列问题。自二十世纪九十年代以来，软件工程领域涌现出了一批新的软件开发方法。这些方法主张软件开发只编写少量文档、以用户为中心、主动适应需求变化。这些方法被称为敏捷软件 开发，其代表性的成果是极限编程。

1.1 敏捷思想 至今人们已提出了几十种软件开发方法，根据这些方法在对软件开发所提出的要求和约束等方面的差异，现有的软件开发方法大致可分为两类：重型软件开发方法和轻型软件开发方法。重型软件开发方法一般具有严格和详尽的软件开发过程，软件开发需产生大量的文档。轻型软件开发方法则强调软件开发过程的简洁性和灵活性，软件开发只需编写少量的文档。

敏捷软件开发是一类轻型的软件开发方法，它 提供了一组思想和策略来指导软件系统的快速开发并响应用户需求的变化。不同于已有的其它软件开发方法，该方法对软件开发具有 以下四个方面的基本认识：（1）较之于过程和工具，应更加重视人和交互的价值；（ 2）较之于面面俱到的文档，应更加重视可运行软件的价值；（ 3）较之于合同谈判，应更加重视客户 合作的价值；（ 4）较之于遵循计划，应更加重视响应用户需求变化的价值[1][2]。

敏捷软件开发方法认为人是软件开发中最为重要的因素，软件开发应坚持以人为本；优秀的软件开发团队离不开人员之间良好的沟通与合作，相比较而言团队的合作与沟通能力比单纯的编程能力更为重要，改善人员之间的交流与合作将有助于提升团队的软件开发水平；应根据软件开发团队的特点选择合适的软件开发过程；在软件开发工具的选择方面，敏捷 软件开发主张从使用小工具开始，只有当小工具不能满足要求时才考虑选择和使用功能强大的 工具。

一直以来，人们将文档视为是对软件开发各个阶段成果进行记录、促进人员之间进行交流的重要媒介和工具，也是软件开发和维护的主要依据。然而，编制过多的文档不仅会耗费大量时间和精力，而且当用户需求变化时难以实现文档与代码的同步，这势必会影响软件系 统的开发和维护。敏捷软件开发方法提倡在软件开发过程中只编写少量短小精炼的文档。

成功的软件开发不应单纯依赖于合同条款和工作说明，而应 将用户和软件开发团队紧密地结合在一起，让用户积极参与软件开发并提供持续不断、频繁的反馈信息。在软件开发过程中，用户需求总会发生变化，这是由于用户需求难以一次性完全捕获，开发人员和用户对于需求的认识会不断地调整。此外，用户的业务本身也可能会动态地发生变化。在复杂软件系统的开发过程中，响应用户需求变化的能力常常决定着软件项目的成败。为了适应用户需求的变化，敏捷软件开发认为软件开发计划不应考虑的太远，不要进行过于周密、详细的计划，只应覆盖短期的工作任务，对于中长期的任务只需有一个粗略的规划即可，要保留计划 的充分灵活性，并根据需求的变化适时地调整计划。

在上述思想的指导下，敏捷软件开发提出了以下十二条原则来指导软件系统的开发[1]。

(1) 尽早和持续地交付有价值的软件，以使用户满意。 敏捷软件开发最关心的是软件系统的交付。诸多软件工程实践表明，初期交付软件系统中包含的功能越少，最终交付软件系统的质量就越高；软件产品交付的越频繁，最终软件产品的质量就越高。尽早的交付可以让软件开发团队尽快获得成就感，提升软件开发团队的激情和效率，尽早从用户处获取对需求、过程、产品等反馈信息。持续性的交付可以让软件开发团队保持胜利感和成就感，持续获取用户的反馈信息，及时调整项目实施的方向和优先级。 该原则主张迭代性的软件开发，并强调每一次迭代都选择对用户最有价值的功能作为本次迭代的任务，迭代周期不宜太长。每次 迭代结束以后，就向用户交付一个可运行的、实现 部分需求的软件产品。

(2) 即使到了软件开发后期，也欢迎用户需求的变化。 需求不断变化和调整是软件工程化开发的一个重要特点。敏捷软件开发方法的实践者不应惧怕变化，而应适应用户需求的变化，从而为用户创造竞争优势。为了支持用户需求的变化，敏捷软件开发所生成的软件结构应具有足够的灵活性，以便在需求变化时能以最小的代价迅速地做出调整。因此，敏捷软件开发主张采用模式、迭代和重构等技术，以适应用户需 求的变化，获得软件结构的灵活性。

(3) 不断交付可运行的软件系统，交付周期可以从几周到几个月。 敏捷软件开发主张软件开发团队应经常性地向用户交付可运行的软件系统，而不是大量的文档或者计划。交付的周期要适宜，太长易使用户失去耐性，软件开发团队也无法从用 户处及时获得反馈信息；过短会使用户难以接受持续不断的软件产品版本。

(4) 在整个软件项目开发期间，用户和开发人员最好能每天一起工作。 为了使软件开发过程保持“敏捷”性，开发人员应及时从用户处获得各种反馈信息，因 此需要用户与软件开发人员一起工作，以便在需要的时候及时给予反馈。

(5) 由积极主动的人来承担项目开发，给他们提供所需环境和支持，信任他们的能力。 在影响软件项目的诸多因素中，人是其中最为重要的因素。因此参与软件项目的人应积 极主动，并要为它们参与软件开发创造良好的环境和条件。

(6) 团队内部最有效的信息传递方式是面对面的交谈。 敏捷软件开发主张软件开发团队人员之间采用面对面交谈的方式来进行沟通，文档不作 为人员之间交流的默认方式，只有在万不得已的情况下，才去编写文档。

(7) 将可运行的软件作为衡量软件开发进度的首要衡量标准。 所谓可运行的软件是指完成了用户的部分或全部需求，并经过测试，可在目标环境下运行的软件系统。不同于其它的软件开发方法，敏捷软件开发不是根据所处的软件开发阶段、已编写的文档数目或者已完成的代码数量来衡量软件开发进度，而是基于可运行的软 件系统实现了多少软件需求来衡量软件开发进度。

(8) 可持续性的开发，出资方、开发方和用户方应当保持长期、恒定的开发速度。 对于许多软件项目而言，软件开发是一个长期的过程。敏捷软件开发主张软件开发团队根据自身的特点选择合适、恒定的软件开发速度。不应盲目追求高速，软件开发速度过快可 能使软件开发人员陷入疲惫状态，可能会出现一些短期行为，以致于给软件项目留下隐患。

(9) 关注优秀的技能和良好的设计会增强敏捷性。 敏捷的一个重要体现是响应变化的能力。良好的设计是提高软件系统应变能力的关键。因此，软件开发人员必须从一开始就努力做好设计，并在整个项目开发期间不断审查和改进设计。所有的软件开发人员都应致力于编写高质量的代码，不要为了追求短期目标而降低 工作质量，将改进的工作留到以后再做。

(10) 简单化。 这里所说的简单化是指软件开发工作应着眼于当前欲解决的问题，不要把问题想的太复杂（如去预测将来可能出现的问题），并采用最为简单的方法去解决它，不要试图去构建 那些华而不实的系统。

(11) 最好的架构、需求和设计出自于自组织的团队。 敏捷团队应当是自组织的，以适应需求的变化。软件开发任务不是从外部直接分配到团队成员，而是交给软件开发团队，然后再由团队自行决定任务应当怎样完成。软件项目开发不是划分成若干部分然后交给相应的成员全权负责，所有成员对于软件项目的所有部分 都有权参与。

(12) 软件开发团队应定期就如何提高工作效率的问题进行反思，并进行相应的调整。 敏捷软件开发方法不是一成不变的，敏捷本身即含有适时调整的意思。随着项目的推进，软件开发团队应不断地对其组织方式、规则、关系等方面进行反思，并对这些方面进 行调整，以便不断优化团队结构、提高软件开发效率。