第 28卷
Vo1．28
第 16期
NO．16
计算机工程与设计
Computer Engineering and Design
2007年 8月
Aug．2007
敏捷软件开发与计划驱动开发的概述比较
夏显鄂 ， 梁洪峻
(天津大学 计算机科学与技术学院，天津 300072)
摘 要：人们在设 想、确定以及创建软件时，身边的环境不断在变更。敏捷是为了在动荡的业务环境中获益而创造变革和响
应变革的能力。极限编程是最著名的敏捷软件开发方法。传统的开发侧重于计划和架构，计划驱动开发关注的是软件的质
量和过程 的可预见性。计划驱动开发最佳范例是能力成熟度模型。两种表面上有 不同观点的方法在争夺着软件开发的主导
权 ，对敏捷软件开发与计划驱动开发进行了概述 ，并就特征、擅长领域和关键要素等进行比较 。
关键词：方法论；敏捷软件开发；计划驱动开发；极限编程；能力成熟度模型
中图法分类号：TP311．52 文献标识码：A 文章编号：1000．7024(2007)16．4035．03
Summarizing and comparing of agile software development to plan—driven development
XIA Xian—e， LIANG Hong-jun
(School of Computer Science and Technology,Tianjin University,Tianjin 300072，China)
Abstract： The environment in which software is imagined， specified， and created is chan ging． Agile is capability, it creates and
responds chan ge for profiting in turbulence operation environm ent． Extreme programming is in the front rank ofagile software develop—
ment methods．Tradition development emphasize particularly on plan and architecture．Plan-driven methods’aRenfion is quality of sol-
tware and predictability ofprocess．Th e first rallk paradigm ofPlan—driven methods is capability maturity mode1．Two having ostensibly
different viewpoint approaches to software development have competed for hegemony． Agile software development to plan -driven de-
velopmen t is summarized， and their feature， adept domain an d key element etc are compared．
Key words：methodology；agile software development；plan-driven development；extreme program ming；capability maturity model
(CMM)
0 引 舌
敏捷软件开发的核心是在项 目管理中运用“轻但够用”的
原则，及以人为本和以沟通为中心的原则。敏捷宣言定义了
敏捷的价值体系。敏捷软件开发实例包括极限编程 (extreme
programming，XP)、自适应软件开发(adaptive software develop-
ment，ASD)、Crystal、Serum、特性驱动编程(feature．driven develo．
pment，FDD)。极限编程是敏捷软件开发中最突出的实例。计
划驱动的方法被认为是传统的软件设计开发方法。基于一些
来自传统工程领域的概念，这些方法使用一些标准的、定义 良
好的、组织持续改进的过程，以一种需求／设计／构建的模式进
行开发。计划驱动开发的实例包括军用标准、通用过程标准、
软件工厂、净室、软件能力成熟度模型(SW-CMM)、CMM集成
(CMMI)、个体软件工程(PSP)／团队软件过程(TSP)。重点介绍
能力成熟度模型，对敏捷软件开发与计划驱动开发进行比较。
l 敏捷软件开发
2001年2月，在美国犹他州的雪鸟城，l7位业界专家聚
在一起概括出了一些可以让软件开发团队具有快速工作、响
应变化能力的价值观和原则。这次会议形成了敏捷软件开发
运动，创建了敏捷联盟。会议的结果是 l7名与会者签署了“敏
捷软件开发宣言”(敏捷联盟诞生于2001年，但其各种方法和
研究这些方法的人的历史可追溯到 10~15年前，FredBrooks在
20世纪50年代中期就使用 了结对编程)。
1．1 敏捷软件开发宣言
“我们通过亲身实践和帮助他人实践，找到了更好的软件
开发方法。在工作中我们得出以下观点：较之于过程和工具，
应更注重人及其交互的价值。较之于面面俱到的各类文挡，
应更注重可运行的软件的价值。较之于合同谈判，应更注重
与客户合作的价值。较之于遵循计划，应更注重响应需求变
化的价值。虽然左侧的观点是有价值的，但我们认为右侧的
观点更有价值。”
在敏捷宣言的价值陈述中，敏捷学家认为，右边项比左边
项更重要，但并不是说工具、过程、文档或合同等不重要。与
其使用有文档但交互中充满敌意的过程，还不如使用没有文
档，而有良好交互的过程 。文档非常有用，但对它们采用“刚
收稿日期：2006-09-20 E-marl：xxe
_ tom@tom．com
作者简介：夏显鄂 (1976一)，男，天津人，硕士研究生，研究方向为软件开发； 梁洪峻，副教授，硕士生导师，研究方向为程序设计语言、形
式化方法、软件工程。
·— — 4035·——
维普资讯
第 28卷第 16 期
Vo l. 28
计算机工程与设计
Computer Engineering and Design
2∞7年 8 月
敏捷软件开发与计划驱动开发的概述比较
夏显鄂， 梁洪峻
(天津大学计算机科学与技术学院，天津 300072)
摘 要:人们在设想、确定以及创建软件时，身边的环境不断在交灵。敏捷足为了在动荡的业务环境中获益而创造交革和响
应变革的能力.极限编程是最著名的敏捷软件开发方法。传统的开发侧重于计划和架构，计划驱动开发关注的是软件的质
量和过程的可预见性。计划驱动开发最佳范例是能力成熟度模型。两种表面上有不同观点的方法在争夺着软件开发的主导
权，对敏捷软件开发与计划驱动开发进行了概述，并就特征、擅长领域和关键要素等进行比较.
关键词:方法论;敏捷软件开发;计划驱动开发;极限编程;能力成熟度模型
中图法分类号: TP31 文献标识码:A 文章编号: 1ω0-7024 (2007) 16-4035-03
Summarizing and comparing of agile S。由ware development to plan-driven development
XIAXi钮-e， LIANG Hong气jun
(School ofComputer Scìence and Technology, Tianjin University, Tianjin 300072, China)
Abstract: The environment in which so丘ware is irnagined, specified, and created is changing. Agile is capability, it creates and
responds change for profiting in turbulence operation environment. Extreme prograrnming is in the front rank of agile so食ware develop-
ment methods. Tradition development emphasize particularly on plan and architecture. Plan-driven methods' attention is quality of sof-
tware and predictability of process. The frrst rank paradigm ofPlan-driven methods is capability maturity model. Two having ostensibly
different vi创叩oint approaches to so食ware development have competed for hegemony. Agile so食ware development to plan-driven de-
velopment is summarized, and their feature, adept domain and key element etc are compared.
Key words: methodology; agile so食ware development; plan-driven development; extreme prograrnming; capability maturity model
(CMM)
。引言
敏捷软件开发的核心是在项目管理中运用"轻但够用"的
原则，及以人为本和以沟通为中心的原则。敏捷宣言定义了
敏捷的价值体系。敏捷软件开发实例包括极限编程 (ex出me
programming, xp)、自适应软件开发 (adaptive so食ware develop-
ment ， ASD)、 Crystal 、 Scrum、特性驱动编程(fi臼.ture-世iven develo-
pment ， FDD)。极限编程是敏捷软件开发中最突出的实例。计
划驱动的方法被认为是传统的软件设计开发方法。基于一些
来自传统工程领域的概念，这些方法使用→些标准的、定义良
好的、组织持续改进的过程，以一种需求/设计/构建的模式进
行开发。计划驱动开发的实例包括军用标准、通用过程标准、
软件工厂、净室、软件能力成熟度模型(SW-CMM) ，CMM 集成
(C岛1MI)、个体软件工程(PSPν团队软件过程(TSP)。重点介绍
能力成熟度模型，对敏捷软件开发与计划驱动开发进行比较。
1 敏捷软件开发
2001 年 2 月，在美国犹他州的雪鸟城， 17 位业界专家聚
收稿日期 2006-09-20 E-maiJ: xxe_tom@
在→起概括出了一些可以让软件开发团队具有快速工作、响
应变化能力的价值观和原则。这次会议形成了敏捷软件开发
运动，创建了敏捷联盟。会议的结果是 17 名与会者签署了"敏
捷软件开发宣言"(敏捷联盟诞生于 2001 年，但其各种方法和
研究这些方法的人的历史可追溯到 10-15 年前， Fred Brooks在
20 世纪 50 年代中期就使用了结对编程)。
敏捷软件开发宣言
"我们通过亲身实践和帮助他人实践，找到了更好的软件
开发方法。在工作中我们得出以下观点 2 较之于过程和工具，
应更注重人及其交互的价值。较之于面面俱到的各类文挡，
应更注重可运行的软件的价值。较之于合同谈判，应更注重
与客户合作的价值。较之于遵循计划，应更注重响应需求变
化的价值。虽然左侧的观点是有价值的，但我们认为右侧的
观点更有价值。"
在敏捷宣言的价值陈述中，敏捷学家认为，右边项比左边
项更重要，但并不是说工具、过程、文档或合同等不重要。与
其使用有文档但交互中充满敌意的过程，还不如使用没有文
档，而有良好交互的过程。文档非常有用，但对它们采用"刚
作者简介s 夏显鄂(1976-)，男，天津人，硕士研究生，研究方向为软件开发; 梁洪峻，副教授，硕士生导师，研究方向为程序设计语言、形
式化方法、软件工程。
一 4035 一
好足够”、“恰好充分”的原则，尽管合同有时会有用，但无论有
没有合同，协作都会巩固开发。制定计划是有用的，每种敏捷
软件开发方法论都包含明确的制定计划活动，也包含处理优
先级变化的机制。
1．2 敏捷软件开发的原则
12个详细原则组成了上述 4个观点，是区别于重型过程
的特征所在：①最高优先级是通过尽早和经常交付有价值的
软件来令客户满意：②不断地交付软件，以每两周或每两个月
为周期，推荐使用较短的周期：⑨可运行的软件是工作进展的
主要度量标准：④ 以积极的态度对待需求的变化，即使在开发
阶段末期也不例外。敏捷过程利用变化来为客户创造竞争优
势；⑤在整个开发过程中，业务人员和开发人员最好能每天一
起工作：⑥项目由积极主动的人员来完成，给他们提供所需的
环境和支持，信任他们能把工作做好：⑦在开发团队中，最具有
效果和最有效率的信息交流手段是面对面的交谈；⑨最好的系
统构架、需求和设计产生于自组织的团队：⑨应时刻关注技术
上的精益求精和合理的设计，这样可以提高应变能力；⑩敏捷过
程提倡可持续开发思想。出资人、开发者、用户应该保持长期、恒
定的开发速度；⑩简单化——最佳化未完成的工作的艺术——
是至关重要的；⑥团队应该定期对其运作方法进行反思，考虑
如何能变得更有效，提出改进意见，并据此进行相应的调整。
2 极限编程
2O世纪9O年代初，克莱斯勒公司的薪资服务部门和信息
服务部门决定采用新的统一系统来取代老系统。1996年，克
莱斯勒邀请 Kent Beck作为顾问，指导这个已陷于困境的C3
项 目。为了解决这个问题，在 1996年到 1999年间，Beck、Curt—
ningh锄 、Jeffa'ies等人构建了现在被称为极限编程的基本元素。
极限编程是敏捷软件开发中最著名的一个，是一种针对
业务和软件开发，将两者力量集中在共同的、可以达到的目标
上。它是一种轻量、高效、低风险、柔性的软件开发方式，由一
系列简单却互相依赖的实践组成。
(1)极限编程的 12个实践：①计划游戏：通过结合使用业
务优先级和技术评估来快速确定下一个版本的范围。当计划
赶不上实际变化时，就应更新计划：②小版本：将一个简单系
统迅速投产，然后以很短的周期发布新版本；⑨隐喻：用有关
整个系统如何运行的简单、众所周知的故事来指导所有开
发：④简单设计：任何时候都应当将系统设计得尽可能简单，
不必要的复杂性一旦被发现就马上去掉；⑤测试：程序员不断
地编写单元测试，在这些测试能够无误地运行的情况下，开发
才可以继续。客户编写测试证明各功能已经完成；⑥重构：程
序员重新构造系统(而不更改其行为)以去除重复、改善沟通、
简化或提高柔性；⑦结对编程：所有的生产代码都是由两个程
序员在同一台计算机上编写的；⑨集体所有权：任何人在任何
时候都可以在系统中的任何位置更改任何代码；⑨持续集成：
每天多次集成和生成系统，每次都完成～项任务；⑩每周工作
4O小时：一般情况下，一周工作不超过4O小时，不要连续两个
星期都加班；⑩现场客户：在团队中加入一位真正的、起作用
的客户，他将全职负责回答问题；⑥编码标准：程序员依照强
调通过代码沟通的规则来编写所有代码；
·— — 4036-——
(2)极限编程的4个变量：成本、时间、质量、范围(客户、管
理人员确定任意 3个变量的值，开发团队确定第 4个变量的
值)。其中范围的控制最有价值。
(3)极限编程的4个准则：沟通、简单、反馈、勇气 。
(4)极限编程的基本原则：快速反馈、假设简单性、递增更
改、提倡更改、优质工作。
(5)极限编程开发软件的4项基本工作是：编码 、测试、倾
听 和设计 。
极限编程的实践、准则、原则和工作之间的关系是：原则
来 自于准则：而原则和准则又都是以12个实践为基础的；12
个实践关联着开发软件的 4项基本工作。极限编程实践提供
了对实际操作的指导。
3 计划驱动开发
计划驱动开发起源于系统工程和质量规范，建立系统工
程的原则，协调大量需要精确协同工作的组件。
通过从需求到 已完成的代码等一系列代表物来推动软件
开发的过程，计划驱动开发非常精确地依赖于明确的步骤。典
型地，瀑布模型，软件开发周期划分成若干个阶段：问题定义、
可行性研究、需求分析、总体设计、详细设计、编码与单元测
试、综合测试、软件维护，各阶段的工作 自项向下，从抽象到具
体顺序进行，每个阶段都必须完成规定的文档，只有前一阶段
的输出文档正确，后一阶段的工作才能获得正确的结果，就好
像奔流不息的瀑布，从概念直到最终产品
计划驱动开发的关键是过程的定义和管理，和过程改进
联系在一起，强势在于标准化所带来的可比较性和可重复性。
过程需要进行定义、标准化并需要逐步改进以提供控制、管理
其操作所需的数据。定义过程执行的方法，和工作产品形式
化的方法，对过程的实施者进行 良好的培训。需要管理层的
支持、组织化的基础设施以及 良好的环境。
4 能力成熟度模型
能力成熟度模型(capability maturity model，CMM)，例证了
传统的计划驱动开发。
能力成熟度模型是由美国卡内基．梅隆大学的软件工程研
究所(sottwareengint~ringinstitute，SEI)提出的一套对软件过程的
管理、改进与评估的模式。CMM 最早被应用于美国国防部
(departmentofdefense，DoD)Pb部企业承接的军事软件项 目，评
估软件供应商是否有能力承担项 目，评估他们的软件过程能
力。此后，CMM 被视为一种公认的标准，建立了CMM认证体
系，用来衡量软件组织或企业的成熟度等级或软件过程能力。
CMM 分为 5个成熟度等级：①初始级：软件工程的特点
是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善
定义的，成功往往依赖于个人或小组的努力：②可重复级：建
立了基本的项 目管理工程来跟踪成本、进度和功能特性。制
定了必要的过程纪律 ，能重复早先类似应用项 目取得的成
功；③ 已定义级：已将管理和工程活动两方面的软件过程文档
化、标准化 ，并综合成该机构的标准软件过程。所有项 目均使
用经批准、裁剪的标准软件过程来开发和维护软件；④ 已管理
级：收集对软件过程和产品质量的详细度量值，对软件过程和
维普资讯
好足够飞"恰好充分"的原则，尽管合同有时会有用，但无论有
没有合同，协作都会巩固开发。制定计划是有用的，每种敏捷
软件开发方法论都包含明确的制定计划活动，也包含处理优
先级变化的机制。
敏捷软件开发的原则
12 个详细原则组成了上述 4 个观点，是区别于重型过程
的特征所在 2①最高优先级是通过尽早和经常交付有价值的
软件来令客户满意:②不断地交付软件，以每两周或每两个月
为周期，推荐使用较短的周期:③可运行的软件是工作进展的
主要度量标准:④以积极的态度对待需求的变化，即使在开发
阶段末期也不例外。敏捷过程利用变化来为客户创造竞争优
势:⑤在整个开发过程中，业务人员和开发人员最好能每天一
起工作;@项目由积极主动的人员来完成，给他们提供所需的
环境和支持，信任他们能把工作做好:⑦在开发团队中，最具有
效果和最有效率的信息交流手段是面对面的交谈;@最好的系
统构架、需求和设计产生于自组织的团队:⑨应时刻关注技术
上的精益求精和合理的设计，这样可以提高应变能力;⑩敏捷过
程提倡可持续开发思想。出资人、开发者、用户应该保持长期、恒
定的开发速度:⑨简单化一一最佳化未完成的工作的艺术一一
是至关重要的:⑨团队应该定期对其运作方法进行反思，考虑
如何能变得更有效，提出改进意见，并据此进行相应的调整。
2 极限编程
20世纪 90年代初，克莱斯勒公司的薪资服务部门和信息
服务部门决定采用新的统一系统来取代老系统。 1996 年，克
莱斯勒邀请 Kent 8eck 作为顾问，指导这个己陷于困境的 C3
项目。为了解决这个问题，在 1996 年到 1999 年间， 8eck、 Cun
ningham、 Je岱iω等人构建了现在被称为极限编程的基本元素。
极限编程是敏捷软件开发中最著名的二个，是一种针对
业务和软件开发，将两者力量集中在共同的、可以达到的目标
上。它是一种轻量、高效、低风险、柔性的软件开发方式，由一
系列简单却互相依赖的实践组成。
(1)极限编程的 12 个实践z①计划游戏:通过结合使用业
务优先级和技术评估来快速确定下二个版本的范围。当计划
赶不上实际变化时，就应更新计划:②小版本 z 将一个简单系
统迅速投产，然后以很短的周期发布新版本:③隐喻z 用有关
整个系统如何运行的简单、众所周知的故事来指导所有开
发:④简单设计:任何时候都应当将系统设计得尽可能简单，
不必要的复杂性一旦被发现就马上去掉:⑤测试z程序员不断
地编写单元测试，在这些测试能够无误地运行的情况下，开发
才可以继续。客户编写测试证明各功能己经完成;@重构z 程
序员重新构造系统(而不更改其行为)以去除重复、改善沟通、
简化或提高柔性:⑦结对编程z 所有的生产代码都是由两个程
序员在同一台计算机上编写的;@集体所有权z任何人在任何
时候都可以在系统中的任何位置更改任何代码:⑨持续集成z
每天多次集成和生成系统，每次都完成-项任务;⑩每周工作
40 小时=一般情况下，一周工作不超过 40 小时，不要连续两个
星期都加班;⑥现场客户 z 在团队中加入一位真正的、起作用
的客户，他将全职负责回答问题:⑨编码标准 z 程序员依照强
调通过代码沟通的规则来编写所有代码:
一 4036 一
(2)极限编程的 4 个变量:成本、时间、质量、范围(客户、管
理人员确定任意 3 个变量的值，开发团队确定第 4 个变量的
值)。其中范围的控制最有价值。
(3)极限编程的 4 个准则 2 沟通、简单、反馈、勇气。
(4)极限编程的基本原则:快速反馈、假设简单性、递增更
改、提倡更改、优质工作。
(5)极限编程开发软件的 4 项基本工作是 z 编码、测试、倾
听和设计。
极限编程的实践、准则、原则和工作之间的关系是:原则
来自于准则:而原则和准则又都是以 12 个实践为基础的; 12
个实践关联着开发软件的 4 项基本工作。极限编程实践提供
了对实际操作的指导。
3 计划驱动开发
计划驱动开发起源于系统工程和质量规范，建立系统工
程的原则，协调大量需要精确协同工作的组件。
通过从需求到己完成的代码等一系列代表物来推动软件
开发的过程，计划驱动开发非常精确地依赖于明确的步骤。典
型地，瀑布模型，软件开发周期划分成若干个阶段z 问题定义、
可行性研究、需求分析、总体设计、详细设计、编码与单元测
试、综合测试、软件维护，各阶段的工作自顶向下，从抽象到具
体顺序进行，每个阶段都必须完成规定的文档，只有前一阶段
的输出文档正确，后一阶段的工作才能获得正确的结果，就好
像奔流不息的瀑布，从概念直到最终产品。
计划驱动开发的关键是过程的定义和管理，和过程改进
联系在一起，强势在于标准化所带来的可比较性和可重复性。
过程需要进行定义、标准化并需要逐步改进以提供控制、管理
其操作所需的数据。定义过程执行的方法，和工作产品形式
化的方法，对过程的实施者进行良好的培训'1. 需要管理层的
支持、组织化的基础设施以及良好的环境。
4 能力成熟度模型
能力成熟度模型(capability maωrity model ， CMM)，例证了
传统的计划驱动开发。
能力成熟度模型是由美国卡内基.梅隆大学的软件工程研
究所(software engineering institute, SEI)提出的一套对软件过程的
管理、改进与评估的模式. CMM 最早被应用于美国国防部
(department of defense , DoD)外部企业承接的军事软件项目，评
估软件供应商是否有能力承担项目，评估他们的软件过程能
力。此后，CMM 被视为二种公认的标准，建立了 CMM 认证体
系，用来衡量软件组织或企业的成熟度等级或软件过程能力。
CMM 分为 5 个成熟度等级 z①初始级 2 软件工程的特点
是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善
定义的，成功往往依赖于个人或小组的努力:②可重复级 2 建
立了基本的项目管理工程来跟踪成本、进度和功能特性。制
定了必要的过程纪律，能重复早先类似应用项目取得的成
功;③己定义级:己将管理和工程活动两方面的软件过程文档
化、标准化，并综合成该机构的标准软件过程。所有项目均使
用经批准、裁剪的标准软件过程来开发和维护软件:④己管理
级:收集对软件过程和产品质量的详细度量值，对软件过程和
产品都有定量的理解和控制；⑤优化级：过程的量化反馈和先
进的新思想、新技术促使过程不断改进。
除了级别①，每个成熟度级别都包含关键过程域 ，一组相
互关联的活动，实现一组对建立过程能力至关重要的目标。规
定每一个关键过程域属于某个成熟度级别。每个关键过程域
由SEI标识为一个基本结构单元域，以帮助确定机构的软件
过程能力和了解要达到软件成熟度级别所需要的过程改进。
CMM的第2级关键过程域包括需求管理、软件项目计划、
软件项目跟踪和监督、软件分包合同管理、软件质量保证和软
件配置管理。
CMM的第 3级关键过程域包括机构过程焦点、机构过程
定义、培训大纲、综合软件管理、软件产品工程、组间协调和同
行 评审 。
CMM 的第 4级关键过程域包括定量过程管理和软件质
量管理。
CMM的第 5级关键过程域包括缺陷预防、技术更新管理
和过程更改管理。
5 敏捷软件开发与计划驱动开发的比较
5．1 敏捷软件开发与计划驱动开发的对比
从以下特征中比较敏捷软件开发和计划驱动开发之间
的不 同：
应用：项目的主要 目标、项 目环境和应用环境；
管理：客户关系、计划和控制，以及项 目沟通；
技术：需求定义 、开发和测试的方法；
人员：客户特征、开发人员的特征，以及组织的文化。
5．1．1 应 用
(1)主要 目标：敏捷软件开发的目标是快速交付价值和响
应变更，在快速变更的环境中，反应式的态度具有优势，但有
一 些风险。计划驱动开发的目标是可预见性、稳定性和高可
靠性，提前行动的态度对于稳定的环境非常有效，认证需要有
计划和规格说明：
(2)规模：敏捷软件开发最适合规模 比较小的项 目，事
实证明，敏捷项 目的规模难 以扩大 。传统 的严格性对大型
项 目更有效，对于大型 、复杂的项 目来说，计划驱动开发是
必 需 的；
(3)环境：敏捷软件开发适用于频频变更的环境，但有一
些风险，关注于眼前的产品，成功主要出现在内部环境，假设
用户系统是灵活的，足以进行演化。计划驱动开发需要稳定
性，范围包括系统工程、组织结构、外包。
5．1．2 管 理
(1)客户关系：敏捷软件开发提倡专职的、在一起工作的
客户，重中之重是客户代表和用户之间的接口，敏捷开发者通
过可以工作的软件来建立客户信任。计划驱动开发依赖于合
同和规格说明，重中之重是开发者和客户之间的接口，计划驱
动开发者使用 已形成的过程成熟度来建立客户信任；
(2)计划和控制：敏捷者把计划看作一种达到 目标的手段，
敏捷软件开发是“计划行为驱动”而非“计划驱动”。计划驱动
开发用计划来进行沟通和协调。两种方法都使用过去的经验
来使计划变得准确；
(3)项目沟通：敏捷软件开发依赖于隐式知识，依赖于频
繁的、人和人之间的沟通，依赖于隐式知识是有风险的，隐式
知识的规模难以扩大。计划驱动开发依赖于显示的、文档化
知识。敏捷软件开发和计划驱动开发中都同时使用了这两种
知识。敏捷软件开发在需要时会编写文档。计划驱动开发则
通常是去掉一些不必要的内容，一旦指定，再去除文档就很难
了，会遭遇“裁剪”综合症。
5．1-3 技 术
(1)需求：敏捷软件开发把非正式的、由用户指定优先级
的素材作为需求。计划驱动开发偏爱明确的、形式化的需求，
计划驱动开发中没有广泛使用优先级这一概念。计划驱动开
发可以更好地处理非功能需求(比如：可靠性、吞吐量、满足实
时限制和可伸缩性)；
(2)开发：敏捷软件开发提倡简单设计，简单设计依赖于
低成本的改写和快速变更，但无法保证低成本的改写，低成本
的改写无法伸展，简单设计意味着你不会需要它的(You are’llt
going to need it， GI)。计划驱动开发提倡使用架构来预测
变更，在快速变更的环境中，架构会造成一些资源的浪费；
(3)测试：敏捷软件开发在编码之前开发测试，然后增量
地测试。计划驱动开发测试的是规格说明。
5．1．4 人 员
(1)客户：敏捷软件开发非常强调专职的、工作在一起的
客户代表，成功依赖于客户代表必须易于协作、有代表性、有
授权、尽责和在行(collaborative，representative，authorized，commit-
ted，knowledgeable，CRACK)。而计划驱动开发则依赖于大量预
先的，客户和开发者之间的合同计划和规格说明方面的工作，
也需要 CRACK型的客户，但可以不是专职的，计划驱动开发
中最大的客户挑战是不要让项 目控制落入过度官僚 (他们认
为遵守合同比取得项 目成果更重要)的合同管理者手中；
(2)开发人员：敏捷开发者需要具备更多的技能。不管是
敏捷团队还是计划驱动团队，都应该尽快识别出也许具有一
些技术能力，但是不能或者不愿意，合作或者遵循公共的方法
的人员，让他们从事一些非决策性质的工作。通过培训能够
完成程序性的方法步骤 (例如，对简单的方法进行编码，进行
简单的重构，遵循编码规范和CM规程，运行测试)的人员，经
过相当多的指导，可以在计划驱动环境中很好地工作。而通
过培训能够完成任意的方法步骤 (例如，把素材分解成适合增
量开发的大小，组合使用模式，进行复杂的重构，进行一些复杂
的商品成品集成)的人员，经过一些指导，可以很好地在敏捷团
队中工作。能够对方法进行裁剪以适应有先例可循的新情况
的人员，可以很好地管理一个小型、有先例可循的敏捷或者计
划驱动项 目。但对于大型或无先例可循的项 目，需要能够对方
法进行修订(违背其规则)以适应无先例可循的新情况的人员；
(3)文化：敏捷者喜欢更多的自由度，计划驱动者需要清
晰的过程和角色。一旦一种文化已被 良好地建立，改变就会
非常困难和耗时，文化的惯性是集成敏捷软件开发和计划驱
动开发时面临的最大挑战。
5．2 5个关键的敏捷性，计划驱动性要素
关键的敏捷性，计划驱动性要素如表 l所示。
(下转第4062页)
- — — 4037-——
维普资讯
产品都有定量的理解和控制:⑤优化级 z 过程的量化反馈和先
进的新思想、新技术促使过程不断改进。
除了级别①，每个成熟度级别都包含关键过程域，一组相
互关联的活动，实现一组对建立过程能力至关重要的目标。规
定每一个关键过程域属于某个成熟度级别。每个关键过程域
由 SEI 标识为一个基本结构单元域，以帮助确定机构的软件
过程能力和了解要达到软件成熟度级别所需要的过程改进。
C岛也4的第2级关键过程域包括需求管理、软件项目计划、
软件项目跟踪和监督、软件分包合同管理、软件质量保证和软
件配置管理。
CMM的第 3 级关键过程域包括机构过程焦点、机构过程
定义、培训大纲、综合软件管理、软件产品工程、组间协调和同
行评审。
C岛也4 的第 4 级关键过程域包括定量过程管理和软件质
量管理。
CMM的第 5 级关键过程域包括缺陷预防、技术更新管理
和过程更改管理。
5 敏捷软件开发与计划驱动开发的比较
敏捷软件开发与计划驱动开发的对比
从以下特征中比较敏捷软件开发和计划驱动开发之间
的不同=
应用=项目的主要目标、项目环境和应用环境:
管理 z 客户关系、计划和控制，以及项目沟通:
技术=需求定义、开发和测试的方法:
人员=客户特征、开发人员的特征，以及组织的文化。
应用
(1)主要目标 s 敏捷软件开发的目标是快速变付价值和响
应变更，在快速变更的环境中，反应式的态度具有优势，但有
一些风险。计划驱动开发的目标是可预见性、稳定性和高可
靠性，提前行动的态度对于稳定的环境非常有效，认证需要有
计划和规格说明:
(2) 规模 s 敏捷软件开发最适合规模比较小的项目，事
实证明，敏捷项目的规模难以扩大。传统的严格性对大型
项目更有效，对于大型、复杂的项目来说，计划驱动开发是
必需的:
(3)环境=敏捷软件开发适用于频频变更的环境，但有一
些风险，关注于眼前的产品，成功主要出现在内部环境，假设
用户系统是灵活的，足以进行演化。计划驱动开发需要稳定
性，范围包括系统工程、组织结构、外包。
5. 管理
(1)客户关系 s 敏捷软件开发提倡专职的、在一起工作的
客户，重中之重是客户代表和用户之间的接口，敏捷开发者通
过可以工作的软件来建立客户信任。计划驱动开发依赖于合
同和规格说明，重中之重是开发者和客户之间的接口，计划驱
动开发者使用已形成的过程成熟度来建立客户信任 t
(2) 计划和控制ε敏捷者把计划看作一种达到目标的手段，
敏捷软件开发是"计划行为驱动"而非"计划驱动飞计划驱动
开发用计划来进行沟通和协调。两种方法都使用过去的经验
来使计划变得准确:
(3) 项目沟通z 敏捷软件开发依赖于隐式知识，依赖于频
繁的、人和人之间的沟通，依赖于隐式知识是有风险的，隐式
知识的规模难以扩大。计划驱动开发依赖于显示的、文档化
知识。敏捷软件开发和计划驱动开发中都同时使用了这两种
知识。敏捷软件开发在需要时会编写文档。计划驱动开发则
通常是去掉一些不必要的内容，一旦指定，再去除文档就很难
了，会遭遇"裁剪"综合症。
技术
(1)需求 s 敏捷软件开发把非正式的、由用户指定优先级
的素材作为需求。计划驱动开发偏爱明确的、形式化的需求，
计划驱动开发中没有广泛使用优先级这一概念。计划驱动开
发可以更好地处理非功能需求(比如 z 可靠性、吞吐量、满足实
时限制和可伸缩性);
。)开发 z 敏捷软件开发提倡简单设计，简单设计依赖于
低成本的改写和快速变更，但无法保证低成本的改写，低成本
的改写无法伸展，简单设计意味着你不会需要它的(You are'nt
going to need it , YANGI)。计划驱动开发提倡使用架构来预测
变更，在快速变更的环境中，架构会造成一些资源的浪费:
(3)测试 z 敏捷软件开发在编码之前开发测试，然后增量
地测试。计划驱动开发测试的是规格说明。
5. 人员
(1)客户 s 敏捷软件开发非常强调专职的、工作在一起的
客户代表，成功依赖于客户代表必须易于协作、有代表性、有
授权、尽责和在行(collaborative，representative，authorized，commit
ted,knowledgeable , CRACK)。而计划驱动开发则依赖于大量预
先的，客户和开发者之间的合同计划和规格说明方面的工作，
也需要 CRACK 型的客户，但可以不是专职的，计划驱动开发
中最大的客户挑战是不要让项目控制落入过度官僚(他们认
为遵守合同比取得项目成果更重要)的合同管理者手中:
(2) 开发入员 z 敏捷开发者需要具备更多的技能。不管是
敏捷团队还是计划驱动团队，都应该尽快识别出也许具有一
些技术能力，但是不能或者不愿意，合作或者遵循公共的方法
的人员，让他们从事一些非决策性质的工作。通过培训能够
完成程序性的方法步骤(例如，对简单的方法进行编码，进行
简单的重构，遵循编码规范和 CM 规程，运行测试)的入员，经
过相当多的指导，可以在计划驱动环境中很好地工作。而通
过培训能够完成任意的方法步骤(例如，把素材分解成适合增
量开发的大小，组合使用模式，进行复杂的重构，进行一些复杂
的商品成品集成)的人员，经过一些指导，可以很好地在敏捷团
队中工作。能够对方法进行裁剪以适应有先例可循的新情况
的人员，可以很好地管理一个小型、有先例可循的敏捷或者计
划驱动项目。但对于大型或无先例可循的项目，需要能够对方
法进行修订(违背其规则)以适应无先例可循的新情况的人员:
(3) 文化 g 敏捷者喜欢更多的自由度，计划驱动者需要清
晰的过程和角色。一旦一种文化已被良好地建立，改变就会
非常困难和耗时，文化的惯性是集成敏捷软件开发和计划驱
动开发时面临的最大挑战。
5 个关键的敏捷性/计划驱动性要素
关键的敏捷性/计划驱动性要素如表 1 所示。
(下转第 4062 页)
-4037 一
3 技术特征和技术难点
系统采用了机电、计算机领域较困难的计算机图像学和
传感器超声波联合对路径进行分析，采用无线通讯方式对数
据进行传输，单片机控制运输装置的运行，使运输装置具有自
动确定运行轨迹。
经过查阅国内外计算机图像学的有关技术资料，确定综
合使用计算机图像学实时远程控制运输装置是较新的技术难
题，系统对软硬件的要求较高，这样才能达到对数字图像的实
时采集、实时处理和实时控制。该系统解决了如下难题：①多
个摄像机多所采集的数字图像进行实时拼接；②对数字图像
进行模式识别采用了运动检测和 目标识别，实时消除数字图
像中的干扰和噪声；③数字图像使用了二值图像进行特征形
状分析。将特征形状分析得到的区域重心表征运输装置或障
碍物的位置坐标；④运输装置或障碍物的位置坐标，通过策略
型人工智能算法(AI)对运输装置的运行轨迹进行处理，并将处
理结果转换成该装置的运动指令，再将指令传输到通讯模块。
4 结束语
实验验证系统采集的图像障碍识别精度 lOOx100蛐 ；运
输装置的运行速度是6 m／rain，图像障碍响应速度 l s，接触障
碍的响应速度 0．1 S，运输装置躲避障碍绕行的响应速度 1．5 S，
运输装置与无线通讯频率为 l k，s。经过实验证明了用数字图
像远程控制和超声波障碍物识别联合控制运输装置是可行的，
达到了预计 目标，实现了三维空间的障碍识别，实现了运输装
置 自动控制和安全运行。
该系统能够提高在 CIMS环境下的柔性制造系统中运输
装置系统的自动化程度。该系统对从事计算机 图形图像控制
方面的科技人员具有一定的参考价值。
参考文献：
[1】 夏良正．数字图像处理[M】-2版．南京：东南大学出版社，2005．
[2】2 EllisHorowitz．计算机算法(c++版)【M】．北京：机械工业出版社，
2006．
[3】 徐爱钧．智能化测量控制仪表原理与设计[M】．北京：北京航空
航天大学出版社，2004．
[4】 杨枝灵．Visual c++数字图像获取处理及实践应用[M】．北京：人
民邮电出版社 2003．
【5】 向世明．Visualc++数字图像与图形处理【M】．北京：电子工业出
版社，2002．
[6]6 Maria Pe~ou．数字图像处理疑难解析[M]．北京：机械工业出版
社．2005．
【7】 苏彦华．Visualc++数字图像识别技术典型案列【M】．北京：人民
邮电出版社，2004
(上接第4037页)
表 l 关键的敏捷性肼 划驱动性要素
要素 敏捷性鉴别器 计划驱动性鉴别器
规模 非常适合小型产品和团队。对隐式知识的依赖限制了可升级性。 适合大型产品和团队。很难针对小型项目进行裁剪。
危险性 未经过安全关键性产品的考验。简单设计和缺乏文档具有一些潜在的问题。 适合应对高安全性的产品 很难针对低安全性的产品进行裁剪。
简单设计和持续重构非常适用于高度动态的环境，但对于高度稳定的环境， 详细的计划和庞大的预先设计非常适合于高度稳定的环境，但是对于高 动态性
会导致潜在的代价昂贵的返工 度动态的环境会导致代价昂贵的返工。
一 直需要一定数量的能够对方法进行裁剪以适应有先例可循的新情况，和 在项目定义期间需要一定数量的能够对方法进行裁剪，和能够对方法进
人员 能够对方法进行修订 (违背其规则)以适应无先例可循的新情况的专家。 行修订的专家，但在项目后期需要的会少一些一 除非环境是高度变更
使用非敏捷的、只能完成程序性的方法步骤的人员会带来风险。 的。通常可以采用一些，通过培训能够完成程序性的方法步骤的人员。
文化 更多的自由度，使人们感到舒适、有权利 (靠混沌繁荣)。 清晰的政策和规程定义人们的角色，使人们感到舒适、有权利(靠秩序繁荣)。
6 结束语 参考文献
敏捷软件开发与计划驱动开发这两种方法各有千秋，都
有各自的擅长领域。敏捷软件开发的擅长领域通常是那些系
统和开发团队规模较小、客户和系统的使用者随时可以到位、
需求和环境容易变更的项 目。
计划驱动开发则更适用于大型、复杂的系统，这些系统时
常具有安全关键或者其它高可靠性的属性，需求应该相当稳
定，环境也具有相当的可预见性。
在他们各自的擅长领域中明显优于对手，有许多敏捷软
件开发擅长的小型的、不危险、技能良好、具有敏捷文化、快速
演化的项目，也有许多计划驱动开发擅长的大型的、高危险、
技能参差不齐、具有秩序文化、稳定的项目。
应用开发的未来发展趋势既需要敏捷又需要规范，一些
平衡方法正在显现，逐步建立方法，而不是 自上而下裁剪，方
法很重要，同时也要关注人、价值观念、沟通 以及期望管理有
关的领域。
·— — 4062·——
【l】 KentBeck．解析极限编程——拥抱变化【M】．唐东铭，译．北京：人
民邮电出版社，2002．
[2] AlistairCockbum．敏捷软件开发[M】．俞涓，译．北京：人民邮政出
版社，2003．
[31 卡内基梅隆大学软件工程研究所．能力成熟度模型(cMM)：软
件过程改进指南[M】．刘孟仁，译．北京：电子工业出版社。2001．
[4】 张海藩．软件工程导论[M】．4版．北京：清华大学出版社。2003．
[5】5 Barry Boehra，Richard Tume．平衡敏捷和规范【M】．邓辉，孙鸣，
译．北京：清华大学出版社，2005．
[6】 雷剑文，陈振冲，李明树．超越传统的软件开发——极限编程的
幻象与真实【M】．北京：电子工业出版社，2005．
[7]7 Roger S Pressman．软件工程：实践者的研究方法[M]．梅宏。译．
5版．北京：机械工业出版社，2002．
【8】 KentBeck,MartinFowler．规划极限编程【M】．曹济，译 t京：人民
邮电出版社，2002．
维普资讯
3 技术特征和技术难点
系统采用了机电、计算机领域较困难的计算机图像学和
传感器超声波联合对路径进行分析，采用无线通讯方式对数
据进行传输，单片机控制运输装置的运行，使运输装置具有自
动确定运行轨迹。
经过查阅国内外计算机图像学的有关技术资料，确定综
合使用计算机图像学实时远程控制运输装置是较新的技术难
题，系统对软硬件的要求较高，这样才能达到对数字图像的实
时采集、实时处理和实时控制。该系统解决了如下难题:①多
个摄像机多所采集的数字图像进行实时拼接:②对数字图像
进行模式识别采用了运动检测和目标识剔，实时消除数字图
像中的干扰和噪声:③数字图像使用了二值图像进行特征形
状分析。将特征形状分析得到的区域重心表征运输装置或障
碍物的位置坐标:④运输装置或障碍物的位置坐标，通过策略
型人工智能算法(AI)对运输装置的运行轨迹进行处理，并将处
理结果转换成该装置的运动指令，再将指令传输到通讯模块。
4 结束语
实验验证系统采集的图像障碍识别精度 100x 100mm; 运
输装置的运行速度是 6 m/min，图像障碍响应速度 1 s，接触障
碍的响应速度 s，运输装置躲避障碍绕行的响应速度 s ,
(主接第 4037 页)
运输装置与无线通讯频率为 1 k/s。经过实验证明了用数字图
像远程控制和超声波障碍物识别联合控制运输装置是可行的，
达到了预计目标，实现了三维空间的障碍识别，实现了运输装
置自动控制和安全运行。
该系统能够提高在 CIMS 环境下的柔性制造系统中运输
装置系统的自动化程度。该系统对从事计算机图形图像控制
方面的科技人员具有一定的参考价值。
参考文献:
[1] 夏良正.数字图像处理[M]口.2版.南京:东南大学出版社，2∞5.
[山2习] E曰Ellis挝sHorowitz恒z
2006.
[3] 徐爱钧.智能化测量控制仪表原理与设计[M].北京:北京航空
航天大学出版社，2004.
[4] 杨校灵.Visua1C++数字图像获取处理及实践应用[M].北京:人
民邮电出版社 2003.
[5] 向世明.Visua1C++数字图像与图形处理[M].北京:电子工业出
版社，2002.
[6] Maria Petrou.数字图像处理疑难解析[M].北京:机械工业出版
社，2∞5.
[7] 苏彦华.Visua1C++数字图像识别技术典型案列[M].北京:人民
邮电出版社，2004
表 l 关键的敏捷性/计划驱动性要素
要素 敏捷性鉴别器 计划驱动性鉴别器
规模 非常适合小型产品和团队。对隐式知识的依赖限制了可升级性。 适合大型产品和团队。很难针对小型项目进行裁剪。
危险性 未经过安全关键性产品的考验。简单设计和缺乏文档具有一些潜在的问题。 适合应对高安全性的产品e 很难针对低安全性的产品进行裁剪。
动态性 简单设计和持续重构非常适用于高度动态的环境，但对于高度稳定的环境， 详细的计划和庞大的预先设计非常适合于高度稳定的环境，但是对于高会导致潜在的代价昂贵的返工。 度动态的环境会导致代价昂贵的返工。
→直需要一定数量的能够对方法进行裁剪以适应有先例可循的新情况，和 在项目定义期间需要→定数量的能够对方法进行裁剪，和能够对方法进
人员 能够对方法进行修订(违背其规则)以适应无先例可循的新情况的专家。
使用非敏捷的、只能完成程序性的方法步骤的人员会带来风险。
文化 更多的自由度，使人们感到舒适、有权利(靠混施繁荣)。
6 结束语
敏捷软件开发与计划驱动开发这两种方法各有千秋，都
有各自的擅长领域。敏捷软件开发的擅长领域通常是那些系
统和开发团队规模较小、客户和系统的使用者随时可以到位、
需求和环境容易变更的项目。
计划驱动开发则更适用于大型、复杂的系统，这些系统时
常具有安全关键或者其它高可靠性的属性，需求应该相当稳
定，环境也具有相当的可预见性。
在他们各自的擅长领域中明显优于对手，有许多敏捷软
件开发擅长的小型的、不危险、技能良好、具有敏捷文化、快速
演化的项目，也有许多计划驱动开发擅长的大型的、高危险、
技能参差不齐、具有秩序文化、稳定的项目。
应用开发的未来发展趋势既需要敏捷又需要规范，一些
平衡方法正在显现，逐步建立方法，而不是自上而下裁剪，方
法很重要，同时也要关注入、价值观念、沟通以及期望管理有
关的领域。
- 4062 一
行修订的专家，但在项目后期需要的会少一些-一除非环境是高度变更
的。通常可以采用 d些，通过培训能够完成程序性的方法步骤的人员。
清晰的政策和规程定义人们的角色，使人们感到舒适、有权利(靠秩序繁荣)。
参考文献:
[1] Kent Beck.解析极限编程→一拥抱变化[M].唐东铭，译.北京:人
民邮电出版社，2002.
[2] Alìstaìr Cockburn.敏捷软件开发[M].俞涓，译.北京:人民邮政出
版社，2003.
[3] 卡内基梅隆大学软件工程研究所.能力成熟度模型(CMM):软
件过程改进指南[M].刘孟仁，译.北京:电子工业出版社，200 1.
[4] 张海藩.软件工程导论[M].4版.北京:清华大学出版社，2003.
[5] B町 Boehm， Richard Turne.平衡敏捷和规范[M].邓辉，孙鸣，
译.北京:清华大学出版社，2005.
[6] 雷剑文，陈振冲，李明树超越传统的软件开发→-极限编程的
幻象与真实[M].北京:电子工业出版社，2005.
[7] Roger S Pressman.软件工程z实践者的研究方法[M].梅宏，译.
5 版.北京:机械工业出版社，2002.
[8] KentBeck,Martìn Fow1er.规划极限编程[M].曹济，译北京:人民
邮电出版社，2002.
