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]