大家好，我是讯享网，很高兴认识大家。

敏捷过程概述

敏捷过程（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

个体与过程、工具比较

个体与个体间的交互

三个臭皮匠能顶诸葛亮

正确看待工具

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

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

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

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

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

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

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

Working software over comprehensive documentation

可以工作的软件的重要性

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

正确看待文档的作用

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

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

我们应该怎么做？

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

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

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

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

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

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

如何看待软件开发的“合同谈判”？

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

成功开发出满足客户需求的产品需要： 开发团队与客户紧密协作 建议：为开发团队和客户的协同工作方式提供指导的合同是最好的合同。 

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

Responding to change over following a plan

讯享网如何看待和处理变更（变化）？ 为什么产生变更？ 变更的影响？ 

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

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

如何响应变化

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

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

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

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

十二条原则

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

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

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

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

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

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

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

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

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

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

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

增强交互的必要手段！

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

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

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

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

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

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

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

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

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

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

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

当30%的必要功能可以工作时，确定进度完成了30% 

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

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

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

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

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

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

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

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

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

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

XP极限编程

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

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

XP的核心价值观

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

沟通

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

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

简单

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

讯享网XP 就是打赌：打赌今天最好做些简单的事，而不是做更 复杂但可能永远也不会用到的事。 

反馈

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

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

勇气

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

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

XP的有效实践方法

如何有效沟通

1、客户作为团队成员

2、站立会议（stand-ups）

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

讯享网

讨论什么

1、我昨天做了什么？
2、我今天要做什么？
3、有什么障碍？有什么会影响有今天的工作吗？

站立会议不应超过15分钟；
核心成员应轮流发言。（非核心成员可以旁听）
会议是个人总结而不是给经理汇报工作。

3、结对编程

内容：是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责编码，而另一个负责保证代码的正确性与可读性。

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

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

4、开放的工作空间

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

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

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

如何保证简单

5、用户素材

怎么简化需求？

很多时候它既是这样的小纸片。

6、验收测试

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

7、简单的设计

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

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

8、重构

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

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

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

9、隐喻

将隐喻看成整个系统联系在一起的全局视图、系统的未来影像。
1、 隐喻描述系统如何运作、新的功能以何种方式加入到系统。
2、隐喻是一种不精确的、不具体的表示方法，其目的是快速的把握全局。

如何有效反馈

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

10、短交付周期

11、持续集成

方法：
提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。
持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。

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

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

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

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

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

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

12、测试驱动开发

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

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

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

各种测试工具

13、计划游戏

游戏内容：根据项目的进展来进行项目计划的调整，一成不变的计划不存在

游戏方法：每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性

14、集体所有权

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

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

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

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

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

15、可持续的开发速度

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

XP项目开发过程

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

XP迭代开发过程

根据交付计划和项目速率，选择要优先完成的用户故事或待消除的Bug，将其分解为1～2天内完成的任务，制订本次迭代计划，然后通过每天的站立会议解决碰到的问题，调整迭代计划，会后是代码共享式的开发工作。开发人员要确保新功能100％通过单元测试，并立即组装，形成新的可运行版本，由用户代表进行验收和测试。

CRC卡

XP的代码共享编程

XP的计划/反馈循环

XP的适用范围

XP适合规模小、进度紧、需求变化大、质量要求严的项目。

它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的 代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。

XP不适用的领域

中大型的项目（项目团队超过10人）；

重构会导致大量开销的应用；

需要很长的编译或者测试周期的系统；

不容易进行测试的应用；

团队人员异地分布的项目；

不能接收XP文化的组织和团队；

XP小结

XP的大部分实践与AP的价值观和原则是一致的
如短交付周期、客户作为团队成员等
XP的某些实践是对AP的进一步发展或补充
如结对编程、隐喻等
XP的这些实践项目团队可以拿来直接采用，也可对其中的一些实践进行修改或增删后再采用

Scrum

致敬两位前辈

鸡和猪的故事

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

三个工件

The Product Backlog

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

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

The Sprint Backlog

开发团队在Sprint开始时从Product Backlog中提取的项目，这些项目是实现Sprint目标所必需的。

Sprint Backlog不是静态的，并且随着团队在Sprint期间完成更多的任务而改变。开发团队可以与产品所有者密切合作，根据Sprint中剩下的时间以及这些项目与Sprint目标的相关性或必要性，添加或删除项目。

The Increment

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

五个事件

The Sprint

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

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

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

Sprint Planning

开发团队与产品所有者合作，从PB中选择应该在Sprint中进行的工作，以实现这一目标。并根据需要重新排序PB。

一个月的sprint，Sprint Planning不应超过8小时。Sprint越短，所需时间就越少。

Sprint Planning包含一个粗略的大纲，和一个更详细的接下来几天的计划。随着Sprint的进展，将Sprint目标和Sprint Backlog所设定的大致大纲转化为一个更具体的计划。

Daily Scrum

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

Sprint Review

一个月的sprint的Review不应超过4小时。Sprint越短，Sprint Review越短。

Sprint Review的输出包括根据所获得知识对PB进行调整。这可能包括在Sprint Review中出现的新想法、发现的错误、对已有PB项目的更改或重置。

回答：根据这个Sprint，接下来的步骤是什么？。

Sprint Retrospective

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

Product Backlog Refinement

不是一个时间点，而是一项持续的活动。

如何改善？
1、弄清楚PB上模糊的无法开始工作的项。
将PB上工作过大、无法再在单个Sprint中完成的PB项分解。
2、重新制定PB项，使接下来的sprint尽量顺利。
3、随着新的需求或见解，添加或删除PB中的项。
4、估计执行特定项目所需的工作量。

