敏捷过程简记

敏捷过程概述

敏捷过程（AP，Agile Process）

AP的提出:

许多软件团队陷入了不断增长的过程泥潭。为矫正某些官僚烦琐的软件过程，2001年2月，17个方法学家达成一致并发起成立：
敏捷软件开发联盟（www.agilealliance.com）
简称为敏捷联盟（Agile Alliance）

AP内容及特点:

软件开发宣言：
软件团队具有快速工作、快速响应变化的能力
4条基本价值观+12条原则

一种典型的软件过程模式
生命周期 + 人员 + 方法 + 产品及关系

AP旗下的敏捷型软件过程流派

1、极限编程XP(Extreme Programming)
2、Scrum
3、动态系统开发方法DSDM（Dynamic System Development Method）
4、水晶系列方法（Crystal Family）
5、开放式源码
6、适配性软件开发（ASD）
7、特征驱动开发（Feature Drive in Development）

全面的理解敏捷过程

不要断章取义。
不要道听途说，偏激地理解敏捷过程。

敏捷过程的价值观与原则

从敏捷软件开发宣言的立场观点，论述AP：

四条价值观

四条价值观声明构成敏捷软件开发宣言。

1、个体和交互 胜于 过程与工具
2、可以合作的软件 胜于 面面俱到的文档
3、客户合作 胜于 合同谈判
4、响应变化 胜于 遵循计划

一、个体和交互胜于过程与工具

Individual and interaction over process and tools

个体与过程、工具比较

人是软件项目获得成功最为重要的因素
如果项目团队中没有优秀的成员，那么使用再好的过程和工具也不能从失败中挽救项目。

个体与个体间的交互

三个臭皮匠能顶诸葛亮

一个团队中的成员未必个个是一流的开发人员， 其中有很多可能是平均水平。
但是一个由平均水平开发人员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平的开发成员、但成员之间不能进行有效交流的团队更有可能获得成功。

正确看待工具

软件开发环境和工具对项目的推进有多大作用/p>

合适的工具对于成功来说非常重要

如编译器、IDE、源代码控制系统等工具，这些对于团队的开发者正确地完成他们的工作是至关重要的。

工具的作用不可被过份地夸大

使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。
更大的、更先进的、价格昂贵的工具通常造成的障碍要大于它们带来的帮助。

个体和交互胜过过程和工具

1、团队的构建(包括个体、交互等)要比项目环境(包括过程、工具)的构建重要得多
2、应该首先致力于构建团队，然后再让团队基于需要来配置环境
3、许多团队和管理者就犯了先构建项目环境，然后期望团队自动凝聚在一起的错误

二、可以合作的软件胜于面面俱到的文档

Working software over comprehensive documentation

可以工作的软件的重要性

软件开发的主要目标：交付给用户可以工作的软件而不是文档。否则应该称之为文档开发而不是软件开发。

正确看待文档的作用

没有文档的软件会引发灾难

代码不是传达系统原理和结构的理想媒介。
团队需要编制易于阅读的文档，以对系统及其设计决策的依据进行描述。

过多的面面俱到的文档比过少的文档更糟

编制众多的文档需要花费大量的时间，并且要使这些文档与代码保持同步就要花费更多的时间，导致进度拖延。
文档和代码之间如果失去同步，那么文档就会变成庞大、复杂的谎言，造成重大的误导

我们应该怎么做/h4>

权衡把握软件创建与文档编制活动

“直到迫切需要并且意义重大时，才进行文档编制”——Martin文档第一定律（Martin’s first law of document）

什么是“迫切需要并且意义重大”呢/strong>
例1：一份系统原理和结构方面的设计文档
因为该文档将作为后续开发工作(实现、测试、维护等)的重要依据。

例2：一份用户手册
因为用户不会操作使用的软件不能认为是可以为用户工作的软件。

例3：一份项目组新成员的培训文档
对于很多中小规模的项目组而言，培训他们最好的教材是代码和团队。代码真实地表达了它所做的事情，是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统脉络图，人与人之间的交互是将这些信息传授的最快捷、有效的方式。

建议：编制的内部文档应尽量短小并且主题突出

例如：编写一份系统原理与结构方面的设计文档
“短小”——指该文档最多有一二十页
“主题突出”——指应该仅论述系统高层结构和概括的设计原理

