《软件项目管理原理与实践》 教案 第10章-敏捷项目管理

第10章敏捷项目管理

内容提要

10.1概述

10.1.1敏捷概述

10.1.2敏捷项目管理的焦点

10.1.3敏捷项目管理指导原则

10.1.4敏捷流程架构

10.2管理的角色与职责

10.2.1角色

10.2.2职责

10.3敏捷项目管理的特征

10.3.1敏捷方法的特点

10.3.2敏捷方法的核心思想

10.3.3敏捷项目管理方式

内容提要

10.4主要敏捷方法

10.4.1XP极限编程

10.4.2Scrum工具

10.4.3Cockbum的水晶系列方法

10.4.4开放式源码

10.4.5Coad的功用驱动开发方法

10.4.6自适应软件开发方法

10.4.7DevOps

10.5案例分析：敏捷开发技术在电子商务软件的应

10.5.1项目背景说明

10.5.2项目组织机构

10.5.3项目实施过程

10.5.4项目实施效果

10.6小结

极限项目管理

极限项目管理

极限项目管理

敏捷项目管理

敏捷项目管理(AgileProjectManagement,APM)是近来流行的项目管理方法论。

APM是该领域的新概念，敏捷宣言是所有APM模型的指导原则。

多数APM模型源于软件开发，因此对软件开发实践的针对性很强.

原型和适应性项目框架是APM模型中仅有的适用于所有类型的项目的模型。

由于开发周期短，对需求管理恰当，敏捷项目管理正在从软件研发行业延伸到已经采取项目化

管理的大部分行业中。

敏捷项目管理

敏捷方法允许软件开发者更快速地反应，提供更好的方法处理变化和捕捉机会，弱化了经典的

软件生命周期，允许开发团队在同一软件系统的不同部分开展工作。

刚开始开发软件时，并不需要一个完整的软件需求说明，很可能只有一个关于这个软件基本想

法的简短描述。

以此作为起点，团队开始根据现实情况的要求创建需求规格说明、编码和测试。

可能第一天编码，第二天撰写软件需求规格说明，第三天一调试程序。

敏捷软件开发

开始，敏捷软件开发并没有一套固定的步骤，更多体现为一套准则。

敏捷方法的创始者确定了两条基本准则。

以通过快速响应为客户提供高质量的软件为目标，使开发的软件能适应不断变化的环境。

之后，敏捷软件开发已经形成一套有关最佳实践和方法的论著，但这些并不是经典软件工程中

那些固定的技术。

敏捷软件工程是一种态度、一种管理风格而不是硬性规定。

敏捷属性

10.1概念及简介

敏捷项目管理的概念来源于敏捷软件开发“随着敏捷软件开发的发展，极限项目管理(Ex:reme

ProjectManagement)和敏捷项目管理(AgileProjectManagement)的概念和方法被相继提出，

并仍在不断发展。

实际上，敏捷项目管理只是各种敏捷软件开发方法相应项目管理的统称。

10.1概念及简介

10.1.1敏捷概述

1.敏捷简介

多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改(codeandfix)”。

设计过程充斥着短期的，即时的决定，而无完整的规划。

这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来

越困难。

同时，错误故障越来越多，越来越难于排除。

一个典型的标志，就是当系统功能完成后有一个很长的测试阶段.有时甚至有遥遥无期之感，

从而对项目的完成产生严重的影响。

1.敏捷简介

我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方

法(methodology)"<>

这些方法，对开发过程有着严格而详尽的规定，使软件开发更有可预设性并提高效率，这种思

路是借鉴了其他工程领域的实践。

这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们

的注意。

对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那么有做太多的事情

需要做，而延缓整个开发法程。

所以它们通常被认为是“繁琐滞重型”方法，或“巨型(monumental)”方法。

软件开发的发展

1.敏捷简介

1.敏捷简介

敏捷简史一意识的代理人

雪鸟城、敏捷宣言

犹他州(Utah)的雪鸟城(Snowbird)位于盐湖城外约25英里的地方，2001年2月11日至13

日，就在这里.一个滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。制定并

签署了行业历史上最重要的文件之一：关于编码集的独立宣言。

2001年2月会上写敏捷学院的软件工程师

《敏捷软件开发宣言》的签署，推动了敏捷方法的发展，敏捷宣言本质是揭示一种更好的软件

开发方法，启迪人们重新思考软件开发中的价值和如何更好的工作。

10.1概念及简介

