微软成为规模化敏捷组织的 16 个关键因素

2022 年 6 月 07 日
本文字数：8840 字
阅读完需：约 29 分钟

在星期二发表的文章的第一部分中，我解释了微软如何成功地实现了为期五年的大规模敏捷转型。在第二部分中，我讨论热点问题“规模化”。

在一个团队甚至几个团队中做敏捷和 Scrum 是一回事。在数百个团队中以协调的方式进行敏捷和 Scrum 是完全不同的概念。依赖关系如何处理？团队如何保持同步？如果数百个团队自治，管理层如何知道发生了什么，更不用说如何控制？

许多总经理甚至怀疑，大规模敏捷是否有可能。创意型经济学习联盟对微软进行的访问活动表明，答案是肯定的。这次访问是创意型经济学习联盟活动的一部分，访问对象是拥有约 4000 名开发人员的开发部门中的 Visual Studio 小组。访问活动表明，微软不是一艘巨型军舰，而更像是同步行进的快艇组成的舰队。

学习联盟由受到 Scrum 联盟赞助的若干家公司组成，致力于相互学习创意型经济的管理实践，即《财富》杂志所说的“新工业革命”。Scrum 联盟本身是一个由 40 多万会员组成的协会，他的使命是致力于改变工作的世界。微软接受访问的是 Aaron Bjork—Visual Studio Online 的一位项目群经理。

1.追求“大规模敏捷”而不是“扩大敏捷”

首先请注意，微软的经理们讨论“大规模敏捷”而不是“扩大敏捷。”言外之意，“扩大敏捷”就像“扩大法律部门规模”或“扩大自助餐厅规模”一样，没有更多意义。敏捷和 Scrum 这套方法并非像狂热者有时认为的那样：是所有可能的管理或领导力问题的灵丹妙药。一个组织的活动有许多方面，包括战略、计划、财务、市场和销售，与敏捷宣言中所指的“工作的软件”这个目标并不相关，至少没有显著的关系。

微软探讨的问题是：“我们如何使整个组织敏捷？”而不是“我们如何扩大敏捷或 Scrum？”软件开发中的 Scrum 和敏捷方法论对回答这个问题有巨大的潜在贡献，但 Scrum 和敏捷只是故事的一部分。

微软的“大规模敏捷”不会不论目标是什么就要求团队盲目遵守。微软开发部门实行的“大规模敏捷”的本质是敏捷的核心价值观。这包括紧密关注向客户交付持续的价值，而不仅仅是产生季度利润或提高当前股价。它还基于对员工的工作能力和天赋深怀敬意，而不是将员工视为可指派的，可优化的一次性“资源”。

管理思维模式的一个关键方面是，管理者自己明确的意识到管理权力既有能激励、鼓舞员工的潜力，也有能使员工沮丧、泄气的潜力。所以，需要有意的，甚至微妙的使用管理权力，为在对齐和自治之间取得适当的平衡而持续努力。

2.关注计划和协调

计划从建立产品愿景开始。然后，一位像 Aaron 这样的项目群经理开发并负责所谓的“场景”，这个场景是产品未来 18 个月的目标，是关于该项目群在 18 个月后成为什么样的故事。故事可以让其他团队参与。该组对自己的能力有 60％的信心去预测并交付客户想要的东西。这一年被分为两个季节，称为“春季”和“秋季”-这两个词是一个当地的笑话，反映了西雅图的夏季非常短暂。

每六个月有一次场景回顾。小组回顾进展，并检查下一步计划。这通常意味着场景重塑，这里有三个问题：基于我们构建的产品，在过去六个月中，我们学到了什么？我们的客户告诉我们什么？市场上发生了什么变化？这既是计划也是学习。

每个团队都有权力更改。如果团队看到某些遗漏的方面，他们只需要告知团队领导，不必为更改去请求许可。

