Agile方法研究综述

Agile方法研究综述

摘 要: 本文综述了近来新出现的Agile方法，对其应用范围、价值系统、核心实践给出了阐述，并介绍了XP、SCRUM、Crystal等主要的Agile方法及其发展趋势，在此基础上，给出了CMM与Agile方法之间的比较分析，最后提出了Agile方法待研究的问题。

关键词 Agile方法，轻载方法，CMM，XP

AN OVERVIEW OF AGILE METHODOLOGY

Abstract :Agile Methodology attempts a useful compromise between no process and too much process, i.e., "Just enough". Given in this paper is an overview of agile methodology and its trends, including XP, SCRUM, Crystal, FDD, ASD, etc.. Also given are application scope, value system, core principles, and key practices of agile methodology. Based on the above survey and analysis, a comparison between CMM and agile methodology is presented，and several issues need further research are pointed out.

Key words Agile Methodology, Lightweight Methodology, CMM, XP

1. 引言
质量和生产率是软件工程的两个核心目标，这两个目标相互作用相互影响，在具体的软件开发实施中要作具体的权衡。随着技术的迅速发展和经济的全球化，软件开发出现了新的特点，即在需求和技术不断变化的情况下实现快节奏的软件开发，这就对生产率提出了很高的要求。ISO-9000、CMM、SPICE目前已被公认为软件质量保障方面的事实标准，但由于其强调管理和控制，追求项目的可预测性和过程状态的可视性，在提高生产率方面并未予以足够的重视，实施时一方面需要大量中间制品（过程文档）的制作，给开发人员带来很大负担，另一方面，追求可预测性与实际需求的模糊和快速变化不相协调。在此情况下，出现了一些新的开发方法。
新的方法主要有Extreme Programming (简称XP)、SCRUM、Crystal Methodologies、Feature Driven Development(简称FDD)、Dynamic Systems Development Methodology(简称DSDM) 、Adaptive Software Development(简称ASD)、Pragmatic Programming等，统称轻载（Lightweight）方法，以区别于传统的开发方法（称重载方法，Heavyweight）。2001年2月，新方法的一些创始人在美国犹他州成立了Agile 联盟,将轻载方法正式更名为Agile方法，Agile有轻巧、机敏、活力的意思[1]。
Agile 方法目前还没有一个明确的定义，其特点是对软件生产率的高度重视，主要适用于需求模糊或快速变化下的、小型项目组的开发。有人称，Agile方法是在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，笼统的讲就是，"刚刚好"（Just enough），即开发中的活动及制品既不要太多也不要太少，在满足所需的软件质量要求的前提下，力求提高开发效率。
这些新方法提出后，引起了软件界的广泛重视，Tom Demarco认为（Cutter Trends Report），"XP对当今时代的作用可与CMM在八十年代和九十年代初的作用相媲美"。新方法在实践中也得到了巨大的成功，如IONA公司的Obix 技术支持小组在采用了XP方法后，软件生产率提高了67%[7]；软件生产率组织（SPG）的Capers Jones则称，SCRUM方法可提高生产率6倍[13]。
2. Agile方法的核心理念及特点
任何软件开发方法都有一个相应的价值系统(Value system)，方法通过价值系统对过程加以指导，方法只有在其应用周境（context）与价值系统相吻合时才能发挥真正效力，价值系统的基础是对世界的信仰和对软件开发特点的认识，可以说是核心理念。
Agile方法的代表人之一Martin Fowler提出了Agile方法的核心理念[2]：适应和以人为本[2]。
2.1 Agile方法基于适应而非预测。
人们不可能在软件开发之前准确地把握当时的需求及其之后的走势，这一点已由Peter Wegner用数学的方法给出了严格的证明[27,28]。设想有一个虚拟的"理想软件"，它是对用户的最大满足，并能随时间的推移和形势变化而与现实保持即时同步，那么软件需求实质上是对"理想软件"的粗略的外部描述。理论上来说，软件开发应是一个跟踪过程,只能通过软件开发过程的自适应性来逼? quot;理想软件"，不可能完全实现。
根据自动控制理论，自适应系统是一个强反馈系统。在软件开发中，需求的获取和分析、软件设计、编码等实质上均为前馈环节，真正的反馈环节应该是用户对可运行软件的使用、使用中与"理想软件"的比较判断及判断后与开发人员的信息交流。另外，控制理论还要求，反馈和前馈这一回路的响应速度应大于被跟踪（或被适应）的系统的变化速度，这就要求软件开发有快速的产出能力。
基于适应性特点，Agile方法通过快速、短迭代式的开发，不断产出和演化可运行软件，加强项目有关人员的信息交流等手段来提高反馈的速度、力度和准确性。在软件过程改进方面，Agile方法通过对实际反馈信息的度量，根据用户满意度（时间和质量的权衡）进行微调，相当于缺陷驱动的改进方式。
2.2 Agile方法是以人为导向而非过程导向。
软件开发中，人的因素是第一位的。人是过程的主体，而人的工作承受力是有限的，任何超出人正常承受力的过程必然导致过程结果的偏离，这一点在注重过程改进的方法中往往被忽视或低估。Agile方法认为，软件开发中的绝大部分是需要创造力的设计工作，软件人员是创造性的工作者，有主观上做好工作的意愿，不同于大工业时代生产流水线上被动性的工人，因此，在管理理念上应注重领导和协作，而非命令和控制，充分发挥软件人员的能动性和创造力。软件开发应首先着眼于有用的可执行的软件，也就是首先考虑商务目标，而不是为过程而过程。
Agile方法特别强调软件开发中相关人员间信息交流，Alistir Cockburn在对数十个项目案例调查分析后提出，"项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人"，而人特别擅长面对面的交流，cockburn认为面对面交流的成本要远远低于文档交流的成本，因此，Agile方法的一个共同特点就是，努力营造诚信、开放的组织氛围，根据项目中信息流通的具体情况，按高内聚、松耦合的原则将项目组划分为若干个小组（每个小组以不超过10人为宜，组员均在一个工作间内工作），通过小组内各种渠道的沟通，来减少中间制品的工作负担，提高应变能力。