《敏捷软件开发宣言》的签署，推动了敏捷方法的发展，敏捷宣言本质是揭示一种更好的软件

开发方法，启迪人们重新思考软件开发中的价值和如何更好的工作。

《敏捷软件开发宣言》四大核心价值

(1)个人和互动高于流程和工具。

(2)工作软件高于理解文档。

(3)客户协作高于合同协酉。

(4)变化响应高于计划遵循。

《敏捷软件开发宣言》12条原则

(1)通过早期和连续型的高价值工作交付满足“客户”。

(2)大工作分成可以迅速完成的较小组成部门。

(3)识别最好的工作是从自我组织的团队中出现的，

(4)为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。

(5)创建可以改善可持续工作的流程。

(6)维持完整工作的不变的步调。

(7)欢迎改变的需求，即使是在项目后期。

(8)在项目期间每天与项目团队和业务所有者开会。

(9)在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。

(10)通过完成的工作量L量工作进度。

(11)不断地追求完善。

(12)利用调整获得竞争优势。

1.敏捷开发方式简介

2.与传统开发方法比较

2.敏捷开发方式与传统开发方法的比较

2.与传统开发方法比较

传统开发是一种瀑布式的流程

2.与传统开发方法比较

敏捷开发流程

2.与传统开发方法比较

二者之间的主要区别如下：

(1)敏捷开发是以人为中心，而传统开发以过程为中心。并不是说，传统开发就没有人的参与，

或者说人不是一个重要因素。应该说的是，敏捷开发和传统开发的侧重点、中心不同。

那么，为什么会是这个样子呢？

因为，传统开发中，设计已经是在初始阶段完成了，在实现阶段不再修改，换句话说，实现阶

段就是对设计的完成，设计方案是不可改变的了。

这样就忽略了用户的反馈、忽略了开发人员的设计的主观能动性，使得开发人员只是专注于代

码层面的事情。

(2)敏捷开发是有适应能力的，而传统开发是计划驱动的。

传统开发，设计阶段完成了，整个的过程就是按照设计方案进行，在设计阶段的后续过程中，

无法再对设计方案进行修改，而敏捷开发需要一次次的迭代完成，正是这些迭代完成了对客户

真实需求的软件的演进。

瀑布模型和敏捷开发流程

传统软件开发与敏捷软件开发的对比

10.1.2敏捷项目管理的焦点

主管期望在项目管理流程中得到什么呢？

丰倍相徨至IIQ小半犍的中西■

首先：〜主管希望这个流蓑是可靠的，每个项目都可以产生创新的结果。

第二，主管希望这个流程是可预见的，这样他可以有效地计划和管理诸如财务管理、人员配备

和产品投放等企业活动。

第三，主管想得到可信的、符合实际的信息，因为构想可能是错的、商业模式可能是错的、人

们可能遇到不能跨越的障碍、项目进展并不总是一帆风顺。

如果项目需要终止，他想及早结束而不是等到后期才结束，可信的进度报告可以让经理尽早采

取适当的措施。

10.1.2敏捷项目管理的焦点

可靠但不重复

在评估项目绩效时，不能区分高度不确定性和高度确定性的项目环境会造成很多混乱。

这种混乱源于两个地方，即范围的定义、估计和限制之间的区别。

可靠流程将重点放在输出，而不是输入。可靠性是以结果为推动力，重复性是以输入为推动力。

敏捷项目中需要考虑的正确范围不是限定的要求，而是清晰明白的产品构想。

“整个产品是否符合客户或者产品营销的构想？”混乱的另一个源泉是将成本和进度看作是估

计，而不是限制。

进度报告

敏捷项S管理并不放弃控制，它确定了责任，修订了对控制内容的定义。

10.1.2敏捷项目管理的焦点

(1)可靠但不重复

在评估项目绩效时，不能区分高度不确定性和高度确定性的项目环境会造成很多混乱。

这种混乱源于两个地方，即范围的定义、估计和限制之间的区别。

可靠流程将重点放在输出，而不是输入。

可靠性是以结果为推动力，重复性是以输入为推动力。敏捷项目中需要考虑的正确范围不是限

定的要求，而是清晰明白的产品构想。

“整个产品是否符合客户或者产品营销的构想？”混乱的另一个源泉是将成本和进度看作是估

计，而不是限制。

(2)进度报告

敏捷项目管理并不放弃控制，它确定了责任，修订了对控制内容的定义。

10.1.3敏捷项目管理指导原则

