通过 Rational Team Concert 实现敏捷的嵌入式产品线开发

敏捷成功故事在 IT 领域已经司空见惯,但嵌入式产品线系统的敏捷性方面的消息却很少发布。Harry Koehnemann 剖析了一家嵌入式产品组织在采用 IBM® Rational Team Concert™ 来支持其敏捷工程实践时的具体遭遇。321 Gang 的 Harry Koehnemann 解释了他们的硬件、软件和项目管理团队的协作方式,他们对敏捷技术的使用,以及他们向 Rational Team Concert 的迁移。查找他们面临的问题、对他们有所帮助的实践和工具变更,以及仍然存在的挑战。

Harry E. Koehnemann, 技术主管, 321 Gang

Harry Koehnemann 的职业生涯始于英特尔公司,最初从事操作系统和编译器的开发和支持。几乎整个上世纪 90 年代,他都在为以软件为中心的系统组织提供咨询和培训,为一家如今仍然屹立不倒的互联网创业公司研究 .com 泡沫(员工编号 4),利用敏捷实践开发 Java Enterprise 系统。泡沫破灭后,Harry 返回到了咨询领域,帮助过 A&D、汽车、电子、医疗和金融行业的无数财富 500 强公司实施他们的工程和软件生命周期实践。他目前是一家 IBM Rational 首要业务合作伙伴 321 Gang 的技术主管,仍在继续热情帮助成功的组织执行大规模、复杂的系统开发。Harry 还在亚利桑那州立大学担任过 10 年多的副教授,从事分布式计算、系统建模和嵌入式软件方面的教学。



2013 年 11 月 07 日

概述

过去 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. 产品的软件和硬件产品变体流
产品 A 的流程图

移动通信行业是高度动态和敏捷的。制造商不断根据反馈集成供应商的零部件的新版本,以尽早揭示问题和显示进度。因此,提供商需要频繁地提供新版本,有时一个月提供多次新版本来应对反馈。CPL 不断与制造商通信,确定将在未来的交付中包含哪些变更。基于这些对话,CPL 每周与固件团队领导重新计划工作两次(从敏捷角度讲,就是每周两次冲刺)。

出于多种原因,不断扩大的客户群为固件团队带来了大量挑战。每个新客户通常拥有定制的增强。由于功能成本、硬件平台、可用内存等因素,不是所有变更(增强和缺陷修复)都会提供给每个客户产品变体。让情况变得更糟的是,客户可能选择以不同的顺序获取变更。在图 3 中所示的示例中,客户 A 需要交付一个变更,但他不需要之前的 2 个变更。在未来的某个时候,之前的变更可能会也可能不会提供给客户 A 的产品变体。

图 3. 变更没有按顺序提供给客户 A
第 3 个产品线变更被当作第 2 个产品线来提供

工程和敏捷性挑战

不断扩大的客户群还要求工程团队满足所选的产品变体和新客户的时间安排。管理这种环境的变更很复杂,因为不是所有变更都将提供给所有产品变体,或者它们可能以不同的顺序提供。为了跟踪工作,每个客户产品变体都有自己的优先的工作积压目录,如图 4 所示。请注意,只有一个开发团队(固件团队)完成了所有这些积压工作。

图 4. 跨产品变体跟踪工作
固件版本,连接到故事和缺陷

随着新客户的增加,他们的工作积压列表将记录在 Excel 电子表格中的一个新选项卡中。在选项卡之间复制表示工作(用户故事中的缺陷或增强)的行,以便记录特定客户对特定变更感兴趣的事实。但是,在电子表格中,无法关联重复的工作,如图 5 所示。对于给定变更,没有任何迹象表明哪个产品变体包含该变更以及何时提供它。

不断扩大的客户群还为旧有的配置管理系统带来了挑战。在基于分支的配置管理系统中,已修改的每个文件必须放在一个独立分支中,如图 5 所示。一次变更可能涉及 5、10 或超过 100 个文件,而且需要固件工程师为每个文件创建合适的分支。

图 5-1. 用于集成产品变体的现有变更管理方法
产品变体的配置管理集成图
图 5-2. 用于集成产品变体的现有变更管理方法
产品变体的配置管理集成图

此环境中的大多数合并操作都很复杂,因为不是所有变更都将交付给特定客户,或者(更糟的情况是)可能不按顺序交付。基于分支的配置管理系统中的复杂合并容易出错,因为这些配置管理系统不会管理变更;它们只管理各个文件变体。执行合并的工程师负责了解哪些文件与变更关联,这些文件位于哪个分支上,以及它们需要在何处合并。这是一个耗时、容易出错的过程。

