2．3．6　极限编程与敏捷过程

1．极限编程

极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让用户能方便地与开发人员沟通，一定要用用户理解的语言，先测试再编码就是先让用户了解软件的外部轮廓，用户使用的功能展现，让用户感觉到未来软件的样子；先测试再编码与瀑布模型显然是背道而驰的。同时，极限编程注重用户反馈与让用户加入开发是一致的，让用户参与就是随时反馈软件是否符合用户的要求。有了反馈，开发子过程的时间变短，迭代也就很自然出现了，快速迭代，小版本发布让开发过程变成更多的自反馈过程，有些像更加细化的快速模型法。当然，极限编程还加入了很多激励开发人员的“措施”，如结对编程、40小时工作等。

1）极限编程关注的重点

极限编程是一种开发管理模式，它强调的重点是角色定位、敏捷开发、追求价值。

（1）角色定位。

极限编程把用户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。用户是软件的最终使用者，使用是否合意以用户的意见为准。不仅让用户参与设计讨论，而且让用户负责编写用户故事（User Story），也就是功能需求，包括软件要实现的功能及完成功能的业务操作过程。用户在软件开发过程中的责任被提到与开发者同样重要的程度。

（2）敏捷开发。

敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期的方法，发布周期可缩短到周、日，完成一个小的功能模块，可以快速测试并及时展现给用户，以便及时反馈。小版本加快了用户沟通反馈的频率，功能简单，可使设计文档环节大大得到简化。极限编程中文档不再重要的原因就是因为每个版本功能简单，不需要复杂的设计过程。极限编程追求设计简单、实现用户要求即可，无须为扩展考虑太多，这是因为可以随时添加用户的新需求。

（3）追求价值。

极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。

极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了“测试→编码→重构（设计）”的软件开发管理思路。极限编程模型如图2－9所示。

图2－9　极限编程模型

2）极限编程的应用原则

极限编程的12个实践是极限编程者总结的经典实践，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。

（1）小版本。

为了高度迭代，向用户展现开发的进展，小版本发布是一个可交流的好办法，用户可以有针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连续性，所以小版本也需要总体合理的规划。

（2）规划游戏。

用户需求，以用户故事的形式，由用户负责编写。极限编程不追求统一的用户需求收集，也不是由开发人员整理，而是采取让用户编写，开发人员分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次迭代，每次迭代完毕后再行修改。用户故事是开发人员与用户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的，沟通一定是顺畅的。

（3）现场客户。

极限编程要求用户参与开发工作，用户需求就是用户负责编写的，所以要求用户在开发现场一起工作，并为每次迭代提供反馈。

（4）隐喻。

隐喻让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为对业务的专业术语开发人员不熟悉，用户又不理解软件开发的术语，因此首先要明确双方使用的隐喻，避免产生歧义。

（5）简单设计。

极限编程体现跟踪用户的需求变化，既然需求是变化的，所以对目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，势必会增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括4个方面含义：通过测试；避免重复代码；明确表达每步编码的目的，代码可读性强；尽可能少的对象类和方法。由于采用简单的设计，所以极限编程没有复杂的设计文档要求。

（6）重构。

重构是极限编程先测试后编码的必然需求，为了使整体软件可以先进行测试，对于一些软件要开发的模块，先简单模拟，让编译通过，到达测试的目的；然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

（7）测试驱动开发。

极限编程是以测试开始的，为了可以展示用户需求的实现，测试程序优先设计，测试是从用户实用的角度出发的，从用户实际使用的软件界面着想，测试是用户需求的直接表现，是用户对软件过程的理解。测试驱动开发，也就是用户的需求驱动软件的开发。

（8）持续集成。

集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成（整体测试）是与用户沟通的依据，也是让用户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

（9）结对编程。

这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个人编码，一个人检查，增加专人审计是为了提高软件编码的质量。经常变换两个人的角色，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

（10）代码共有。

在极限编程里没有对文档进行严格管理，代码为开发团队所共有，这样有利于开发者的流动管理，这是因为所有人都熟悉编码。

（11）编码标准。

编码是开发团队中每个人的工作，没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些像编码人员的隐喻。

（12）每周40小时工作。

极限编程认为编程是一种愉快的事件，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。

2．敏捷过程

极限编程的思想体现了适应用户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

1）敏捷软件开发宣言

2001年，17名编程大师分别代表极限编程、Scrum（“棒球”团队开发模式）、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表了“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，用于替代以文件驱动开发的瀑布开发模式。敏捷方式也称为轻量级开发方法。敏捷软件开发宣言的内容如下：

（1）个体和交互胜过过程和工具；

（2）可以工作的软件胜过面面俱到的文档；

（3）用户合作胜过合同谈判；

（4）响应变化胜过遵循计划。

2）敏捷开发的特点

敏捷开发集成了新型开发模式的共同特点，它重点强调以下几点。

（1）以人为本，注重编程中自我特长的发挥。

（2）强调软件开发的产品是软件，而不是文档；文档是为软件开发服务的，而不是开发的主体。

（3）用户与开发者的关系是协作，不是合约；开发者不是用户业务的“专家”，要适应用户的需求，是要用户合作来阐述实际的需求细节，而不是为了开发软件，把开发者变成用户业务的专家，这是传统开发模式或行业软件开发企业所面临的最大问题。

（4）设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应用户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”，要不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。

3）敏捷开发的关注点

敏捷开发避免了传统瀑布方式的弊端，主要吸收了各种新型开发模式的“动态”特性，关注点从文档到开发者，管理方式也从工厂的流水线形式变为团队的自我放松式的组织。总结敏捷过程与瀑布模式的不同，主要有以下几个“敏捷”的关注点。

（1）迭代。软件的功能是用户的需求，界面的操作是用户的“感觉”，对迭代的强调则缩短了更新软件版本的周期。

（2）用户参与。以人为本，用户是软件的使用者，是业务理解的专家，没有用户的参与，开发者很难理解用户的真实需求。

（3）小版本。快速功能的展现看似简单，但对于复杂的用户需求，合理地分割与总体上的统一，要很好地兼顾两者是不容易的。

敏捷就是“快”，快才可以适应目前社会的快节奏；要快就要发挥个人的个性思维多一些，个性思维的增多，虽然通过结对编程、代码共有、团队替补等方式减少个人对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷开发是一个新的思路，但不是软件开发的终极选择。对于长时间、人数众多的大型应用软件的开发，文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合，是软件开发组织者面临的新课题。