史上第一个真正意义上的规模化敏捷转型案例

作者：吕毅 

摘要

基于组件的矩阵组织在传统的复杂产品开发中很常见。这篇文章描述了一个将它转变成基于Scrum的敏捷组织的旅程。我们从第一个Scrum团队到多团队Scrum扩展过程中创造了小成功；然后我们决定转变整个组织，为了更大的成功开始跨越鸿沟。你会了解到在这个变革过程中我们是如何检视并适应的。

引言

在过去的十年里，敏捷软件开发相对于瀑布开发 – 因为其聚焦于“个体与交互”、“可工作软件”、“客户协作”和“响应变化” – 越来越多地受到认可。

基于组件的矩阵组织通常与瀑布开发相伴随。因此，从瀑布开发转向敏捷开发也意味着要转变基于组件的矩阵组织。

开始

我们从2005年开始旅程。当时的组织是位于诺基亚网络，也就是现在的诺西（注：全称为诺基亚西门子网络，2018年后叫做上海诺基亚贝尔）。它开发平台，供几个3G网络中的网元使用。这是一个多地的基于组件的矩阵组织，总共大约有400人。

上图展示的是我们当时组织结构的简化视图。系统设计、软件开发、软件集成及验证和系统测试是矩阵结构中的职能维度，而项目管理则是矩阵结构中的项目维度。此外，软件开发和软件集成及验证进一步围绕组件来组织。参与到同一平台开发的有两个工作地点，分别是中国的杭州和芬兰的艾斯堡。在每个地点都有更小规模的基于组件的矩阵组织，两地之间仅有细微差别。更完整的视图里还包括组件团队层面的职能经理也要管理子项目，在这点上跟其它矩阵组织略有不同。

就聚焦和灵活性而言，这个组织有很多挑战：

• 矩阵组织试图实现一定程度的并行，以在职能线上达到优化使用资源。这导致了创建并行项目。然而软件开发从来不是按顺序发生。对某个职能线来说，当第一次经历他们的流程阶段时，工作通常并没有完成。项目经常看起来运行得不错，直到进入后期；而从我们的客户视角来看，特性开发周期非常长。由此多任务应运而生。一个人同时工作在多个需要修改他所负责组件的项目上这种情况很普遍。大家失去聚焦的工作方式，从而导致特性开发中的低效。客户焦点也被稀释。组件开发人员通常很少有客户特性的视角。一些组件工作完成后经常很多个月没有被集成和验证。
  
• 为了交付客户特性需要所有职能线的工作。从精益的视角看，在制品带来了不灵活。职能线的分割导致长的特性开发周期，然后使得变更不可避免。而变更被视作干扰，因为它浪费了前期的工作。动态的客户需求从来都不跟着相对静态的组件团队资源配置来。从项目管理的角度看，总有一些组件处在关键路径上，从而影响整体特性的交付。集成时机总有问题。职能和组件上的过度专业化正在导致不灵活，它与高“卡车系数”相关。

敏捷软件开发进入到我们的视野中。敏捷意味着灵活性，恰好是我们组织所缺乏的。迭代增量开发、灵活的特性团队和聚焦的工作方式都是吸引我们的可以改善我们情况的特征。整体目标是想把很长的版本周期缩短成较小的增量，因此有更好的可见度和聚焦特性交付。这相应地又能帮助组织更紧密地跟客户对齐。Scrum因为其作为项目管理框架的简洁尤其受到关注。

上层管理和团队都看到变革的需要，尽管出发点不同。2005年下半年那时并没有转向敏捷运作的公司内部成功案例，因此可以理解上层管理并没有立即从上至下发起大规模的变革。各种顾虑也无处不在。有必要先来创建小成功。

小成功

变革应该是从矩阵中的职能线还是项目开始呢？两个选项各有利弊。职能线是员工的长期汇报线，能让变革更可持续。而项目天生就是短期的，更可能随着团队解散而失去变革效果。另一方面，项目是客户导向的，因此能够建立跨职能特性团队，也就是穿透多个职能组件团队。此外在项目中开始变革还有一个好处，因为项目在矩阵中是虚线，所以变革看起来更容易回退，使得试运行更容易被接受。最终我开始承担最近版本的项目经理来发起变革。

它始于

在2005年12月，我去芬兰赫尔辛基参加了Ken Schwaber的CSM培训。之后我们就在中国杭州成立了第一个Scrum团队。它有4位成员，包括我作为SM（ScrumMaster）。从一开始我们就组织成纯项目团队，没有任何组件相关的结构。我们有一个在异地的PO（Product Owner），尽管不是最佳选择，因为时间仓促我们还是接受了。PO和SM简单做了版本计划并创建了初始的产品待办列表。然后就开始了。