PB改善不是一个正式的会议，而是一系列正在进行的活动，以完善即将到来的Sprint的Product Backlog而工作。可以由不同的人组成，以不同的形式发生。

Scrum角色

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

SCRUM的工具

任务白板

燃尽图

敏捷过程特点

生命周期

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

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

人员

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、简单化

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、这四大要素中，前面三种要素的中心目标是服务于第四大要素，即交付可以工作的软件产品

AP优点小结

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

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

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

实施依据：

实施策略：

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

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

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

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

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

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

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

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

案例一——拒绝变化

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

“现在已经无法将它们加入了。”Carl 坚决地说。 “编码阶段已完成，现在所剩的任务是系统测试。若要加这两个报表，必须单独为它们编码，制作输入界面，还要修改数据库。我们的开发是基于需求分析的，如果不能执行，那么制定它还有什么意义呢 ? 现在加入那些 报表所花费的代价是最初即将其设为需求的5~10 倍。如果现在开始修改，那我甚至不能保证年终你能使用系统的任何部分。我们必须坚持按照需求进行开发以确保项目的成功。你已经同意了我们所做的需求分析，难道不记得了吗 ? 还有，你也在报告上签字表示同意了，不是吗？” Catherine 指出自己无法控制 IRS的要求，但 Carl 拒绝在项目后期做任何需求变更。

Catherine去找Carl的上司Claire，抱怨Carl将需求确认书作为挡箭牌，不理会她的任何要求。 “我是客户，对吗 ？” 她说，“为什么他从不听我的意见呢 ? 我不管是否会多花两个月，那些报表是必须要有的。”

案例二——欢迎变化

Mike领导了Giga-Bill3.0的开发。在项目伊始，他便找到Catherine讨论项目规划。 “这次我们将尽量做到能够满足一些变更要求，”他告诉Catherine，“但是，这并不意味着可以无休止地提出变更，但我们会努力做到不让你们过分为难。” Catherine对此表示满意。

同Carl及其开发组成员在Giga-Bill2.0的开发过程中一样，Mike先是领导开发小组做了常规的需求征集工作。在该项工作完成后，Mike小组为新报表做了一个生动的输入界面原型，并给Catherine做了演示。“以前我从未注意到，”她说，“但确实应当将这两个报表组合为一个”。

“没问题，”Mike 说，“还有其他要求吗 ?”Catherine说希望能让会计部门的其他人员看一下输入界面和报告，于是双方约定好第二天进行这项工作。

按计划3.0版仅对2.0版做小的升级，2.0版的开发时间为7个月，因此开发小组将3.0版的开发时间估算为3个月。随着完成期限的临近，开发组不可避免地收到了许多增加新报表和输入界面的要求。按照约定，不太重要的要求推迟到“第4版再实现，这样，到了交付日期，没有一个变更要求是非做不可的，项目得以顺利交工。用户对3.0 版软件充满热情，认为正是他们上次想要而没有得到的。

产品交付后，一个开发组成员指出为了实现灵活性，在设计和编码阶段浪费了很多时间，做了不少多余的工作。“没有关系，”Mike 说，“我们可以在下一版本开发时用上它们。”

案例一成败教训总结

对需求变化的态度
建立一组稳定的需求，即拒绝需求变化
当财务部客户提出增加一些新的报表和新的数据项的需求变更时，Carl一律以签字画押后的需求确认书为挡箭牌予以回绝
教训根源
该软件过程模式中四要素间相对优先级的错误选择
结果
财务部客户对开发出来的产品反映冷淡，且公司领导不在给他任命任何技术领导的职务

案例二成功经验总结

对需求变化的态度：欢迎需求变化
满足需求变化操作细节方面：合理控制了客户的期望值
在项目开始阶段建立一个输入界面原型，通过该原型主动征集财务部客户对需求变化的意见
在项目的中途，尽量满足最重要的需求变更要求，而对不太重要的要求则推迟到下一个版本中实现，这样既实现了客户比较满意的目标，又避免了出现项目延期的问题——一种双赢的策略
设计方法方面：选择了RUP的以构架为中心而非AP的简单化
质量要求：表面上为实现产品的灵活性而在设计方面花费了很多时间，但在可预见的产品下一个版本开发中，这一构架的灵活性马上就会发挥作用
这一做法符合敏捷过程实施策略的最后一条原则——“根据具体不同的项目需求进行一定程序的裁剪适配，必要时还可扩充其它过程的一些思想方法”。

小结

AP诞生史、主要流派、注意事项
AP规范内容：4条价值观+12条原则
AP相对RUP的特点：从软件过程模式角度
生命周期：一维、快速敏捷
人员：客户重要性，平等协作关系
方法：动态满足需求，简单，团队持续改进
产品：可以工作的软件拥有最高的优先级
四要素关系：以软件为中心，个体高于过程与方法工具

1．敏捷过程的四条价值观是什么?
2．敏捷过程的生命周期结构是一维还是二维的？为什么？
3．在人员方面，敏捷过程相对RUP具有哪些不同的特色？
4．在对待需求变更方面，敏捷过程采取了何种方法和应对策略？这一方法策略有何现实意义？
5．在设计方法上，敏捷过程的简单化设计方法与RUP的以构架为中心的设计方法有何不同？怎样看待它们之间的关系？
6.敏捷过程认为哪类产品的优先级最高？为什么?
7.敏捷过程这一软件过程模式的适用于何种类型的软件开发项目？