巴伐利亚汽车制造商的LeSS转型

Valtech德国公司是选中的供应商，以帮助其应用敏捷开发来创建宝马集团的新*BMW i*汽车的直销流程。这需要新的IT支持系统，所有这些系统都已嵌入到现有的IT环境中，其中80多个系统会受到影响。有一个跨越许多项目的大型项目集来创建新的支持系统。

其中一个项目是新的统一销售平台（USP）系统。USP从头开始实现，集成了30多个外部系统接口。*BMW i*推出的其他合作伙伴项目，仍沿用非敏捷过程模型。因此，跨项目的共同里程碑、报告和协作成为一个挑战。

经过2年多的开发，USP按时发布，并具有很高的质量和客户（比利时-荷兰-卢森堡市场）满意度。

阶段1：在多个特性团队之前

2012年2月，USP在充满挑战的环境中开始开发：

• 时间压力大，因为上线日期已经确定
• 直销业务流程仍在讨论中，尚未定义
• 因此，USP产品的范围还不清楚
• 大多数参与者不熟悉宝马集团的业务、销售流程及敏捷方法
• USP项目嵌入在传统的项目集（*BMW i*项目集）管理系统中

由于上述情况，USP项目决定使用Scrum和敏捷工程实践，来尽早和持续地获取有关产品进度和组织进度的反馈。敏捷开发从一个Scrum团队开始。这个团队建立了合适的敏捷开发流程，搭建了合理的开发基础架构，找到了与业务部门的协作模式，并为敏捷开发奠定了坚实的基础。

这个最初的团队评估了所需的工具，搭建了开发环境和持续集成系统，尝试了不同的Sprint长度，并实现了第一个业务功能，验证了新组织是否可以正常工作。

从第一个Sprint开始，USP团队在每个Sprint结束都演示了可运行的和经过测试的软件。

后来，团队增加了一些人，这些人以传统的职能和组件团队的结构进行了组织，这代表了更广泛的*BMW i*项目集中使用的标准模型。

在USP 1.0版本之前团队一直在使用这种结构。

阶段2：转变到多个特性团队与LeSS

当前的组织结构对发布1.0版本来说已经够用了。不过，作为教练我们预见到，对于下一个更大的版本，这种组织结构的扩展性不好。团队需要更灵活（敏捷），因为优先级和需求经常变化。团队需要能够从产品待办列表中选择不同的条目，并交付完整的端到端特性。此外，还需要减少特性的周期时间以缩短“上市时间(time to market)”。

在先前的组织中，团队只能做一种类型的功能或特定的组件工作。这限制了更改产品待办事项的优先级和团队灵活地“转到新工作”的能力。而且，专家小组间的交接和延误，延长了平均周期时间。此外，还增加了协调和集成的工作量和问题。

因此，根据我们的建议，团队同意重组为多个特性团队并同时采用LeSS。

我们的目标是创建五个新的跨组件和跨职能的特性团队。

由于现有的商业合同和项目集的政策，USP项目组无法完全重组为特性团队。例如，有一个UI设计治理小组负责整个程序的UI一致性。还有一个测试管理团队，负责协调项目集范围内的跨项目测试活动，并为整个项目集提供报告。这个团队不做测试工作；测试工作仍由实现团队自己完成。不过，测试管理团队对（实现团队）“未完成（undone）”的部分做出了贡献，例如组织外部公司做渗透（安全漏洞）测试。此外，按照项目集政策，这里还需要一个项目管理团队，汇报给上层的（传统）项目集管理团队并负责人员、设施和设备管理。

图 1: 阶段2的USP项目的组织结构

自设计特性团队工作坊

我们还达成一个共识，即通过*自设计团队工作坊*（LeSS实验之一），重组为特性团队。

团队花了3轮的时间（每轮20分钟）形成了符合愿景的组织：所有特性团队应能够独立处理所有利益相关者/请求者的产品待办事项。