第一个迭代

在2005年12月晚些时候，我们的第一个Scrum团队开始了第一个迭代。迭代计划以速率驱动的方式进行，包含两个标准部分 – 选择产品待办列表条目和创建迭代待办列表。PO最初对整个版本有所评估，但还是由团队做了自己的评估并相应承诺了第一个迭代目标。

我们找到一个会议室供团队一起工作，这对形成团队身份和引导大家协作起到关键作用。团队很快就习惯Scrum的节奏。然而到迭代后期对工作量的低估还是很明显。我提醒大家有权去跟PO重新调整承诺，但是他们并不愿意。有两个主要原因，一是他们想履行他们作为团队的第一个承诺，二是产品待办列表条目太大，调整起来并不容易。他们反而决定通过加班来达成第一个迭代目标。

迭代评审分为两个标准部分 – 开发完的功能展示和迭代回顾。团队反思了很多方面，比如技术、Scrum流程、工程实践和环境。

PO在异地的现实还是限制了他和团队有更多的交互。我们把迭代计划和评审会议安排在下午以弥补两个地点之间的时差，但是只靠语音会议和Netmeeting一些信息还是丢失了。在迭代过程中，PO对邮件的响应被团队认为至关重要，而我们的PO在这方面做得不错。

跨职能团队

自从第二个迭代，有一位软件集成及验证的成员加入到团队，团队因此跨职能了。开始时Scrum团队中的软件开发成员还是指望测试成员做所有的功能测试。不久团队发现测试成员在迭代中比较空，因为他已经完成了测试计划和测试用例设计，但直到迭代后期功能开发好了，他才能开始做测试执行；同时在迭代后期测试执行和报告的工作量又让他难以应付。团队在两个方面引入了变化。一是团队成员跨职能地来分担工作量，认可各个成员具备的基于流程阶段的专业技能并相互学习。二是在迭代中引入了小的增量，使得不同流程阶段所需的工作量被更均匀地分布在迭代中。

我们的跨职能团队中没有包含系统设计的现实带给我们额外的挑战。在我们的组织中，系统设计的职能线负责需求分析和技术方案。我们分别来应对。PO做需求分析，而我们的Scrum团队负责技术方案，不过他们仍然会从系统设计职能线得到输入。

协同工作

在一个Scrum团队的工作期间一直有新成员加入。到第5/6个迭代，我们已经有9个成员了。有一次一个新成员让我在有他的工作时通知他。我意识到有必要持续关注提倡团队工作的精神。虽然团队工作不是什么新概念，Scrum却把它带到另一个协作层次，要求思维和习惯上的变化。就这点来讲，团队成员的逐步增加工作得还不错。

从说“我做完了”到问“我们做完了吗”，团队发生了转变。在一开始时由所有团队成员一起定义“完成”是个重要的活动。在一个人人都有清晰的组件职责的组织环境中，即使定义了“完成”仍然需要一些时间来让大家不再说“我做完了”。

每日站会、迭代待办列表和燃尽图是用来支持团队协作的新工具。团队从只是在迭代末期才关心进度到开始在整个迭代过程中都关注进度花费了一段时间。我们尝试了不同形式的迭代待办列表，从Excel表格到墙上的白纸，以寻找最适合团队的方式。

工程环境和实践是协作的另一个方面。从第二个迭代开始我们用Subversion代替Clearcase作为版本控制和配置管理系统。这个措施来自于第一个迭代的回顾。它对工程实践上的改变具有深远影响。工作坊和结对工作比之前更经常了。那时大多数诸如测试驱动开发、持续集成之类的敏捷工程实践还没有到位，我们只是从最基本的单元测试开始，在当时的工程环境中我们通常连这也是不做的。

微小的成功

在扩展到多团队之前我们作为一个Scrum团队运作了有6个迭代。PO对我们的交付能力和相互协作感到满意。我们也对自己的能力提升、开发环境的改善等感到高兴。我们享受着这微小的成功！

同时，因为给予的Scrum介绍课程和实实在在Scrum团队的存在，相比半年前，Scrum开始被更多人所知晓。我们也给组织过程组分享了第一阶段的经验报告，进一步播下了种子。

多团队扩展

在2006年6月，我们开始扩展Scrum团队以加速开发项目。同时也意味着我们需要探索多团队如何工作，做到这一点对于像我们这样几百人的组织来说至关重要。

