English Audio versions of this case study are _available here

概要

我坚信宽泛的产品边界，结合在产品全范围之内运行的特性团队，是最有可能取得长期成功的。如果因可能性的艺术排除了这种选择，那么一种增量的方式 - 从扩展的（更跨职能）组件团队开始，积极地转向扩大的（更跨组件）组件团队和特性团队 - 仍然是值得尝试的。

在中岛公司的模块化计算系统部门，这个策略的好处包括：

• 在扩展组件边界内这个局部改善了适应性和价值交付
• 改进了带来质量提升的技术实践，同时也提升了团队对改进所能带来什么的认知
• 早期识别和解决与扩展组件相关的缺陷
• 提升了在扩展组件团队内的员工协作、参与度和学习
• 提升了对组织障碍，以及更多组织变革必要性的认知

我希望我们的成功能让你感受到鼓舞和启发。同样，我也希望你能避免重复我们的错误，而是把精力放在新错误的学习上。

略读提示

这个案例特别长，并且很详细。如果你想快速浏览，我建议只读以下部分：

• 概要章节
• 所有图表及相关说明
• 结论章节

LeSS导入的总体背景

产品概述及相关人员

中岛公司的模块化计算系统（MCS）部门专注于一系列集成硬件、软件和网络组件的产品开发，这些组件共同作为一个完整预捆绑的内部数据中心解决方案。在某种程度上，它可以说是一个亚马逊网络服务类型平台的现场迁移部署。典型的终端客户是大型银行、保险公司、手机供应商和科研机构。

就规模而言，仅中岛公司的MCS部门就有几千人。该部门的大多数员工集中在旧金山、波特兰和班加罗尔等大城市地区。

整个MCS部门都聚焦于MCS产品的开发。而所有的制造工作，包括电路板制造、金属制造、组装和其它大规模生产工作，均采用MCS部门制定的规范被外包出去。

现场支持则由中岛公司的的另一个部门负责。现场支持部门专注于为中岛公司的所有产品提供无缝的客户支持体验。现场支持部门支持的产品包括广泛的网络产品，如电话系统、视频会议解决方案、无线网络解决方案，以及许多与MCS无关的产品。

实际上，现场支持部门里是有专家专注于支持MCS产品的。这些专家能够观察到现场客户的实际情况，以及在大且多样的MCS客户群体中存在的差异。基于此，开发MCS产品的工程师可以通过直接与这些现场支持专家合作，来获得一些最有用的且未经过滤的反馈。

MCS产品支持人员和组织能力不应与你可能在典型大众消费产品中会遇到的相混淆。这是一类快速响应、预算充裕的技术支持，当需要时就会有真正的人员到现场。许多现场支持专家在他们的专业领域里与开发MCS产品的工程师一样地知识渊博和薪酬优厚。

特伦特·甘贝尔（Trent Gambale）负责MCS部门内的项目管理组，该小组由不超过十几名项目经理组成，帮助协调MCS的整体开发工作。日常项目管理的许多方面都由MCS部门内的各个工程总监负责。我在MCS部门的最初赞助来自特伦特，当时他的副总裁（VP）和高级副总裁（SVP）/总经理（GM）都积极参与。特伦特是通过我之前在中岛公司另一个部门的工作听说我的。

敏捷导入的初始重点

最初的重点是评估少量业已存在的（表面上）“敏捷”团队，以协助他们做任何有意义的改进；并在该部门内识别出一些有希望的领域开始导入敏捷。

经过几天的调研，所有这些现存的“敏捷”工作很明显其实什么都不是。例如，

• 管理层习惯性地将估算视为承诺。
• 缺乏熟练的工程实践，例如自动化单元测试。
• 没有正式的“检查并适应”活动，例如回顾会议。
• 团队远没有自我管理。

在我对现存的所谓敏捷工作进行初步检查之后，我与特伦特进行了讨论。我们认为，当下聚焦我们精力最有效的地方应该是，在那些被认为最有利于成功变革的领域创建新的合适的跨职能和跨组件Scrum团队。每个团队应该拥有技能和授权以工作于各种相关技术的任何方面，同时具备完成开发、测试、发布，以及其它相关活动的所有方面的能力。

从我对现存工作的调查来看，大多数高级管理层对健康的自管理团队显然并没有真正的了解或接触。没有这一点就很难让大家对更持续的整个部门组织变革产生足够的兴趣。特伦特和我希望借助一个成功的Scrum团队示例来获得更大的支持。

但我们未能解决一些结构性问题最终瓦解了我们早期的成功。导致瓦解的两大结构性问题是：

• 未能充分重组汇报关系鼓动了一些经理分散了团队成员的工作注意力。
• 新构建的功能对管理者激励的贡献有限，尽管它为中岛公司整体带来了巨大的节省。

第一条和第五条拉曼组织行为法则的表现章节对此有更详细的阐述。

我们最初成立了一个单独的Scrum团队，专注于为MCS产品增加端到端诊断能力。端到端诊断展示团队并不是本案例的主要重点，尽管这项工作的部分成功为更广泛的BIOS相关工作敲开了大门。

因为端到端诊断的工作帮助照亮和预示了BIOS工作中遇到的一些挑战，稍后也将更详细地描述诊断团队的工作。

在BIOS组内面向LeSS的导入

诊断团队的早期成功以及我在MCS部门的持续交流传播激发了兴趣，并最终有了BIOS组美国工程师主管米提亚（Mitya）的加入。由米提亚和我牵头、在BIOS组内面向LeSS的导入是本案例的主要重点。

人为自加的复杂程度以及BIOS领域本身难懂的属性，使得即使仅限于BIOS开发这样一个组件边界，仍能从LeSS结构中受益良多。LeSS结构将有助于解决多年来那些有问题的实践。

BIOS领域还提供了一条通向整个MCS系统完整切片的自然演进路径。在英特尔CPU生产上市之前将其新一代预生产CPU快速吸收进MCS产品中的能力对于保持市场相关性至关重要。这包括要确保所有必需的BIOS功能在预生产CPU上正常工作，同时要确保刀片（blade）架构的任何修订和扩展都能与CPU正常集成。此外，还需要确保MCS管理用户界面上公开的所有CPU管理服务都能正常工作，并得到扩展以支持英特尔在预生产CPU中引入的新功能。

所有这些都可以被视作一个自然的以MCS为整体产品的LeSS巨型需求领域。

LeSS框架规定，在LeSS巨型导入中每个需求领域都应“在开始时”建立完整的LeSS结构。虽然米提亚和我从一开始就对BIOS组内的美国成员进行了彻底重组，但如果能更好地让高级管理层达成一致认同，其实可以从更完整更合适的产品垂直切片开始。

我们从尽可能好的起点开始，然后逐渐沿着各种整体组件层次往外扩展BIOS组件的边界。BIOS的特性团队导入地图以及初始的BIOS组件边界和扩大的BIOS多组件边界这些图呈现了这种增量扩大。敏锐的读者会注意到这种方式与《大规模Scrum》书中描述的特性团队导入地图指南相一致。

BIOS面向LeSS的导入工作因VP/GM的变动而受阻，恰好发生在米提亚和我开始变革的时候。如果能保持与原先VP/GM同等的管理层支持，那么我们很可能会取得更广泛更持久的成功。

我从中岛公司MCS部门面向LeSS的导入工作的成功和失败中学到了很多。希望当你从我们的成功和失败中学习时，本案例能帮助你在旅程中有所指引。

初始重点在固件而非硬件开发

从历史上来说，大多数的版本时间表预测问题都发生在MCS产品开发组的固件（比如BIOS、网络接口控制器、机框控制器等）和更高层级的软件（比如MCS管理员、诊断等）开发部分。而硬件开发部分通常更能预测。

实际上，我只花费了少量时间与为外部制造商设计生产规范的人员交谈。虽然把LeSS导入扩大包含进硬件设计工程师从长期来说是合理的，它并不是我的初始重点。

实际上，我花费大多数时间一起工作的诊断团队和BIOS团队都不需要跟硬件工程师活跃地协作。任何时候固件工程师有需要，就会去找硬件设计工程师交谈，只是不经常发生而已。我在参与MCS部门的时候MCS产品已经相对成熟；从而大多数硬件设计改动通常比较小且增量。将来有机会可以通过更宽泛的跨职能团队 - 更紧密地集成硬件和固件开发 - 来鼓励更大的创新。

展示Scrum团队的好处

在MCS部门最初存在许多对Scrum是否适合硬件和固件开发工作的怀疑。他们认为固件和硬件工作与典型的企业软件开发不同，因此并不适合使用Scrum（具有讽刺意味的是，原先80年代来自哈佛大学Scrum根源的研究就涉及硬件产品）。这一观点因事实上MCS内所有先前存在的“敏捷”开发工作都不与硬件和固件开发相关而得到加强。

考虑到这种情况，合理的做法会是应用增量的LeSS导入指南，使用特性团队导入地图来识别一个有意义的多组件边界，建立起一个健康的Scrum团队，并能展示有用的结果。这是说合理的做法是展示一个小团队的价值，他们拥有解决问题的所有技能，直接与有问题的客户工作，并且迭代地、适应地和增量地解决客户问题。

我们希望能获得额外的政治资本，通过展示：

• 固件/硬件Scrum
• 自管理团队
• 改善客户协作
• 改善价值交付
• 结构对文化的影响
• 提高代码质量
• 避免合同游戏

多组件试点的理想特征