这组团队执行六个月后，再次回顾计划，该组对于他们在六个月内能够完成的工作充满信心。但他们没有建立一个跨多个团队的甘特图，计划时间或那些细节。他们都是通过团队之间的谈话获得直觉，去判断在六个月内需要做什么，哪些方面可以做到。并且基于他们从客户了解到的信息和他们学到的知识，计划可能更改。

任何时候，每个团队都维护和负责一个经过深思熟虑的详细的计划，这个计划包含三个 sprint，每个 sprint 是三个星期。对于接下来的三个 sprint 中将要做什么，团队总会有好主意。在每个 sprint 结束时，团队会决定做什么。他们可能决定开发新的功能或决定学习新的东西，可能决定需要把一些东西提前到从现在开始的两个 sprint 中。这里有调整的空间，而且这种调整是被期望的。事实上，这就是整个重点所在。

如何计划和协调，没有唯一正确的答案。它不仅仅是在刚刚完成的 sprint 结尾添加一个新的 sprint。团队正在谈论这些问题，并与经理们讨论，回顾他们所学到的东西。在每个 sprint 中，他们都从用户角度重新审视。

在 sprint 的最后，团队认识到他们已经完成了什么。但他们不会过多地向后看。他们不会说，“我们真的完成了三个 sprint 计划！”他们对所做的有所认识，但他们没有庆祝他们做对的事情，或为做错的事情感到悲哀。唯一重要的问题是：客户如何回应他们正在做的事情？

过去，团队会盲目地遵循计划，因为计划已经得到管理层的同意和批准。而且团队似乎正在交付计划。最后，团队会说，“我们交付了计划！多棒，对吧？“表面上，的确是的。但实际上，隐藏的质量问题往往会越积越多，技术债务正在积累，总有一天必须偿还。客户在想什么？没有人关心，关注点在内部。

当然，不是一切都会按预期发生。例如，一个团队有一个计划，包含三个 sprint，他们说，“我们将在下一个 sprint 做 A，B 和 C。”但他们没有完成，下一个 sprint 仍然是 A，B 和 C，第三个 sprint 也仍然是 A，B 和 C。显然有些事不对。发生什么了？团队进行讨论，如果是团队内部问题，他们就会与管理层讨论。如果他们正在做的事情比预期复杂得多，也许他们应该重新做一些计划。没有关系，重点是谈话正在进行，而不是盲目地遵循一个计划。

3.获得适当的对齐和自主平衡

微软大规模敏捷的目标是在（组织结构的）顶部拥有对齐，在底部拥有自治。团队需要自治，这驱动他们工作和创造伟大的产品。但同时，他们的工作必须与业务对齐。如果控制太多，什么也做不成：没有人想在那里工作，这不是一个有趣的环境，事实上，这是一场灾难。如果控制太少，就会混乱：每个人都在构建自己想要的东西，没有端到端的场景，客户也会很受挫，所做的一切都没有商业意义。所以管理者努力在两者间争取适当的平衡。

管理者负责交通法规。这包括明确角色、团队、节奏、词汇和对团队可以有的 bug 数量的限制（“bug 上限”）。

团队在如何开展工作方面拥有自治权，包括计划和实践。在总体框架内，每个人都可以采取不同的方法。具体的工程实践取决于团队。例如，团队自己决定是否做结对编程。

管理的作用就像建立交通法规。你可以在高速公路上快速开车，事实上，高速公路的设计就是为了让你快速行驶。但规则是存在的。当你开车转向时，你必须开指示灯。你必须在一定的点上慢下来。你必须注意这些东西。交通管理部门可以通过每隔一百码放置减速带，以及每英里设置红绿灯，使高速公路更加安全。虽然这会更安全，但会减慢速度。微软的经理们采取相同的方法。他们规定团队需要遵守的最小的基本交通法规集。他们的目标是确保这些法规可以帮助团队快速前进，去他们想要和需要去的地方，而不是减慢团队的速度。

当然，如果你问一个工程团队，正如 Aaron 所说，“领导让你做的什么事情会减慢你的速度？”你会得到一堆反馈，而不是一两项。他们经常提出成串的问题。团队只是在等经理问问题！团队会告诉经理他所做错的一切，并就此双方进行对话。关键是有这次谈话，这是一个安全的谈话。