2.3 Agile方法中的价值系统和指导原则
Agile联盟提出了"四个价值"、"十二个指导原则"[1]。
Agile方法的四个价值：
（1） 较之于过程和工具，更注重人及其相互作用的价值。
（2） 较之于无所不及的各类文档，更注重可运行的软件的价值。
（3） 较之于合同谈判，更注重与客户合作的价值。
（4） 较之于按计划行事，更注重响应需求变化的价值。
Agile方法的指导原则：
（1） 在快速不断地交付用户可运行软件的过程中，将使用户满意放在第一位。
（2） 以积极的态度对待需求的变化（不管该变化出现在开发早期还是后期）。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。
（3） 以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。
（4） 在项目过程中，业务人员和开发人员最好能一起工作。
（5） 以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任。
（6） 在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。
（7） 项目进度度量的首要依据是可运行的软件。
（8） Agile过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。
（9） 应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力。
（10） 简单化（尽可能减少不必要工作的艺术）是基本原则。
（11） 最好的框架结构、需求和设计产生于自组织的项目组。
（12） 项目组要定期对其运作方面进行反思，提出改进意见，并相应进行细调。
此外，Agile方法实施中一般采用面向对象技术（接口定义良好的其它开发技术也可），另外还强调在开发中要有足够的工具（如配置管理工具、建模工具等）支持。
2.4 Agile方法的适用范围[2]
Martin Fowler认为，新方法不是到处可适用的。在以下情况下，适合采用Agile方法：
l 需求不确定和易挥发（Volatile,意指今天的要求明天就不需要了）的场合。
l 有责任感和积极向上的开发人员 。
l 用户容易沟通并能参与。
在以下情况下，不适合Agile方法：
l 超过50人的项目组
l 开发范围被限定（如由合同限定了价格）