在组建新团队后，他们创建了新的团队名称，找到了自己的团队空间，选举了Scrum Master和“首席”开发人员（由于政策原因，这仍然是必需的角色）。

整个团队的自设计工作坊大约持续了三个半小时。 有关自设计团队工作坊的详细信息，请点击此处

团队建设工作坊

自设计团队工作坊是一个很好的开始。但是在自设计团队工作坊结束时，有一些新成立的团队，他们必须应对新的动态。根据LeSS的说法，向特性团队的转变是对旧系统的重大更改。该项目组面临着两方面的扩展。一方面是跨团队协作，按照一个产品待办列表的优先级与所有团队合作。在LeSS环境中，Sprint仪式和同步会议覆盖了这一方面。第二方面与团队内的可用知识有关。所有团队都让团队成员了解不同的组件。这体现了团队中的一个瓶颈，因此这种情况是扩展的障碍。为了在系统层面上进行改进，需要改善团队内部的知识共享。另外，项目管理团队的目标是尽快使这些新团队重新发挥作用（尽快开始工作）。因此，项目管理为每个团队提供了进行额外的团队建设工作坊的机会。本次工作坊的目的是降低社交障碍，启动知识共享措施，寻找工作协议并在团队挑战中反思团队动力。

工作坊日程：

时长 主题

00:05 介绍、日程

00:10 破冰练习

00:30 团队知识模型 (agile world 2013)

00:45 一致同意的措施

00:30 团队愿景和团队章程

00:50 团队挑战 (室外) “有毒废料Toxic waste”

00:10 结束和反馈

03:00 社交：午饭或晚饭

{: .grid_table_with_header}

这个工作坊大约用了三个小时，接下来就是午饭或晚饭。以下段落描述了部分的日程主题。

“团队知识模型”和“一致同意的措施”

在此工作坊中团队成员使用团队知识模型 (TKM)来可视化团队成员之间的知识分布。

团队在业务水平和技术技能水平上建立了团队知识模型。

图2：TKM业务水平和技术技能水平分布的例子

在TKM模型中，按照与项目相关的各知识领域，所有团队成员在技能水平（X轴）和日常挑战（Y轴）两个维度找到他们的位置。坐标轴分为三个区域：低中高。从挑战维度看，低挑战意味着团队成员在该特定知识领域没有任务或只有非常简单的任务。高挑战则表明团队成员工作的任务很复杂。技能水平，可以理解或替代为LeSS中提到的守破离（Shu/Ha/Ri）对应的经验水准。

上面的示例显示了“测试专业（TEST FACHLICH）”领域的两个成员(译者注：图中两个粉色的X)。一位团队成员表示，他的知识刚够应付日常工作（当前边做边学）。另一位团队成员在此领域有很好的知识，但不在该领域中工作（浪费了专家知识）。如果这两个团队成员结对完成该领域的任务，则两者都会受益并迅速达到心流状态。

此外，该模型表明，团队具备了所需的基本知识，唯独棕色的领域是个例外。在棕色的领域中，团队需要其他团队的帮助，以快速提高团队知识。单击此处了解团队知识模型的更多信息。

在TKM中可视化知识分布后，团队可以基于模型寻找合适的措施来改善团队的知识分布，例如，确定特定主题的结对人选，组织团队代码道场等。一些团队随后提出需要跨团队的知识共享，因此启动了实践社区。

通过此模型，团队还可以获取反馈，无论他们是否对产品待办事项列表的工作有足够的知识，或者是否存在某些知识空白。基于这个可视化模型，每个团队都定义并商定了改进措施，例如谁将进行结对编程，组织代码道场或测试道场，其他培训课程，结对工作，看书和事后分享……团队开始意识到：作为持续改进的一部分，自己要对个人和团队的学习负责。

“团队愿景和团队章程”