原先的Scrum团队成员被分散到了三个团队，在此基础上增加了新的成员。异地PO由本地PO取代，以帮助到更好地跟团队交互。这也让迭代计划和评审的实际安排更为容易，因为要不然扩展后的迭代计划和评审会没法安排进两个地点的共同工作时段内。新的SM也从本地选出。他们当时还不是实践者，但都认可和赞同团队自管理，并对敏捷开发抱有热情。同时他们各有不同背景，有些熟悉现有的项目管理实践，而有些则不熟悉。通过辅导和一起紧密工作，事实证明运作得还不错。

然后项目的第二阶段以新团队的启动开始，达成了对项目目标的共识，并约定了“完成”的标准。所有三个团队共享同一份产品待办列表。我们的产品待办列表在团队扩展时经历了重大调整，这一次所有团队都有机会参与其中。

Scrum of Scrums

我们提出了扩展到三个团队的迭代计划和评审议程。

上述框架在项目第二阶段的6个迭代中基本保持不变。迭代计划和迭代评审各花费6个小时左右。最初的迭代计划采用了速率驱动的方式。呈现的产品待办列表条目数量是基于版本计划中的估算。我们在后面的迭代中尝试了承诺驱动的方式，团队对此更为喜欢。然而也存在一些实际挑战，因为只有唯一的PO，团队不得不一直都待在一起，由此引起一些团队间的相互干扰。迭代计划的第三部分（发生在中国的下午时间和芬兰的上午时间）也被用作向两地干系人的总结。

每日站会扩展成了Scrum of Scrums，由各个团队的代表参加，并把那三个问题中的“你”改成“你们团队”。所有团队都决定轮流成员作为团队代表参加Scrum of Scrums。迭代计划和评审中分享的信息为运作扩展的每日站会提供了基础。

持续集成

随着团队规模的增加，持续集成通过持续同步团队间的工作为成功协作开发所起到的作用越发关键。CruiseControl被用于创建基础设施。

如前所述，虽然Scrum并没有规定使用任何工程实践，它的有效实施确实要求在工程实践上有所变革。由于迭代增量式开发的特性，回归测试的权重相比瀑布开发要大很多。期待一夜之间就有完整的自动化回归测试集合并不现实。更重要的是让事情能开始转起来。我们在开发新功能时写更多的测试代码和脚本，即使它的执行最开始并没有绑定到每日构建。我们一次走一小步，但是确保持续在进步。

“大震动”

在2006年的秋天，Craig Larman关于敏捷和迭代开发的研讨会推动了进一步的变革。研讨会在杭州和艾斯堡各举行了一场。通过聆听敏捷和迭代开发的历史，学习现代的工程实践，我们工程师的兴趣被进一步唤起，并扩散到更大的范围。愿意尝试的热情和伴有顾虑的犹豫都有利于保持变革的生机。

我们组织中的上层管理开始更明确地讨论向敏捷开发和Scrum变革，并开始准备具体针对我们组织上下文的建议。

小成功

在三个团队完成了又一轮六个迭代后，我们成功实现了项目目标。作为本土的成功故事，我们在组织中广泛分享了经历，并在组织的不同部分触发了具体措施。这一小成功为我们作为早期实践者创建了更多机会去扩大影响，以使其它项目和职能线也做出改变。

同期在芬兰艾斯堡有一个职能线团队也实施了Scrum并获得积极反馈。他们和我们的经历一起对下一步行动产生了重要的影响。

下一步行动

到2007年上半年，在更多团队开始运行Scrum的同时，上层管理已经在制定组织层面推进变革的计划。

考虑客户焦点和灵活性，理想的组织结构将是建立跨职能特性团队，并把它们组织成客户需求视角的领域。这也被称作需求领域。

需求领域比单个特性更为稳定，具有更长的生命周期。在我们的上下文中需求领域的例子有电路交换、分组交换、高速分组接入、高度可用性、性能统计等。特性团队可以持续工作于同一需求领域的不同特性。

然而一次性转变会有一些困难。首先在我们的组织中有严重的过度专业化，而产品又相对复杂，因此需要更多时间来逐步克服限制。其次我们在诸如持续集成这些现代工程实践方面很落后，而它们又是让特性团队工作起来所必需的。考虑到这些困难，多数管理层仍然对一步转向理想结构缺乏信心。因此，当时我们对下一步要引入中间的组织结构来获取更多经验是有共识的。

有两个主要的演进选项。

1. 在基于大组件的领域里创建长期的部分特性团队。
   
2. 围绕整体特性创建短期项目团队，而仍然保留基于组件的矩阵组织。
   相比团队开发的因素，这个选项更看重客户特性。因为项目团队较短的生命周期，团队可能永远没能达到高效状态，或者刚达到就被解散了。此外，矩阵中的组件组织依然存在，这对特性团队成员扩展他们的专业领域形成了一定障碍。