人是受价值观驱使的，敏捷项目管理因而也是以价值观为唯动力的。

一个团队可以采用敏捷做法，但如果它不接受敏捷价值观和原则，它将不能得到敏捷开发的潜

在好处。

原则性强的领导是高效团队最为关键的特征之一。在业绩优良的团队中、领导管理原则，而原

则管理团队。

敏捷宣言的核心价值观派生出6条原则，而正是这6条原则指导着敏捷项目管理。

如果没有这些指导原则，那么，即使敏捷做法，如迭代交付，通常也会被错误使用，甚至更糟

糕的是，团队自以为自己使用的是敏捷做法而其实却不然。

10.1.3敏捷项目管理指导原则

1.客户价值和创新产品

(1)提供客户价值；

(2)采用迭代的、基于功能的交付方式；

(3)支持卓越技术。

2.领导一协作管理

(1)鼓励探索；

(2)建立适应能力(自我组织、自律)强的团队；

(3)简单化。

敏捷项目管理指导原则

这6条原则有效地组合在一起，组成了一个原则体系。虽然，各条原则分开来也可能有帮助，

但6条原则合在一起则可以创造一个促进突发结果的环境,

10.1.4敏捷流程架构

流程也许不如人那么重要，但绝非不重要。

像其他事物一样，流程必多页与企业目标联系起来。如果企业目标是重复性的制造，那么常规性

流程是完全适当的,而如果企业目标是可靠的创新，则流程架构必须是有机的、灵活的和容易

改变的。

敏捷流程架构需要体现其核心原则，除了支持企业目标外，该架构还需要：

(1)支持构想、探索、适应文化；

(2)支持自我组织、自律的团队；

(3)根据项目的不确定性程度，尽量提高可靠性和连贯性；

(4)保持灵活和易于变化；

(5)支持流程的透明化；

(6)与学习结合起来；

(7)将支持各个阶段的做法包括在内；

(8)提供管理检查点(Checkpoint)、对该构架进行评估,

10.1.4敏捷流程架构

该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不

同，其意义重大。

第一，“构想”代替较传统的“开始”，指出构想的重要性。

第二，推测阶段代替计划阶段。每个词都传达一定的意义而各个意义来自他们长期的系统用

法。"计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。许多面临

不确定未来的项目经理仍在试图“计划”排除该不确定性，我们必须学会推测和适应，而不是

计划和建造。

第三，敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭代交付的方式，很明

显探索是非线性的、并存的、非瀑布式的模式。在推测阶段提出的问题需要“探索

鉴于结果不能完全预测，推测暗示着灵活性的需求基于现实。

敏捷项目管理模式强调执行以及探索性而非确定性。

实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段。最

后，敏捷项目管理模式以结束阶段收尾，这个阶段的主要目标是传递知识。

敏捷项目管理流程

敏捷项目管理模式的结构：构想一推测一探索一适应一结束

1.构想

构想，需要确定产品构想、项目范围、项目社团以及团队共同工作的方式。

构想阶段为客户和项目团队创造构想，该构想包括提供什么、谁提供和如何提供。

如果没有构想，其他的项目启动活动都是无用之功。

用商业话语来说，构想是项目早期“成功的关键因素”。

首先，我们需要构想提供什么，即产品及项目范围构想。

其次，我们需要构想参与的人是谁，客户、产品经理、项目团队成员和利益相关方组成的社团。

最后，项目团队成员必须构想他们打算如何共同工作。

2.推测

推测，需要制定基于功能的发布计划、里程碑和迭代计划，确保交付构想的产品。

“推测”一词首先让人们想到不计后果的冒险景象，但实际上字典对它的定义是“根据不完全

的事实或者信息猜测某事二这正是这个阶段要做的事情。

“计划”一词具有确定和预测的含义，而计划的更有用的定义，至少对于探索性项目来说，是

基于不完全的信息推测或者猜测。

人们认为制定计划可以产生确定性，但事实远非如此。

他们带来的只不过是衡量他们绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能

重新计划。

2.推测

敏捷项目管理更多的是构想、探索，而不是计划、执行，它迫使我们面对这样的现实：

不稳定的商业环境和变化多端的产品开发环境。

推测阶段实际上是构想阶段的延伸并与它相互影响，它包括：

(1)收集初始的、广泛的产品要求。

(2)将工作量定义为一个产品功能清单。

(3)制订一个交付计划(发布、里程碑、迭代)，包括那些功能的进度表和资源分配。