4.掌握经理的新角色

当团队不能完成一个 sprint 时会发生什么？经理不监控团队的燃尽图。燃尽图是给团队用的。如果他们落后于进度，猜猜团队做什么？他们会谈论要做什么。这正是经理想要的行为。经理支持这种行为，因为文化支持它。如果经理对团队喊叫或监控他们的燃尽图，猜猜经理会得到什么？完美的燃尽图！那么经理想要完美的燃尽图还是适宜的对话？终究，必须是后者。

这是原则和实践之间的区别。人们理解为什么他们在做这些，这至关重要。人们为他们所做的这些带来的价值承担责任。如果每日站会没有效果，那么做一个成年人，做出改变！这就是自主权。“你在控制！你负责！”。

5.处理团队级别的依赖关系

在微软的开发部门，团队之间尽可能自己处理依赖关系。所有团队都在一起，彼此知道其他团队正在做什么。经理或团队并非只关心产品中由他们负责的那一部分，他们也了解其他团队的进展，他们都知道其他团队在做什么。如果一个团队对另一个团队有依赖，他们不会等到会议时才让对方知道。项目群经理和工程经理会提前谈论并发现这种依赖关系。他们自我管理并学习如何变得擅长自我管理。

当然，有时候，团队的领导们会参加会议并发现：“哦，你们已经开始这项内容了吗？我们不知道！你应该告诉其他团队。”他们确保团队之间进行一次交谈，交谈在线下完成后，领导弄清楚现状。

我们希望这个包含三个 sprint 的计划包括所有的依赖关系。Aaron 和他的五个团队一起工作。其他团队组成的六个组也采用相同的流程。经理们坐在一起谈论团队级别的依赖关系，并持续地进行梳理。他们坐在同一个房间里，这是一个持续的对话。

每三个月有一次跨所有团队的常设会议。它被称为“功能团队谈话”。开会时，每个团队加入进来，并讨论他们的计划。Aaron 共有 90 分钟，他的每个团队有 15 分钟的时间加入进来分享团队的计划。他的同事也携团队参与进来分享。所有团队都参加这个会议，所以所有人都了解情况。开发部门的领导团队也有机会同步当前进展。

6.确保持续集成

持续交付意味着设计要更加模块化，架构也要随之改变。当开发部门首次进入服务业务领域时，他们使用定做的产品，将其放在云端，然后祈祷。结果这个产品不工作。当产品的一部分不工作时，整个产品都不工作。他们明白了他们需要把服务分层，来把出问题的部分隔离开，而避免殃及整个产品。因此，持续集成是需要深入的架构改变来支持的。

当他们开始时，在为期三周的一个 sprint 期间，每个团队都在一个代码分支工作。在 sprint 的最后，他们会把代码全部放在一起，结果一片混乱。事实上，团队欠大量的“集成债务”，该模型没有起作用。因此，为了交付每一个 sprint，他们不得不做出根本性的改变。原则上说，现在所有的团队“在同一个分支工作。”

“在同一个分支工作”的意思是，每个团队都使用一个名为 Git 的程序，拉分支，做改变。但是团队不是独自封闭地工作三个星期后，再希望代码聚在一起。而是他们一整天都在一起，每天都在一起。因此，如果一个团队损坏了构建，它会竭尽所能，立即修复构建。团队推迟将代码放在一起的时间越长，技术和集成债务的风险就越大，最终导致灾难。

团队使用他们所谓的“功能标志”，这里简明扼要地描述一下它是怎么工作的。如果他们要做新的东西，他们做的第一件事是把他们正在变更的代码隔离开，并为变更的代码进入集成代码建立一个开关。这个开关由数据库中的一个标志提供。这是一个配置变更。当团队编写代码时，他们将其写在标志的安全保护之后。到达某个阶段，一切准备就绪后，他们只为团队而开放。该开关不是全局的开关，而是给这个团队专用的开关。如果顺利，那么团队可以为某些客户打开开关。这些客户可以看到，且可以尝试，从而帮助团队发现错误和问题。当团队通过以上这些关口，并且认为一切确实准备就绪，他们会准备发布说明和公告，为所有人打开开关。然后他们回去重构旧的代码。“功能标志”的工作机制使得多个团队可以在相同的代码上一起工作，而不会彼此干扰。