为了实现上述展示的目标，我们需要识别出适合让试点Scrum团队专注的的MCS产品功能集。我认识到，如果我们能够识别一组基本隔离和解耦的多个组件，它能映射到整个产品中的一个自然LeSS巨型需求领域（RA），那么成功的机会将会最大。(请注意，RA并不是由组件或架构的边界来定义的，但有时功能的RA和相关代码体有很大的重叠，这在前期步骤下是一项优势，可以简化导入）。

下面的标准描述了我们预想识别的多组件组。我们想要一组组件……

• 贯穿MCS的“前端到后端”
• 适合单个团队的能力
• 为客户提供有意义的价值
• 其成功交付在政治上难以忽视
• 可以保护团队不受交付压力的影响
• 代码库与MCS系统其它部分至少适度解耦，以避免瀑布式开发大军的糟糕实践

另一个我们可以没有但希望也能找到的标准是：

• 一组可以独立于瀑布式MCS发布的组件；从而提供来自真实客户的更快反馈

为试点Scrum团队识别的合适诊断特性集

我们与特伦特和组织内的其他人进行了一些深思熟虑的讨论，以找到好的候选组件集。结论是什么？MCS的诊断特性集结果是一个非常好的选择，因为它满足了清单上的每一个项目。

在客户支持成本方面的巨大财务节省和相关的声誉利益有助于提供政治上的掩护，同时也能在现场支持部门产生热情的支持。诊断特性集是唯一明显符合我们标准的特性集，但它的匹配度非常棒！

诊断团队行为成就

从最初启动大家就开始在行为上跟以前有所不同。在四或五个迭代之后，改变的行为包括……

• 在整个诊断Scrum团队和现场支持部门的工程师之间积极协作
• 一个协同工作而非只有个体的团队，每个迭代增量地调整和改进他们的实践，总能产出可交付的组件增量，并和关键干系人建立了丰富直接的协作关系
• 一份多组件的待办列表，其排序受到现场支持和另一个协作部门所产出度量的很大影响。这些度量让我们能为大多数构想的诊断能力指定一个估算的每月延迟成本。高优先级诊断能力的预期节省是惊人的！

诊断团队技术成就

一个显式并扩展的完成定义、有效的Scrum活动、少量技术指导，以及避免合同游戏，这些加一起在技术实践上产生了巨大的变化。

在四到五个迭代中，很容易观察到如下：

• 诊断团队触碰到的MCS任何部分的C++和Python代码都有自动化单元测试
• 自动化单元测试实践，为所有诊断特定代码和整个MCS代码库的一些部分能有更精心编写的代码和更少的麻烦代码，起到了一种强制作用
• 积极开发比以前为MCS系统存在的更完善、更广泛的自动化集成测试

诊断团队启动步骤

我们的成功并不神秘。步骤包括：

• 将LeSS指南临时伪PO应用于诊断多组件，确认了一个有利于支持和指导团队的人格，他有足够的地位和政治影响力，其决定会得到各干系人的尊重。
  • 这个人是伪PO，因为他们仍然要玩合同游戏，按照公司其他人的指示做需求并遵守里程碑。
• 组建了一个由八人组成的开发团队，拥有所有需要的（或可以学到的）软件和测试工程技能，以在要求的各种MCS子系统中工作。
• 完全占据一间中型会议室，作为开发团队的联合工作空间。
• 我为所有Scrum团队成员以及关键干系人提供了两天正式的课堂培训。
• 我们进行了一次协作的章程制定工作，包括两天专门的章程制定会议，以及各种准备和跟进会议。这有助于实现干系人和Scrum团队成员之间以及他们内部的整体对齐。
• 在最初的几个迭代中，我提供了积极的管理、流程和技术指导，然后将大部分精力重新聚焦于即将在MCS部门BIOS组发生的面向LeSS的导入上。

更多关于启动团队的指导，请参阅《大规模Scrum》书中的开始指南。虽然它是从在LeSS结构中启动多团队的角度写的，同样适用于启动一个试点Scrum团队。

诊断团队照片和工件

诊断团队文化相关的要素

一些试点工作相关的文化观察被列在下面。它们中的许多也有助于更好地理解随后BIOS组面向LeSS的导入。

第一条和第五条拉曼组织行为法则的表现

第一条和第五条拉曼组织行为法则分别是：

• 组织隐含地被优化成会避免改变现状中的中层和初级经理以及“专家”的地位和权力结构。
• （在大型成熟组织中）文化遵循结构。而在小型年轻组织中，则结构遵循文化。

所有五条拉曼组织行为法则都可以从LeSS网站上LeSS结构页面找到。

即使在较小的诊断试点Scrum团队中，第一条和第五条法则也明显可见。在有效的结构和由此而来的文化上，正向变化只局限于诊断团队以及他们积极协作的干系人中。相反，大多数中层管理的现状基本没有变化。

诊断团队扩大的组件边界涉及MCS系统中的许多不同组件。这些组件中每一个通常都有自己的一组工程师，并在每个地理区域有一位经理，往上汇报给两位VP中的其中一位。诊断开发团队的建立是通过让每一位相关经理完全分配一位有相关模块知识的软件或测试工程师。考虑到整体瀑布开发的交付压力，经理们是挺不愿意把人分配给诊断团队的。他们最终这么做只是因为原先的SVP要求所致。

当Scrum团队开始运转时，通过来自原先的SVP的许多政治压力和正式指示，才使得第一第二级经理停止试图给诊断开发团队个体成员指派不相关的工作。一些开发团队成员不得不被正式指派给一位与诊断工作相关的经理，才得以终止这些问题。

就像拉曼组织行为法则所预测的那样，让Scrum开发团队成员汇报给同时承受来自整体MCS产品交付压力的工程经理是很有问题的。虽然SVP的支持缓解了这个问题，组织结构图从未完全扁平化。许多开发团队成员仍继续往上汇报给其中一位从未完全拥抱变化的VP。唯一涉及的汇报变化是由哪位主管负责一些诊断Scrum开发团队成员。

与LeSS书中指南的对比

乍一看，诊断试点与第三本LeSS书《大规模Scrum》中的并行组织一致。很遗憾，至少有两点有害的差异。

当描述并行组织的策略时，拉曼（Larman）和沃代（Vodde）列出了一些告诫。第一条列出的告诫是：

一个并行组织并不是一个试点，由此而来的一项后果就是它的组织汇报线独立于与传统组织。

诊断团队的有效团队层面结构被显著改变以与Scrum一致，然而正式的组织汇报关系却保留了下来。这一失败让团队非常易受高层管理变动的影响。

尽管诊断团队从未受合同游戏影响，诊断团队成员却还是汇报给参与到整体瀑布工作合同游戏中的中层经理。当中层经理为有更多开发产能投入到即将到来的瀑布发布而感到绝望时，他们越来越多回到之前重新指派诊断团队个体成员工作的行为。尽管原先的工程SVP/GM积极保护诊断团队免受其害，一旦他离开了，遗留的现状就开始侵蚀让诊断团队早期成功的支持性环境。

第二个关键差异是诊断团队被看作是一个展示案例，而不是最终会形成一个并行组织的许多团队中的第一个。换句话说，诊断工作并没有被看作是在执行一个被高管承诺的集体决策 - 逐渐把所有MCS开发转成面向LeSS的结构 - 的第一步。

相关参考

最新版的LeSS规则可以在LeSS网站上找到。

以下LeSS规则看起来特别相关：

• “LeSS规则：对产品组从一开始就建立完整的LeSS结构，这个对LeSS导入至关重要。”

因为只建立了一个团队，我们明显没有做到这一点。虽然从一开始就创建了诊断团队层面的结构，我们没有做到改变汇报关系，并削平与诊断团队相关的组织机构图。

《大规模Scrum》提供了以下相关指南：

• 指南：构建基于团队的组织：特别关注这个指南中论述设立稳定组织优于动态矩阵结构的部分。
• 指南：LeSS组织结构：包含如下引述：“LeSS组织没有矩阵结构，也没有虚线经理。”
• 指南：转向特性团队：提供了各种转变策略的高度概括。
• 指南：一次一个需求领域：详细说明了LeSS巨型导入的一个增量方式。
• 指南：并行组织：详细说明了作为一个导入策略的单独组织创建。列出的告诫尤其富有洞察力。
• 指南：特性团队导入地图：提供了更多洞察用以可视化特性团队职责的逐渐扩大，如以上图4所呈现的那样。
• 指南：演进完成的定义：解释了完成的定义可以如何用来更显式地可视化增量改进以及与各个干系人的关联。
• 指南：开始：不仅适用于一组团队，同样适用于单个团队

对于高层管理变更的反思

尽管新的SVP以他自己的方式也是很能干的，并且具备一定的技术水平，他却缺乏他所替代的短期的总工型SVP所具有的工程洞察力。

现有汇报给SVP的高层管理缺乏与具备良好软件工程实践的像样敏捷团队的真实接触。没有这样的经历，就难以取得对更大变革的支持。

没能避免合同游戏，以及想要自我保护现有的权力结构，使得很多人难以欣赏并接受所发生的改进。这恰恰是之前提到的第一条拉曼组织行为法则所预测的。

如果我那时就有智慧和技能意识到需要举行一个类似认证LeSS高管的管理层工作坊，聚焦帮助高管来对变革形成拥有而非租借的态度，那么事情也许会有不同。如果我在还有原先的SVP支持的时候这样做，原先的SVP可能会被认为做出了足够大的改变，从而在部门层面之上的政治力量下存活下来。

如果没有别的作用，一个管理层工作坊，结合对变革知情同意的工作坊，至少有助于突显出软件VP的消极挑衅行为。

让大家更多意识到持续文化变革所需的组织结构变化量级也有风险，也可能在形成增量收益之前就停止了任何改进。然而，如果原先的SVP在一个管理层工作坊之后愿意承诺面向LeSS的导入，反转导入进程也会变得更难。

在新的SVP出现那时，大量裁员和破坏许多有意义改进的前景其实已经注定。我只是还不知道，在接下来一年中都不知情。

对于所取得的仍有很大的收益。由试点诊断团队开发的诊断功能继续节省着百万成本。在老的组织结构下不太可能实现同等质量的诊断能力。在BIOS生产代码、BIOS测试基础设施，以及BIOS团队组织规范上所做改进产生的积极影响已经大到无法完全被反转。

开启的头脑看到的世界永远不再一样。类似地，嵌入在生产代码中的改进也将持续数十年。

BIOS管理层的兴趣

随着诊断Scrum团队开始定型，我开始寻找MCS的另一个领域来关注。我再次借助了特伦特的组织动态知识。和以前一样，我们希望逐步转向特性团队，同时聚焦于有充分管理层支持的领域。鉴于诊断Scrum团队工作的有效性，稍微广泛点的范围已经变得更加可行。尽管如此，我仍然是唯一的教练，而且当时也没有足够的资金来增加辅导能力。

有一位主管，米提亚·杜宾克西（Mitya Dubinksy），虽然最初有些怀疑，但他对可能的收益表示了兴趣。在几周时间里，我使米提亚的思想过程更进一步。在这一努力中，我得到了米提亚的一位名叫克里希纳·米什拉（Krishna Mishra）的同事的协助。克里希纳在诊断试点Scrum团队工作中发挥了关键作用。克里希纳还碰巧管理着一组工程师，他们经常与米提亚的小组互动。

米提亚的小组负责为MCS提供一个定制BIOS。BIOS是用于在启动过程中对计算节点（刀片）进行硬件初始化的固件。它还为在MCS内的计算节点上运行的任何操作系统提供运行时服务。就MCS和其竞品而言，定制BIOS是使远程管理每个节点的硬件设置，而不需要实际访问硬件，成为可能的部分原因。当你认识到硬件通常是在一个遥远的、人员稀少的服务器群时，这种访问就显得尤为重要。

BIOS概览

定制BIOS代码很容易成为整个MCS系统中最具挑战和最专业化的软件开发部分。大部分剩余系统是由运行在成熟芯片组和在专用设备硬件的精简Linux操作系统上的C++、Java和Python中间件组成。其中一些系统需要在低功耗和内存限制的环境下竞争资源，但这与BIOS工程师必须应对的挑战相比微不足道。尽管如此，BIOS组仍然是管理层最渴望改变和改进的组。

市场生存能力要求中岛公司开发定制BIOS足够快，以跟上英特尔处理器的版本。虽然AMI提供了BIOS固件的基础，但由于中岛公司历来工程实践较差，以及缺乏跨职能的多面学习团队，这意味着它仍需要一组40个甚至更多的高度专业化的硬件、软件和测试工程师为MCS定制BIOS工作，才能与英特尔保持同步。

尽管主要的BIOS版本往往与MCS大版本相对应，但有时也会发布较小的独立BIOS版本。较小的独立版本通常由英特尔硬件的次要修订或者MCS定制BIOS所基于的AMI代码库的次要更新所驱动。

考虑到BIOS直线管理层对改变的渴望，以及缺乏软件VP的支持，明智的做法是在硬件VP和质量保证VP的影响力下去追求可能性的艺术。我们决定定义一个仅限于定制BIOS的组件边界，然后随着BIOS团队的成熟再慢慢扩大边界。

在宏观层面上，BIOS仅仅是整个MCS系统的一个组件，但在微观层面上，面向LeSS的结构的每一点都是完全相关的。BIOS组件本身又由很大一组子组件构成，而它们超出了本文的范围。

MCS部门拥有数千名工程师，他们专注于MCS产品的各个方面。在BIOS组件团队范围内改进工程实践以及交叉培训之前就开始更为广泛扩大的BIOS多组件边界，可能会出现问题。整个MCS的工程实践是相对糟糕的，就像你可以从好多年来的合同游戏中所预期的那样。在最初的BIOS组件边界内已有足够多的质量问题和工程陷阱，足以消耗掉我们所有的辅导精力。

LeSS建议在三个层面（组织、团队和技术）进行辅导，如此所述，我涵盖了所有三个层面。我在班加罗尔帮助特伦特面试并招募了两名教练，但我是西半球MCS部门唯一的敏捷教练。如果在我任职的前两个半月里没有失去原先的工程SVP/GM，那么教练容量的局面可能会有所不同。由于新的工程SVP/GM希望缩小部门规模，并且没有完全理解敏捷导入所需要的工作量，我们能有这些辅导力量已属幸运。

BIOS自下而上的扩大

根据LeSS所述：

LeSS巨型导入大致有两种方法：

1) 一次一个需求领域