(4)在估计项目成本这个计划中加入风险降低策略，并生成其他必要的行政管理和财务信息。

3.探索

探索，需要在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。

探索阶段提供产品功能。从项目管理的角度看，此阶段有三个关键的活动区域。

第一，是通过管理工作量和使用适当的技术方法和风险降低策略，交付计划的功能。

第二，是建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理推动。

第三，是管理团队与客户、产品经理和其他利益相关方的相互交流。

敏捷项目管理的构想和探索周期

探索，需要在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。

4.适应

适应，需要审核提交的结果、当前情况以及团队的绩效，必要时做出调整。

适应意味着修改或改变而不是成功或失败。如果项目的指导哲学认为，适应变化比执行计划更

重要，则将失败归罪于计划的变更是不会有任何结果的。

非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键。

自构想阶段以后，其循环通常是“推测-探索-适应"，每次迭代都不断对产品进行提炼。

但要是团队收集到新的信息，定期地回到构想阶段也很有必要。

在适应阶段，需要从客户、技术、人员和流程绩效、以及项目状况等方面对结果进行评估。

该分析将会对比实际结果和计划的结果，但更重要的是，要根据项目得到的最新信息，思考实

际的与修订后的项目前景。

修改后的结果将返回、融入到重新计划工作中，开始新的迭代。

5.结束

结束，表明终止项目、交流主要的学习成果并庆祝。

在某种程度上，项目根据开始和结束来界定。

许多组织由于没有明确项目的终结点，通常在客户之间会造成理解问题。项目应该以庆祝方式

结束。

结束阶段以及每次迭代末尾的“小型"结束的主要目标，是学习并将学到的东西融入到下一次

迭代工作中，或者传递给下一个项目团队。

5.结束

在敏捷项目管理的每个阶段中，都有与敏捷价值观和指导原则相一致的具体做法。

这些做法，应该看作是一个“做法系统”，因为它们作为一个系统相互补充，与价值观和原则保

持一致。

但它们并不局限于保持一致，它们还着眼于实施。

没有做法的原则只是个空壳，而没有原则的做法，往往会毫无判断地被生搬硬套。

没有原则，我们就不知道如何实施做法，比如说，没有简单原则，我们往往会过多地看重做法

的形式和仪式。

原则指导做法，做法用实际例子证明原则，它们是相辅相成的。

5.结束

在选择和使用这些做法时，采用了如下指导原则：

(1)简单的；

(2)再生的而非常规性的；

(3)与敏捷价值观和原则一致的；

(4)集中于交付活动(增值)而非合规活动；

(5)最少数量(刚刚可以完成工作)的；

(6)相互支持的(做法系统)。

10.2管理的角色与职责

10.2.1角色

在敏捷项目管理中主要的角色：

项目经理、主任业务分析师、项目团队和产品所有者。

1.项目经理

在敏捷世界中把项目经理描述成项目领导者

2.业务分析师

业务分析师是产品管理、营销、会计等的一部分或需要向这些机构报告，而项目团队需要向首

席信息官(ChiefInformaticnOfficer,CIO)或者首席技术官(ChiefTechnologyOfficer.CTO)

报告。

10.2管理的角色与职责

3.产品所有者

从项目投资组合的角度看，这个角色是主要的派遣人，如果当前的冲刺中有与功能有关的问题

出现时，他也是整个项目团队的联系点。

4.项目03队

项目团队成员从他们的日常活动继承了项目的衡量标准，他们会在团队、产品所有者和其他项

目利益相关者中传播这种衡量标准。

10.2.2职责

10.2.2职责

(1)清除障碍

在敏捷项目管理中有两种机制来处理这些障碍。

第一个，是每曰例会，在这里人们将问题表达出来并且寻求解决的方案。

第二个，是项目经理的角色，他负责处理那些阻碍团队进展的问题。

10.2.2职贲

(2)制定迭代计划

迭代的时间通常为2~6周，越短越好，尤其是在项目的早期阶段。

10.2.2职责

(3)回顾

回顾并不是学习教训。

传统的“学习-教训|-总结"安排在项目的末尾进行。

敏捷项目在迭代与迭代之间执行回顾。

(4)评估

敏捷项目中，只有开发团队才能估算结果。敏捷项目经理要获取并跟踪估算的结果。

采用哪种估算的方法，选择哪种评估技巧要以易用以及能快速采用为准。

10.2.2职责

⑸报告