三、客户合作胜过合同谈判

如何看待软件开发的“合同谈判”/h4>

合同是制约、保证合作双方利益的协议。
但软件是特殊的。客户很难做到一次性地将他们的需求完整清晰地表述在合同当中。
因为：
1、软件本身难于描述定义。
2、客户没有足够的技能去精确的定义软件。

四、响应变化胜过遵循计划

Responding to change over following a plan

变化是软件开发中存在的现实

首先，商务环境可能会变化，这会引起需求的变动
其次，随着系统逐渐开始运作，项目关系人（包括开发人员与客户）对系统的理解也会发生变化
最后，技术随着时间也在变化

如何响应变化

制定灵活可塑的计划，即细致度逐渐降低的计划
为下两周做详细的计划，为下三个月做粗略的计划，再以后就作极为粗糙的计划。
应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求，至于系统一年后将要做什么，有一个模糊的想法就行了。

制定灵活可塑的计划的意义

对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会知道根据这个计划启动工作并有了相应的投入。

另一方面，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着足够的灵活性与可塑性，在形势发生变化时能够迅速调整以适应商务和技术方面发生的变化。

十二条原则

帮助人们更好的理解宣言中表达的基本价值观
12条原则是敏捷实践区别于其它重型过程的特征所在

一、最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意

可工作的软件 > 文档（原型、分析模型等）
尽早交付意味着：更充裕的测试时间。
持续的交付 —> 迭代

尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。
表现为初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。

以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。
表现为交付的越频繁，最终产品的质量就越高

如何尽早、持续地交付有价值的软件/h4>

努力在项目刚开始的几周内就交付一个具有基本功能的系统。

然后，每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。

二、即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。 这是一个对需求变化的态度声明

不惧怕变化，那些改变意味着，团队已经学到了很多如何满足市场需要的知识。

应对策略：努力地保持合同、计划、软件结构及其它方面的灵活性。

1. 签订带有协同工作方式的合同、制定细致度逐渐降低的计划。
2. 采用更灵活的设计：高内聚低耦合、MVC模式

三、经常性交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好

迭代，不断地迭代。
交付的是软件，而不是文档或其他任何东西。
更小的交付周期，更灵活的计划。

四、在整个项目开发期间，商务人员和开发人员必须天天都工作在一起

增强交互的必要手段！

客户、开发人员以及涉众之间频繁地交互有利于持续不断地引入对不断变化需求的反馈。

五、围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作

人是项目取得成功的最重要的因素。所有其他的因素(过程、环境、管理等等)都是次要的。

当次要因素对于人有负面影响时，就要对它们进行改变。
例如：
办公环境对团队的工作造成阻碍，就必须对办公环境进行改变；
某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行改变。

六、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈

首要和默认的沟通方式——面对面的交谈。
其它沟通方式只有在有必要的时候才会进行。
例如：编写文档，只有这些文档是迫切需要且意义重大时才会去编写，并且不会企图在文档中包含所有的项目信息。

七、工作的软件是首要的进度度量标准

瀑布模型：
需求阶段——软件需求规格说明书（文档）
设计阶段——概要设计说明书、数据库设计说明（文档）

RUP：
四个生命周期里程碑；
各次迭代结束；

敏捷过程——可工作的软件

敏捷对开发进度度量方法：

是当前软件满足客户需求的数量。
非所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施、代码的数量。

八、敏捷过程提倡可持续的开发速度，责任人(sponsors)、开发者和用户应该能够保持一个长期的、恒定的开发速度

跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。
拒绝经常性加班、整个项目开发期间应保持最高质量标准的可持续的速度。

九、不断地关注优秀设计的技能，好的设计会增强敏捷能力

关注代码质量——所有成员都致力于编写他们能够编写的最高质量的代码。
勇于重构！
保证代码的简洁和干净。
不断优化设计。

十、简单是根本——使未完成的工作最大化的艺术

并不看重对于明天会出现的问题的预测，不在今天就对那些问题进行防卫。

深信：在今天以最高的质量完成最简单的工作，如果在明天发生了问题，也会很容易进行处理。

十一、最好的构架、需求和设计出自于有组织的团队

任务不是从外部分配给单个团队成员，而是分配给整个团队。

不存在单一的团队队员对系统构架、需求或者测试负责的情况，每一个成员都具有项目中所有方面的参与权力。（模糊的分工）