团队愿景或团队章程可以帮助团队聚焦于同一方向。因此，在此活动中，团队创建了愿景，例如“我们胸襟开阔，愿意改进并互相支持。”或团队章程，其中一些团队定义了“做什么与不做什么”之类的规则，或者定义了诸如“每天至少进行两次结对编程”，“回归测试保持绿色”的工作协议。

“团队挑战（室外）”

图3：团队挑战“有毒废料 toxic waste”

在户外的挑战下，团队可以反思他们如何合作。例如团队沟通的工作方式，或在时间压力下的行为。如果团队在给定时间内没有成功，则团队可以有多次迭代。这是个缺省的过程，旨在使团队可以反思他们的方法。然后再开始下一轮。有些团队三轮比赛才成功，有些则两轮就成功了。挑战之后，他们都达成了共识，那就是他们通过良好的沟通、检视和适应以及所有团队成员的参与才能成功。

工作坊结束后，团队按照自己的意愿去选择午餐或晚餐。在那里，团队成员分享了他们对工作坊的见解和经验，并加深了对团队动力的理解。

一个产品待办列表

根据LeSS的要求（因为它支持聚焦整个产品、透明性和简化），只有一个产品待办事项列表，所有特性团队都为之工作。转型到特性团队后（而不是组件团队和单功能团队），每个团队都可以完成端到端的客户特性。产品待办列表中的每个条目都代表了完整的端到端客户特性。

为了满足整个项目集的传统项目报告要求，我们创建了一个自动报告的解决方案，该解决方案从一个产品待办事项列表中提取数据，并以传统的“瀑布式”项目集管理小组熟悉的方式进行展示。

产品所有权与设计治理小组

作为对一个产品待办事项列表的补充，在LeSS中，只有一个产品负责人可以排序（排优先级），因此，这位产品负责人具有强烈的产品所有权意识，从他那里会得到强烈而一致的愿景。相比之下，宝马集团有一项默认政策，即治理委员会中确定内容、范围和优先次序。如果要做出决定，则必须包括不同业务部门的许多利益相关者。因此，宝马集团的项目有一个“设计治理”小组。该小组作为团队排优先级。当然，这与标准的LeSS框架不同，却是可能性的艺术。特别是从外部团队（例如Valtech DE）而非内部引入LeSS时新的工作方式，这种组织层面的妥协尤其普遍。

产品待办列表的排序是通过与所有利益相关者的交谈完成的。以下条件影响了顺序：

• 利益相关者目标日期/里程碑
• 预期的价值
• 可能降低的风险
• 每个利益相关者的剩余项目预算

与LeSS原则“聚焦整个产品”有关，每个Sprint两周一次，该（设计治理）小组与特性团队和跨领域团队的代表一起进行了整体的产品待办事项列表梳理工作坊（PBR）。

设计治理小组组织了不同业务部门（领域专家）与特性团队之间的互动。他们与特性团队一起确保，在将相应的待办事项条目纳入Sprint之前，解决了并发需求的冲突。设计治理小组成员还组织并参加了特性团队的“产品待办列表梳理（PBR）”工作坊。

LeSS中的Sprint仪式

在第一阶段，USP项目几乎从一片空白开始。该系统是从头开始构建的。负责新款*BMW i*销售流程的业务部门仅获得了以传统方式创建的一份系统建议。因此，将系统建议分解为产品待办列表条目（PBI）是合理的。在本例中，我们编写了具有验收标准的用户故事。在项目开始时，在很高的层面上完成（译者注：指的是粒度较粗）。随着时间的推移，团队根据优先级与业务部门的领域专家一起细化这些条目。业务部门/领域专家与团队之间存在1对1的关系。功能方面的协调是在治理小组和业务部门级别进行的。技术方面的协调则在团队间完成。作为下个Sprint的预览，Sprint中举办产品待办列表梳理会议。在Sprint计划会议第1部分结束时，举办同步会议。团队在这两个会议上协调技术方面。所有团队的代表都参与了这两个会议。

该项目组同意了以下对所有团队有效的“就绪定义”（DoR）：