3. Agile具体方法介绍
Agile方法是一组开发方法的统称，下面介绍几个典型的Agile开发方法。
3.1 XP（Extreme Programming）[3～9]
由Kent Beck提出，是Agile方法中最引人注目的一个，名称中Extreme的含义是将好的开发实践（Practices）运用到极致。XP最初实践于 1997年Crysler公司的C3项目（人员薪金管理），采用Smalltalk语言开发。适用于10人以下项目组、开发地点集中的场合，现已成为小组开发方法的一个典型，被业界广泛用于需求模糊和挥发性强的场合。XP基于四个价值(values)提出了十二个核心实践（Practices）。
3.1.1 XP方法的四个价值:
l 交流（Communication）。项目相关人员之间充分、多渠道（最好面对面）的沟通。
l 简化（Simplicity）。在系统可运转的前提下，做最简洁的工作；在开发中不断优化设计，时刻保持代码简洁、无冗余。
l 反馈（Feedback）。强调各种形式的反馈，如小交付、短迭代、先考虑测试再编码等。
l 胆识（Courage）。面对压力做正确的判断并敢于付诸行动，如，敢于丢弃设计不良的代码，疲惫时立即休息等。
3.1.2 XP方法的十二个核心实践：
l 工作团队（Whole Team）。所有的小组成员应在同一个工作地点工作。成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开发优先级，把握开发的动向。通常还设一?quot;教练"（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表，充分贡献自己的技能。
l 计划（Planning Game）。包括两类：交付计划和迭代（Iteration）计划，前者是在项目开始时对软件交付日期的粗略估计，后者是在每个迭代开始时对本次迭代的工作安排。二者都可在执行时调整，只不过迭代计划要更为具体和准确。
l 系统比拟（Metaphor）。系统比拟是待开发软件系统的一个形象化比喻，这个比喻必须是每个组员都熟悉的，它相当于一个粗略的软件体系结构（Architecture），使用户和开发人员建立一个一致的框架，从而指导开发的进行。
l 小交付（Small release）。经常交付可运行的、具有商业价值的小软件，供用户代表评估或最终使用。这里的"小"意味着软件模块能尽快（可在一个迭代内完成）、不断地交付。
l 测试（testing）。XP要求先开发测试用例(可自动执行)然后进行编码（testing then coding），而且测试要不断进行，保证代码测试要100%通过。分两种测试：单元测试和验收测试(Acceptance test)。单元测试由开发人员负责，验收测试由用户代表负责。
l 简洁设计（Simple Design）。有两个含义：一是设计只考虑当前定义的功能而不考虑以后需求的变化，二是指该设计是完成目前功能所需的最简洁的设计，要简单易懂、没有冗余。
l 结对开发（Pair Programming）。开发人员两人结一对，在一台机器前进行开发，一人打字编程另一人查看其编码，配对的两人是不固定的，建议每天轮换。
l 设计改进（Design Improvement）。在整个开发过程中，应对程序结构进行持续不断的梳理（Refactoring，在不影响程序的外部可见行为的情况下，按高内聚松耦合的原则对程序内部结构进行改进）, 保持代码简洁、无冗余。
l 持续集成（Continuous Integration）。保持项目组中所有开发的模块始终是组装完毕、集成良好且可执行的，一旦新的模块通过了单元测试，应立即将其组装、集成，形成新的可执行系统。
l 代码共享（Collective code Ownership）。任何结对开发者在任何时候都可改进项目组中的任何代码。
l 编码标准（Coding Standard）。对编程风格（命名、注释、格式等）要有一个大家认可的、共同遵守的标准，使整个程序如同一人编写。
l 可持续步调（Sustainable Pace）。整个项目的开发节奏应该是可长期维持的，XP提出每周40小时工作制，即不要加班，以使开发人员能长期保持工作的高效率。

3.1.3 XP开发过程：
l 整体开发过程
如图1所示，用户代表提出用户故事（User stories，类似于用例，但更简单，不超过三句话即可，一般只涉及功能要求），项目组据此进行讨论提出系统比拟，在此活动中有可能要进行体系结构的刺探（Spike,意在试探解决有关技术难点，走通技术路线）。在系统比拟和用户故事的基础上，根据用户设定的优先级制订交付计划（制订计划中可能需要对某个技术难点进行刺探），然后开始多个迭代过程（每个迭代一般为1~3周），在迭代期内产生的新用户故事不在本迭代内解决，以保证开发不受干扰。经验收测试通过后交付使用。
l 迭代过程
如图2所示。根据交付计划和项目速率（Project velocity,实际开发时间和估计时间的比率，如估计1天完成的工作实际为2天，项目速率为2），选择要优先完成的用户故事或待消除的Bugs，将其分解为可在1~2天内完成的任务，制定本次迭代计划，然后通过每天的站立会议（Stand up meeting,参加人员站着开会以缩短时间/提高效率）解决碰到的问题、调整迭代计划，会后是代码共享式的开发工作，开发人员要确保新功能100%通过单元测试，并立即组装形成新的可运行版本，由用户代表进行验收测试。
l 代码共享的编程
如图3所示。