2) 逐渐扩大团队的工作范围、完成的定义，以及产品的定义

— 源自于此

我们采用了第二种方法，尽管第一种方法（一次一个需求领域）意味着更具影响力的组织变革。

BIOS面向LeSS的导入并不是由以客户为中心、以整个产品为中心的原则直接驱动的。而是面向LeSS结构的机制被视为BIOS团队正面临的许多透明度、协调性、以及质量问题的一个解决方案。

我们致力于扩大BIOS多组件边界直到它与MCS产品的自然功能集达到一致。最初BIOS团队或管理层并不清楚这其中的好处，但随着时间的推移，这些好处变得越来越明显。这些意识的提高是由多种因素推动的，包括：由BIOS团队外部依赖关系所导致障碍的透明度得到了提升，有效的回顾会议带来每个新迭代中有意义的实验，还有我的持续辅导。BIOS组件边界扩大了章节将会提供更多细节。

不太寻常的是，LeSS团队扩展多组件边界是从整个产品架构中的一个深奥的组件开始，然后再慢慢向上扩大到用户界面。虽然这不寻常，并不是导入LeSS的理想起点，但这却是管理层对变革有认同和兴趣的地方。即使在不太理想的起步条件下，只要发挥团队的创造潜能，就能取得显著的成就。

“介于两者之间”的BIOS团队

为新组建的BIOS团队选择一个好的形容词是有点困难的。

新组建的BIOS团队比传统BIOS团队更跨职能。每个团队都有责任和能力修改BIOS并端到端测试任何改动。

新组建的BIOS团队也从一开始就自管理，并同处一地。尽管由于裁员和其它组织变动，这些团队并没有像我和米提亚所期望的那样长久。

《大规模Scrum》书中的特性团队导入地图指南提供了几个有用的定义来描述团队。其中两个是：

扩展组件团队——任何组件工作范围有限，但仍负责检查他们这部分能否在更大产品中工作的团队，就是一个扩展组件团队。

特性团队——任何以整个产品为中心，并参与从澄清客户导向的特性到测试它们的团队，就是一个特性团队。特性团队也有不同的程度。他们可以仅限于实现那些被需要的特性。或者，当产品定义足够广泛时，他们可以参与识别和解决客户的实际问题，从而在整个系统上共创产品。

新组建的BIOS团队从其构成就有能力作为扩展组件团队。他们有能力和责任对所做的任何改动执行端到端测试。测试是从MCS图形用户界面（代码不是他们写的）扩展到机框控制器（代码也不是他们写的），再到节点控制器（同样代码也不是他们写的），最后到英特尔CPU上运行的BIOS代码。相比之下，新组建的BIOS团队编写的代码最初仅在图8中详细描述的初始BIOS组件边界内。如你所见，这与扩展组件团队的定义完全一致。

新组建的BIOS团队最初未能满足特性团队的定义。要成为特性团队，需要包括从前端到后端的所有相关代码。虽然在我任职中岛公司MCS部门期间，BIOS团队从未完全实现这一目标，但他们取得了一些进展。

总结一下，新组建的BIOS团队：

1. 是从自管理和同处一地的扩展组件团队开始的。
2. 旨在成为扩大的组件团队来涵盖在BIOS组件和MCS图形用户界面组件之间通信路径上的更多组件。
3. 计划通过将其职责扩大到交付端到端特性所需的“一切”，从而成为特性团队。

BIOS组织背景

BIOS面向LeSS的导入发生在公司高管层活跃变动期间。当开始BIOS导入时，负责所有硬件开发的VP非常支持，还有组织中其他几个VP也是如此。这足以使初始的导入工作在短期内成为可能并取得成功。当SVP和VP级别的管理层发生变化时，我们失去了很多所需的支持，尽管大多数相关人员普遍认为我们的工作是成功的。新SVP的摇摆、支持我们的硬件VP的流失，再加上大规模裁员，最终侵蚀了我们的进展。下面一系列组织架构图可以帮助突显当时的情况。

BIOS的组件边界和地理位置

由于历史原因，现实是每一代新硬件都有一个完全独立的BIOS代码库，几乎没有提取任何通用功能成为可重用的子组件。

有趣的是，这提供了一个以更可持续的步伐去发展BIOS团队的机会。当先前未参与的BIOS开发人员完成前几代硬件缺陷的修复工作时，我们就可以在面向LeSS的结构中组建额外的跨职能团队。BIOS代码库的动态以及其与AMI的关系将在下面更详细地解释。

在需要更积极地影响印度的BIOS开发人员和经理之前，基于在美国向米提亚汇报的人员建立的跨职能BIOS团队有半年的缓冲。当印度BIOS工程师开始与美国BIOS工程师工作于同一个BIOS代码库时，美国BIOS工程师这时已经足够定型，从而能对还没未加入跨职能BIOS团队的印度工程师没达到同等质量标准的情况进行抵制。

最初的抗争通常很简单，诸如确保印度的BIOS工程师足够当心，只有在干净构建并通过基本的冒烟测试时才提交代码。额外的自动化测试，以及一个由跨职能BIOS团队直接控制的私有CI服务器，帮助美国团队在问题被某个不遵循质量标准的开发人员引入时就能检测到。

跨职能BIOS团队的成功让米提亚和我处于更强的政治地位，从而可以开始解决根本的结构性问题。米提亚应项目管理SVP的要求，就跨职能BIOS团队的改进在全中岛公司做了演讲；我们的成功显然引起了注意。

对于印度的BIOS人员来说，显而易见的解决方案是将他们作为一个或两个额外的跨功能BIOS团队加入。理想情况下，所有这些结构性问题从一开始就已经得到解决，然而当我们开始时，这在政治上并不可行。相反，我们做了能做的。我们有意创造性地隔离并拖延了这个问题，同时为未来的政治胜利做好准备。我们不仅预计到了两种不同运营模式之间的摩擦，还依靠它在将来实现有意义的结构变革。

米提亚和我当时已经准备好前往印度，如果不是支持我们的硬件VP辞职并宣布裁员的话，就要开始解决政治问题了。如果硬件VP还在，我认为我们将能够解决BIOS组件边界内更紧迫的政治挑战。我们已经有了一个印度的BIOS经理站在我们这边，但还需要解决主管层面的一些问题。

单独的代码库不好

每一代新硬件都有一个完全独立的BIOS代码库，这不是一件好事。我们善加利用了这一事实，但这远不是我们想要的。

有太多的复制粘贴重用，自动化测试覆盖率不足以让开发人员自信地进行向后兼容的改动，以及未能使用AMI插件层将任何与MCS相关的改动与AMI代码库改动隔离开来。

这种自我造成的过重负担使其更难适应英特尔CPU的变化。具有讽刺意味的是，比英特尔发布周期更快地适应英特尔CPU变化的能力对MCS部门收入和市场份额的持续性至关重要。

开始解决这些问题的努力可以在稍后讨论的BIOS完成的定义部分中看到。

BIOS地理位置分散的团队

从优化最高级别的适应性以服务于学习并交付全局最高的价值这个角度来说，就不应该有那么多的工程师工作在这个产品上。就分布在多个地点和时区的工程师而言，也是如此。然而，这就是我们的起点，从一开始试图说服组织不要这样做是不会成功的。

为英特尔发布日期做好准备的关键性，再加上遗留代码库中大量使用了复制粘贴，使得这一局面充满挑战。如果没有大多数美国BIOS团队成员的共同努力，就不会有足够的整体知识来及时做出所需要的更改，并同时解决导致这种情况的不良工程实践。相比之下，增加另一个处于完全不同时区的地区只会拖慢进展。

LeSS书中的一些不同引用有助于突显这一点：

“从一小群很棒的人开始，并且只有真正开始痛的时候才增长。”很少这样发生。— 《精益和敏捷开发大型应用指南》

不去争论是否需要这么多人，而是试图支持大家用敏捷和精益原则来提升开发水平，以便在某个时候，团队自己会清楚他们在太多的地方有着太多的人。— 《精益和敏捷开发大型应用实战》

质量保证小组的命名很糟糕

意识到质量问题不能在事后被保证是很重要的。为什么？产品质量是整个产品开发系统的结果，而不是单独的质量控制小组的责任。虽然测试组的正式名称是“质量保证”，但更准确的名称应该是“质量控制”。

质量保证这个说法合适的使用应该是指诸如建立测试先行或测试驱动开发、建立有效的代码评审实践、实施静态代码分析工具、建立持续集成的行为，以及建立结对或群聚编程等活动。请注意，以上活动没有任何一个是在软件开发被认为“代码完成”或类似说法之后尝试保证质量。

质量保证小组的名称实在很糟糕。甚至连命名本身就意味着对如何最好地开发高质量产品有着错误的心智模式。然而，为了历史的准确性，我将继续把包含遗留结构中所有测试人员的组织分支称为质量保证小组。阅读本文时请记得这一差别。

BIOS测试人员带来端到端的知识

MCS的广度和复杂性，再加上一直以来的过度专业化，意味着很少有人像测试人员那样了解端到端产品，他们以前在传统结构中花费大部分时间进行端到端测试。因此，测试人员为他们各自的BIOS团队带去的价值与传统的BIOS固件开发人员一样多。

BIOS团队里有测试背景的成员仍然正式汇报给质量保证VP。她和相关质量保证主管的支持对于实现在BIOS团队中事实上的平等至关重要。保持这种正式的汇报关系有助于获得组织对BIOS面向LeSS团队大幅提高的质量的认可。

为测试人员保留单独的汇报结构会带来一定程度系统性的组织脆弱。质量保证VP角色的变动很容易就能瓦解正在发生的许多积极变化。作为一个长期目标，在组织架构中消除任何正式的专门区分测试将有助于避免具有测试背景的团队成员被其它与他们团队迭代待办列表不相干的工作转移注意力的风险。

《精益和敏捷开发大型应用实战》中的第三章全面介绍了在实践和战略层面如何最佳地对待测试。

扩大的BIOS多组件目标和限制

尽管从未在电子邮件、白板涂鸦和口头对话之外正式记录过，但BIOS的LeSS导入目标包括：

• 提高MCS的BIOS适应任何MCS硬件未来变化的能力，尤其是对英特尔芯片组的例行定期更新。
• 创造一种重视技术卓越的文化，避免由合同游戏带来的无益压力。

BIOS对最新英特尔芯片组的支持很难成为MCS产品与其竞争对手之间的重要差异点，但在英特尔发布期间缺乏对等的支持则会让我们在一夜之间大幅降低市场份额和收入。整个部门的管理层都很清楚这一事实。因此，以下约束条件至关重要：

• BIOS敏捷导入的工作永远不允许成为MCS产品无法支持英特尔CPU生产版本的原因。

因此，尽管BIOS的适应性目标在高级管理层心目中的地位并不如米提亚那样，但该目标的重要性仍然默认得到了充分理解和重视。

尽管有这样的共识，但传统瀑布式开发带来的紊乱程度并没有被广泛地承认。整个部门都仍可以看到合同游戏、糟糕的工程实践，以及过度专业化。

如果你反思上述目标，你会发现它们与《大规模Scrum》书中提到的组织完美愿景指南中的LeSS完美愿景非常相似。你还会发现，它们与该指南从局部优化中识别真正系统改进的两个问题也有很强的关联。

