|
尽管一个大型项目整体很好地遵循着一个瀑布模型，但该项目的应用程序开发团队希望改用敏捷开发。开发人员曾讨论过要让项目全面地改用敏捷模型，但最终决定只使敏捷开发作为项目的一部分、适当地融入到整体瀑布式结构中。最后，该团队实现了更优异的质量、更多可交付成果以及更高的开发效率。这一成功使得他们在整个项目范围内提倡敏捷理念，并且得到越来越多的支持，最终让所有参与团队都信任敏捷开发。
瀑布式项目方法在许多组织中都确立了十分牢固的地位，于是编写代码的开发团队通常没有权力做出 “迁移到敏捷流程”
这一决策。在涉及到数个组织的大型项目中，情况尤是如此。
虽然已有提议让最近的一个重点项目采用敏捷开发，但在负责项目中关键应用程序之一的开发团队没有决定更进一步、将敏捷方法应用到他们所控制的那部分项目中之前，这些提议没能得到进展。采用敏捷开发这一决策所产生的成果证明了敏捷开发的价值和益处，更重要的项目管理团队在整体项目环境中可理解并欣赏这种价值和益处。
本文介绍了开发团队如何在较大型的瀑布式项目中成功地实现敏捷开发。本示例包含所执行的概念和技巧、所面临的挑战以及所产生的益处，可帮助您寻找到类似的有用方法，利用这种方法您可将敏捷概念和流程介绍到您的组织中。
本文假定您熟悉基本项目管理、敏捷开发概念和术语。
作为本案例研究之对象的特定应用程序，是一款现有的由一个全球销售团队使用的销售合同应用程序。此应用程序已面世数年，通常每年都发布
3 到 4 个主要或次要版本。此应用程序的客户群很大而且多样化，包括 3,000 名超级用户，以及数千名临时用户。
这一正在进行中的项目由 CIO 办公室管理，解决方案领导代表了客户。项目团队整体中的各种成员 —— 用户、设计师、架构师、开发人员、测试人员、生产操作人员等等
—— 来自公司内的不同组织。
此瀑布式项目的整合开发流程包含以下阶段：
在制定概念前阶段，开发团队提供粗数量级 (ROM) 的提议发布内容和（未确定的）目标日期。在制定概念阶段，客户为所发布内容的候选列表排列优先级，创建并审查业务需求和系统需求，开发团队还提供业务需求
(BR) 和系统需求的 (SR) 的影响等级 (LOE)。在计划阶段，SR 候选列表会确定，而且开发团队会对这些需求确立初步的规模估计。
对此项目而言，典型的计划如下所示：
- 制定概念阶段：2 个月
- 计划阶段：2 个月
- 开发阶段：6 周
- 验证阶段：6 周
在这些阶段（甚至是为期 6 周的开发阶段）中，客户要求 (CWN)、BR、SR 以及最后的更改请求的候选列表将持续更新并重新划分优先级。
就应用程序中所使用的技术而论，它构建于一个面向服务架构 (SOA) 平台之上，利用了 IBM®
WebSphere® Process Server V6.0.2.4、IBM WebSphere
Portal V6.1 和 IBM DB2® 9.1.6 的高可用性功能。该应用程序利用 Web
服务以与公司内部其他应用程序相整合。此外，利用了 WebSphere Process Server 技术来管理业务规则和过程工作流。与其他内部应用程序的需求和版本发布计划相协调，可降低项目应用程序版本发布的规划和安排的复杂性。
此应用程序每次发布典型版本，都将大量时间（长达 7 个月的周期中的 4 个月）消耗在制定概念和计划阶段。尽管这样，需求依然会变化。开发团队决定寻求一种敏捷方法，因为敏捷方法可适应业务优先级和需求的变化，并在项目进展时适应开发重构。这种方法将使开发团队能够减少制定概念和计划阶段的大量时间，将更多时间用于开发阶段，并且将重点放在交付更多功能和更高质量上。
由于部署窗口和参与验收测试的有效用户是有限的，所以部署日期也受到限制，而且通常在制定概念阶段早期就确定了。冗长的计划和再计划通常导致开发阶段缩短，于是开发阶段会持续混乱并必然延迟。在开发阶段频繁改变发布优先级并不会起到帮助作用。
开发团队的一个主要目标是采用更好的开发流程，来控制因外部影响（后期需求、不断变化的需求等）和自有的不良流程（不完全的开发流程、低下的代码质量等）而引起的混乱。采用敏捷方法可改变他们的开发文化，使其获得流程的控制权。
除此之外，开发团队还意识到敏捷方法的其他益处：更佳的质量、更快的实现以及更高的客户满意度。他们还相信，如果他们能够推进敏捷流程，他们将有动力说服更大的项目整体改用敏捷方法。他们获得的教训帮助他们制作出其工具和流程的任何操作指南，并加快向敏捷流程的最终转变。
在项目最初开始时，开发团队尝试了采用一些（而不是全部）Scrum
框架 的概念，Scrum 框架是一种基于经验流程控制理论的敏捷流程，它关注透明度、审查以及适应。该团队实现了日常站立短会和
burndown 图表，但选择不采用组件来支持审查，例如 sprint
计划、sprint 审查和回顾会议 (retrospective meeting)。
当项目进展到瀑布验证阶段 —— 在此阶段中开发团队需要处理持续的一串流程来测试缺陷 —— 团队的 scrum
流程就结束了。当下一版本的开发阶段开始时，他们必须再次启动 scrum 流程。从根本上讲，初次尝试 Scrum
而失败是没有采用审查流程的结果；这一教训在之后的 Scrum 工作中对团队起到了帮助作用。
在更近期版本的开发阶段，开发团队决定改弦更张，引入以 Scrum 概念和特征为基础的完整敏捷流程。该团队坚决进行
sprint 计划、sprint 审查和回顾会议。更重要的是，他们致力于执行审查与自我治理。
- 角色
为全面采用 Scrum 工作方式，团队必须确定 scrum 团队中的哪些成员将担任 3 个必要角色，即产品负责人
(Product Owner)、项目经理 (ScrumMaster) 和
团队 (Team)。最初，开发项目经理担当主要产品负责人的身份。该团队由现有开发团队成员组成。被选定的
ScrumMaster 确立了周期为 3 到 4 周的 sprint 日程表， 以及不一定要与瀑布流程里程碑一致的起止日期；团队认识到，计划中的
sprint 会议与瀑布里程碑太近，会导致团队重心转移到两个事件之一之上，而不能兼顾，那么被忽视的事件会产生不利的结果。
- 待办事项
在 sprint 计划会议上，开发团队首先要讨论的是，客户（在制定概念和计划阶段）已针对应用程序未来版本而鉴定出的候选产品待办事项。产品负责人挑选出这些项目的一个子集，包含考虑在
sprint 中解决的可能产品待办事项。在 sprint 计划会议中，开发团队研究他们相信自己可在
sprint 中完成的产品待办事项，从中整理出 sprint 待办事项。这些待办事项就是团队要在
sprint 过程中实际处理的任务、任务评估和分配。
- 审查
在每个 sprint 的末尾，开发团队要举行一个 sprint 审查会议。此会议的目的是向 stakeholders
说明 sprint 中的成果，并为涉众提供适时的机会来评论和提问，这可能生成一份期望修改列表。这些修改和任何缺失的或错误的功能都添加到下一次
sprint 的产品待办事项中。
- 回顾
在每个 sprint 的末尾，开发团队还要举行一个 sprint 回顾会议，来回顾
sprint 中良好的部分和可以改进的部分。基于此反馈，他们可以适当修改流程，以及向产品待办事项追加非功能性操作项。
- 计划
典型的计划是在 sprint 结束时的同一天举行 sprint 审查和 sprint 回顾会议，接下来的第二天就举行下一个
sprint 的 sprint 计划会议。这些会议在 Scrum 时间盒指导方针下进行。
- 参与者
客户代表 (解决方案领导者) 会参与 sprint 计划和 sprint 审查会议。最初，客户的利益由开发项目经理代表，但在之后的
sprint 中，开发团队能够使解决方案领导者介入，通过这些关键参与者获取直接的客户输入和反馈。这种方法目的很明显；团队希望良好地理解流程与方法，然后再扩大参与者圈子，让解决方案领导者加入。
- 用户案例
开发团队还在计划中采用了用户。虽然客户代表（解决方案领导者）应当负责创建用户案例，但开发团队根据现有需求为之代劳了，因为更大的项目尚未使用敏捷流程。然后该团队让解决方案领导者参与验证用户案例，合作改进案例并更好地理解需求。这一实践极大程度地改善了对需求的理解和需求的准确度，并且显著减少了实行之后的返工。
- 质量保证
开发团队曾长期使用连续累计，但他们最近将自动测试引入到了开发流程中。直到自动测试可用并且融合到测试工具中，才能认为工作项是完整的。每日构建和自动测试可确保在代码签入时不破坏编码基数。这会生成高质量代码，并减少验证阶段中将发现的缺陷。直到功能可以在活动服务器上验证，才能认为编码项是完整的。例如新流程或文档等非编码项，发表在开发团队的内部
wiki 上，并分发给团队，以便在完整呈现于 sprint 审查会议上之前先进行审查。
因为开发团队依照严格瀑布式流程而运作，所以他们不能全方面采用敏捷开发。团队仍然履行一个需求周期，以将
CWN 细化为 BR 和 SR、划分优先级、ROM、LOE 和初步规模估计、添加新需求，以及重复地循环。
开发团队能够在需求周期中促成一些改进；例如，他们能够处理由客户代表核对过的优先列表，能够在需求周期中根据不同要点筛分用户案例，从而构建候选作用域列表以供客户审查。团队利用了
Scrum 流程来处理这种活动，针对需求周期生成了必要的工作产品，最终减少了开发阶段可怕的需求混杂。
如果项目完全改用敏捷流程，用户案例有希望在周期之初就确立，优先级的划分有希望限于 1 或 2 个周期中完成，而且更多时间有希望用在开发阶段。敏捷采用的这种状态可支持与客户一起审查已实现的特性，并且根据客户反馈来更新功能，而不是在文件上多次重新修改不同等级的需求。
开发团队没有完全依靠 sprint 待办事项和 burndown 图表工具来分配和跟踪工作，而是使用了一个传统的
Microsoft® Project 计划来在开发阶段安排任务。这种做的理由有很多。首先，这向客户证明了分配给此项目的资源已完全利用，交付了尽可能多的内容。其次，Microsoft
Project 是瀑布式项目中备受期待而且更受认可的状态交流方式。然而，在更新状态时除了项目计划外还参考
burndown，开发团队就采取了措施，使其他团队接触并过渡到敏捷跟踪方法。
当然，以两种内在特性不同的项目管理风格（和文化）来进行工作，会给开发团队带来诸多挑战：
- 语言
从瀑布流程过渡到敏捷流程时，一个重要挑战就是要衔接术语。在本项目中，开发项目经理非常出色地进行了术语转换，既同客户以瀑布形式交流，又弥合了敏捷环境和瀑布环境中相对应的工具和状态之间的差异。借助这种适当的
“衔接”，开发团队更加自由地采用自己的流程，并且采取了本文所述的循序渐进的步骤。
- 计划
开发团队的标准运作模式是持续执行 sprint 周期 —— 不管他们是否正特别处理一个候选发布版本。所以，sprint
包含了规模估计工作、生产支持活动以及验证工作。因此，该团队尝试不使 sprint 在开发转换里程碑
(DCUT) 之日启动和中止。同样，使 sprint 不在 DCUT 之日结束也很有用；在那个重要时期抽出两天进行必要的会议，这不利于目标版本进入验证阶段。sprint
通常在 DCUT 之后的一周结束。
- 支持
最初，开发团队努力在 sprint 中处理必然的产品支持。一些开发人员专门处理 3 级支持，但是出现的产品缺陷中多数需要整个开发团队的成员来解决。尽管不能全面计划所有这些工作，但是可预计一些与支持相关的常规工作。这种工作分两部分执行：分析和解决。有助于团队将产品支持整合到
Scrum 模型之中的基本原则是，将任意产品缺陷的优先级设为最高的可能值，于是初始分析会优先于开发人员手头或者任务列表中的任意其他工作。
在分析方面，当产品缺陷生成时，通知单会添加到当前 sprint，并根据严重性而分配。执行根源分析，可确定提供解决方案要涉及的工作，而且此分析将找出问题的原因（或者，如果原因不明显，则找出识别原因所必要的内容），预估实现修复和创建单元测试的规模以及实现修复的困难度。一旦上述工作完成，通知单会从当前
sprint 中移除，产品负责人会确定与产品待办事项中其他项目相比的优先级。根源分析预定要在现有服务水平协议
(Service Level Agreement) 需求的范围内执行。
然后产品负责人将问题分配到 sprint 待办事项（可能是当前 sprint 或者将来 sprint
的产品代办事项），那么之后会通过一个发布版本、一个修复程序包或小修补程序而实现修复。
开发团队估计在部署新版本之后的两周内，每周会出现 10 个缺陷，如果进行过 4 小时的分析，则每周出现
3 个缺陷。
- 更改
产品问题会周期性地引发更改请求。开发团队的指导方针指出，这些请求必须由产品负责人为之在 sprint
中划分优先级。如果产品负责人相信更改请求是开发团队的最优先事项，那么 ScrumMaster 和产品负责人要确定当前
sprint 是否应当调整或（在罕见情况下）暂停，以适应这些请求。
- 转换
基础架构团队是开发团队的一个子集，他们负责编译工具、（测试和生产）服务器管理、数据库管理等。此团队分配在
sprint 之中，但他们也定期接收到来自项目中其他团队的工作请求。这违背了 Scrum 的原则，该原则声明团队要单独执行其
sprint 工作。
为缓解此问题，开发团队利用了 3 个战略：
- 团队识别出应当在每个 sprint 中都包含的基础架构任务，并将这些任务加入 sprint
待办事项（例如，alpha 部署、beta 部署支持、产品在线备份等）。
- 识别与产品待办事项相关的任意基础架构任务，并将之加入 sprint 待办事项。
- 基础架构团队领导被指定为外部技术架构技能请求的焦点，与产品负责人合作确定这些工作项的优先级，并根据需要将工作项加入
sprint 待办事项。
基础架构团队成员了解到要拒绝这种干扰，于是遵从上述流程来处理这类请求。这使他们能全身心地继续从事于
Scrum 流程。
- 规模
由于其规模，开发团队最终会转移为 Scrum 团队的一个层次，划分为 4 个团队：
- 业务流程/后端服务
- 用户界面
- 生命周期管理
- 基础架构
这些团队在内部执行每日 scrum。每两周举行一次 scrum 的 scrum，每个
Scrum 团队有一名代表参加并总结最近一次会议以来他们团队的状态、下一次会议之前该团队的计划、任意现存障碍，以及他们会对其他
Scrum 团队造成何种干扰。
开发团队利用一个 bug/问题跟踪系统，该系统提供一个具有便利的报表程序的整合 Wiki。IBM
Rational Team Concert™ 提供这种功能。团队针对所有开发工作项创建跟踪单，并为
sprint 生成（在其他报表之中的） burndown 图表。团队还能扩展工具和 Wiki 来适应自身需求。例如，团队可创建整合到
Wikipedia 之中的用户案例工具。
开发团队大量利用开发 Wiki 来记录流程，提供对进度报表的访问，以及接入其跟踪系统。因为接入跟踪系统，Wiki
是一种特别好的、用于文档编制和协作的机制。
开发团队在 Microsoft Project 中构建项目计划。项目计划引用了计划所包含的每个低级计划的跟踪单；这是在迁移到敏捷流程之前开始的演化。不是在相关时间内引用一个
CWN，而是为在一个版本中交付 CWN 所涉及的每个任务创建跟踪单。在可能的情况下，会细分任务，并将时间分配给两个或更多开发人员，从而提高工作效率并减少整体编码时间。细分出的每个任务都获得自己的跟踪单，并在项目计划中单独引用（目的是使每个任务单/任务最多只有一名所有者）。项目计划也会为个体开发人员确定任务优先级，还确定候选版本的整体优先级。在跟踪单上会创建一个自定义优先级字段，此字段根据项目计划而更新，并且按照开发人员执行任务的正当顺序传达给他们。
正如预期和宣传的那样，采用敏捷流程的结果就是提高了代码质量、加快了实现、提升了客户满意度，而且优化了开发流程。开发团队还获得了其他益处，包括一些通常被认为和敏捷无关的益处：
- 处理大型任务
采用 Scrum 的重要益处之一就是，Srucm 使开发团队能够将高价值项目加入版本中。这可能违反直觉；毕竟依照一些说法，限制在
2 周到 4 周之内的 sprint 不能处理大型功能。在本项目中，大型特性很难填入到一个版本的优先表中；比起一个大项目，客户通常更愿意选择
10 个较小的项目，即使那个大项目很重要。Scrum 强制开发团队逐步重视这些大型特性，分解大型特性以进行分析或研究，然后增量式地实现。团队能够在与开发阶段无关的
sprint 中良好地分析或研究，根据要求完成前置任务，然后更易于将增量实现加入到版本优先事项中。
这种方法也适用于非功能性项目，例如代码重构和自动化整合测试。很难让客户相信这种工作很重要，但是开发团队能够将重构工作打散成小块，构建一个渐进的变更计划，然后在
sprint 和版本中实现增量式变更。
- 灵活性
与此相关的益处是，可获得解构大型任务的能力和规程；sprints 强制开发团队以对待较小规模任务的方式思考。对于较小的任务，团队能更好地计划版本内容，还能在任务发生意外的情况下重新分配资源。大型任务往往需要更广泛的技能和专业知识，但是分解成小任务之后，很多都能分配给技能范围较窄的开发人员，这就提高了资源分配的灵活性。在数个版本和多个
sprint 计划会议之后，这种 “小任务” 理念就能在整个团队的头脑中生根了。
- 流程改进
Scrum 流程还提供了一个框架，以实现开发团队之前所缺乏的增量流程改进。Sprint 回顾会议提供了有用的反馈，而且流程更改添加给下一个
sprint。在一些情况下，例如在生产支持和基础架构团队的任务中，需要数个 sprint 来细化流程从而铸造成功。团队忠实于流程，解决了问题，并构建了很好地为团队工作的流程。
- 处理更改
开发团队能更好地处理变更，即使是在 sprint 中期。在一个版本发布过程中，他们携着对优先事项的清晰理解，开始了开发阶段；然后在一个
sprint 的中期，客户带来了全新的最优先事项。通常这种混杂会挫伤团队士气，但他们利用了 Scrum
原则来讨论可选项（中断 sprint 并重新开始，或者继续遵从不正确的优先级列表）。因为开发团队被授权制定决策，所以他们能够改变方式，接受全新的优先级，以获得成功。
- 工作环境
Scrum 流程的采用对团队士气、团队纪律以及团队互动具有重大的影响。因为开发团队被授权改进自己的流程，所以他们彻底忠实于流程，充满活力与激情地面对一切。创造力被应用到流程改进中，这种创造力更扩展到团队的开发工作中。此外，更新的流程会极大地改善开发周期，减少
DCUT 里程碑期间的恐慌，还减少在验证阶段及生产阶段中所发现缺陷的数量和严重性。版本发布流程将更加稳定、工作计划更周密，而该团队体验到的混乱时间更少。工作时间的预测性更强，即使团队到达了关键日期，这提高了士气并减少了开发人员与处理该项目的其他团队之间的压力。
敏捷开发的价值和益处逐渐变得明晰，而且获得了令人印象深刻的成果。在应用程序下一个发布版中使用 Scrum
将整个项目迁移到敏捷流程；针对该版本的敏捷研讨会刚刚举行。开发团队将能轻松保留开发流程，通过调整局部方法来适应更大型的敏捷流程。
作为开发计划和跟踪的一部分，开发团队拥有一个不合格的冗长候选待办事项（CWN 和缺陷）。它们将存储在团队的问题跟踪工具中，并引入到全新敏捷流程中，以备在将来版本中得到考虑。
开发团队中的巨大变化就是，用户案例由项目负责人开发。这一工作以开始敏捷研讨会为起始，使用 Rational
Team Concert 作为首选工具。因为用户案例流程提出了更高的质量要求，所以项目负责人致力于此，推动用户案例将极大地改进流程。
另一个重要改变就是，将 Scrum 团队从当前孤立的结构（基于开发中的功能域）转换为一个包含了项目代表的结构。以前，由于
Scrum 仅限于开发团队，所以职能的划分是必然的。在开始研讨会上，针对下一个版本讨论并制定了团队结构。开发团队已采取措施，针对当前版本而迁移到混合团队结构，他们将在流程中进行审查和修订，并将积累的经验教训应用到下一个版本。
开发团队逐渐转向测试驱动方法，并已采取措施与测试团队接触（测试团队在独立的组织中）。开发团队将与测试团队合作，让后者加入
sprint，向他们传授 Scrum 概念，并且共同在整个项目中采用敏捷开发。
最后，未来计划包括，向项目整体中的合作伙伴团队宣传 Scrum 和敏捷原则。开发团队的经验使他们处于培训角色的地位，这不仅是因为他们拥有敏捷知识并吸取了教训，还因为他们最了解应用程序的工作方式，而且体验过在组织中使用敏捷开发。
| 