在敏捷项目中，报告的力量极为强大，因为团队可以分享内部和外部所完成的需求，项目的进

展以及系统的质量。

(6)每日例会

主持会议包括确保团队成员以同事的方式互相报告状态，在会议上提出可能阻碍问题需进行记

录，列入项目经理需要做的工作列表中。

10.2.2职责

(7)领导

在迭代中，需要发挥领导技能让团队前进。

团队中典型的问题都是这样的，琐碎的或者非常具有挑战的未被解决的瑕疵、没有开发人员主

动去解决生成的崩溃问题、开发人员结对的时间太长而需要其他人员更多地融合以及需要对需

求进行协商等。

敏捷项目经理提醒团队成员吧工作做好、随时了解关键条目的最新状态并且记录已完成的事项。

10.3敏捷项目管理的特征

10.3.1敏捷方法的特点

敏捷型方法主要有两个特点

10.3敏捷项目管理的特征

1.适应性和预设性

软件过程不可能照搬其它工程领域原有的方法，需要有适应其特点的新的开发方法。

10.3敏捷项目管理的特征

2.面向人而非面向过程

敏捷方法特别强调开发中相关人员之间的信息交流。

项目失败的原囚最终都可以追溯到信息没有及时准确地传究到应该接受它的人。

在开发过程中，项目的需求是在不断变化的，管理人员之司、开发人员之间以及管理人员和开

发人员之间，都必须不断地了解这些变化，对这些变化做出反应，并实施在随后的开发过程中。

3.方法的敏捷，而不仅是软件的敏捷

当前，软件开发敏捷度的推进，反映了对软件工艺化的认同。

面对不可避免的变化的需求时，敏捷软件开发的目的，是为了提升软件的灵活性、适应性。

这是通过推行“小增量”产发来生产软件，在快速迭代过程中获得反馈，并根据需要对软件不

断调整来实现的。

敏捷软件开发团队，有自己的工作方式，根据手上的项目选择他们需要的方法来开发软件，并

根据项目实际情况调整开发过程。

实际上，软件开发过程中，敏捷开发团队需要像他们开发软件那样敏捷地改进其方法。

10.3.2敏捷方法的核心思想

1.核心思想

敏捷软件开发(AgileSoftwareDevelopment)是一组强调在不确定和混乱的情况下适应软件需

求快速变化的、基于迭代式开发的软件开发方法、实践。

当前，敏捷方法是一种主流软件开发方法，广泛应用于各种软件开发中，也包括很多规模较大

的软件开发中。

敏捷软件开发主要由有经验的软件工程师和咨询师提出，而非来自于学术界的研究成果。

在2001年“雪鸟会议”期间，与会者形成了一些关于软件开发的共同观点，即敏捷宣言“个体

和互动胜过流程和工具，可以工作的软件胜过详尽的文档客户合作胜过合同谈判，响应变化

胜过遵循计划”。

该宣言定义了，敏捷软件下发的核心价值观和原则，而这些原则具体是由敏捷实践、敏捷实践

的组合，即敏捷方法来实现的。

1.核心思想

敏捷方法的核心思想，主要有下面三点：

(1)敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也可以说它的

初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。

(2)敏捷方法是以人为本而非以过程为本。传统方法以过程为本，强调充分发挥人的特性，

不去限制它。

并且软件开发在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。

(3)迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版

本小型化。

它根据客户需求的优先级和开发风险，制定版本发行计划每一发行版都是在前一成功发行版

的基础上进行功能需求扩充，最后满足客户的所有功能需求。

2.基本特征

我们把软件开发过程中拥有大量中间产品(如需求规约、设计模型等)和复杂控制的软件开发

方法称为重型方法。

由此，我们称中间产品较少的方法为轻型方法。

从表象来看,重型方法注重开发文档的完备性和充分性；而敏捷型方法认为最根本的文档应该

是源码，而不是繁琐的文档。

从实质上说，有如下两方面更深层次的区别，

(1)敏捷型方法的思想是“自适应”的，而非如“预设”的重型方法试图预先固定需求并拟定

详细开发计划。

敏捷型方法适应需求的变化，甚至可以说其初衷就是针对变化的需求的。

(2)敏捷型方法的思考角度是“面向人”的，而非“面向开发过程”的。

重型方法在实践原则中总是把开发者看作是一个泛化的生产要素.而忽视了作为决定性因素的

人的特殊性；而敏捷型方法则强调以人为本，并贯穿实践哈终。