十二、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

过程改进
调整范围包括团队的组织方式、规则、规范、关系等各方面。

XP极限编程

XP是一个轻量级的、灵巧的软件开发方法 ，是一种软件工程方法学；

强调程序设计师团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重作为软件开发中人的作用。

XP的核心价值观

沟通(Communication)
简单(Simplicity)
勇气(Courage)
反馈(Feedback)

沟通

问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。因此，项目相关人员之间进行充分、多渠道(最好面对面)的沟通;

• 以人为本，重视客户的参与；
• 在开发组间交换成员；
• 召开版本发布会等。

简单

保持代码的简单
1、在系统可运转的前提下，做最简洁的工作，坚定地专注于最小化解决方案；
2、在开发中不断优化设计，时刻保持代码简洁、无冗余;
还有需求尽量简单，设计尽量简单，文档尽量简单…

反馈

用户的反馈
1、尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。
2、更早和经常来自客户、团队和实际最终用户的具体反馈意见可以提供更多的机会来调整力量。
3、反馈可以让您把握住正确的方向，少走弯路；

前提：
尽快发布新版本；
客户应该是小组的一员。

勇气

这是最重要的核心价值。因为XP强调要“拥抱变化”，因此对于用户的反馈，提倡积极面对现实和修理问题的勇气，如放弃已有代码、改进系统设计等。

1、勇敢的重构；
2、所有人拥有代码；
3、敢于极限（把好的方法做到极至）

XP的有效实践方法

如何有效沟通

1、客户作为团队成员

要求至少有一名实际的客户代表在整个项目开发周期和团队开发人员在同一个房间中一起紧密地工作，负责确定需求、回答团队问题以及编写功能验收测试。
如果确实无法工作在一起，就去寻找一个能够工作在一起、愿意并能够代替真正客户的人

2、站立会议（stand-ups）

每日例会：
当遇到问题或者每天上班的时候召开一个简短的会议。

两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起整合测试(Integration Test)，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作。

作用：结对编程是一种非正式的同级评审，它要求成对编程的两个开发人员在性格和技能上应该相互匹配。
注意事项：结对编程是加强开发人员沟通与评审的一种方式，但并非唯一的方式，具体的方式可以结合项目的情况进行。

4、开放的工作空间

XP项目的所有参与者（开发人员、测试人员、客户等）一起工作在一个开放的场所中

场所的墙壁上随意悬挂着大幅的、显著的图表以及其它一些显示进度的东西

项目组成员在这个开发的场所中进行积极的讨论和交流

6、验收测试

目的：可以以客户指定的验收测试的形式来捕获有关用户素材的细节。
用户素材的验收测试的编写时间：在就要实现该用户素材之前或实现该用户素材的同时进行编写的。

7、简单的设计

团队保持设计恰好与计划在本次迭代中要完成的用户素材相匹配，不会考虑未来的用户素材。

在一次次迭代中，他们不断变迁系统设计，使之对正在实现的用户素材而言始终保持在最优状态。

8、重构

代码重构含义：指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。代码重构与简单化设计思想一脉相承。

重构需要勇气，敢于舍弃修改已经不合理的设计和实现，从而达到简单和高效。

注意：不要过分的依赖重构，甚至轻视设计，否则，对于大中型的系统而言，将设计推迟或者干脆不作设计，会造成一场灾难。

如何有效反馈

什么能获得最好的用户反馈br> 软件产品！

10、短交付周期

时间：XP项目每两周交付一次可以工作的软件
目的：每两周的迭代都实现了涉众的一些需求，在每次迭代结束时，会给涉众演示迭代生成的系统，以得到他们的反馈。

11、持续集成

方法：
提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。

持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。

随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。

每次只有一个PAIR在整合，而且必须运行功能测试。

持续集成需要良好的软件配置变更管理工具的有效支持。

作用：可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。

附：持续集成不是XP专有的最佳实践，微软公司就有每日编译( Daily Build ) 的成功实践

测试先行是持续集成的一个重要前提。

12、测试驱动开发

XP 强调“测试先行”：在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。

代码未动，测试先行；先测试，再编码；

测试驱动：以通过单元测试为目的

各种测试工具

14、集体所有权

“我们”的代码，而不是“我”的代码。

任何人可以改动任何一段代码，但改动后 的代码必须通过所有相关的测试。