• UI模型设计完成
• 验收标准已提供
• 产品负责人同意
• 安全性、角色和权利已定义

治理小组仅对下一个Sprint符合DoR标准的条目进行优先级排序。团队根据（开发）速率为接下来的一个半到两个Sprint准备了最大数量的条目。

在USP的第二阶段，转变为特性团队后，PBR的流程发生了变化。现在，该项目必须处理来自不同利益相关者的需求，有时会与其它需求或现有功能发生冲突。用户故事作为唯一的条目类型不够用了。利益相关者所需的功能与现有功能之间的差距必须表达出来。因此，项目组引入了“topic”一词，用于描述所需功能与现有功能之间的差距。利益相关者的需求之间可能存在的冲突在topic级别解决。设计治理小组负责topic级别。他们解决了不同业务部门之间可能出现的冲突，定义了无冲突且大致细化过的条目。之后他们与特性团队一起做进一步的条目细化工作，细化后的条目与阶段一的条目可以做相同处理。

扩展协调与集成的技术

在LeSS中，众所周知，真正强大的持续集成实践对于成功扩展规模至关重要，因此，持续集成是LeSS“技术卓越”部分的指南之一。有了持续集成，协调和内部开源、增加透明度和关注整个产品成为可能。因此，USP小组投入精力改进开发者行为（持续地集成），并建立了一个强大的持续集成（CI）系统和相应流程。

CI系统的核心是主版本（master-build）概念。部署或验证所需的每个工件（例如JAR文件，配置数据，测试等）都与主版本号绑定在一起。该系统的所有结果（例如，构建产物，测试结果，日志和轨迹记录）均关联到相应的主版本号并存储到中心存储库。

CI系统由3个主要组件构成，分3个步骤执行：

1. 编译并生成可执行文件。
2. 部署和测试。在目标系统上部署主版本，执行端到端测试，并将相应的结果，日志和跟踪存储在中央存储库中。
3. 报告结果，创建一个主版本历史记录表，其中显示了主版本号和所有对应的结果。然后通过电子邮件向感兴趣的人发送报告的链接。

有关持续集成的技术视角表明，它具有高度的可扩展性，无论开发人员是在现场、在异地甚至在离岸工作都没有关系。

图4：开发环境的组件

每15分钟创建一次的系统版本均带有专用的版本号标记。最近成功的系统构建（无失败的单元测试和模块测试）部署到类目标环境（target-similar）中。

之后执行端到端的冒烟测试。冒烟测试是自动回归测试的一个子集，反映了最重要的测试场景，以便在集成级别为开发人员提供快速反馈。测试结果链接到主版本号，并记录在主版本历史中。

图5：主版本历史表、测试结果及链接到详细结果的例子

只有通过了冒烟测试的主版本才可以进入下一阶段。下一阶段是自动回归测试。作为“完成的定义”（DoD）的一部分，团队将条目的验收标准转化为自动化的回归测试（“可执行的需求”）。所有可以运行的回归测试均在此阶段执行。同时，还并发执行了一些质量检测，例如静态代码检查（Sonar）或性能测试。这些结果都记录在相应的主版本构建历史中。

所有测试均有标记关联到相应的产品待办事项条目，由此关联到USP不同领域的功能。因此可以查看产品的哪个功能领域存在问题。

图6：功能领域的主版本测试结果

通过逐级点开功能领域，所有小组成员都可以深入研究有问题的条目，并可以从功能角度分析问题，即哪一条验收标准出了问题。当然，在最低级别（未显示）提供了与技术/代码级别的关联，例如，列表条目的预期数量为 <2> 但收到的结果却为 <0> ，或其它的异常详细信息……。

图7：功能区域测试结果的详情

这样，每个人都可以立即获得有关主版本的当前功能质量的全貌。

在LeSS的大规模开发中，较短的CI系统反馈周期尤其重要，因为不可能大家一直在一起交谈。因此CI系统需要成为一个发信号的工具，以便在出现问题时迅速告诉小组。然后人们找出跟谁一起聊可以解决问题。这样，具有快速反馈的CI系统成为了协调的工具。