为了支持上述目标，BIOS组内的目标包括：

• 建立单一的BIOS组件待办列表，以使最高价值的BIOS工作更加可见。渐进地迈向一份单一的产品级别待办列表。
• 扩展每个工程师的知识和技能，以涵盖产品的更广泛部分；从而提高每个团队的适应能力，以及切换并专注于新发现的最高价值工作的整体能力。
• 在转向一个扩大的、跨越MCS更大部分的BIOS多组件边界的同时，增加每个BIOS团队的“整体产品焦点”（一个LeSS原则）。
• 致力于改进围绕MCS的BIOS组件的匠艺实践。
• 尽可能避免合同游戏。

仅从图中就能看到的BIOS导入故事

当你有足够的上下文来理解时会发现，把时间线图、组件边界图、特性导入地图、组织结构图，和特性团队按硬件代次扩展图，以及每个图的相关说明放在一起提供了一个相当清晰的整体故事架构视角。

BIOS的工程和文化挑战

希望你现在对定制BIOS系统在MCS中所起的作用有了相当程度的理解。在试图避免过于深入细节的同时，我将尝试总结BIOS团队面临的一些工程和文化方面的挑战。如果这对于你来说过于详细，请随意跳过。

AMI提供了BIOS代码的基础

为MCS计算节点定制的BIOS是通过修改一个AMI许可的持续更新的代码库创建的。驱动AMI进行持续BIOS代码库更新的典型事件包括：

• 英特尔在其原型芯片组或参考板设计中改变了硬件到固件接口的一个方面
• AMI增加了由英特尔芯片组原型或参考板设计的一些改善特性所带来的新BIOS功能的支持
• AMI修复了一个它或者其许可合作伙伴发现的错误
• AMI基于他们认为合理的任何原因决定更改BIOS代码库

如果MCS的BIOS定制和AMI代码库之间的接口基本稳定，那么这些常态化的AMI更新带来的影响就可以最小化。可惜这种情况很少发生。尽管AMI代码库中存在一些正式插件功能，但中岛公司的大多数BIOS定制一直都是深入到AMI代码库内部。

对于每一个新芯片组，MCS的BIOS工程师都会尝试将旧BIOS版本适应旧芯片组的定制功能复制到新的原型芯片组的代码中。同样，MCS的BIOS工程师会尝试与任何AMI代码改动保持更新，将它们合并到活跃的工作分支上，然后手动重新测试。有些测试仍需要在实验室里亲自动手，尽管有更多测试是可以被自动化的。

英特尔发布驱动的死亡行军文化

市场节奏被英特尔芯片组的发布日期所主导。硬件集成商可以尽早获得原型芯片组和参考板架构。能够在英特尔发布日期同时发布对于在市场上保持竞争力至关重要。

明智的组织设计决策应该是优化提高对英特尔规格变化的响应能力。可不幸的是，传统的组织反应是将大量的人投入到这个问题上，然后朝发布日期死亡行军。在即将到来的发行日期面前，质量永远都是不可避免地被牺牲。

中岛公司MCS部落知识的丢失

多年来，许多最初建MCS系统组成部分的人离开了中岛公司。当这些人离开时，他们的部落知识也随之丢失了。理想情况下，应该在测试金字塔的所有级别都有广泛的自动化测试，以及精心制作的可读代码。至少会有一些有用的文档详细说明整个系统架构。但是正如你对在瀑布文化的交付压力下开发的任何复杂产品所能期待的那样，这些几乎都没有。

英特尔BIOS的高度专业化

AMI估计全世界只有几千名熟悉BIOS定制的工程师。许多x86硬件固件接口行为和实际规范需要追溯到PC革命早期的部落知识。

实际上，MCS的BIOS中的每个定制领域都是一两个工程师深入挖掘AMI代码库并对其进行逆向工程的结果。在某种程度上，这与任何专业软件工程师日常做的事情并没有什么不同，差异只在于BIOS开发中更为深奥和频繁。

分布在三个地区的大量工程师

有足够的工作让大约四十名工程师忙碌。随着更好的匠艺实践，最终需要的人可能会远比这少。虽说如此，仅解决所有自己造成的技术问题就要花费巨大的工作量和对齐。

由于历史原因，专注于BIOS的软件、硬件和测试工程师遍布波特兰、旧金山和班加罗尔。任何扩大团队规模的计划都必须解决地理分布的问题。幸运的是，我们在某种程度上能够自组织形成同处一地的团队。此外，班加罗尔的工作多少独立于波特兰和旧金山的工作。

多半先天的技术挑战

尽管MCS的BIOS团队面临的许多挑战都是自己造成的，但有些挑战很大程度上是工作本身固有的。其中包括：

• 定期会有原型芯片组和电路板的硬件更新。制造新电路板设计通常的前置时间约为六周。有人可能会说，其中一些问题与其说是物理问题，不如说是组织障碍。
• 原型芯片组有问题的可能性与固件同样大。因此，测试和故障排除的重要方面需要在实验室实际操作。
• x86的BIOS工具链非常陈旧，因为AMI没有足够的经济激励来进行重大投资以改进工具。
• 在整个全球x86的BIOS开发文化中，诸如自动化单元测试这样的软件工程实践基本都是缺乏的。我们可以在MCS的BIOS团队定制的AMI代码库中清楚地观察到这种文化历史。这导致了以下并发症：
  • 任何单元测试工具都必须完全手工搭建。
  • 将有效的依赖反转机制嵌入AMI的BIOS代码库比在典型的Java或C#框架中要困难得多。
  • 没有书籍、文章、论坛帖子、示例代码或其它资源可用于指导在BIOS环境中的单元测试。
  • 对于MCS的BIOS工程师来说，自动化单元测试的概念是完全陌生的，更不用说测试先行或TDD实践了。
• 底层固件开发的任何事都比一般软件开发工作更加乏味。与MCS的BIOS相关的几个例子包括：
  • 不存在操作系统服务，因为没有操作系统。
  • 代码必须经过交叉编译，然后闪存到目标。
  • 在BIOS启动流程的早期阶段还不存在TCP/IP网络栈，这使得早期与目标设备通信特别困难。与目标设备的早期通信仅限于串行端口通信和类似的受限机制。
  • 大多数固件开发工程师，相比软件工程专业知识，通常更懂微电子工程专业知识。

这里列出的问题没有一个是无法克服的。在许多情况下，来自诸如大型web应用程序开发之类其它领域的技术已经提供了如何解决这些问题的方向。

例如，Java和C#都有现成先进的依赖注入框架。詹姆斯·格伦宁（James Grenning）的《嵌入式C测试驱动开发》就是一个尝试帮助改进这些技术交叉传播的例子。

BIOS导入工作

米提亚和我意识到我们的努力有个令人生畏的范围。我们用来建立、启动和帮助BIOS功能团队变得成熟的步骤与我在诊断团队中所做的基本相同。主要差异在于所涉挑战的难度和规模。

主要差异大多集中在相当直接的规模方面。

BIOS启动步骤

米提亚和我决定首先聚焦于旧金山和波特兰的工程师。旧金山和波特兰主要专注于把新的英特尔芯片组和电路板设计运行起来。班加罗尔的工程师则主要专注于解决支持已经投入生产的芯片组的问题。

我和米提亚一起为旧金山和波特兰每一位MCS的BIOS工程师安排了Scrum培训。我们确保包含了一些来自另一个小组但跟我们紧密协作的测试工程师，以及一些其他相关方。如果我没记错的话，在三周的时间里，我在旧金山进行了两场培训，在波特兰进行了一场。米提亚参加了在旧金山的每一场培训。米提亚没有参加波特兰的培训，但是克里希纳·米什拉在那里提供支持。但在不到一周后的后续启动步骤中，米提亚确实和我一起飞到了波特兰。

启动工作被拆分成跨旧金山和波特兰两地进行。最初两天的启动活动于周四和周五在旧金山进行，而波特兰的BIOS团队成员通过电话会议拨入。接下来的那周，我和米提亚则在波特兰会面，与波特兰团队成员继续启动工作。这为波特兰团队成员提供了一个更好的机会来影响、调整和核定前一周的工作。在波特兰的启动工作期间，我们经常有旧金山的团队成员拨入。

在启动活动期间，我列出了我们需要实现的所有东西的清单，确保每个人都理解每项的意图。然后，我基本上往后站，尽可能让团队来驱动，只在需要时才介入。该清单包括创建初始的BIOS组件待办列表、确定一个共同的完成定义、决定各个团队的边界，以及制定事件的时间表。

BIOS组件待办列表

启动工作中最有趣的部分是围绕组件待办列表的创建。把下一代英特尔芯片组运行起来所需的知识在整个团队里分得很散。没有一个团队成员有很好的整体理解。解决方案包括：先是两天头脑风暴，然后以小的工作组进行各个产品待办条目的详细梳理，最后是增量的故事构图工作。

初始组件待办列表头脑风暴

最初的BIOS组件待办列表头脑风暴的结构是相当标准的，不同之处在于达成的有用细节程度和对齐水平，以及做好它所需的时间。

这里BIOS工程师只是在做一些他们以前集体做过很多次的事情。只要他们共同工作，从彼此的头脑中汲取必要的知识，他们有能力创建一份包含几乎所有需要内容的庞大而详细的列表。回想起来我相信，是诸如复制粘贴重用和依赖手动测试之类糟糕的软件实践导致了BIOS工程师在每一个新的英特尔芯片组上大部分时间都在重复相同的步骤。

我们一起把能想到的每一样都写在便利贴上，贴在我们预定的大会议室的窗户上。然后米提亚或另一名团队成员带领团队过每一张便利贴。我们再收集便利贴放入合理涌现出的分组中，同时合并重复项。在讨论每一张便利贴以达成共识的过程中，只要合理参会者就会即时生成新的便利贴。然后我们会花多些时间以小的工作组来生成新的便利贴，再回到一个讨论环节以整合所有内容。这花了我们第一天的大部分时间。在第一天结束时，我们转向启动清单上的其它项目，约定让大家为第二天准备更多便利贴。

第二天早上，我们继续进行BIOS组件待办列表的头脑风暴活动，在午餐时结束了头脑风暴。然后我们继续完成启动清单上的其它事情。

我们有足够的组件待办列表来支持第一个迭代，但是还未达到我们想要的并可能达到的有用细节程度。如果这是一个在更典型软件工程环境下开发的新产品，我认为我们所做的将会是浪费。然而在这里我们有效地整理和记录了多年的部落知识。

《大规模Scrum》中的初始PBR指南更详细地介绍了初始产品待办列表梳理。一个动力是：

有限的客户视角知识。

即使以前的条目是以客户视角表达的，因为之前孤立专家只关注狭窄的任务，所以仍不理解完整的客户视角。

《精益和敏捷开发大型应用实战》的第5章：计划中也有各种相关的实验。最直接相关的是尝试……以一个初始产品待办列表梳理工作坊开启大规模Scrum。

初始BIOS组件待办列表梳理

在前两个迭代过程中，我与那些对启动时创建的BIOS组件待办列表的不同方面最为了解的工程师小组一起工作。我提醒每个工作组注意INVEST测试，并帮助他们工作于创建几个PBI。一旦一个组对好的PBI切分应该是怎样的有所感知，他们就会继续对他们所了解的每一个PBI进行梳理。大多数情况下，在他们进行时我会留下来支持。每个工作组通常需要一两个小时来掌握如何将一行描述转换成带良好验收标准的PBI。然后工作组会再花了一两个小时将其余相关的高优先级PBI梳理成精细的PBI。这些工作组中的开发人员通常跨越了我们在启动时组建的两个或多个BIOS特性团队。