开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责

简单设计，编程规范和Pair Programming，使阅读和修改Team内其他人的代码变得实际可行。

另一方面，代码集体所有权并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责

15、可持续的开发速度

不加班，不熬夜；
做法：XP充分体现“以人为本”的原则，要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率
可实现性：如果要真正的实施下去，对于项目进度和工作量合理安排的要求就比较高

XP项目开发过程

用户代表提出用户故事，项目组据此进行讨论、提出隐喻，在此活动中有可能要进行系统结构的Spike。在隐喻和用户故事的基础上，根据用户设定的优先级制订交付计划，然后开始多个迭代过程，在迭代期内产生的新用户故事不在本迭代内解决，以保证开发不受干扰。经验收测试通过后交付使用。

CRC卡

XP的计划/反馈循环

五个重复的事件、三个工件、三个角色 及其关联

每个想法、问题、假设、特征、bug或其他工作都作为一个单独的项目表示在产品Backlog上。可以是广泛的、也可是细小的问题。

可以使用“用户故事”的方式描述

The Increment

它表示团队在Sprint期间完成的所有Product Backlog项的集合——如新特性、错误修复和其他调整。

增量的目的是验证对迄今所做工作的假设。与该产品有利害关系的人可以看看它，并确定它是否满足他们的需要。增量也是新想法的驱动因素，因为具体的产品是人们看到新可能性的一个很好的方式。
增量是对复杂问题进行经验过程控制的主要手段。每一次增量都是从一种直觉、一种假设或一种潜在的有价值的想法开始的，即如何使产品更接近其目标。

五个事件

The Sprint

Sprint是一次试探、也是一次迭代。就像从一个较小的区域开始解决一个复杂的拼图一样，每个Sprint的目的是试图解决一个复杂问题的一部分。

这个部分解决方案由产品的增量版本表示，它可以一起检查以决定接下来应该发生什么。

Sprint是一次有时间限制的探索，可以探讨开发产品的复杂问题的特定部分，而其他四个Scrum事件则代表了Sprint内如何促进这种探索。

Sprint Planning

每24小时进行一次。
检查实现Sprint目标的工作进展情况。
这使得整个团队的Sprint Backlog透明，并可作出相应调整。
每日Scrum不应超过15分钟。这是一个在今后24小时内协调合作的短暂和最小的机会。

Sprint Review

发生Sprint Review之后。
检查Scrum团队是如何共同工作实现Sprint目标的，在下一个Sprint中可以改进的地方。
1、Sprint Review 侧重 产品和所做工作的内容
2、Sprint Retrospective 侧重 完成工作的过程。
对于一个月的Sprint，Sprint Retrospective不应超过3小时。 但是Sprint越短，Sprint Retrospective越短。

Product Backlog Refinement

三个角色来平衡三个不同的视角：价值、质量和过程。

SCRUM的工具

任务白板

燃尽图

敏捷过程特点

生命周期

AP相对RUP：
具有对变化和不确定性的“更快速、更敏捷”的反应特性

快速的同时仍保持可持续性

该特性能较好地适应商业竞争环境下对小型项目提出的有限开发时间的约束

人员

1、人员描述

1.1、客户角色的重要性

对客户角色重要性进行突出强调
在AP中的第3条价值观和第4条原则中，强调将客户视为项目团队中的一员，项目开发人员必须与客户通力协作、频繁交互，甚至要求他们必须天天工作在一起。

强调的意义
不同客户有不同的需求，并且他们的需求可能不断变化，全面动态满足客户需求的有效途径之一就是与客户通力协作，持续将他们的需求反馈回来以对过程进行适应性校正调整。

与客户交互的实际操作
要求与客户频繁交互的形式体现为与他们天天工作在一起，这在实际项目操作中实现难度很大，建议只要达到了持续交互的目的，交互的形式应该不拘一格，可灵活多样

1.2、个体间的相互关系和协作方式

相互关系
个体相互的地位关系是平等的
职责是共同的
任务分配给整个团队而不是单个团队成员，每一个成员都有项目所有方面的参与权力，不存在单一成员对系统的构架、需求或测试等单一方面负责的情况

协作方式
首要协作交互方式为面对面的交谈
也编写文档，但文档仅作为辅助交互方式

2、人员特点