由上可知敏捷型方法其实是软件开发方法论从无到重型再进一步发展的成果。

3.适用范围

实际上，满足工程设计标准的唯一文档是源代码清单。软「牛项目的设计，是一个抽象的概念。

它涉及了程序的概括形状、结构以及每一模块、类和方法的详细形状。系统设计得到了有关系

的一个清晰的“图像”，这一图像可以保持到首次发布。

但随着项目的开发，程序“片段”就可能像不断腐化的“面包碎片二发出“臭味”，并不断蔓

延和积累，使得系统越来越难以维护，以至于不得不要求重新设计。但这样的重新设计，是很

难成功的。

因此，与这种传统的方法相比，敏捷方法比较适合需求变化比较大或者开发前期对需求不是很

清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。

另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在

开发团队比较庞大的项目中实施，当然这也不是绝对的。

10.3敏捷项目管理的特征

10.3.3敏捷型方法的含义及其特征

(1)敏捷型方法的思想是“自适应”的，而非如“预设”的重型方法试图预先固定需求并拟定

详细开发计划

(2)敏捷型方法的思考角度是“面向人”的，而非“面向开发过程”的

10.3.3敏捷项目管理方式

提供产品价值，即在目标时间范围内生产的产品功能，是敏捷项目管理的基础，并且客户是其

流程的推动力。

为了在提供该价值方面有效而又及时地创新，敏捷团队采用了迭代、基于功能的交付。

最后，为了确保该价值在现在以及未来的提供，产品可以在开发期间和第一次使用后都能够适

应客户不断变化的需要，项目经理和团队需要创造环境，将卓越技术看作是一个关键的优先考

虑事项。

1.鼓励探索

探索是困难的，它会引发焦虑、颤抖，甚至有时是恐惧。

敏捷项目管理需要鼓励和激发团队成员渡过这些高度变化环境造成的困难。这种鼓励包括保持

自我镇静、鼓励试验、借鉴成功和错误，以及帮助团队成员理解产品构想。

鼓励型领导者，知道好目标和坏目标之间的区别。领导者帮助弄清目标，团队透彻了解这些目

标并以此鼓励自己。

演示、原型、模拟和模型是相互交流的催化剂，它们组成了“共享空间二其中开发者、市场人

员、客户和经理可以做有意义的相互交流。

共享空间有两个要求一直观化和公共性。公共性意味着原型需要得到开发工作的所有相关方

的理解。

2.建立团队

建立自我组织的框架必须要：

(1)找到适当的人

流程可以为人们的高效工作提供共同框架，但它不能代替能力和技能；产品是由能干、技术熟

练的个人制造的，而不是由流程制造的。

(2)清楚表述产品构想、界限和团队角色。

(3)鼓励团队之间的相互交流和信息流动

健康团队关系的核心是信任和尊重。项目经理需要将精力放在相互交流、协作上，需要先协调，

然后再准备适当的文档，因为文档会妨碍交流。

(4)促进参与式决策

决策是协作的心脏和灵魂。团队如何作出决策确定了团队是否真正协作。选择双赢思维模式，

用重新构思代替妥协。重新构思意味着将多种想法合并起来，创造一种比任何一个单独想法更

好的东西。

(5)坚持负责

责任和负责创造了高效的自我组织团队。如图10-16所示，信任是协作的基石，而履行承诺是

建立信任的核心。

(6)引导而不是控制

那些想建立适应能力强的、自我组织的项目团队的经理应该引导而不是控制，他们影响、轻推、

促进、劝告，以及在某些情况下指导，他们将自己看作是教练。

2.建立团队

同时，自律是自由、授权的前提。

(1)自律的个人可以对结果负责。

(2)用严谨的思维对抗现实。

(3)参与激烈的交流和争论。

(4)愿意在自我组织框架为工作。

(5)尊重同事。

3简化流程

如果你想X速而又敏捷，那么，就要使事情保持简单。

速度不是简化的结果，但简化能提高速度。

当你去掉详细的任务和工作、简化流程时，你就强迫人们思考和交流，因为无论是他们或他们

的经理都不能用结构作为一个拐杖。

(1)再生规则：简单规则是复杂性理论“群集智能”的一面。其想法是正确的一套简单规则,

一旦应用到一群充分交流的个人之中，会产生诸如创新和创造力之类的复杂性为。

一套正确的规则应该是为创新和生产设立界限最少的一组规则，它们制定简单的、但产生复杂

行为的规则组，营造创新环境。