合并错误具有很高的代价,因为它们常常难以定位。由于这种复杂性和潜在的成本,固件团队建立了一个称为集成人员(Integrator)的角色。只有集成人员才有资格将变更合并到客户分支中。不幸的是,集成人员成为了流程中的瓶颈,有时还会导致不能按时将特性或缺陷修复包含在需要每个月交付多次的版本中。

尽管他们没有明确地自称 “敏捷”,但移动通信行业中的公司遵循了许多敏捷原则,就像这家公司一样。他们频繁地集成变更(持续集成),甚至跨提供商,一个月集成多次。此外,基于他们从与客户的频繁对话中获得的信息,他们不断调整产品积压工作的优先级(自适应规划)。对于这家组织,此过程每周发生两次。

更小规模的工作、自适应规划和持续集成等敏捷实践,可能让未准备处理这些变更的开发组织手足无措。他们现有的工具不是为处理我们今天看到的频繁变更和集成而设计的。在许多情况下,我们现在看到组织中的变更流程所花的时间比系统中的还要多。这个变更流程的开销常常体现在变更管理工具的缺陷上,就像本文中的情况:过时的配置管理系统、Excel 和 VB 宏。

总体来讲,这个工程组织面临着三大关键挑战:

  • Excel 难以跨产品线来规划和跟踪工作。在他们尝试跨产品线管理和优先化变更,然后尝试理解已对哪些产品变体做了哪些变更,何时将对一个产品变体执行特定的变更时,该过程会迅速土崩瓦解。
  • 基于分支的配置管理软件无法满足他们的敏捷、持续集成需求。无法简单地将代码变更与电子表格计划中的工作任务相关联,所以很难看到其他人在以前的产品变体中做了哪些变更。配置管理工具对复杂的合并爱莫能助,这导致需要一个集成人员角色来执行合并。集成人员成为了瓶颈,延迟了变更的交付。
  • 工程经理需要浪费一些时间在 Excel 电子表格中创建 VB 宏,以便连接到状态信息的开发存储库。

通过 Rational Team Concert 实现敏捷

该团队选择采用 Rational Team Concert 来应对这些挑战。该组织有三大主要需求:

  • 一个更加强大的配置管理工具
    他们需要一个解决方案,以便在选择将一个变更合并到一个产品变体中时,帮助更轻松地识别要合并的所有文件变体。它必须提供一种更轻松的方式来集成变更,以便不再需要集成人员角色。该软件还必须支持 Excel 电子表格任务与执行的代码变更之间的关系,以便在不同产品变体中重新应用该变更时,他们能够更好地了解更改了哪些代码。
  • 简化的跨产品线规划
    他们需要为一个将应用于多个产品变体的变更创建独立但相关的工作任务,以便独立地管理它们并设定优先级。工作任务需要进行关联,以便 CPL 能够确定哪些产品线拥有缺陷或增强,开发团队可找到针对该缺点或增强的所有代码变更。他们需要一种机制来简化产品线内和跨产品线的工作时间安排。
  • 更轻松、更有效的开发状态可视化
    工程经理厌倦了通过更新和运行 VB 宏来获取开发流程的状态。

一个更强大的配置管理解决方案

本节介绍团队如何使用 Rational Team Concert 应对与配置管理相关的挑战。

将代码变更与工作相关联

为了解决第一个需求,Rational Team Concert 提供了与工作项 自动建立关系的功能。软件开发人员可轻松地将一组代码变更与分配给他们的工作相关联。图 6 的屏幕部分显示了工作项和它们关联的文件更改。这使得开发人员能快速查找对另一个产品线执行了哪些变更,无需查找代码分支。采用 Rational Team Concert 之前,工程师必须查看代码分支,查找其他人在另一个产品线上做了什么。现在他们可轻松地找到工作任务并查看所有关联的变更集。

此外,开发人员可使用 Rational Team Concert 同时处理同一个工作区中的多个变更。他们不需要创建源代码存储库的多个本地副本,记住哪些本地副本与哪次变更相关联。开发人员只需选择要暂停或恢复工作的工作项,Rational Team Concert 可以使用这些变更自动配置本地沙盒。

图 6. 在 Rational Team Concert 中处理多个变更
该屏幕显示了 Outgoing 和 Suspended 工作项

基于流的配置管理

Rational Team Concert 基于流的 配置管理提供了一种更简单、更强大的方法来管理产品线变更。图 5 显示了选择一个变更,然后查找和合并所有相关文件的挑战。Rational Team Concert 自动识别必须合并到传入的流(产品变体)中的所有文件变更。

图 7. 使用 Rational Team Concert Streams 将变更集成到产品线中
该图显示向客户 A 交付了一个变更

