1.5.8 敏捷软件开发模型
1.敏捷过程概述
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常常发生变化，强烈的市场竞争要求更快速地开发软件，同时软件也能够以更快的速度更新。传统的方法在开发时效上时常面临挑战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。如今，“敏捷”已经成为一个非常时尚的名词。敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。
敏捷开发开始于《敏捷软件开发宣言》。在2001年2月，17位软件开发方法学家在美国犹他州召开了长达两天的会议，制定并签署了《敏捷软件开发宣言》，该宣言给出了四个价值观。
（1）个体与交互高于过程和工具。这并不是否定过程与工具的重要性，而是更加强调人与人的沟通在软件开发中的作用。因为软件开发过程最终还是要人来实施的，只有涉及软件开发过程的各方面人员（需求人员、设计师、程序员、测试人员、客户和项目经理等）充分地沟通和交流，才能保证最终的软件产品符合客户的需求。如果只是具有良好的开发过程和先进的过程工具，而开发人员本身技能很差，又不能很好地沟通，那么软件产品最终一样会遭到失败。
（2）可运行软件高于详尽的文档。对用户来说，更多地会通过直接运行程序而不是阅读大量的使用文档来了解软件的功能。因此，敏捷软件开发强调不断地、快速地向用户提交可运行程序（虽然不一定是完整程序），来让用户了解软件并得到用户的认可。重要文档仍然是不可缺少的，它能帮助用户更精准、全面地了解软件的功能，但软件开发的主要目标是开发出可执行的软件。
（3）与客户协作高于合同（契约）谈判。大量实践表明，在软件开发的前期，很少有客户能够精确完整地表达他们的需求，即便是那些已经确定下来的需求，也常常会在开发过程中改变。因此，靠合同谈判的方式将需求确定下来非常困难。对于开发人员来说，客户的部分需求变更甚至会导致软件的大范围重构，而通过深入分析客户需求之后，有时还会发现通过适当调整需求就可以避免做出重大调整。而对于前者的情况，开发团队往往通过和客户谈判，撰写精确的需求合同来限制需求变更。但这会导致最终的软件产品功能与客户需求之间存在难以避免的差异，也会导致客户的满意度降低。因此，敏捷软件开发强调与客户的协作，通过密切的沟通合作而不是合同契约来确定用户的需求。
（4）对变更及时响应高于遵循计划。任何的软件开发都需要制订详细的开发计划，确定各任务活动的先后顺序及大致日期。然而，随着项目的进展，需求、业务环境、技术和团队等都有可能发生变化，任务的优先顺序和时间有时面临必要的调整，所以，必须保证项目计划能够很好地适应这种难以预料的变化，并能够根据变化修订计划。比如，软件开发的后期，如果团队人员流失，那么如果时间允许，适当后延计划比补充新的开发人员进入项目要风险更小。
发表《敏捷软件开发宣言》的17位软件开发人员组成了敏捷软件开发联盟（Agile software development alliance），简称“敏捷联盟”。他们当中有极限编程的发明者Kent Beck、Serum的发明者Jeff Sutherland和Crystal的发明者Alistair Cockburn。“敏捷联盟”为了帮助希望使用敏捷方法来进行软件开发的人们定义了12条原则。
①首先要做的是通过尽早和持续交付有价值的软件来让客户满意。
②需求变更可以发生在整个软件的开发过程中，即使在开发后期，也欢迎客户对于需求的变更。敏捷过程利用变更为客户创造竞争优势。
③经常交付可工作的软件。交付的时间间隔越短越好，最好2～3周一次。
④在整个软件开发周期中，业务人员和开发人员应该天天在一起工作。
⑤围绕受激励的个人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。
⑥在团队的内部，最有效果和效率的信息传递方法是面对面交谈。
⑦可工作的软件是进度的首要度量标准。
⑧敏捷过程提倡可持续的开发速度，责任人、开发人员和用户应该能够保持一种长期稳定的开发速度。
⑨不断地关注优秀的技能和好的设计会增强敏捷能力。(https://www.daowen.com)
⑩尽量使工作简单化。
⑪好的架构、需求和设计来源于自组织团队。
⑫每隔一段时间，团队应该反省如何才能有效地工作，并相应调整自己的行为。
2.极限编程
敏捷模型包括多种实践方法，如极限编程（eXtreme Programming，XP），自适应软件开发（Adaptive Software Development，ASD），动态系统开发方法（Dynamic System Development Method，DSDM），Serum，Cyrstal和特征驱动开发（Feature Driven Development，FDD）等。
极限编程是一种实践性较强的、规范化的软件开发方法，它强调用户需求和团队工作。利用极限编程方法进行软件开发实践的工程师，即使在开发周期的末期，也可以很快地响应用户需求。在团队工作中，项目经理、用户及开发人员都有责任为提高软件产品的质量而努力。XP特别适用于软件需求模糊且容易改变、开发团队人数少于10人、开发地点集中（如一个办公室）的场合。
极限编程包含了一组相互作用和相互影响的规则和实践。在项目计划阶段，需要建立合理和简洁的用户故事。在设计系统的体系架构时，可以采用CRC（Class Responsibility Collaboration）卡建模促使团队成员共同努力。代码的质量在极限编程项目中非常重要。为了保证代码的质量，可以采用结对编程及在编码之前构造测试用例等措施。在测试方面，开发人员有责任向用户证明代码的正确性，而不是由用户来查找代码的缺陷。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。
极限编程的整体开发过程如图1.16所示。
图1.16 极限编程的整体开发过程
首先，项目组针对客户代表提出的“用户故事”（用户故事类似于用例，但比用例更简单，通常仅描述功能需求），进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”，所谓试探就是提出相关技术难点的试探性解决方案。然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划（为了制订出切实可行的交付计划，可能需要对某些技术难点进行试探）。接下来开始多个迭代过程（通常每个迭代历时1～3周），在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次开发过程不受干扰。开发出的新版本软件通过验收测试之后交付用户使用。
极限编程的迭代开发过程如图1.17所示。
图1.17 极限编程的迭代开发过程
项目组根据交付计划和“项目速率”（即实际开发时间和估计时间的比值），选择需要优先完成的用户故事或待消除的差错，将其分解成可在1～2天内完成的任务，制订出本次迭代计划。然后，通过每天举行一次的“站立会议”（与会人员站着开会以缩短会议时间，提高工作效率），解决遇到的问题，调整迭代计划，会后进行代码共享式的开发工作。所开发出的新功能必须100%通过单元测试，并且立即进行集成，得到的新的可运行版本由客户代表进行验收测试。开发人员与客户代表交流此次代码共享式编程的情况，讨论所发现的问题，提出新的用户故事，算出新的项目速率，并把相关的信息提交给站立会议。
综上所述，以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性，而且在快速的同时仍然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。