(2)刚刚足够的方法论：在决定流程、方法、做法、文档以及产品开发的其他方面时，简化的

警告将我们引向刚刚足够、引向精简、引向实施“比刚刚够少一点”。必须快速适应，但永远

不要失去控制。

10.4主要敏捷方法

手工作坊式的软件生产方式，已经被无数次的项目失败证明为低效和应被舍弃的。

传统软件开发方法(如ISO9000和CMM)在规范和保证开发进程的同时，由于其繁琐的过程

控制和严格的文档要求招致了开发者潜在的抵触。

此外，开发人员流动性大于软件的可持续开发之间的矛盾日渐显露，如何保证软件的高可传承

性以及尽可能地延长软件生命周期，成了摆在开发者和管理者面前的难题。

为了应对这种局面，近年来，已经出现很多敏捷型方法，它们有许多的共同特征，但也有一些

重要的不同之处。

这里，就其中影响比较大的几种敏捷方法作做一些简单的介绍。

10.4.1XP极限编程

极限编程(ExtremeProgramming,XP)是一种轻量级的软件开发方法，它使用快速的反馈，大

量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。

10.4.1XP极限编程

10.4.1XP极限编程

10.4.1XP极限编程

XP流程

XP强调4个因素。

交流(Communication):

XP要求程序员之间以及和用户之间有大量而迅速的交流。

简单(Simplicity):

XP要求设计和实现简单和干净。

反馈(Feedback)：

通过测试得到反馈，尽快提交软件并根据反馈修改。

勇气(Courage)：

勇敢的面对需求和技术上的变化。

10.4.2Scrum工具

Scrum中有三种角色：

产品经理(ProductOwner),

ScrumMaster(相当于项目经理)

团队(Team)

scrum:兼顾计划与灵活的敏捷开发

scrum:兼顾计划与灵活的敏捷开发

10.4.2Scrum工具

10.4.2Scrum工具

另外Scrum的三大特点，和传统瀑布式的项目管理的最大区别如下。

(1)"可能性的”艺术：强调想事情的时候不应该把注意力集中在"不能做的事情”上，而是

关注当下“什么事情可以做或者可能做"，不要被诸多的不确定性因素所困扰，先做可以做的，

然后看有什么新的发现，有什么新的思维出现。

(2)团队自组织，自管理：强调"放权"，让团队自己寻找解决问题的最佳方案。可以激发团

队创造力，增强团队责任感，显著提高生产力。

(3)面对面沟通：强调面对面的沟通，以有效减少沟通障碍。

10.4.2Scrum工具

敏捷方法之极限编程(XP)和Scrum区别

(1)迭代长度的不同。

XP的一个Sprint的迭代长度大致为1-2周，而Scrum的迭代长度一般为2-4周。

(2)在迭代中，是否允许修改需求。XP在一个迭代中，如果一个UserStory(用户素材，也就

是一个需求)还没有实现，则可以考虑用另外的需求将其替换，替换的原则是需求实现的时间

量是相等的。

而Scrum是不允许这样做的，一旦迭代开工会完毕，任何需求都不允许添加进来，并有Scrum

Master严格把关，不允许开发团队受到干扰。

(3)在迭代中，UserStory是否严格按照优先级别来实现。

XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum

这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进

度就耽误了。另外一个原因是.如果按优先级排序的UserStory#6和#10,虽然#6优先级高，

但是如果#6的实现要依赖于#10,则不得不优先做#10。

(4)软件的实施过程中，是否采用严格的工程方法，保证进度或者质量。

Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流

程方法定义非常严格，规定需要采用TDD,自动测试，结对编程，简单设计，重构等约束团队

的行为。

敏捷方法之极限编程(XP)和Scrum区别

10.4.3Cockbum的水晶系列方法

水晶系列方法与XP方法一样，都有以人为中心的理念，但在实践上有所不同。

Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度严格纪

律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达

到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵

循它。

Crystal系列开发方法，分为CrystalClear,CrystalYellow,CrystalOrange和CrystalRed分别适

用于不同的项目。项目可以按照参加的人员和重要性划分。

CrystalClear的七大特征

10.4.4开放式源码

这里提到的开放式源码，指的是开放源码界所用的一种运咋方式。

开放式源码项目有一个特另J之处，就是程序开发人员在地域上分布很广，这使得它和其它他敏

捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作

o开放源码的一个突出特点就是查错排障（Debug）的高度并行性，任何人发现了错误都可将