这里的一个局限性是,Rational Team Concert 在不按顺序交付变更时使用了一种补丁 解决方案。补丁机制的挑战在于,我们失去了一个通用变更的可跟踪性(不过,本文后面将提供这一局限性的一个解决方案)。Rational Team Concert 团队认识到他们需要一个更好的解决方案,而且 Rational Team Concert 积压目录中有多个解决此问题的工作项。有关的更多信息,请参阅 Rational Team Concert 工作项编号 128329

帮助处理复杂的合并

Rational Team Concert 以多种方式帮助解决复杂合并。首先,它提供了将变更合并到一个新流(产品变体)的所有必要因素的视图。因此,不会错误地确定哪些文件需要合并。如图 8 所示,Rational Team Concert 列出了每个变更集的文件,指明了合并过程中何处存在潜在的冲突。

图 8. Rational Team Concert 合并
Rational Team Concert 暂停针对复杂合并变更的屏幕截图

开发人员也可以在执行复杂合并之前获取其个人工作区的快照。在合并过程中,Rational Team Concert 自动将所有合并相关的变更存储在一个独立的变更集中。如果合并不顺利,开发人员可通过暂停或丢弃变更集来恢复到快照状态。

图 9. 工作区快照
屏幕截图

跨产品线的多个链接的工作任务

开发人员可复制 一个工作项,创建一个引用了原始工作项的独立副本。复制的工作项对固件团队很有用,可以使用这些工作项创建跨多个产品线执行的工作。独立(但链接)的工作项可分开计划和开发。您可以快速查看原始工作项上的链接,以查看其他哪些产品变体将拥有此变更,以及它们是否已交付。

在图 10 中,故事 174 被创建为故事 57 的一个副本。当开发人员开始在故事 174 上工作时,他可以访问相关的故事 57 的链接(已在故事 174 中突出显示),然后在其工作区中接受故事 57 的变更集(已在故事 57 中突出显示并显示为红色变更集)。如果接受以前的故事的变更集,则会自动将所有文件区别放入开发人员的工作区中。合并所需的新变更会自动将这些变更放入到一个新变更集中,并与故事 174 关联,如图所示。

图 10. 在 Rational Team Concert 中跨产品变体链接工作
针对不同产品变体和它们的变更集的工作项之间的关系

流程支持

固件团队还使用 Rational Team Concert 流程控件。破坏的构建版本会大大减缓使用持续集成实践的敏捷团队的进度。Rational Team Concert 使团队能够锁定向各个流的交付,以便只有当前计划发布给客户的工作是可交付的。尽管有人可能会想,任何工作软件都可以在一次迭代期间进行交付,但嵌入式软件对时间和空间问题很敏感,不是为当前迭代规划的软件可能与未来的版本相分离,从而破坏构建版本。

但是,固件团队还希望使工程师能够合作探索未来工作的实施解决方案。解决方案是为客户流执行一个严格的交付策略,然后使用更加宽松的交付规则创建一个 Rational Team Concert 沙盒 团队。沙盒团队中的开发人员可使用限制更少的规则,为协作创建额外的流。

简化的跨产品线规划

电子表格计划具有许多限制。它难以管理和跟踪跨产品线的重复工作,很难调整优先级,而且人们一般不愿意创建详细的工作任务,因为创建和移动它们很困难。结果,许多与一个变更有关联的工作任务(对硬件测试台的更新,对开发工具的修改)都未跟踪,因此可能丢失它们。

子工作项

Rational Team Concert 是第一批简化工作项之间的关系的问题跟踪系统之一。该软件使得创建关系并然后浏览和查询它们变得很简单。嵌入式系统开发可能需要在执行固件变更后执行下游任务,比如更新测试台、客户开发工具、用户文档等。当然,您不希望缺少这些任务。

这些任务不会出现在电子表格计划中,所以它们存在丢失的风险。Rational Team Concert 在工作项之间建立的关系使得工程师能够定义这项额外的工作并跟踪它,确保它在交付前已完成。

跨产品线的计划

跨多个产品线的计划太过庞大,无法在电子表格中完成。CPL 和固件团队需要采用一种机制来显示为哪些迭代计划了哪些工作,支持在迭代之间轻松地转移工作。

Rational Team Concert 敏捷计划功能解决了许多这样的问题。工作可在多种自定义的计划模式下查看,这使得 CPL(产品所有者)能够查看单个产品线的工作。新产品安装一周后,CPL 和固件团队领导使用 Rational Team Concert 计划工具(而不是电子表格)来帮助执行一周两次的计划会议,并取得了巨大成功。