一旦我们觉得在BIOS组件待办列表中有了足够的细节，米提亚和我就转向故事构图和相似估算。米提亚和我用小卡片格式打印出每个PBI的概要细节，并开始在旧金山BIOS团队所坐区域附近的一个专用的信息辐射器房间里构建故事地图。米提亚和我在合适的时候拉入各个组的BIOS工程师，同时注意不过多占用他们的时间。我们最终确定了一个合理的BIOS组件待办列表排序，以及针对新的英特尔芯片组和电路板设计的MVP。结果发现MVP超过了组件待办列表的一半。由于涉及到的复杂性，我们在几天的深度思考过程中进行了多次一到两个小时的讨论，才让故事地图开始稳定下来。

在初始梳理工作即将结束时，我们召集了一个包含每个BIOS团队成员的更大会议，来评审我们在墙上的内容。我们使用了数码照片和视频会议的组合让波特兰的团队成员能够有效参与进来。在这次更大规模的会议中，BIOS团队成员帮助米提亚对整个故事地图进行了完整性检查。我们还采用相似估算得到了MVP中每个PBI的粗略工作量评估。

既然我们终于捕获了BIOS团队中每个人的集体知识，我们就开始进入常规的梳理会议，主要集中在接下来一两个迭代的短期视野上。

来自LeSS书上的各种多地参考内容列在了下面多地参考内容小节中。

多地参考内容

《精益和敏捷开发大型应用实战》书中有大量与引导多地会议相关的有用内容。甚至书的副标题都暗示了这一点。

《大规模Scrum》书中也包含了一段相关叙述和两个相关指南。

《大规模Scrum》中的内容包括：

• 指南：跨团队会议
• 指南：多地PBR
• LeSS巨型故事：多地团队

《精益和敏捷开发大型应用实战》书中第12章多地则完全专注于应对多地带来的挑战。在那章里与初始BIOS组件待办列表梳理工作最直接相关的几个实验包括：

• 尝试……眼见为实——无处不在便宜的视频技术和视频文化
• 尝试……多地计划扑克（估算扑克）
• 尝试……多地会议的基本实践

对初始梳理工作的反思

在梳理初始BIOS组件待办列表上所花费的细节和精力无疑比我以前或以后所做的任何类似工作都要多。然而考虑到上下文，我还是会这么做。我们实现了一定程度的对齐，以及不这样做就难以达到的BIOS工程师的深入参与。

所创建的细节一定可以在将来扩展组件待办列表加入未来英特尔芯片组原型时使用。随着AMI插件架构的更多使用，返工将会少得多，所以细节也会有所不同。然而，新PBI最好的出发点还是查看以前做过的事情。

我们并没有强加给自己一些人为的梳理时间盒。我们决定什么程度的清晰度和细节在我们的上下文中最为合理，然后集中精力去实现它。过后我们再改变做法，采用更有节奏的跨团队梳理会议。

BIOS完成的定义

启动工作中第二个最有趣的部分是创建完成的定义。团队决定尽可能地避免过去糟糕的复制粘贴行为。他们决定确保可能的时候就用AMI的可插拔扩展点，并向AMI施压以添加任何缺失的必要扩展点。你可以在下面更正式的完成的定义中看到这一承诺。查找以“在可插拔层之外没有改动，……”开头的行。

BIOS的Scrum关键角色

特伦特、米提亚和我花了很多心思试图找出PO和SM的最佳人选。

正如我将更详细地解释的那样，米提亚最终成为可以找到的唯一明智的PO人选。

我们还得出结论，我最初需要担任所有团队的SM。没有其他可以找到的SM具备必要的经验。如果不是如此依赖米提亚作为PO，我们可能会选择米提亚作为SM。

关于PO和SM选择更细致的见解如下。如果你感兴趣就看，没有的话可以跳过。

米提亚作为临时伪PO

米提亚是整个BIOS组的负责人。米提亚、特伦特和我认识到（所有Scrum专家都认识到），由于不平衡的权力关系（见下文），PO对开发团队成员拥有直接的权力通常是非常有问题的。如果是另一种性格的人担任这个角色，可能会是一个严重的问题。我们这里米提亚是一个天生谦逊的仆人式领导者，因而冲突并不是一个严重的问题。

特伦特、米提亚和我试图找出一个更好的PO人选。最后我们意识到，没有其他合适的人选，既具备足够的组件深度以能高效工作，又具备恰当的性格优势。其他候选人要么性格有问题，要么对整个MCS产品和BIOS组件缺乏足够的了解来胜任该角色。

避免直线经理成为PO

只是因为在特定情况下，我们让米提亚同时担任直线经理和伪临时PO还能应付过去。我通常不建议你尝试同样的做法。LeSS关于组织结构的指南明确避免让团队成员向PO汇报。

以下引用自《大规模Scrum》的内容很有指导意义：

是伙伴，而不是苦工—如果团队在层级权力关系中直接或间接地向PO汇报，那种结构需要改变，以使团队和PO成为协作的伙伴。PO不把团队当作完成任务的苦工，而是培养一种协作关系。—指南：五种关系

在这种组织结构中，重要的一点是团队和PO是伙伴—他们没有等级关系。我们发现保持角色之间的权力平衡很重要。团队和PO应该是合作的伙伴关系，来共同构建尽可能最好的产品，伙伴结构支持这一点。这一点将在PO章节中进一步探讨。—指南：LeSS组织结构

妥协的组件边界对PO的影响

在产品管理组中有我们考虑过的真正的PO候选人。不幸的是，由于相关VP的影响范围有限，无法将组件边界扩大到形成一个这些人中任何一个有领域知识来管理的多组件边界。即使有一个扩大的BIOS多组件边界，MCS的BIOS组件以及整个MCS产品的内在复杂度也远远大于典型的企业信息系统，记住这一点很重要。

尽管我们得到了部门内一些最资深高管的支持，但这些高管还有很多其它需要关注的问题。我相当肯定的是，一些关键的部门主管为我们的变革提供了比我们所知道的多得多的政治掩护。根本的现实是，需要一些时间和更多的成功证明来获得足够的政治资本，以能让我们进行更重大的组织变革。

在更多高度专业化的BIOS工程师他们自己能够更自信地跨越各个BIOS子组件工作之前，更广泛扩大的BIOS多组件边界将把BIOS团队的技术和协作能力拉伸过快，从而难以持续。因此，在早期进一步扩大BIOS组件边界并不是一个真正的选择。正是这类原因让LeSS建议增量地扩展产品定义，并在LeSS巨型导入中增量地增加需求领域。

相关的LeSS产品规则

以下选出的LeSS框架规则尤其相关:

• 对于完整的可交付产品，有一个PO和一份产品待办列表。
• PO不应该独自梳理产品待办列表；她通过由多个团队直接与客户/用户以及其他干系人工作来获得支持。
• 所有的优先级排序都要经过PO，但澄清尽可能在团队和客户/用户以及其他干系人之间直接进行。

产品主人翁意识不是最大的挑战

从扩大的BIOS多组件角度来看，客户问题相当简单。每个新英特尔芯片组的定制BIOS必须提供运行在前几代英特尔芯片组上的前几代BIOS所提供的相同服务。每一代新的芯片组经常需要对这些能力进行微小的扩展，但与基本功能相比，这些扩展微不足道。在某种程度上，BIOS的伪PO只是一个专家，他与团队一起找出未来解决问题的更好方法。

代码库的糟糕状态是历史上被合同游戏驱使的糟糕工程实践造成的。一直有高层强加的要满足不切实际的人为“代码完成”最后期限的压力，缺乏充分的个人安全来磨练技艺。大量复制粘贴重用的历史加上糟糕的自动化测试覆盖率提供了两个由合同游戏导致的自我伤害的好例子。最终结果是人为地把适配BIOS代码库到每一代英特尔芯片组变成了一项永久的工作。

具有讽刺意味的是，有了一个更全面的完成定义，以及一个可以增量地完成所有测试的跨职能团队，总是有足够的时间来做得更好。英特尔芯片组的发布日期是真实的，但瀑布的阶段关卡日期却是由瀑布流程强加的人为产物。

新BIOS团队所产生的大幅提高的质量将及时改变这种情况。一旦绝大多数BIOS定制都在具备更好自动化测试的可插拔层中，那么适配新的英特尔芯片组就可能比过去少很多工作量。此外，随着不断的改进努力，BIOS团队将完全地把他们的能力扩展到MCS系统管理层。

一旦质量改进和组件边界的扩展都取得足够的进展，新的团队将有时间和技能集来处理更为动态的需求。在此之前，事实是扩大BIOS多组件的目标是如此清晰和简洁——所涉及的工作是如此庞大——因此不太需要PO这个角色。事实是，这群拥有多年BIOS经验的BIOS工程师只是需要开辟一条新的道路，来更好地实现他们以前已经实现过多次的东西。

一旦BIOS团队开始定型，工程实践得到改进，扩大的BIOS多组件边界被延伸到MCSA从而形成整体MCS产品的一个自然的需求领域，到那时一个来自产品管理组真正的PO最终将变得至关重要。

PO选择限制的总结

所有这些原因一起让我们选择米提亚作为PO的最佳中期选择。这就是说，我们选择实施《精益和敏捷开发大型应用实战》书中描述的伪PO实验和《大规模Scrum》书中的在早期或混乱情况下从临时伪PO开始指南。

• BIOS团队的过度专业化和本地化，加上多年糟糕的工程实践所带来的额外复杂度，需要从一个伪PO来开始。这个人要有足够的专业技术深度来理解BIOS组件待办列表，并维护BIOS团队的尊重。
• 一个天生倾向于授权他人并避免微观管理的PO，对于帮助建立一个支持BIOS团队成长并成熟的环境至关重要。
• 由于BIOS面向LeSS的结构是在一个由合同游戏驱使的大瀑布环境里运行的，有一个具有足够地位和政治影响力的PO来为BIOS团队帮助建立一个支持的环境至关重要。
• 扩大组件边界将有助于减少理解和指导BIOS组件待办列表所需的BIOS特定知识，从而使其他好的PO选择成为可能。在BIOS工程师更大程度的跨功能使这成为可能之前，我们会需要一个拥有大量BIOS知识的伪PO。
• 伪PO的存在会进一步将BIOS团队与整体MCS产品的客户隔离开来。我们要在可行的情况下尽快摆脱对伪PO的需要。

教练作为SM

MCS部门里没有任何全职员工我们认为有足够的经验能在BIOS团队这样具有挑战性的环境中来有效地指导建立Scrum团队。任何被选中的全职员工都需要接受辅导以逐渐胜任该角色。

特伦特和我都觉得米提亚具备成为一名优秀SM所需的性格、人际关系、组织知识以及组件知识。不幸的是，在组件边界进一步扩大之前，我们确实需要米提亚担任PO的角色。

我们最终决定最初由我来担任SM。特伦特和我小心地确保我有足够的带宽来完成这个角色。我搬到BIOS工程区域的一个空位上，并在接下来的几个月里主要致力于启动和完善BIOS团队。因为我本来就每周飞，所以只要有必要我就可以去波特兰。实际上，我和米提亚大部分事情都是一起做的。我会不断帮助米提亚和部门里其他强有力的自然领导者成长为可以自己来带领大多数活动。

随着BIOS团队的定型和成熟，涌现出另外几个自然的SM候选人。这些人并不一定从开始就参与到Scrum中，但他们就这么随时间推移成为合适的人选。米提亚和我专注于将这些人培养成潜在的未来SM。

以下来自米提亚的推荐说明了具有挑战性的相关环境：

与詹姆斯共事对我和整个团队来说都是一次转变经历。

他把我们从“这里不可能做Scrum”带到了“我们再不能回去”。他将团队从瀑布带到Scrum。

