敏捷软件开发与计划驱动开发的概述比较

2018-07-31 09:53:44

0 引 言

敏捷软件开发的核心是在项目管理中运用“轻但够用”的 原则,及以人为本和以沟通为中心的原则。敏捷宣言定义了 敏捷的价值体系。敏捷软件开发实例包括极限编程 (extreme programming,XP)、自适应软件开发(adaptive software development,ASD)、Crystal、Scrum、特性驱动编程(feature-driven development,FDD)。极限编程是敏捷软件开发中最突出的实例。计 划驱动的方法被认为是传统的软件设计开发方法。基于一些 来自传统工程领域的概念,这些方法使用一些标准的、定义良 好的、组织持续改进的过程,以一种需求/设计/构建的模式进 行开发。计划驱动开发的实例包括军用标准、通用过程标准、 软件工厂、净室、软件能力成熟度模型(SW-CMM)、CMM 集成 (CMMI)、个体软件工程(PSP)/团队软件过程(TSP)。重点介绍 能力成熟度模型,对敏捷软件开发与计划驱动开发进行比较。

1 敏捷软件开发

2001 年 2 月,在美国犹他州的雪鸟城,17 位业界专家聚 在一起概括出了一些可以让软件开发团队具有快速工作、响 应变化能力的价值观和原则。这次会议形成了敏捷软件开发 运动,创建了敏捷联盟。会议的结果是 17 名与会者签署了“敏 捷软件开发宣言”(敏捷联盟诞生于 2001 年,但其各种方法和 研究这些方法的人的历史可追溯到 10~15 年前,Fred Brooks在 20 世纪 50 年代中期就使用了结对编程)。

1.1 敏捷软件开发宣言

“我们通过亲身实践和帮助他人实践,找到了更好的软件 开发方法。在工作中我们得出以下观点:较之于过程和工具, 应更注重人及其交互的价值。较之于面面俱到的各类文挡, 应更注重可运行的软件的价值。较之于合同谈判,应更注重 与客户合作的价值。较之于遵循计划,应更注重响应需求变 化的价值。虽然左侧的观点是有价值的,但我们认为右侧的 观点更有价值。”

在敏捷宣言的价值陈述中,敏捷学家认为,右边项比左边 项更重要,但并不是说工具、过程、文档或合同等不重要。与 其使用有文档但交互中充满敌意的过程,还不如使用没有文 档,而有良好交互的过程。文档非常有用,但对它们采用“刚好足够”、“恰好充分”的原则,尽管合同有时会有用,但无论有 没有合同,协作都会巩固开发。制定计划是有用的,每种敏捷 软件开发方法论都包含明确的制定计划活动,也包含处理优 先级变化的机制。

1.2 敏捷软件开发的原则

12 个详细原则组成了上述 4 个观点,是区别于重型过程 的特征所在:①最高优先级是通过尽早和经常交付有价值的 软件来令客户满意;②不断地交付软件,以每两周或每两个月 为周期,推荐使用较短的周期;③可运行的软件是工作进展的 主要度量标准;④以积极的态度对待需求的变化,即使在开发 阶段末期也不例外。敏捷过程利用变化来为客户创造竞争优 势;⑤在整个开发过程中,业务人员和开发人员最好能每天一 起工作;⑥项目由积极主动的人员来完成,给他们提供所需的 环境和支持,信任他们能把工作做好;⑦在开发团队中,最具有 效果和最有效率的信息交流手段是面对面的交谈;⑧最好的系 统构架、需求和设计产生于自组织的团队;⑨应时刻关注技术 上的精益求精和合理的设计,这样可以提高应变能力; 敏捷过 程提倡可持续开发思想。出资人、开发者、用户应该保持长期、恒 定的开发速度; 简单化——最佳化未完成的工作的艺术—— 是至关重要的; 团队应该定期对其运作方法进行反思,考虑 如何能变得更有效,提出改进意见,并据此进行相应的调整。 2 极限编程 20 世纪 90 年代初,克莱斯勒公司的薪资服务部门和信息 服务部门决定采用新的统一系统来取代老系统。1996 年,克 莱斯勒邀请 Kent Beck 作为顾问,指导这个已陷于困境的 C3 项目。为了解决这个问题,在 1996 年到 1999 年间,Beck、Cunningham、Jeffries等人构建了现在被称为极限编程的基本元素。 极限编程是敏捷软件开发中最著名的一个,是一种针对 业务和软件开发,将两者力量集中在共同的、可以达到的目标 上。它是一种轻量、高效、低风险、柔性的软件开发方式,由一 系列简单却互相依赖的实践组成。