在每个 sprint 结束时，团队向包含 Visual Studio Online 小组和领导团队的所有 450 人发送电子邮件。他们谈论他们在 sprint 中完成了什么，他们的下一个 sprint 计划是什么。他们录制了 3-5 分钟的视频。（提示：如果团队有位雄心勃勃的好莱坞导演，视频会很神奇。）视频取代了 sprint 演示。

7.把技术债放在首位

“在过去，”Aaron 说，“当代码写好时，团队举行聚会庆祝。他们感觉已经完成了一些东西。但事实上，他们正坐在堆积如山的 bug 上，他们甚至还没有发现所有的 bug。现在他们不得不回头找出所有这些 bug 并修复它们。他们离交付还有几个月。这是一场噩梦。

“现在 bug 再也不增长。有一个关键性能指标（KPI），我们称之为“错误上限”，即你团队中工程师人数的四倍。因此，如果你有十个工程师，你的错误上限是 40。如果你团队的 bug 数达到 40 个，就需要停止新功能开发，在下一个 sprint 中，让 bug 数降到低于 40。这就是自管理，团队懂得这一点。这意味着现在我们可以随时发布产品，因为我们知道我们总是处于一个健康的状态。

8.拥抱 DevOps 和持续交付

以开发和运营合并的方式工作。团队集每个新功能的计划、开发、交付和运营于一身。

因此，如果服务不能正常工作，那么他们必须停止正在进行的工作来处理它。如果发现 bug 或需要修复 bug，他们就是修复 bug 的人。过去曾经有单独的支持团队做这些事，但谁想花时间修复其他团队的错误？

团队负责该功能的整个生命周期。如果服务频繁崩溃，那么这是代码质量的问题，也是构建优质代码的动力。团队在连续的基础上开展工作。团队对自己创建的功能负责，不去责备任何其他人。他们没有大型发布的压力，他们可以把工作分阶段，按照他们的节奏解决问题。

时间框架的变化导致很大不同。现在截止日期为三个星期。三个星期没有什么大不了的。之前，你只有两个机会，如果你错过了，你必须等待两年。现在，如果产品的质量不高，你不推出它，而是把它扣留下来。没能如期发布令人失望。你在回顾会议中谈论它。你做错什么了吗？或者你只是低估了复杂性？你遗漏什么了吗？来一次交谈要好于临时补救或惩罚没有完成承诺的团队，更好于交付质量低劣的产品。

事情发生了巨大变化。以前，组织中有很多 bug，人们对于谁负责哪个 bug 指手画脚，但结果是 bug 持续了很长时间，并且越来越多。现在团队自己找到它们，修复它们，并完成它。Bug 周期已经大大降低。

两年前，该团队轻率地提出每日交付代码的想法。但他们发现客户并不想要，这意味着太多的变化，每日交付的商业需求并不存在。同时，团队正在学着一小块一小块的做工作。

9.持续监控进展

团队针对功能被使用的情况做了大量监控。监控结果进入待办项，成为远大的目标，称之为场景。每个月，项目群经理都会报告关于不同服务使用状况的度量数据。这样，这个组正学着成为一个了解数据的团队。他们不称之为“数据驱动”，因为这将有一叶障目不见泰山的风险。他们凭借直觉思考，也借助于数据。但数据不是思考以后的结果，而经常是谈话的开始部分。

数据可以用来局部地预测“完成”的情况。团队在测试功能和功能刚一上线时，都能看到并监控这些数据。监控数据不是他们发布功能以后才在 Sprint 里做的事，而是发布验收标准中的一部分。