我们是一个固件工程师团队，坚信Scrum不属于我们的领域。詹姆斯向我们展示了Scrum是一个聚焦于软件工艺、质量和计划我们工作的方式上的框架。

詹姆斯辅导我担任PO，并辅导团队克服采用Scrum框架带来的学习曲线。

团队发现他对开发、测试、CI/CD的技术方面的关注非常有用。他向我们介绍了许多概念和工具，并在需要的技术方面与团队成员一起工作。

结果非常明确。我们已经实践Scrum将近一年了。我们对待办列表有了更好的可见性。团队参与度提高了。初期产品质量也更好了。

SM选择限制的总结

• 异类的硬件和固件工程环境，再加上涉及到的文化挑战，对于任何内部的全职SM候选人来说都太过挑战了。
• 米提亚具备迅速成长为一名高效SM的自然能力。由于我们需要米提亚作为伪PO，因此排除了这个选项。
• 一旦扩展组件边界在政治上和技术上变得可行，我们就可以取代米提亚作为PO，而将米提亚或其他表现出前景和成长的人过渡到SM角色。
• 我是唯一一个拥有足够强SM技能来尝试这样挑战的Scrum导入的人。我只能通过在共同找到改进方法的过程中依靠BIOS开发人员、米提亚和其他人的指导才能做到。

BIOS团队自选组成

在开始阶段，我们合作确定了每个新团队的成员。

让波特兰的成员组成一个团队是个容易的决定。在波特兰只有五六个人，包含软件、硬件和测试工程师。远在决定在波特兰要培训哪些人时，米提亚、克里希纳、特伦特和我已经努力确保会是这样的情况。我认为是克里希纳帮助我们从工作于MCS另一块的部门里找到了一个合适的测试工程师。

真正的挑战在于决定谁会在哪个旧金山团队，以及会有几个旧金山团队。我们最初的结果是两个。我记得，一组人在启动的第一天下午自设计团队组成取得了初步成功。经过一夜的沉思和思考，在启动的第二天大家对团队组成进行了一些微调。

几个月后，我们加进了多几个可以在BIOS组件边界的边缘上工作的开发人员，并在相同的面向LeSS结构中组建了另外一两个团队。

尽管波特兰团队基本上同处一地，但最初他们缺少一些关键的工程技能。有一段时间，有一两名旧金山工程师是波特兰团队的成员。随着时间的推移，我相信，波特兰的工程师做到了完全自给自足。

BIOS节奏和迭代时间选择

大家决定采用两周的节奏。我们确保迭代边界在周中，以便我可以和团队一起，而不是在路上。

BIOS回顾结构调整

我们在跨团队和团队各自的回顾中尝试了几种变化。这些回顾结构与LeSS迭代规则在精神上接近，尽管在细节上略有不同。

从回顾的元结构角度来看，我们通常遵循埃丝特·德比（Esther Derby）和戴安娜·拉森（Diana Larsen）在《敏捷回顾》中的建议。最常用的技术是简单的头脑风暴加以点投票、固定时长的讨论，以及对回顾结构本身使用一个简短的四框回顾。

初始回顾结构

初始的回顾结构如下：

1. 跨团队会议来识别最高优先级的跨团队讨论事项
2. 团队各自回顾来讨论团队自身的问题和最高优先级的跨团队事项
3. 跨团队会议（LeSS整体回顾）来讨论团队各自会议的产出，并就解决跨团队问题的方法达成共识

两个跨团队会议都包括了每个BIOS团队的所有成员、米提亚（伪PO），还有我自己（代理SM）。

第一个跨团队会议聚焦于识别大家觉得重要到要让团队层面的回顾考虑的任何跨团队问题。意图是提供给大家一个机会在更小的团队层面讨论中找到跨团队问题的潜在解决方案，以便后续的跨团队会议能受益于这些在更大范围讨论中未必能显露的、更深的洞察。

你会注意到这和LeSS框架中团队层面回顾之后跟一个整体回顾的结构非常类似。关键的差别在于我们的团队层面回顾夹在了整体回顾的第一和第二部分之间。

实际上，团队层面的回顾看起来花费了大多数时间在那些第一部分的整体回顾中识别出来的问题上。如果团队层面的回顾像LeSS框架指定的那样在任何整体回顾会议之前进行，我相信团队层面的回顾可能会更有洞察。

大多数显露的问题本质上都是跨团队的。我不知道这只是特定环境带来的结果，还是由于在团队层面回顾之前进行了一部分整体回顾，无意中分散了团队对那些更具挑战性的团队层面讨论的注意力。

后期回顾结构

我们通常都很谨慎，在结束最后的跨团队回顾之后会对回顾本身进行一次回顾。由此我们最终决定改为以下回顾结构。

1. 跨团队会议来识别最高优先级的跨团队讨论事项
2. 为前几个点投票出来的问题进行分组。分组倾向于跨团队边界，大家通常会自行选择参加他们最热衷或最需要的分组
3. 跨团队会议来讨论分组会议的结果，并就解决跨团队问题的方法达成共识

如你所见，这个结构除了中间步骤之外与初始结构相同。我们没有分开进行团队各自的回顾，而是分成跨团队边界的工作组，把最相关最感兴趣的人聚在一起。

在实践中，波特兰团队通常在第二步中仍保持在一起。我们通常是在一组远程会议室中进行跨团队活动。如果旧金山有人对主要是波特兰人所选的话题特别感兴趣，我们会使用电视直播室来讨论这个话题。其他工作组则会去其它只有有限远程能力的会议室。

在旧金山如何分成回顾工作组往往有些随机。我们通常会在会议桌中间分开，当有必要时再交换几个人。

鉴于参与人员的自然协作特征和关系历史，缺乏专门的团队回顾似乎并不重要。在我合作过的其他组织中，团队各自的回顾往往是至关重要的。也许随着时间的推移和其他团队的加入，动态会发生变化，以致于大家决定恢复团队层面的回顾。

更大的结构问题并没有在整体回顾中解决

在LeSS中，整体回顾旨在解决更广泛的系统性问题。尽管BIOS团队在其控制范围内积极解决并实施了跨团队系统问题的解决方案，但几乎没有能力解决更广泛的系统问题。无论是VP层管理者还是新的SVP都从来没有参加过整体回顾。

有关本主题的更多细节，请参阅《大规模Scrum》书中的指南：整体回顾。

BIOS与LeSS规则的比对

在继续探讨来自BIOS团队的更多细节和洞察之前，检查与LeSS规则的一致性具有指导意义。

LeSS结构比对

• 采用真正的团队作为基本模块来构建组织。

  是的

• 每个团队（1）自管理、（2）跨职能、（3）同处一地，和（4）长久。

  自管理：每个团队从第一天开始就自管理。团队控制拉入多少工作进入迭代，每个迭代协作分工，在BIOS代码库内能完全控制架构决策，运行自己的站会，以及你会对一个自管理团队有所期望的其它事情。

  跨职能：起初每个团队倾向于对BIOS组件的某个领域有很强的归属感。即使在BIOS组件内部变得更跨职能也花费了每个团队一阵子时间。随着团队进一步演进，他们开始逐渐扩展到原先归属领域之外。

  一份共同的BIOS组件待办列表和单一伪PO的存在产生了结构动力，它们持续鼓励增加在团队内和团队间的交叉培训程度。

  当BIOS团队工作进一步扩展BIOS组件边界到MCSA，团队慢慢地从整体MCS产品的角度也变得更跨职能了。虽然没能实现其完全的潜力，有一个紧密从事MCSA相关BIOS工作的团队无疑是在这条路上。这个话题将在BIOS组件边界扩大了章节进一步探讨。

  同处一地：每个团队总体来看都是同处一地的。因为波特兰团队缺乏BIOS代码库中一些领域的知识，最初他们有一两位成员在旧金山地区。团队工作于积极交叉培训来解决这些例外情况。我记得波特兰团队中位于旧金山的成员在几个迭代之内就可以离开并加入到旧金山的团队了。

  长久：团队基本上连续几个月保持不变。很明显大量裁员最终影响到了长久性。当波特兰团队变得不那么分散，以及更多BIOS开发人员可以加入到开发中硬件代次的BIOS工作时，发生了一些团队之间成员的自发调整。大抵上新加入的成员组成了新的团队，而原先的三个团队保持了相当的稳定。

  因此，虽然团队最终没有像我希望的那样长久，但他们无疑也不是每几个月就被随机分配到新的团队。

  当从若干年的时长来看长久性，则肯定是有问题的。在《精益和敏捷开发大型应用指南》中，拉曼和沃代基于杰伊·加尔布雷思的星型模型讲述了组织策略。在各种元素中，激励和人员实践的元素没有得到足够的重视。

  虽然之前的薪资结构已经对工程师继续在技术路线上发展提供了一定程度的激励，还是有强得多的在经济和文化上对转向管理路线的激励。同样，由于部门高层仍在继续承诺游戏而导致的持续压力使得几乎没有时间来进行大量学习和职业提升。

• 大多数团队是聚焦客户的特性团队。

  虽然团队在BIOS组件边界内基本上是垂直切分的，BIOS组件边界本身就是一个妥协。随着BIOS团队的成熟，我们尝试建立贯穿整体MCS产品的更为垂直扩展的多组件边界，尽管从未达到我们可以最终实现的程度。

• SM们负责一个运行良好的LeSS导入。他们关注于团队、PO、组织和开发实践。

  是的

• SM不只是关注一个团队，而是整个组织系统。

  是的

• SM是一个专门的全职角色。

  是的

• 一个SM可以服务1-3个团队。

  在所有美国BIOS工程师都被融进特性团队时，我服务了5个团队。实际上我跟米提亚，还有其他几位我们有意发展的SM人选，分担了许多工作。

• LeSS不强制有管理者角色，但是如果确实存在，他们的角色可能会改变。他们的焦点从管理日常的产品工作转向改善产品开发系统的价值交付能力。

  是的。米提亚、特伦特和我保持了非常扁平的有效结构。我不记得米提亚曾经关注于管理日常的BIOS组件工作。

• 管理者的角色是通过实践现场观察、鼓励停下来修复，以及“实验优于遵从”来改善产品开发系统。

  是的。

  米提亚和我都跟旧金山的团队坐一起，并且也时常飞去波特兰。各种现场观察和实验优于遵从的例子包括：

  • 米提亚和我都会不时跟一个或更多个BIOS开发人员结对编程，和/或在被认为有益时参加设计讨论。
  • 米提亚和我会积极接触组织上下及各处的人来帮助解决各种组织障碍。
  • 我花费了大量时间与埃米特·布朗结对来解决如何为BIOS代码创建自动化单元测试。
  • 我花费了大量时间与几个开发人员结对建立起一个由BIOS团队控制的CI服务器。
  • BIOS团队的回顾一直能在每个迭代确定至少一个实验，团队会在接下来的迭代中采取措施。

• 针对产品组，“从一开始”就建立完全的LeSS结构；这对一个LeSS导入来说至关重要。

  是的，在扩大的BIOS组件范围内。不是，在更广泛的整体MCS产品范围内。

• 针对产品组之上的更大组织，演进地导入LeSS，用现场观察来创建一个实验和改进常态化的组织。

  是的

LeSS产品比对

• 针对整个可交付的产品有一个PO和一份产品待办列表。

  对BIOS组件来说是的。对整个MCS产品来说则不是。

• PO不应该独自工作于产品待办列表梳理；她从直接与客户/用户以及其他干系人工作的多个团队那里得到支持。

  是的

• 所有优先级排序都通过PO，但是澄清尽可能直接发生于团队和客户/用户以及其他干系人之间。

  对BIOS组件来说是的。对整个MCS产品来说则不是。