改正源码的“补丁”文件发给维护者。

然后由维护者将这些“补丁”或是新增的代码并入源码库。

10.4.4开放式源码

多数开放源码项目有一个或多个源码维护者。只有维护者才能将新的或修改过的源码段并入源

码库。

其他众人可以修改源码，但需将他们所做的改动送交给维护者，由维护者对这些改动进行审核

并决定是否并入源码库

通常来说，这些改动是以“补丁”文件的形式，这样处理起来容易一些。维护者负责协调这些

改动并保持设计的一致性。

维护者的角色在不同的项目中有不同的产生和处理方式。

有些项目只有一个维护者，有些项目把整个系统分成若干个模块，每个模块有一个维护者。有

些是轮流做维护者，有些是同一个源码部分有多个维护者，有些则是这些方式的组合。

许多开放源码项目的参与者只是部分时间（或业余时间），如果项目要求是全日制的，那么这

有一个问题，就是怎样才能把这些开发人员有效地协调组织起来。

10.4.4开放式源码

开放源码的一个突出特点就是查错排故（Debug）的高度并行性，因为许多人都能同时参与查

错排故。

如果他们发现了错误，他们可将改正源码的"补丁”文件发给维护者。

这种查错排故角色对非维护者来说合适，对那些设计能力不是很强的人来说，也是一项挺好的

工作。

开源软件是一种源代码可以任意获取的计算机软件。

开源软件开发方法是伴随着互联网在全球的快速发展而兴起的。

以Linux为例，Linux起步发展的时间（1993年-1994年）与互联网在全球的快速发展几乎是同

步的。

开源软件开发方法，依赖于分散在全球的开发者和使用者的协作，而只有互联网才能为这种大

规模协助提供交流沟通的工具。廉价的互联网是Linux模式得以发展的必要条件。

10.4.4开放式源码

开源软件开发方法还启发了一种称之为众包（CrowdSourcing）的软件开发组织方式。

众包的方式继承了开源软件开发的大部分实践，但与传统开源软件开发方法还存在一些差异。

10.4.4开放式源码

10.4.5Coad的功用驱动开发方法

特征驱动开发(FeatureDrivenDevelopments,FDD)是由JeffDeLuca和PeterCoad提出来

的。

像其它他方法一样，它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期一

般是两周。

在FDD中，编程开发人员分成两类：首席程序员和"类"程序员(classowner)o

首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序

员则主要做源码编写。

FDD流程图

10.4.5Coad的功用驱动开发方法

关于特性驱动开发需要知道的7件事

10.4.5Coad的功用驱动开发方法

(1)开发整体模型

这是FDD开始一个项目的初始工作,在主设计师的指导下，带领领域专家和开发小组成员一起

工作。

主要是收集系统的功能需求，然后使用四色原型进行域建模。在此阶段中，能够得出系统的架

构设计图。

(2)构建功能列表

这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家

对领域的划分，将整个领域分成一定数量的区域(主要功能集)，每个区域再细化为一定数量的

活动。

活动中的每一步被划分称为一个功能。形成了具有层次结构的分类功能列表。在此阶段中，能

够形成系统的概要设计。

(3)计划功能开发

项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的

复杂性，计划实现功能的顺序，完成一个功能开发计划。

它提供了对项目的高层视图，让业务代表了解功能开发、测试和发布日期，以便业务代表和部

署小组能够计划交付哪些功能的日期。本阶段的主要成果，是能够形成项目开发计划。

10.4.5Coad的功用驱动开发方法

(4)按照功能设计

项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。

同时在域模型的基础上进行分析、设计，得出分析模型、设计模型。由于一次设计并不全面，

因此也可以直接进入设计模型。

根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果，应该包

括详细设计、项目里程碑计划等。

(5)按照功能构建

按照设计进行编码实现，由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、

评审。在测试和检查通过后检入到配置管理库中进行构建。

第5和第4阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的

实现功能集中的功能。

每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑的继续，直到最后项目的完成。

10.4.6自适应软件开发方法

自适应软件开发(AdaptiveSoftwareDevelopment,ASD)方法由世界知名的敏捷专家、《敏捷

宣言》的创始人吉姆海史密斯(JimHighsmith)提出。其核心是三个非线性的、重叠的开发阶

段：猜测、合作与学习。

吉姆・海史密斯和自适应软件开发

10.4.7DevOps

DevOps(Development和。perations的组合词)是一组过程、方法与系统的统称，用于促进开

发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

De