其实两个选项都不算好，但是因为觉得在我们的环境中还是有必要引入中间步骤，最后我们选了第一个选项，并设计了以下组织。

在这个组织里，我们去除了矩阵中的项目维度；而保留了系统设计和系统测试的职能，这是因为我们的领域还不是需求领域而是组件领域的缘故。在组件领域中的Scrum团队有时是整体特性团队（当某个特性开发正好发生在一个大组件领域内），有时是部分特性团队（当某个特性开发需要多个组件领域的工作）。这一变化让我们离理想结构靠近了一步。

这次变革发生在2007年的夏天。从那以后，我作为其中一个领域的管理者继续前进。

跨越鸿沟

我们在敏捷和Scrum的导入中取得了小成功。上层管理迈出了下一步。我们现在看到一个有希望的未来。然而，如果我们不注意，很多陷阱都将导致失败；为了更大的成功我们必须跨越它们。

当最初的团队取得小成功时，组织的其它部分落在了后面。他们过去是基于小组件来组织的。在大组件领域中，我们尝试在它里面创建特性团队。这是个挺好的机会来采用自我选择组建团队（下图所示是其中的部分场景），它是一个变革的鲜明信号。有个风险是变革怀疑者们可能会扎堆；后来我们确实在建设其中一些团队时遇到了更多挑战。

陷阱

在最初的几个月里，各种怀疑接踵而至，感觉鸿沟就在眼前。

“我们需要遵守承诺”

在Scrum中是由团队决定做多少，他们在迭代计划中做出承诺。Scrum也认可有需要做更长期的计划，通过版本计划、需求大小估算和速率度量来完成。如果我们已经做了承诺并需要团队有更高的速率该怎么办？有两项建议被组织里的一些人一次又一次地提出来。

1. “完成”拖慢了我们，我们为了更高的速率能调整它吗？我们引入了诸如单元测试、测试驱动开发和验收测试自动化这些新的工程实践，之前我们并不做。我们看到因此花费了更多的工作量，所以如果停止做这些，我们的速率可以立刻增加，对吗？如果我们不理解那些工程实践对迭代增量开发有多关键，如果我们不能坚持做这些实践，我们的Scrum实施将只是表面上的。
   
2. 我们要加班来达到所需速率。我们知道在晚了的项目中加入更多的人只会让它更晚，但是我们可以让团队加班来达到期望的速率以遵守承诺，对吗？这是可能发生的情况。我们在做前期版本计划（注意这不是持续的计划）时把估算当作了承诺。如果我们的估算错了 – 低估了工作量，我们就加班来赶上以遵守承诺。那样的话，在迭代计划前我们已经知道那个迭代需要交付什么。这样有什么问题吗？首先Scrum强调可持续的节奏，而在计划中放入加班并不持续。其次这总是会导致降低质量的情况，从而逐渐产生遗留软件。

两个建议看起来都很吸引人，但是它们最终都将伤害到我们的产品开发。为了应对，我们必须接受现有速率低于预期的现实，同时持续地改进。我们不应该裁剪Scrum来隐藏问题，或者在真正理解Scrum之前就对其加以裁剪。

“我担心有人偷懒”

Scrum给团队太多自由，让组织里的一些人不太舒适。自组织、团队估算、任务选择等都有失控的风险。如果团队故意多估工作量以便有更多时间上网该怎么办？如果团队因为没有经理管理他们而不能承诺于迭代目标该怎么办？当然，不压他们团队是不会高效的。

关于团队动机有X和Y两种理论。X理论里管理者假设员工本质上是懒惰的，会尽可能避免工作。Y理论里管理者假设员工可以自我激励和自我组织，相信他们是享受工作的，在给他们自主时反而能有更高的生产力。很明显，Scrum带有Y理论的假设。

我们的组织在变革前是指挥和控制的文化，我们的员工开始时在Scrum模式中的表现未必好。他们可能看起来并不积极承担职责，他们可能看起来在高质量标准上并不够职业，他们可能看起来有点懒散，他们可能看起来跟其他成员协作得并不好。如果以此就断定我们的成员不够好所以Scrum在这里不适合则就大错特错了。我们看到的问题更可能是由之前的系统带来的。当总是有经理告诉他们做什么怎么做时，成员会失去主动思考和解决问题的能力。在新的系统中他们的潜能随着我们的帮助和耐心将会被释放。这其实就是领导变革的意义。

“我们不能承受效率损失”