• 产品的定义应该在实际可行的情况下尽可能广泛和终端用户导向。随着时间的推移，产品的定义可以扩展。更广泛的定义会更好。

  从尽可能扩大BIOS组件边界来说是的。从缺乏一个LeSS上下文来包含整个MCS产品来说则不是。

• 有一个针对整个产品的所有团队共同的完成的定义。每个团队可以通过扩展共同的定义有他们自己更强的完成的定义。

  从BIOS团队共同使用的完成的定义来说是的。从整体MCS产品来说则不是。

• 完美目标是改善完成的定义以达成每个迭代有一个可交付产品（或者甚至更频繁）。

  从BIOS组件来说是的。有一些我们在更广泛地导入LeSS到整个MCS产品之前没法避免的完成外工作。

LeSS迭代比对

• 有一个产品层面的迭代，而不是每个团队有不同的迭代。

  从BIOS扩展组件团队来说是的。

• 每个团队同时开始和结束迭代。每个迭代都产出一个集成的整体产品。

  从BIOS扩展组件团队来说是的。

• 迭代计划由两部分组成：迭代计划一对所有团队是共同的，而迭代计划二通常每个团队各自进行。针对紧密相关的条目在共享空间里做多团队迭代计划二。

  从BIOS扩展组件团队来说是的。

• 迭代计划一由PO和团队或团队代表参加。他们一起暂定选择每个团队这个迭代会工作的条目。团队寻找一起工作的机会，并澄清最后的问题。

  从BIOS扩展组件团队来说是的。

• 每个团队有他们自己的迭代待办列表。

  从BIOS扩展组件团队来说是的。

• 迭代计划二是让团队决定他们将如何做选了的条目。这通常涉及设计和创建他们的迭代待办列表。

  从BIOS扩展组件团队来说是的。

• 每个团队有他们自己的每日站会。

  从BIOS扩展组件团队来说是的。

• 跨团队协调由团队决定。相对集中式协调，优先采用分布式和非正式的协调。强调直接交谈和通过代码中交流、跨团队会议、组件导师、旅行者、侦察兵，和开放空间形成的非正式网络。

  从BIOS扩展组件团队来说是的。

• 产品待办列表梳理（PBR）最好多个团队来做，以增加共享学习和利用协调机会。

  从BIOS扩展组件团队来说是的。

• 有一个产品迭代评审；是所有团队共同的。确保合适的干系人参加并贡献有效检查并适应所需的信息。

  从BIOS扩展组件团队来说是的。

• 每个团队有他们自己的迭代回顾。

  从BIOS扩展组件团队来说最初是的。我们后来有所偏离，如之前在BIOS回顾结构调整章节中所述。

• 在团队回顾之后举行一个整体回顾，讨论跨团队和系统性的问题，并创建改进实验。这由PO、SM、团队代表和管理者（如果有的话）参加。

  从BIOS扩展组件团队来说是的。

BIOS分流规则

BIOS团队经常被来自于工作在整个MCS系统其它部分的工程师和管理者的请求所打扰。这些请求中的一些需要即刻行动以服务于整体MCS开发工作，而另一些却最好即刻拒绝，或者移入BIOS组件待办列表来排优先级。

除了几位测试工程师之外，所有BIOS的Scrum开发团队成员都直接汇报给米提亚。职能经理打扰汇报给他们的BIOS团队成员的问题基本上不存在。

这些打扰多数情况下是因为相比真实的MCS产品边界来说并不完美的BIOS组件边界，以及MCS的BIOS代码与AMI的BIOS代码之间过于耦合。

在根本原因能更完全地被解决之前，创建一组正式的分流指南很有助于管理这些干扰。好处包括：

• 尊重PO的意图
• 保持对关键未预料到请求的响应
• 帮助BIOS工程师对不适当的请求说不
• 提供透明性给每个相关的人
• 把BIOS工程师的集体智慧结成一体
• 实现BIOS团队内的对齐
• BIOS的SM们基于历史数据更好地检查并适应的能力

BIOS的单元测试是可能的

有志者事竟成。我们知道自动化单元测试在BIOS里将会非常有挑战。在开发早期还没有TCP/IP网络协议栈，只有少数标准C库函数可以用，所有代码必须被交叉编译再闪存到目标环境，以及在AMI的BIOS生态系统里找不到已有的单元测试方法。

虽然我作为一个软件工程师实践测试先行开发已经超过十年了，我却对BIOS和底层硬件设计知之甚少。同样，BIOS工程师几乎没有见过高水平中间件团队会使用的语言、工具、设计模式，以及各种匠艺实践。在许多方面，大多数MCS的BIOS工程师是具备很窄软件工程技能的电子工程行家。

埃米特·布朗（Emmett Brown）是一个有热情的工程师，他决心搞清楚如何让MCS的BIOS代码转向测试先行开发。我和埃米特工作来帮助他理解所需的设计元素，并展示给他每个元素在各种高层开发生态系统中的实例。相应地，埃米特则教我UEFI标准的各种细节、BIOS工具链，以及涉及的硬件限制。我们然后摸索解决这些挑战，并考虑解决问题的不同方式。

虽然花费了几周的工作，但是埃米特最终做出了一个可工作的原型。他采用部分UEFI标准实现了依赖反转，硬编码了他的测试替身，移植了一个简陋的C单元测试框架，并且在串口连接上构建了一个基本的传输协议，从而能将结果传回Windows工作站或者CI服务器，在那上面有构建工具链可以整体协调管理。

我听到过在技术上远没这么有挑战的上下文中，用命令式语言开发的工程师，以各种理由说为什么自动化单元测试技术上不可行。别相信他们。埃米特在原始得多的、半初始化的复杂电路板环境 - 没有任何有用的预制单元测试工具 - 中实现了自动化单元测试。

BIOS团队数量增加了

为了让最初导入的范围可管理，一开始只包含了工作于支持最新英特尔芯片组和参考板设计的那些人。任何工作在更老的量产英特尔芯片组的缺陷修复和其它次要工作的人则继续在传统组织设计中工作。换种说法，BIOS组件边界只包含了最新的原型英特尔芯片组。

因为每个主要的英特尔版本都有一个单独的AMI代码库，这一策略工作得相当好。等到与遗留英特尔芯片组的相关工作逐渐缩小时，前三个BIOS的Scrum团队已经基本上定型了。

随着额外的旧金山BIOS开发人员可以加入，我们组建了两个新团队，从一份合并的BIOS组件待办列表中选取工作。每个新团队都被允许影响并正式批准各种跨团队工件，以帮助确保他们对流程的全情投入和承诺。我记不清了，但我相信在这个过程中碰到过一些还需敏捷概述培训的人。

随着我们推出两个新的Scrum团队，我们实际上同时扩大了BIOS组件边界，包含了所有代次的因特尔芯片组。

BIOS组件边界扩大了

MCS系统的最高层是模块化计算系统管理员（MCSA），负责管理整个MCS基础设施。当一个MCS客户的系统管理员与MCS交互时，与他们交互的通常就是MCSA。

在MCS的BIOS代码里的一些增强需要对MCSA做些小改动。不太常见的改动也会发生在运行于低功耗节点控制器上的固件里。

最初BIOS团队会为任何横切功能与几位更资深的MCSA开发人员协作。BIOS团队经常发现与MCSA开发人员协调工作是有挑战的。MCSA开发人员正饱受所有在瀑布管理的项目中常见的交付压力。

如果最初开启一个更广泛的扩大的BIOS组件边界 - 它可以对应到一个自然的整体MCS产品需求领域 - 在政治上可行的话，上述的协调问题就不会存在。

考虑到政治形势，显而易见的解决方案是让MCS的BIOS开发人员逐渐具备自己做MCSA改动的专业技能。随着BIOS团队的成熟，这一需要对许多BIOS团队来说变得越来越明显。我也倾向于鼓励他们朝这个方向发展。

通过各种各样的交谈，我们得到了在MCSA工作的一小撮工程师以及工作于节点控制器固件的另一组人的认同。形成的约定是让他们帮助指导BIOS团队来识别，什么时候横切改动足够简单，可以让BIOS团队自己改动。然后BIOS团队来改动，并让BIOS团队之外的相关专家来做代码评审。

旧金山的BIOS开发人员已经与许多旧金山的MCSA开发人员成功协作了很多年。从关键MCSA组长和架构师的角度来看，BIOS团队能够做的任何有助于一些MCSA和BIOS集成工作的事都被视作是一种受欢迎的对他们的缓解。因此，软件VP对变革消极而积极维护现状的事实在实践中并没有成为一个显著的问题。只要MCSA和BIOS的集成工作完成了，高级管理层中没人关心是如何发生的。

节点控制器的开发人员向上汇报给同一个曾经帮助建立诊断团队的主管。因此没有什么显著的政治挑战来阻碍交叉培训BIOS团队，以便他们能做一些在节点控制器里的小改动。大多数的节点控制器开发人员与波特兰的BIOS团队同处于波特兰的小办公室中。

米提亚和我推理，这种方式的成功可以随着时间增长。我们预测，最终在政治上会变得难以不指派一两位MCSA专家到BIOS组。BIOS的Scrum团队获得越多在MCS端到端地工作的能力，BIOS组件边界就变得越自然。越来越多的产品待办条目成为对MCS产品管理组有意义的东西。当那发生时，米提亚可以脱离不再担任伪PO。然后他可以进一步改善团队动态，并帮助SM们成长以接替我的位置。

但是在可以采取重大行动开始把至少一个BIOS团队延伸到BIOS代码库外部之前，部门开始在我们周围衰落。后面支撑系统倒塌了章节将更详细一些讲述高级管理层变动和裁员。

BIOS的印度团队挑战

在旧金山和印度办公室之间的巨大时差一直是个挑战。同样，不同的汇报线也倾向于让对齐问题复杂化。一些复杂性细化如下。

反思以下LeSS框架和LeSS巨型框架规则具有指导意义：

• 对产品组“从一开始”就建立完整的LeSS结构，这个对LeSS导入至关重要。
• LeSS巨型导入，包括其中的结构变革，则以演进式增量的方式进行。

如果有更广泛高层管理者的认同，在与印度团队工作时碰到的一些挑战有可能更早就从结构层面被解决。另一方面，在任何时候只有这么多的变化是可持续的。也有必要记得，在BIOS的LeSS导入启动时，积极认同变革的原先的工程SVP已经离开了。

在整个BIOS的敏捷导入过程中，米提亚和我确保让我们做的事情为人所知。即使工作在更老英特尔芯片组的遗留支持的工程师也知道新英特尔芯片组使用的完成的定义。来自印度的主管工程师经常从他们那里拨进来参加面向LeSS的迭代评审。

在图15和附近的BIOS组织背景章节中，我描述了米提亚和我采取的隔离和延迟印度BIOS开发人员组织变革的策略。能把英特尔芯片组代次作为其中一个扩大的多组件边界，以及印度团队最初聚焦于修复更老代次英特尔芯片组的相关问题，使得这一策略可行。这是一个冒险的策略，因为它依赖于来自硬件VP的持续支持，而他在我们完全实施这一策略之前离开了；然而基于我们面临的限制，我也没能想到其它可行的选择。尽管我可能愿意在将来没有其它选项时重复这一策略，但我强烈建议如果可能的话尝试提前获得对更广泛变革的认同。

辅导支持

我在那儿的第一年里是MCS部门唯一的教练。虽然特伦特和我挺早就去了印度，我们最初并没有足够的辅导容量来显著影响那里的事情。我交付了几天的培训，建立了关系，但是不太可能做别的了。

我在的第二年，特伦特找到足够的预算在印度招几位教练。在印度找到经验丰富的敏捷教练比在美国还难，但经历了几个月的面试之后我最终还是找到几位。在一两个月之后，特伦特和我成功得到了印度经理对这些教练的共同祝福，然后就结束谈判并开始工作。