图 11. 对比电子表格与 Rational Team Concert 计划
这些插图对比了两种格式

尽管取得了成功,但使用 Rational Team Concert 进行跨多个时间线的计划有一些挑战。该计划基于敏捷原则。时间线分解为嵌套的迭代(版本-冲刺),并且在任何层级上只有一个迭代是最新的(2.1 版,冲刺 3)。敏捷团队处理单一的时间线。为了支持这些敏捷实践,这些计划选择了单一的团队(或团队的团队)和单一的迭代(版本、冲刺)来计划和跟踪工作。在产品线系统中,一个团队处理多个产品线,每个产品线拥有自己的时间安排。

在单个团队(固件团队)处理多个积压目录,一个目录对应一个客户产品变体时,存在一个问题。要查看针对不同客户的工作,固件团队需要不断更改计划的 Planned For 属性。敏捷提倡者会说,CPL 应在内部跨不同客户确定其工作的优先级,向固件团队提供单一、统一的积压目录。但是,这不是合理的请求,而且有一些要求在单个计划上选择多个时间线的 Rational Team Concert 增强请求(有关的更多信息,请参见 Rational Team Concert 工作项 94056)。

这家组织选择让 CPL 来跟踪分开的时间线中的工作。当敏捷团队希望看到他们的工作时,可以更改其计划所引用的时间线。尽管更改计划时间不是一个理想的解决方案,但也是一个不错的解决办法,而且总体解决方案比电子表格好得多。

更轻松、更好的开发状态实时可视化

为了报告工程状态和执行情况,工程经理在 Excel 中编写了 Visual Basic 脚本,以便从以前的问题跟踪系统中拉取数据。Rational Team Concert 工作项查询和包含的仪表板为跟踪进度提供了一个轻松的解决方案。工程经理在 Rational Team Concert 部署后的第一周就开始配置其仪表板。

图 12. Rational Team Concert 中的项目可视性
图表和报告屏幕截图

结束语

本文介绍了一家跨多个产品线开发嵌入式产品的电信提供商如何应用敏捷实践。随着企业客户群的不断增大,由于以下因素,固件团队很难满足交付时间表:

  • Excel 难以跨产品线规划和跟踪工作。当他们尝试跨产品线来管理和优先化变更、随后尝试理解已对哪些产品变体做了哪些变更以及何时将对一个产品变体执行特定变更的时候,该过程会迅速土崩瓦解。
  • 基于分支的配置管理软件无法满足他们的敏捷、持续集成需求。无法简单地将代码变更与电子表格计划中的工作任务相关联,所以很难看到其他人在以前的产品变体中做了哪些变更。配置管理工具对复杂的合并爱莫能助,这导致需要一个集成人员角色来执行合并。集成人员成为了瓶颈,延迟了变更的交付。
  • 工程经理需要浪费一些时间在 Excel 电子表格中创建 VB 宏,以便连接到状态更新的开发存储库。

Rational Team Concert 通过下表中所示的变更,解决了几乎所有这些问题。

表 1. Rational Team Concert 解决的变更
变更类别之前之后
计划Microsoft Excel 电子表格Rational Team Concert 敏捷计划
跨产品线跟踪重复工作尝试跨电子表格中的多个选项卡来查找链接相关的工作项
管理产品变体的代码SCM 工具中的分支每个产品变体一个 Rational Team Concert 流
查找上一个产品版本中执行的工作查找 SCM 工具中的合适分支查看与 Rational Team Concert 工作项关联的变更集
谁在集成代码特殊的 “集成人员”每个人
执行复杂的合并容易出错、基于分支的合并过程向客户流提供变更集,Rational Team Concert 识别需要合并的文件
针对测试台、客户开发、工具的其他工作固件团队 “记住”Rational Team Concert 子工作项
状态Excel 中的 VB 宏Rational Team Concert 仪表板和计划

有趣的是,第一次与这个客户交谈时,他们讨论的问题是基于分支的集成。但他们很快认识到,Rational Team Concert 工作项和计划功能是一个好得多的产品线计划和跟踪解决方案。

参考资料

学习

获得产品和技术

  • Jazz.net 下载 Rational Team Concert,它可供至多 10 名开发人员免费试用,只要您愿意(需要注册)。如果您愿意的话,可在沙盒中试用它,无需将它安装到自己的系统上。
  • 以最适合您的方式 评估 IBM 软件:通过下载获得一个试用版,在线试用它,在云环境中使用它,或者在 SOA 沙盒 中花几小时学习如何高效地实现面向服务的架构。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=951910
ArticleTitle=通过 Rational Team Concert 实现敏捷的嵌入式产品线开发
publish-date=11072013