3.1.4 XP的实践和发展 XP方法引起了世界各地广泛的注意，越来越多的项目组采用或正考虑采用XP方法。2001年7月，在美国北卡莱罗纳州举行了XP国际研讨会，会议上SEI、IBM、SAS等知名机构的专家作了专题演讲，表明了XP的活跃程度。 对XP 的批评主要有两个：一是XP中的文档问题（几乎没有文档），对此Ron Jeffries的解释是，XP中的系统比拟、用户故事、和测试用例都是传统方法中的文档，另外，XP紧紧围绕用户代表展开，他可决定文档制作的程度；二是XP只强调共享与合作，另一个推动社会进步的因素-竞争并没有体现，为此许多XP的实践者对该方法作了一定程度的变通。 3.2 SCRUM方法[10～16] 由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM方法最初实践于Easel公司(1993年)，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发[11]。SCRUM提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master、SCRUM Team、Demo等模式已被PLOP作为组织和过程模式（Organizational and Process Pattern）的标准[12]。 SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程，因而可重复（Repeatable）执行并能产生预期的结果，并能通过科学理论对其最优化。经验性过程与之相反，应作为一个黑箱（Black box）来处理，通过对黑箱的输入输出不断进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，从而产生满意的输出。SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，充分发挥人的创造力。如将经验性过程按确定性过程来处理（如瀑布模型），必将使过程缺乏适应力。 3.2.1 SCRUM方法的开发过程 包括三个过程： (1) 计划和体系结构设计（确定性过程） 将Backlog（急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等）按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。 建立系统体系结构（如为已有系统改进，则只作有限分析、调整），将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个 Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组（SCRUM 小组）,分配各小组合适的Backlog项或问题包。建立开发运行环境。 (2) Sprint（经验性过程） 该过程由若干个迭代的冲刺(Sprint) 活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1~6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的 Backlog项并有可执行的产出）。 每个Sprint包含以下活动： l 开发。对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。 l 打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。 l 评审（Review）。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue)及难点（problem）, 增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。 l 调整（Adjust）。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。 (3) 交付和巩固（确定性过程） 一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。 SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。 3.2.2 SCRUM对过程的管理： (1) SCRUM的控制手段。 SCRUM提出了八个控制项（Controls）用于开发过程的调控，其中风险控制是首要的手段。 l Backlog。 l 对象/构件。 l Packets。 l 变动（Changes）。实施一个Backlog项时，对相应Packet的改动。 l 难点（Problems）。实施一个变动时所必须解决的技术难点。 l 问题（Issues）。涉及到整个项目或在Backlog项分解到Packet之前须解决的问题。 l 措施（Solutions）。对问题或难点的解决，通常会导致变动。 l 风险（Risks）。影响项目成功的风险，应持续跟踪评估并相应做出调整。风险评估的结果将影响其他所有控制项。SCRUM定义了六个概念性变量来用于风险评估：用户需求，时间压力，竞争，质量，远见（vision）和可用资源。 在SCRUM的各个阶段都使用这些控制项来评估和权衡，管理人员侧重于以此管理Backlog，开发组用以处理变动和难点。所有人员一起来管理问题、风险和措施。 根据对控制项特别是风险的不断度量评估和权衡，一方面，计划和进度（在每个Sprint结束时）不断相应调整，保证实现产品的商务目标；另一方面，对开发中的工作任务Backlog动态地进行优先级排序，开发组总是先开发优先级最高的Backlog项，这样就保证了资源的最合理使用。另外，SCRUM强调度量（采用标准功能点度量方法）的重要性，通过对每个Sprint中生产率等的度量，计划和进度将越来越趋于准确。 (2) 项目组织。 项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组： l 项目管理组。由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。 l 若干个SCRUM小组。各小组由组长（SCRUM Master）领衔。每个小组都是跨专业的（通常包括开发人员，文档人员，质量控制人员或用户代表等），通常为3~7人，以使小组内有充分的交流。小组的划分最好是功能导向的（按所分配的问题包或Backlog），也可是系统层次导向（按体系结构中的分层）。. 在项目组人数增大时，可在管理组之上再设管理组（SCRUM of SCRUM）,从而使SCRUM方法的应用到大项目中。 (3) Sprint期间的调控。 在Sprint期间，应使各SCRUM小组尽量避免外界的干扰（不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决），使小组成员专心于目前的工作，使他们工作在混沌的边沿。 为避免项目组在Sprint期间不陷入混乱，SCRUM采取两个措施: l SCRUM会议（SCRUM Meeting）。对小组行为进行监控和刺激。会议在Sprint期间每天在同一地点举行，由SCRUM Master主持。会议上，SCRUM Master对每个小组成员提三个问题： 1） 昨天的工作进展如何。 2） 有否遇到困难和障碍。 3） 今天的工作打算。 会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。 l Sprint评审会议。评审后根据对每人的工作成绩，进行相应的激励。 3.2.3 SCRUM方法的实践效果和发展方向： SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones称可提高6倍），在实施中有一个"间断平衡"（Punctuated equilibrium）现象（类似于自然界中物种的进化，在经过一段相对平衡的各自独立、并行的发展期后，在交汇处发生变异），即在经过紧张、并行的 Sprint开发后，在Sprint评审时，软件产品产生较剧烈的变化。SCRUM方法的最近动向是设法借鉴XP方法。 3.3 Crystal方法系列[17～21] 由Alistir Cockburn提出。与其它Agile方法的提出者不同，Cockburn的研究基于对IBM公司近四十个项目（这些项目有大有小，方法有轻载和重载，时间跨度为1980~1999年）案例的调查。他认为不同的项目需采用不同的开发方法，并随着开发的进行应不断细调（On-the-fly tuning）,也就是连续不断的过程改进。据此他提出了一系列方法（Crystal Clear、Crystal yellow、Crystal Orange、Crystal Red等，名称借自于自然界中的晶体，有透明的、黄色的、橙色的等）作为基本参照和一些原则来指导方法的调整。 Crystal方法系列的核心理念： 软件开发可视为创造和交流相协调的过程，其中人的因素是第一位的，软件开发的第一目标是交付有用的、可运行的软件，其次是保持开发工作的可延续性。 Crystal方法系列强调的价值： l 以人和沟通为中心。工具、中间制品、过程均是服务于人的。 l 高度宽容（High tolerance）。应该认识到人与人之间文化的差异。 Crystal方法系列的原则（principles）： l 通过经常产出可运行的代码、充分利用人与人之间的多种交流渠道，项目组可减少中间制品（如开发文档，进度计划等）的工作量。 l 由于每个项目有不同的情况并且其状态在不断变化，项目组内普遍接受的惯例和 约定应随之塑造和演化。 l 项目组人数越多，采用的方法应越重（需要更多的文档支持）。 l 对软件可靠性要求越高，则应采用越严格的过程纪律。 l 解决工作中的瓶颈则需工作的重叠，从而使非瓶颈性工作效率降低。 Crystal方法系列的共同规则(rules)： l 采用渐增迭代式开发，每个迭代不超过4个月。 l 在每个迭代的开发和结束时，必须进行评审、反思，并相应调整。 Crystal 方法的显著特点是对人的高度重视，认为人是一个非线形的、能动的、行为不连贯的（极易受外部影响而中断当前行为）、擅长交流（特别是面对面交流）的构件（Component）[21]，据此Crystal强调对方法的选择和调整要考虑两个因素，一是充分发挥考虑人的特长，二是满足待开发软件的可靠性要求。Crystal方法的选择如下图所示，坐标横轴是项目组人数，纵轴为软件可靠性要求（软件缺陷可能导致的后果）。Crystal Clear适用于项目组在6人以下，且该项目的疏漏不会造成直接经济损失的情况，依次类推Crystal yellow用于20人以下不造成人命损失的情况。 Crystal方法系列对具体的开发过程并没有严格的要求。它强调某个方法应有哪些角色及多少人参与、组织结构如何、迭代周期多长、应有哪些中间文档、采用哪些工具等。如Crystal Clear,用在6人左右的项目组（无下层小组），迭代周期应为2-3个月，角色应有项目资助者、高级设计开发员、设计开发员、用户，开发制品有：交付序列、进度安排、有注解的用例、设计纲要、通用对象模型、可执行代码、移植代码、测试用例、用户手册。 3.4 DSDM方法[26] 起源于英国，是一个工业联盟。由16家公司发起（1994年）并组成，最初的目的是开发一种更好的面向领域的快速应用开发（RAD）方法，现在会员已超出英国（美国、印度、德国、法国等），应用范围也不再限于IT行业。由于有良好的组织基础，它在技术支持、培训认证、应用推广、研究改进等方面都远比其他 Agile方法要完善的多。DSDM适用于时间要求紧的项目。 DSDM的基本观点是，任何事情都不可能一次性的圆满完成，应该用20%的时间完成 80%的有用功能，以适合商业目的为准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争需求的最大化满足（传统方法一般是需求固定，时间和资源可变）。具体做法是采用时间框（TimeBox，指项目计划进度中一个固定的时间段，有固定的完成时间，并被赋予一按优先级排序的用户需求集合，在结束时要求有可见的产出。时间框可以嵌套，即一个时间框可由一系列子时间框组成）技术和MoSCoW（Must dO， Should do， Could dO， Won't do）优先级排序方法，先提出项目的整体时间框,然后根据需求的细化提出一系列子时间框，依次类推直至子时间框被分解为2-6周的时间长度，在每个时间框内按MoSCoW优先级原则进行开发，这样就保证了在限定时间内完成最有用的功能需求。另外，DSDM通过工作间（Workshop，即将跨部门跨专业的人员组成小组，使他们在一个房间内工作，并合理安排布局以确保充分沟通）方法加强信息沟通，提高开发速度。 DSDM方法的基本原则： l 积极主动的用户参与。 l 赋予DSDM项目组充分的决策权。 l 强调经常性的产品提交（注重结果而非过程）。 l 以适合商业目标作为工作确认的首要衡量标准。 l 迭代和增量式的开发方法（不同于传统的瀑布型模型）。 l 开发中所有变化是可追朔的（reversible）。 l 基于软件需求提出的开发计划作为宏观进度控制的基线。 l 测试活动贯彻于软件开发周期的各个阶段。 l 强调所有项目相关人员的合作。 3.4.1 DSDM的开发过程 包括5个阶段，其中前两个阶段在时间上有顺序关系，是后续工作的基础和前提。后三个阶段在实施中视情况可交叉重叠或并行。 (1) 可行性研究（Feasibility Study） 确定DSDM方法是否适合于该项目的开发，检查项目实施的技术和管理条件是否满足。该过程一般在几周内完成。 (2) 商务研究（Business Study） 研究整个项目活动的范围，为进一步的开发提供业务和技术基础。根据功能和非功能需求设定开发进度基线，提出系统体系结构和可维护性目标。一般在一个月内完成。 (3) 功能模型迭代 该迭代主要侧重于系统商业方面的细化，构造高级（high-level）的功能和技术方面的需求。与设计与构造迭代类似，主要有四个活动： l 标识要开发的功能需求。 l 讨论决定如何做和何时完成。 l 产品开发。 l 评审。 采用演化的原型法辅助需求分析，目标是通过本迭代和设计与构造迭代，形成经过测试的系统。所有DSDM中的原型都是被用来继续演化的，因此应充分考虑其健壮性。 (4) 设计与构造迭代 该迭代主要侧重于用户可用的、高标准的、经过测试的系统。通过对功能模型迭代中的原型进行增量开发，形成可用的系统。 (5) 实施 将设计与构造迭代中形成的软件系统从开发环境转移到运行环境，进行必要的用户的培训和系统移交，整理项目评审文档，检查所有的需求情况，总结项目的产出，对项目的整体完成程度进行评审。由于采用渐增式开发，评审可能有几种结果： l 所有需求都完成并交付，无需后续开发。 l 开发中发现了新的功能区域。开发转至商务研究阶段。 l 由于时间限制，一些非重要功能在开发中忽略。将其提交功能模型迭代阶段。 l 非功能性需求未能满足。开发转至设计与构造阶段去调整。 3.5 FDD（Feature Driven Development）[22，23] 由Jeff de Luca 和Peter Coad提出，是一个模型驱动、短迭代的开发方法，适用于变化周期短的业务应用开发。所谓的特征点（Feature）是一些用户眼中有用的小功能项，一个特征点能在两周或更短的时间内被实施,且产生可见的、能运行的

 http://www.trucy.org/blog/fanghong/archives/2006/07/agilenueoe.html