印度BIOS工程师身上的瀑布压力

随着与遗留英特尔芯片组相关的工作逐渐缩小，一些印度的BIOS工程师开始贡献在新英特尔芯片组的BIOS代码库上。印度工程师充分知晓共同的完成定义，以及面向LeSS的BIOS团队的相关规范。不幸的是，他们的管理层仍被瀑布方式所驱动。

早期的BIOS团队旧金山成员对不能让他们努力改善了的质量逐渐毁坏态度坚定。旧金山BIOS团队成员改进了他们的持续集成实践，改进了他们集成测试的自动化，对任何代码变更进行频繁评审，以及许多次与印度BIOS工程师的交心谈话。这些战术层面的解决方案无疑产生了正面影响，并部分缓解了一些问题。

米提亚和我已经预料到了这些问题。我们有意设计了BIOS的组件边界，以延迟这一组织斗争直到更大的政治势头有利于获胜。有意的延迟确保了在印度办公室有合格的敏捷教练到位，BIOS在美国的LeSS团队已经成形，并有显著证据表明在BIOS的LeSS团队中质量和预测透明性都得到了大幅提升。

米提亚、特伦特和我意识到需要花费不少精力和穿梭外交来解决根本性的结构问题。我们准备好把结构问题推向危机，以便可以解决它们。不幸的是，差不多同时失去支持变革的硬件VP和大规模裁员毁坏了我们的策略。

你可以把敏捷导入时间线图、组织结构图序列和BIOS通过MCS硬件代次扩展组件团队图组合起来看到这些不同元素的融合。

支撑系统倒塌了

到我在中岛公司MCS部门的任期即将结束时，在汇报结构、部门预算、员工数量和高级管理层方面都有了很大变化。

随着市场份额不断下降和竞争格局日趋成熟，MCS的收入也在萎缩。中岛公司的高层做出了一个激进缩减MCS部门规模的决定。结果是要减少大致一半的部门人员数量。许多中岛公司的人告诉我这是他们在中岛公司见过的最大规模裁员。BIOS团队至少有一半将很快被裁掉。

在裁员之前，许多管理层的人被招募到一家资金特别充裕的初创公司。这包括米提亚原先汇报的VP。米提亚然后开始汇报给从一开始就没有完全支持过Srum和敏捷的软件VP。在我离开没多久之后，米提亚跟随他之前的VP去了那家新初创公司。

虽然裁员发生之后我还在，特伦特要想续约我的合同在政治上已经站不住脚。一个敏捷顾问的市场价格和差旅成本足以支付至少两到三名工程师的费用。如果由特伦特决定的话，我的合同可能会被延长，但是即使特伦特也得获取再往上两层的预算签字。一年多一点以后，特伦特也离开了中岛公司。

结论

关于深层组织变革的思考

回顾过去，早期失去了支持变革的工程SVP，加上在专注于短期快速修复利润率而频繁裁员的文化中缺乏长远的工作安全，大大降低了在转变组织结构和文化上获得长期成功的机会。没有这些挑战，我相信在BIOS组件内的成功可以有助于更广泛的LeSS导入。

在BIOS内的LeSS导入获得成功后，我相信原先的工程SVP会帮助取得继续下去所需的更广泛的高级管理层加入。相反，高级管理层在忙于争相推出即将发布的MCS版本，同时努力应对即将发生裁员的政治形势。我相信早期更激进的结构变革会有帮助，然而我不认为，如果没有逐渐建立成功记录的过程，参与的高管会准备好接受那样的变革。

我想起了播种者的寓言，里面有一个农民在各种土壤条件下广泛播种。尽管撒在浅层土壤里的种子发芽生长很快，但由于缺乏深层根系，它们很快就在阳光下枯萎了。相比之下，播种在较深土壤里的种子却生长出丰富的作物。如果没有为LeSS导入准备好适当的土壤，即使你经常在早期获得巨大成功，很可能也会导致长期问题。BIOS的LeSS导入的土壤足够深到产生了一些很好的早期结果，但还不够深到实现其丰富的潜力。

收益总结

BIOS团队开始时是扩展的组件团队，然后转向扩大的组件团队和特性团队。其中的收益包括：

• 在扩展组件边界内局部改进的适应能力和价值交付
  • 先前的观察：
    • 只有一两个人知道一个给定的BIOS子组件。代码所有权和知识实际上是在个体文件层面。
    • BIOS组件之外的代码库知识在BIOS工程部门几乎不存在。
    • 没有人知道把新一代英特尔CPU在新的刀片硬件上运行起来所需的整个工作。每个BIOS固件工程师和测试人员只知道他们的一小块拼图。
  • 先前的影响：
    • BIOS工程师不能在任何时间点都选择最有价值的工作，因为他们被限制在各自的专业领域。
    • 几乎不可能准确地预测完成情况。
  • 后续的观察：
    • 每个团队成员逐渐变得可以工作在比之前更多数量的BIOS子组件上。
    • 许多BIOS团队成员逐渐变得更加有能力测试和修改沿着从GUI到BIOS组件执行路径上整个系统的每个方面。
    • 每个BIOS团队成员都对运行一块新的英特尔CPU所需的工作有一个好的整体理解。面向LeSS的BIOS团队中任何成员都能解释在BIOS组件待办列表上的任何条目，以及它是如何与整体情况相融的。
    • BIOS组件待办列表始终提供一个交付下一个BIOS版本所需的所有剩余工作的更新视图。
    • BIOS团队接受产品开发的自然变化，并承诺于在BIOS完成的定义中所显式表述的质量（而非范围）。
  • 后续的影响：
    • 面向LeSS的BIOS团队能够在任何时间点都始终聚焦于最有价值的工作。
    • BIOS团队对他们的发布预测更有信心。
    • BIOS团队能够确保，在开发低优先级功能之前，已开发功能已经达到了可发布级别。
    • 面向LeSS的BIOS扩展组件团队确保每个迭代的增量可以与MCS系统整体成功集成并测试。在几千名工程师中，只有那个诊断试点的小Scrum团队可以声称类似的情况。
• 改进的技术实践提高了质量，同时提高了对其它改进可能带来好处的意识
  • 先前的观察：
    • 对质量标准是什么没有共同的约定。
    • AMI提供的BIOS代码改动和MCS特有的代码改动揉在一起难以维护。每一个新代次的英特尔CPU事实上都需要从零开始。
  • 先前的影响：
    • 让MCS适配每一个新代次的英特尔CPU都需要花费超过一年和一大群BIOS工程师。没能在英特尔官方发布新CPU之前完成这项工作将导致数千万的收入损失。
  • 后续的观察：
    • BIOS完成的定义是一个活的质量标准，被每一个新BIOS团队所接受。完成的定义由团队自己持续澄清和不断扩展。
    • BIOS完成的定义一直包含了一个承诺来确保任何MCS的BIOS改动尽可能地利用AMI插件层。这一明智的要求来源于团队，而非教练或管理层。
  • 后续的影响：
    • 改进的技术实践预计会有助于大大缩短适配未来代次英特尔CPU所需的时间。
    • 健康的回顾和对质量的持续关注为下一步的改进提供了清晰度。
• 与扩展组件相关缺陷的尽早识别和解决
  • 先前的观察：
    • BIOS固件工程师修改完代码，然后就扔给测试组。在测试人员识别出问题并把它们扔回给BIOS固件工程师时，通常已经过去数周甚至数月了。
    • 很少有自动化测试。几乎所有测试都是手工的。
    • 把有编译问题的代码提交进源代码控制是普遍的做法。
  • 先前的影响：
    • 在缺陷被发现并解决之前通常会花费数月时间。
    • BIOS工程师经常浪费时间来追寻另一个开发人员引入的破坏性改动。许多次这样的改动都是由另一个在不同时区的开发人员引入的，而当问题被发现时他已经不在工作了。
  • 后续的观察：
    • 每个BIOS团队都包含具备开发和测试任何改动的技能和领域知识的人员。
    • 每个BIOS团队通常在任何一个时候只专注于少量的改动。他们作为真正的团队而不是个人工作，因为他们积极聚焦于实现相关产品待办条目的完成定义。
    • BIOS团队成员在技术和领域知识上都积极相互交叉培训。测试人员变成了更强的开发人员，而开发人员变成了更强的测试人员。
    • 不断提高的自动化测试和自动化构建系统有助于进一步确保问题被尽早发现。
    • 自动化构建和测试尤其有助于识别遗留团队和面向LeSS的团队之间冲突的优先级。
  • 后续的影响：
    • 缺陷在几分钟或几小时 - 而不是几个月 - 内就被发现并解决。通常浪费在“代码冻结”之后消除缺陷上的几个月是完全没必要的。
    • 当海外团队开始工作在同一个代码库上时，传统结构中工作的海外团队有冲突的质量激励和目标就变得非常明显。如果给以时间和有管理连续性，我相信这种可见性将使重组和改进海外团队在政治上变得可行。
• 在扩展组件团队中改进的员工协作、投入和学习
  • 先前的观察：
    • 大家都以个人而非团队成员的身份工作，每个人只专注于自己的个人任务。
    • 团队遵循一种典型的投入模式，由经理来领导并推动互动和工作分配。
    • 成长和学习仅限于个人的职责领域和过往的专业知识。扩展某人的专业知识和职责需要安排和变换任务。这需要时间，并且不总是现实可行。
  • 先前的影响：
    • “付出大量努力却回报有限” –米提亚
  • 后续的观察：
    • 团队自己管理工作，共同热情地聚焦于交付他们团队选择的产品待办条目。
    • 个人和团队积极学习为完成他们团队目前关注的条目所需的一切。团队内部和团队之间知识转移的程度比之前观察到的要大一个数量级。
  • 后续的影响：
    • 用理查德·哈克曼（Richard Hackman）《高效团队：领导团队走向成功的5大黄金法则》书中的术语来说，BIOS团队是真正的团队，而非松散协作的一群个体。每个团队都有一个清晰的团队任务，清晰的边界，清晰指定的管理他们自己工作流程的权力，以及成员的稳定性。
• 提升的对组织障碍和进行更多组织变革必要性的意识
  • 先前的观察：
    • 开发周期长、缺陷发现晚、频繁的跨团队交接、工作在某个人这里成了瓶颈，还有很多其它问题，都被认为是正常的。对情况是可能明显好转的几乎没有意识。
    • 个体团队成员几乎没有结构性激励来关注全局层面的适应性或价值交付。
    • 几乎没有讨论或努力来消除长期存在的组织障碍。
  • 先前的影响：
    • 很少有富有成效的努力来在全局层面改善适应性和价值交付。
  • 后续的观察：
    • 在BIOS团队内定期的团队和整体回顾经常识别出组织障碍，对此团队和管理层会积极尝试解决。
    • BIOS扩展组件团队为充分验证任何BIOS改动所做的努力越来越促使他们挑战代码所有权边界，并扩展他们的能力来跨多组件改动代码。
    • 对表现在BIOS完成的定义中的更严格质量标准的追求帮助突显了传统BIOS团队有冲突的结构性激励。
  • 后续的影响：
    • 大家慢慢意识到什么是可能的，以及进行更大组织变革的必要性。

总结

我坚信，长期成功的最佳机会在于实现一个广泛的产品边界以及工作在产品整个范围内的特性团队。如果可能的艺术排除了这一选择，那么从扩展的组件团队开始并积极转向扩大的组件团队和特性团队的增量方式仍然是值得去做的。

致谢

我感谢维克多·格里奇（Viktor Grgic）和克雷格·拉曼（Craig Larman）在整个编辑评审过程中提供的广泛工作和指导。