2.1、AP相对RUP的人员特点

客户角色的重要性方面
AP：进行了突出强调
RUP：无
个体间的相互关系及协作方式
AP：相互地位平等，首要协作方式为面对面的交谈
RUP：未给出个体间地位关系，协作方式为“形式化的文档——模型”这一书面形式而非口头交谈方式

2.2、尝试将AP与RUP人员特点进行结合

个体间的职责进行明确分工，同时个体间为平等协作关系
有助于打破传统默认的从高层的分析师、设计师到底层的程序员、测试员的等级壁垒观念，以整个团队而非个人完成构架、需求设计
个体间的交互方式首选交谈，但在必要情况下，如交谈的结果将作为设计开发的依据，则有必要编写文档或创建模型，以书面的形式记录交谈的结果

方法

1、动态满足需求——从欢迎变化、与客户合作到响应变化

需求的本质特征
需求是源于多个不同用户形成的复杂集合
该集合具有明显的动态特性
随着项目进展和用户认识的变化，需求在不断变化
满足这类需求是一个动态的过程

满足需求动态过程中采用的三个步骤
步骤一：欢迎变化
1、对变化的态度——欢迎变化
AP在第2条原则中申明，即使到了开发后期也欢迎改变需求，AP利用变化来为客户创造竞争优势

2、在项目一开始采取各种灵活性措施保证系统对变化的可容纳性与适应性
例如，签订带有指导与客户协同工作方式而非指明了需求进度的合同、制定细致度逐渐降低的而非一成不变的计划、采用面向对象设计的原则和模式等等

步骤二：与客户合作
通过合作引入客户需求的反馈

步骤三：响应变化
在对客户需求的反馈引入过程中，一旦发现需求发生了变化，立即进行响应

2、简单化

AP第10条以及第9条原则中提出：
简单是根本，这一方法是系统从需求分析、设计到实现各阶段中各项产品功能与内容界定的重要准则。即以最简单的工作完成最高质量的产品，深信保持软件尽可能的清洁是快速开发健壮软件的途径

AP的简单化方法与RUP的以构架为中心方法的区别与联系
区别
RUP：考虑产品的适应性、可扩展性与可重用性等高性能特性，提倡以构架为中心的设计方法，要求构架必须留有实现现在和未来需要的所有用例空间

AP：要求在设计阶段尽可能的识别出最简单的构架
1、一方面需要构架，“不断地关注优秀设计的技能和好的设计会增强敏捷能力”(第9条原则)
2、另一方面，反对过早使用复杂的模式，反对为支持未来的复用或系统进化等需求而过度构架系统，未来问题未来解决，如重构方法等

联系
是对产品不同质量要求的不同的应对策略
1、简单质量要求环境：
在可预见的最近几次生命周期内，对产品质量仅为无缺陷要求，而对适应性、可扩展性、可重用性等高性能指标没有要求
采用AP的简单化设计方法，以达到快速开发的目的

2、复杂质量要求环境：
在可预见的最近几次生命周期内，对产品质量不仅为无缺陷要求，而且对适应性、可扩展性、可重用性等高性能指标可能有若干要求
采用RUP的以构架为中心设计方法，以避免可能发生的系统整体重构造成最终开发效率的极速下降

3、团队持续自我反省

内容

第12条原则提出，每隔一定的时间，团队会在如何才能更有效的工作方面进行反省，然后相应的对自己的行为进行调整；调整的内容包括团队的组织方式、规则、规范、关系等方面

注意事项
这种持续自我反省是提高团队项目管理水平的一种途径，在实践过程中应防止流于走过场、形式化

小结

敏捷过程提出的以上三种方法与RUP中提出的三种方法在项目开发的不同阶段中可同时使用，互为补充。如
1、整个过程建模：采用UML语言
2、在需求分析阶段：同时采用用例驱动方法和动态满足需求方法
3、在设计阶段：根据不同的项目质量需求选择以构架为中心和简单化两种方法中的一种实施

产品

各类产品的优先级

AP：第2条价值观中明确指出，可以工作的软件胜过面面俱到的文档，即可以工作的软件在过程各类产品的重要性方面拥有最高的优先级

RUP：强调创建和维护形式化的文档——模型，而非文字化的文档，但就模型与软件两者的优先级未给出论述

