微软5年敏捷转型策略：成功的16个关键

许多管理者怀疑规模化敏捷组织是否可行。微软成功地实现了为期五年的大规模敏捷转型表明，答案是肯定的。微软已不是一艘巨型军舰，而更像是同步行进的快艇组成的舰队：数百个团队中以协调的方式进行敏捷和Scrum。依赖关系如何处理？团队如何保持同步？如果数百个团队自治，管理层如何知道发生了什么，更不用说如何控制？

大公司能真正敏捷吗？微软的5年转型

2011年7月，当微软公司副总裁Brian Harry在一篇给Scrum社区的博客文章中宣布了对敏捷的企业承诺时，许多人和员工对此持怀疑态度。像微软这样的大公司可以成为真正的敏捷公司吗？

对敏捷的变革承诺是由业务必要性的驱动的，而不仅仅是认识到它能在劳动力中产生更多的活力、能量、远见和活力，毕竟这是完成工作的更好方式。每隔几年就把新版本的软件装在一个盒子里交付的日子已经一去不复返了。现在，软件以几周或几个月而不是几年的方式在线交付更新。为了跟上，微软别无选择，只能去敏捷。

令人高兴的是，5年后敏捷价值观在微软的研发组织仍然活跃。该司不仅为自己实施敏捷、Scrum和DevOps的常规实践和方法，还为他人推广它们。包括开发人员都以敏捷价值观生活、思考、交谈和行动。它不仅在做敏捷。它正在敏捷。有一种普遍的敏捷思维，其中尊重、重视和吸引那些根据客户需求所做的工作的人是核心。

这对微软来说是一个巨大的变化。过去产品周期为两三年，而现在是三周。团队自主性、掌握性和目的性极大提高。可以看到一个良性循环，更有效和更投入的员工队伍运营得更快，质量更好，更容易与客户建立联系和理解客户的需求，并更快地做出反应，以便客户定期感到满意。

但敏捷转型之旅绝不是一条从A到B的直线道路。导入Scrum的方法——冲刺规划、迭代几乎在、每日站会、迭代反思会——只是挑战的一部分。更重要的是，更困难的是所有参与者的思维转变。

业已形成敏捷工作场所： 凭借开放空间、新鲜、鲜艳的色彩、舒适的会议室、多种变化和机会，鼓励在愉快和非正式的氛围中协作，以及无处不在的“信息散热器”，物理场所看起来就敏捷。看到高管们经常坐在与最年轻员工完全相同的移动办公桌前，这是从自上而下、基于权威的文化转变的强大视觉信号。

企业敏捷转型

微软如何成功地实现了为期五年的大规模敏捷转型？在一个团队甚至几个团队中做敏捷和Scrum是一回事。在数百个团队中以协调的方式进行敏捷和Scrum是完全不同的概念。依赖关系如何处理？团队如何保持同步？如果数百个团队自治，管理层如何知道发生了什么，更不用说如何控制？本文让我们讨论热点问题“微软如何做到敏捷规模化”。

本案例研究基于深度访谈 Aaron Bjork—Visual Studio Online 的一位项目群经理，一个拥有约4000名开发人员的开发组织中的 Visual Studio 小组。访谈调研表明，微软已不是一艘巨型军舰，而更像是同步行进的快艇组成的舰队。

企业敏捷转型

立即查看方案 >

疫后企业经营如何解困？VUCA时代企业必须构建新能力快速灵活应对变化。以敏捷型组织机制执行，提升价值交付和协作效率，快速响应市场变化，强化创新应变竞争优势。

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用他们7.04%以上的时间和客户沟通。

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

11）处理来自高层的指导

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

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

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

12）以自组织团队鼓励集体担责

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

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

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

创新方案冲刺

立即查看方案 >

许多创新项目方向无法清晰，团队交付进展甚微，无法继续推进。如何解决创新项目面临的策略、产品和增长等难题困局？采用硅谷最热门的设计冲刺法仅用1-3周让团队获得一个快速的答案！

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，它不会起作用。它不得不进化。人们需要那样的时间来让它进化。情绪上，它需要时间。你不能同时做出所有改变。