从签入（代码）开始计时，持续集成团队能够将冒烟测试的快速反馈周期时间保持在一小时到一个半小时之间。每天可获得两到三次回归测试结果，回归测试大约需要三到五个小时。

随着系统功能的增加，测试规模也随之增加。为了缩短反馈周期，必须进行并行测试。这需要更多的虚拟服务器，当然也需要更多的硬件。主版本部署到多台服务器上。根据标签将测试划分为功能领域（例如“财务测试”），并同时在多个服务器上执行（不同功能领域的）测试。之后将测试结果合并到一个报告中。

除了用于自动化测试的环境外，还有两个手动测试环境，与宝马集团所有其他相关IT系统完全集成。仅在这两个环境中，条目才可以按照“完成的定义”（DoD）被接受。此外，每个特性团队都有自己的测试环境用于内部探索性测试。他们能够在这些测试服务器上添加新特性并对其运行自动化测试。好处是签入代码之前快速集成反馈。所有这些服务器都按照宝马集团的staging流程通过中央Jenkins服务器进行部署。

所有其他利益相关者都可以看到主版本号，并在构建历史表中很容易地查看当前已安装软件的功能质量。绿色的冒烟测试和回归测试是通用的DoD条件。因此，每个人都可以验证当前实现的版本是否会对现有功能产生副作用。

失败构建的协调

每次构建/测试运行后，CI系统都会向用户发送一封电子邮件，其中包含功能结果概述。该电子邮件还包含指向CI系统提供的功能和技术构建详细信息的链接。所谓的“每日回归”是与每个团队的代表举行的简短站立会议，用于协调活动，以防过夜的回归失败。

在*BMW i*项目集中规划了总体6个月的系统集成测试阶段。对于所有相关项目都有固定的代码冻结通告。因为USP项目能够交付高质量的软件，所以*BMW i*项目集就要求更多特性，并在最后一刻收到来自市场方面的更改。因此，团队跳过了USP项目的代码冻结。在技​​术“上线”的两周之前，USP每周都会提供新功能（仍然是两周的Sprint）到整个系统集成环境。在此期间，全面的测试管理，包括市场上的测试设备发现的缺陷比宝马集团的另一个类似项目少了95％。少数缺陷中的三分之一与USP功能无关。在“业务上线”后的五周内，没有发现与USP功能相关的严重问题，或是会阻塞业务且在很短的时间内无法解决的问题。

因此，该小组的自动化测试和集成实践为整体成功做出了巨大贡献。

在USP的指导中我们遵循了LeSS原则。“聚焦整个产品”非常重要，因此我们在开发过程中集成了所有相关的合作伙伴系统。作为“完成的定义”的一部分，该项目从一开始就定义并执行了BMW i的整个项目集的集成测试。与功能测试自动化一起，为2014年秋季的成功发布做出了重大贡献。根据我在同类项目中的经验，USP项目达到了卓越的质量。

此外，该项目采用了*透明性*和*以客户为中心*（LeSS原则）的方法，通过每个Sprint向所有团队展示整个项目可运行的软件，并根据客户的反馈调整产品待办事项，确保了很高的客户满意度。

通过*经验过程控制*，该项目能够提供现实的、基于事实的、具体的进行中特性的进度预测（相对于“甘特图进度”的错觉），从而提高了可预测性和可靠性。高质量赢得了多方的信任，包括整体项目集、传统测试管理，客户及合作伙伴系统。尽管其他合作伙伴系统不得不遵循传统的集成测试阶段（译者注：在此阶段代码冻结），USP项目是个例外。直到技术上线前的两周，USP项目被允许并能够提供新特性（“晚期”的更改）！

LeSS和敏捷原则为整个项目提供了出色的指导，在许多情况下，它们是关键项目决策的基础。

原文链接