软件开发-在瀑布式项目中实现敏捷开发.docx

在瀑布式项目中实现敏捷开发 尽管一个大型项目整体很好地遵循着一个瀑布模型，但该项目的应用程序开发团队希望改用敏捷开发。开发人员曾讨论过要让项目全面地改用敏捷模型，但最终决定只使敏捷开发作为项目的一部分、适当地融入到整体瀑布式结构中。最后，该团队实现了更优异的质量、更多可交付成果以及更高的开发效率。这一成功使得他们在整个项目范围内提倡敏捷理念，并且得到越来越多的支持，最终让所有参与团队都信任敏捷开发。 本文来自于? HYPERLINK /developerworks/cn/websphere/techjournal/ IBM WebSphere Developer Technical Journal。 HYPERLINK /developerworks/cn/websphere/techjournal/0907_hines/0907_hines.html \l authorN1001C Liz Hines, 程序主管, IBM HYPERLINK /developerworks/cn/websphere/techjournal/0907_hines/0907_hines.html \l authorN1002E Scott Baldwin, ScrumMaster 和软件工程师, IBM HYPERLINK /developerworks/cn/websphere/techjournal/0907_hines/0907_hines.html \l authorN10040 Mark Giles, 开发经理, IBM HYPERLINK /developerworks/cn/websphere/techjournal/0907_hines/0907_hines.html \l authorN10052 Juan Peralta, 开发项目经理, IBM 2009 年 9 月 24 日 简介 瀑布式项目方法在许多组织中都确立了十分牢固的地位，于是编写代码的开发团队通常没有权力做出 “迁移到敏捷流程” 这一决策。在涉及到数个组织的大型项目中，情况尤是如此。 虽然已有提议让最近的一个重点项目采用敏捷开发，但在负责项目中关键应用程序之一的开发团队没有决定更进一步、将敏捷方法应用到他们所控制的那部分项目中之前，这些提议没能得到进展。采用敏捷开发这一决策所产生的成果证明了敏捷开发的价值和益处，更重要的项目管理团队在整体项目环境中可理解并欣赏这种价值和益处。 本文介绍了开发团队如何在较大型的瀑布式项目中成功地实现敏捷开发。本示例包含所执行的概念和技巧、所面临的挑战以及所产生的益处，可帮助您寻找到类似的有用方法，利用这种方法您可将敏捷概念和流程介绍到您的组织中。 本文假定您熟悉基本项目管理、敏捷开发概念和术语。 项目背景 作为本案例研究之对象的特定应用程序，是一款现有的由一个全球销售团队使用的销售合同应用程序。此应用程序已面世数年，通常每年都发布 3 到 4 个主要或次要版本。此应用程序的客户群很大而且多样化，包括 3,000 名超级用户，以及数千名临时用户。 这一正在进行中的项目由 CIO 办公室管理，解决方案领导代表了客户。项目团队整体中的各种成员 —— 用户、设计师、架构师、开发人员、测试人员、生产操作人员等等 —— 来自公司内的不同组织。 此瀑布式项目的整合开发流程包含以下阶段： 制定概念前 制定概念 计划 开发 验证 首次展示 在制定概念前阶段，开发团队提供粗数量级 (ROM) 的提议发布内容和（未确定的）目标日期。在制定概念阶段，客户为所发布内容的候选列表排列优先级，创建并审查业务需求和系统需求，开发团队还提供业务需求 (BR) 和系统需求的 (SR) 的影响等级 (LOE)。在计划阶段，SR 候选列表会确定，而且开发团队会对这些需求确立初步的规模估计。 对此项目而言，典型的计划如下所示： 制定概念阶段：2 个月 计划阶段：2 个月 开发阶段：6 周 验证阶段：6 周 在这些阶段（甚至是为期 6 周的开发阶段）中，客户要求 (CWN)、BR、SR 以及最后的更改请求的候选列表将持续更新并重新划分优先级。 就应用程序中所使用的技术而论，它构建于一个面向服务架构 (SOA) 平台之上，利用了 IBM? WebSphere? Process Server V、IBM WebSphere Portal V6.1 和 IBM DB2? 9.1.6 的高可用性功能。该应用程序利用 Web 服务以与公司内部其他应用程序相整合。此外，利用了 WebSphere Process Server 技术来管理业务规则和过程工作流。与其他内部应用程序的需求和版本发布计划相协调，可降低项目应用程序版本发布的规划和安排的复杂性。 为什么要使瀑布式项目变得敏