AP&RUP融合后的各类产品之间优先级的结论：
1、软件开发的主要和中心活动就是创建可以工作的软件
2、直到迫切需要且意义重大时，才进行文档编制
3、编制的内部文档应尽量短小并且主题突出，满足这种要求的最好的文档形式是模型

产品的功能规模和质量要求

尽量简单化

相互关系

第1条价值观和第1、9条原则中即开宗明义的指出，过程最优先要做的是尽早的、持续的交付有价值的软件产品，在这一交付过程中，个体与交互胜过过程与工具

1、这四大要素中，前面三种要素的中心目标是服务于第四大要素，即交付可以工作的软件产品

2、就前面三种要素的重要性而言，个体具有最高的优先级地位
为解决商业环境下项目中存在有限资源约束问题指明了方向，即应该将有限资源的大部分（当然并非全部）投向有最高优先级的要素中

AP优点小结

AP总体特征：针对商业环境下通常具有有限资源和有限时间约束的小型项目提出了一些独具特色的、操作性较强的解决方案

RUP：提供的是理想开发环境下软件过程的一种完整且完美的模式，但对商业环境具有有限资源和有限时间约束的项目未能给出具体完整的配置方案

因此，AP可作为对RUP的一种补充和完善

实施依据：

AP作为过程模式并不完整
相对RUP，AP在人员、方法、产品等方面的论述远不及RUP全面详细，例如，AP未给出人员的职责分配方案、各方法赖以实现的工具环境、产品的类型划分及建模方法等等

AP对RUP进行了补充和完善
RUP作为一种可配置过程，未能给出对于具有有限资源和时间约束项目的完整配置方案

实施策略：

AP的适用范围是具有有限资源和有限时间约束的项目，典型的如商业环境下的小型项目

作为对RUP的一种补充和完善， AP的实施应在RUP这一基础框架上进行

对AP中各种方法的引入可以从弱到强、逐步进行

项目是多样性的，应根据具体不同的项目需求进行一定程序的裁剪适配，必要时还可扩充其它过程的一些思想方法

敏捷过程案例——对需求变化的两种态度

对需求变化正反两方面的案例

对AP的重点 “动态满足需求——从欢迎变化、与客户合作到响应变化”这一动态满足需求的方法进行诠释

同时说明一些具体操作上的细节问题

案例一——拒绝变化

Carl刚刚接受完需求分析培训，他急切地希望将所学到的新知识用于工作中。这次培训使他明白了项目开发时首先建立一组稳定的需求是非常重要的，在开发过程中不断变换需求所花费用是需求始终保持不变时所花费用的50~20倍，他希望今后的开发能在这一原则的基础上做得更好。
Carl在培训后参加的第一个项目是将公司内部使用的票据处理系统升级为Giga-Bill2.0。他领导项目组成员在该系统的用户一一财务部内做了广泛调研，列出一份详尽的需求列表。在进行系统设计之前，Carl先将此列表递交给财务部负责人Catherine，Catherine看完后签名表示同意。基于这份详细需求，项目组预计在5个月内能够完成开发。财务部对此进度计划予以认可，这表示到11月1日，即可使用该系统，此时距年终大量票据处理任务来临还有一段很充裕的时间。

项目组在第一个月搭建了系统架构，第二个月末完成了所有系统设计。这时，Carl接到了Catherine打来的电话。

“我们想知道在系统中加入一些新的报表难度有多大。”她说。Carl解释说开发正在按着需求进行，并提醒她，需求是经过她确认的。“我知道，” Catherine说道，“但是很多人需要这些报表，我们希望能在这一版本中加入。”Carl以前曾经历过这样的情形，他明白中途添加新的需求会破坏进度计划，现在答应Catherine的要求将为后续工作开了一个不好的先例。于是他表示抱歉，由于已进入编码阶段，所以需求不能改变。但他允诺在下一版本中加入那些报表。几星期后，Catherine提出要求在已有的表中添加一些新数据项，Carl 同样拒绝了。
到第四个月末，距完成期限不远了，人人都努力工作，满心盼望能够如期交付产品。离交付日期还有三个星期的时候，Catherine再次约见了Carl，这次她只提出增加两个报表。由于此前的要求均被拒绝了，Catherine 有些恼火。“其它报表可以暂时不做，但这两个是我们年终处理票据时一定要用到的。我很抱歉在需求

来源：book&sword