一旦代码发布，团队会问：软件人们用的怎么样？它是否正驱动人们集中到我们交谈的核心？他们会成为常客吗？或者只是一位偶然的客户？他们使用度量来驱动业务向前发展。

10.倾听客户想要的，但满足他们需要的

项目群经理进行各种各样的客户拜访活动，包括在负责战略的执行发布中心拜访最高层，在客户委员会拜访使用产品的人们，以及微软最有价值专业人士。这些专业人士通常在现场担任顾问，以某些形式销售微软的产品，他们不是微软的员工。还有一个分布表，称为冠军名单。这些人整天给微软写信谈他们想要的东西。项目群经理会与他们交谈。销售团队将开发人员与客户挂钩。项目群经理会在 Twitter TWTR 用他们 7.04%以上的时间和客户沟通。

对客户所说的，团队不会盲从。他们有自己的“饼干原则”。如果你有一盘饼干，你问别人是否想尝尝，他们会说是。没有人会拒绝饼干。如果你去问客户，“你想要这个功能吗？”猜猜他们说什么？为什么不要呢？这是创新者的困境。外面有很多好东西是你能做的。你需要倾听，但不能盲从。项目群经理需要倾听客户说他们想要什么，但他们的工作是构建客户需要并且公司可以销售的产品。否则，经理们就失职了。

11.处理来自高层的指导

Aaron 从来没有听说过任何上级说，“停止敏捷这个东西！”当然原因之一是敏捷团队已经非常成功了。敏捷因其成功而成长和扩展。

团队仍然接受来自高层的指导。在我们拜访期间，一个团队正被调去做别的事情。虽然这是破坏性的，但的确正在发生，因为其他地方需要这个团队。团队成员会作为一个整体待在一起，经理们坐下来和团队商量这件事。

保持团队之间平衡的负担几乎没有。如果一个团队落后，他们不会解散团队或把人力挪到落后的团队中来解决问题。他们要求团队自己解决这个问题。他们尝试在 12 或 18 个月中，让团队们在一起。这才是团队自己喜欢的。目标是让他们得以擅长一起构建软件。那是他们的工作。如果你每三个 sprint 对团队进行一次重组，甚至对他们正在做的事情进行重组，团队之间很难配合默契。公司正在对团队进行至少九个月或一年的投资。

12.使用自组织团队以鼓励团队所有权

正如微软公司副总裁布莱恩 • 哈里（Brian Harry）在一篇有趣的文章中所述，经理们让员工选择在哪个团队工作。员工可以每 18-24 个月重组一次。大约三分之二的团队成员决定留在原先的团队。因此，全新的团队不是很多。但是团队成员有重新选择的权利。这样做的结果是对持久的团队的重大投资，除了导致团队的健康，还导致更高的绩效。

团队拥有待办项。当然，有很多关于优先事项的讨论。但是经理不告诉团队看板上的下一项应该是什么。团队也不指挥经理。他们会总是谈论它。这是一个持续不断的对话。这就像，“嘿，这个怎么样？我们应该做那个吗？你是否认为我们已经在那里投入很多了呢？我们应该去这里吗？”项目群经理与他的经理进行同样的对话。

这些对话需要一定程度的相互信任。作为一个经理，你不可能参与一切，你不可能知道一切。经理对团队说一些事，团队倾听但不盲从。这是给予和采纳。这是一个基于了解数据的对话。这样的对话一直在进行。

13.认识到团队是产品

在软件中，产品生命周期缩短。在传统核算中，业务资产是产品。但在实践中，能够交付产品的团队成为越来越重要的资产。团队产生价值的生命周期比产品本身更长。这是关注点的重大转变。

在开始敏捷转型以前很长时间，微软就在拥有团队方面具备优势。微软已经存在强大的团队文化。对于没有团队历史的企业来说，敏捷转型会更加困难。当你思考敏捷，你会认识到敏捷的很多价值观来源于工作由团队来做这个事实。所以，看到你起步的基线很重要。