(1) 极限编程的 12 个实践:①计划游戏:通过结合使用业 务优先级和技术评估来快速确定下一个版本的范围。当计划 赶不上实际变化时,就应更新计划;②小版本:将一个简单系 统迅速投产,然后以很短的周期发布新版本;③隐喻:用有关 整个系统如何运行的简单、众所周知的故事来指导所有开 发;④简单设计:任何时候都应当将系统设计得尽可能简单, 不必要的复杂性一旦被发现就马上去掉;⑤测试:程序员不断 地编写单元测试,在这些测试能够无误地运行的情况下,开发 才可以继续。客户编写测试证明各功能已经完成;⑥重构:程 序员重新构造系统(而不更改其行为)以去除重复、改善沟通、 简化或提高柔性;⑦结对编程:所有的生产代码都是由两个程 序员在同一台计算机上编写的;⑧集体所有权:任何人在任何 时候都可以在系统中的任何位置更改任何代码;⑨持续集成: 每天多次集成和生成系统,每次都完成一项任务; 每周工作 40 小时:一般情况下,一周工作不超过 40 小时,不要连续两个 星期都加班; 现场客户:在团队中加入一位真正的、起作用 的客户,他将全职负责回答问题; 编码标准:程序员依照强 调通过代码沟通的规则来编写所有代码;

(2)极限编程的 4 个变量:成本、时间、质量、范围(客户、管 理人员确定任意 3 个变量的值,开发团队确定第 4 个变量的 值)。其中范围的控制最有价值。

(3)极限编程的 4 个准则:沟通、简单、反馈、勇气。 (4)极限编程的基本原则:快速反馈、假设简单性、递增更 改、提倡更改、优质工作。 (5)极限编程开发软件的 4 项基本工作是:编码、测试、倾 听和设计。 极限编程的实践、准则、原则和工作之间的关系是:原则 来自于准则;而原则和准则又都是以 12 个实践为基础的;12 个实践关联着开发软件的 4 项基本工作。极限编程实践提供 了对实际操作的指导。 3 计划驱动开发 计划驱动开发起源于系统工程和质量规范,建立系统工 程的原则,协调大量需要精确协同工作的组件。 通过从需求到已完成的代码等一系列代表物来推动软件 开发的过程,计划驱动开发非常精确地依赖于明确的步骤。典 型地,瀑布模型,软件开发周期划分成若干个阶段:问题定义、 可行性研究、需求分析、总体设计、详细设计、编码与单元测 试、综合测试、软件维护,各阶段的工作自顶向下,从抽象到具 体顺序进行,每个阶段都必须完成规定的文档,只有前一阶段 的输出文档正确,后一阶段的工作才能获得正确的结果,就好 像奔流不息的瀑布,从概念直到最终产品。 计划驱动开发的关键是过程的定义和管理,和过程改进 联系在一起,强势在于标准化所带来的可比较性和可重复性。 过程需要进行定义、标准化并需要逐步改进以提供控制、管理 其操作所需的数据。定义过程执行的方法,和工作产品形式 化的方法,对过程的实施者进行良好的培训。需要管理层的 支持、组织化的基础设施以及良好的环境。