321 Gang 的 Harry Koehnemann 解释了他们的硬件、软件和项目管理团队的协作方式，他们对敏捷技术的使用，以及他们向 Rational Team Concert 的迁移。查找他们面临的问题、对他们有所帮助的实践和工具变更，以及仍然存在的挑战。
过去 10 年中，软件社区大量采用了敏捷实践。这些实践反映了现有的瀑布式软件开发流程中的缺陷：
交付缓慢 瀑布式方法需要几个月或者甚至几年才能创建出可执行（且可审核）的系统，因此减少了利益相关者提供反馈的机会，限制了业务灵活性。 尽早决策 由于提供审核和建议的机会有限，利益相关者必须尽早地确定对系统成功至关重要的特性。 有限的调整机会 长期、固定的计划减少了针对新环境进行调整的能力，无论是从技术发现还是从业务变更方面。
相比较而言，敏捷实践持续集成小型系统变更，提供了一个用于持续审核的环境。它们将大型项目分解成为相对较小的用户故事 和任务，然后将它们集成到一个持续集成 和构建流程中。持续集成变更能够尽早揭示错误，供早期系统验证所用。它还支持更加频繁的审核，这有助于实现早期验证。
在典型的 scrum 流程中，利益相关者（产品所有者）会确定产品积压目录 中某个工作列表（用户故事）的优先级。在每次迭代开始时，产品所有者从产品积压目录选择最高优先级的工作项目，与开发团队讨论它们的细节。然后，开发团队将这些故事分解为任务，在随后的 2 到 4 周的冲刺（sprint）（迭代）中完成。在冲刺阶段，开发团队会不断地会面（每日 scrum 会议）和不断地集成变更。冲刺结束时，开发团队向产品所有者演示来自最新的系统构建版本的新功能。
许多早期敏捷成功故事拥有相同的特征：小型团队、相同地点、构建相对较小的 IT 类型 Web 或数据库应用程序。但是，复杂系统开发能够（而且确实已经）从这些敏捷价值中获益，包括更快的交付、延迟决策、持续集成、早期反馈和自适应规划。
例如，在本文中，一家虚构的电信公司提供了一个嵌入式零部件的产品线。本文将介绍他们遵循的敏捷实践，他们在现有的开发基础架构中面临的挑战，以及他们迁移到 IBM® Rational Team Concert 协作式软件后如何应对这些挑战。
项目背景
一家移动通信行业的电信提供商负责供应移动电话的零部件。他们的团队被组织成硬件团队、固件（软件团队）、测试团队和一个应用程序支持团队。应用程序支持团队创建开发工具和测试平台，并对遇到问题的客户提供支持。客户产品领导 (Customer product leads, CPL) 管理与客户的关系，并将来自客户的增强请求和缺陷报告提供给工程团队。CPL 类似于 scrum 项目管理中的产品所有者角色。
以前，CPL 使用一个电子表格来跟踪工作。通过在电子表格中上移或下移行来不断调整开发的优先级。工程团队使用了一个在内部开发的单独系统来跟踪测试和客户发现的缺陷。固件团队有两个工作积压列表：电子表格和问题跟踪缺陷。工程经理在 Microsoft Excel 中编写 Visual Basic (VB) 宏，以便从问题跟踪系统外部收集数据，进而收集各种指标。他们使用一个现有的、基于分支的工具来处理配置管理 (CM)。
图 1. 项目的组织结构
业务扩展
上世纪末的经济低迷，这使得该企业有机会扩大其客户群。每个客户都拥有独特的需求，可能还有额外的硬件需求。最初的一个硬件平台上的单个产品已增长为跨 4 个硬件平台的超过 18 个产品变体（product variant）。图 2 描绘了从单一产品 A 到跨多个硬件平台的产品变体的增长过程的一部分。每条线表示一个产品变体，箭头指示了变更在各个产品变体之间的流动方式。
图 2. 产品的软件和硬件产品变体流
移动通信行业是高度动态和敏捷的。制造商不断根据反馈集成供应商的零部件的新版本，以尽早揭示问题和显示进度。因此，提供商需要频繁地提供新版本，有时一个月提供多次新版本来应对反馈。CPL 不断与制造商通信，确定将在未来的交付中包含哪些变更。基于这些对话，CPL 每周与固件团队领导重新计划工作两次（从敏捷角度讲，就是每周两次冲刺）。
出于多种原因，不断扩大的客户群为固件团队带来了大量挑战。每个新客户通常拥有定制的增强。由于功能成本、硬件平台、可用内存等因素，不是所有变更（增强和缺陷修复）都会提供给每个客户产品变体。让情况变得更糟的是，客户可能选择以不同的顺序获取变更。在图 3 中所示的示例中，客户 A 需要交付一个变更，但他不需要之前的 2 个变更。在未来的某个时候，之前的变更可能会也可能不会提供给客户 A 的产品变体。
图 3. 变更没有按顺序提供给客户 A