微软把自己看做在对那些人进行投资。有时候组织不认可这种投资。高层可能只是把人看做可移动的资源，这种风险是存在的。“在微软，那样行不通，”Aarson 说，“领导团队理解这一点。”

但改变有时是必要的而且需要成本。例如，当一个团队被调走时，其他团队会感到难过，因为他们已经花费时间和精力与这个团队打交道，他们去年一起工作了一年，这是一种投资。某一团队被调走，对每个人都有破坏性。Aaron 解释了做出这个决定的原因，并告诉团队：“在新的领域里，你们不会有同样的速度。你必须提升和建立专业技能。“但在这种情况下，他们至少已经是一个团队，所以他们已经有一定程度的信任。如果全新的一组人在一个全新领域一起工作，成本会高得多。

14.从开始就注重质量

在微软敏捷转型之初，要学习的内容很多。在前几个 sprint 中，有个 3 周 sprint 的协议。领导签署了敏捷和 Scrum 的想法，但他们有点担心敏捷和 scrum 效果怎样。所以他们在五个 sprint 后计划了一个“稳定 sprint”。但是，那就鼓励一些团队想：“不需要担心 bug，因为我们有稳定 sprint！”结果产生了很多 bug，所有团队不得不参与帮忙解决它们。

实际上，他们已经告诉人们做一件事，但他们创造了一个环境，促使一些团队做相反的事情。谁能责怪团队呢？团队告诉经理：“不要再这样对我们了！”这是一个意外后果的很好例子。

最重要的是，目标是避免序列：在第一个 sprint 中写代码，在第二个 sprint 中测试，在第三个 sprint 中的修复错误。交通法规是：每个 sprint 交付完成的产品。

它是自治概念的一部分。如果团队可以控制自己的质量，他们就不会对将来不得不做什么感到惊讶，比如周末加班。他们可以搞好自己的业务，不受他们无法控制的东西影响。

15.小心使用教练

站点拜访发现，微软的外部教练和培训师缺席现场显而易见。Scrum 开始时有过一些辅导和基础培训。但过了一段时间，小组开始只是自己“做”，弄清楚哪些起作用就多做，哪些没用就不做。一些微软员工和经理实际上转为敏捷和 Scrum 教练。但总体来说，小组自己出发，大胆去做。

最近，很多没有做基础培训的人加入进来。于是公司给出了多做培训的想法。同时，公司也意识到没有“一刀切”的办法，在其他地方起作用的办法可能不适合微软文化。

16.确保高层支持

微软最高管理层在敏捷转型之初持谨慎态度。但现在已经改变了。“现在有了广泛的认可，”Aaron 说，“敏捷是构建软件的现代方式，在团队层面实施并不太难。你抓来十个人和一本 Scrum 指南就可以做了。但是你怎么横跨四千人实施敏捷并保持同步？这才是挑战。你怎么规模化地实施敏捷？”

为了实现规模化敏捷，公司副总裁 Brian Harry 的支持已经成为核心。现在，在开发部门，Scrum 和敏捷实践有了坚实的立足点，Aarson 已经获益其中。Visual Studio 小组正在把微软作为一个整体引领变化。它拥有“第一小组工程系统许可证”（IES），并正在整个公司推行。有月度记分卡追踪大部门在实施敏捷方面做的怎么样。

这种领导作用与语境有部分相关，从提供云服务可见一斑：他们的客户甚至在知道用户故事是什么之前就在编写用户故事。所以他们必须是快速的学习者。

“这需要时间，”Aaron 说。“我们已经花费五年时间致力于此了。我们没有同时做出所有改变。物理空间的改变是我们所做的最后的改变之一。如果我们搬进一个团队室，把所有的规范放在一起，试图做三个星期的 sprint，它不会起作用。它不得不进化。人们需要那样的时间来让它进化。情绪上，它需要时间。你不能同时做出所有改变。

采取方式

当我问 Aarson 对其他大型公司开始敏捷转型有什么建议时，他提出了以下建议：