我们已经在组件团队的结构下形成了单一专业化。当我们现在转向跨职能特性团队时，成员的过度专业化变得很可见。做组件工作的效率跟单一专业化绑在一起，所以我们想，我们不能承受效率损失，因此最好保留目前的专业化。

过度专业化导致不灵活，而我们按常规假设专业化是有利于效率的。认识到消除单一专业化可能损失效率，但是相对于高效地工作在低优先级特性，低效地工作在高优先级特性经常更好。更别说效率的假设也在被初学者心态的概念和相关实验所冲击。

如果想在我们的组织里打破单一专业化，我们并不需要发展所有团队和成员准备做我们产品中所有新特性的能力配置。切合实际的方式是结合特性开发来执行“工作中学习”。当我们开发一个特性时需要改动组件A、B和C，我们在那时学习这些组件。我们学习模块结构，并学习改动特性所需要的细节。随着一个个特性的开发，我们学习到更多组件，也更深入。如果某些人从深度到广度来学习更为有效，也有一些方式。我们可以更多聚焦在某些组件，同时也不排除工作于其它组件。不管哪种方式，我们逐渐都在发展更多人成为通用专家。

“共享责任就是没人负责”

共享责任是Scrum团队的根本，事实上它是任何高效团队的根本。然而共享责任过去并不是我们组织的常态。把共享责任理解成没人负责还是在很多人包括一些管理者中根深蒂固。这导致了很多误解和功能障碍。

在SM负责团队产出和SM负责团队的良好运转之间有细微但重要的差别。一个运转良好的团队会负责自己的产出。把责任放在一个人身上反而会抑制团队通往自管理。

当我们从组件团队转向特性团队时，多个团队将会工作在同一组件上。共享组件要求很强的协作意识和工程纪律，而这些都是我们转型开始时所缺乏的。团队起先只关注自己的工作，当有共享组件被破坏时就相互指责。“如果每天提交我的工作那会一团糟”，我们习惯于大批量滞后做集成。我们认为这对开发是好事，因为这样做相互不干扰更有效。我们的工程实践落在后面。我们没有单元测试用具；我们不重构代码以至于代码库越来越难看；我们没有自动化验收测试。让我们共同承担共享组件的责任确实有很大的挑战。当我们刚组建特性团队时，大家一起讨论并约定了创建团队分支以减少相互干扰。在迭代评审前三四天，团队才试着把他们的工作集成到主干。经历惨痛的失败也就不足为奇了。

在组织层面，我们的管理团队更像是一个群组，每个人有自己的范围并相互竞争。围绕各自范围设立目标和奖金造成了竞争大于协作。

一旦我们陷入争论，最好的前进办法是去做并一路解决问题。那些问题其实一直都在。现在既然显露，就是时候解决它们了。

解决方案

面对挑战，我们聚焦以下事情来帮助跨越鸿沟。

培养人员

我们有了新的SM，他们跟团队紧密工作在一起。因此我们投入在培养SM的领导力和对敏捷工程实践的理解上。我们在组织里创建了连接所有SM的网络。我们发展Scrum伙伴关系 – 彼此观察并给予及时反馈 – 来为他们的学习建立反馈回路。我们从自己组织的早期实践者中或者从外部引入Scrum教练。

导入诸如单元测试、测试驱动开发和验收测试自动化这些新的工程实践需要为团队提供支持。我们为此引入外部教练的做法是行之有效的。期间我们开始发展自己的内部教练，以便能在外部教练离开后继续支持其它团队。持续集成是非常关键的实践，要求我们养成纪律和协作态度。

人总会倾向于退回到老习惯和实践。许多陷阱都与此相关，所以培养人员对解决它们至为关键。

挑战和改变组织

敏捷和Scrum不只是软件开发。它要求在我们组织的很多方面都有进一步的变革。我们得持续挑战常规和背后的假设。比如我们需要改变奖励机制来支持协作。

我们为整个组织维护了一份障碍列表，以便聚焦于解决障碍来推动变革。带着组建理想中完全跨职能特性团队的终极目标，我们抓住每一个机会来向它演进。

经历这个阶段就像跨越鸿沟，挺难！坚持并加以战术，我们相信将会抵达彼岸！

结论

自从开始把敏捷和Scrum引入到我们组织到现在已经有两年多了。回看起来对我而言关于引入变革最有价值的学习是“检视并适应”，这也正是敏捷开发的关键宗旨。

思索未来。我们将把组件领域转变成需求领域。我们将扩展Scrum团队的“完成”以把系统设计和系统测试包含进需求领域。在那之后，平台本身也是一个大组件。。。

写于2008年