敏捷开发

微软如何成为规模化敏捷组织


在一个团队甚至几个团队中做敏捷和Scrum是一回事。在数百个团队中以协调的方式进行敏捷和Scrum是完全不同的概念。创意型经济学习联盟对微软进行了访问活动,访问对象是拥有约4000名开发人员的开发部门中的Visual Studio小组。访问活动表明,微软不是一艘巨型军舰,而更像是同步行进的快艇组成的舰队。

一、关键因素

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和他的五个团队一起工作。其他团队组成的六个组也采用相同的流程。经理们坐在一起谈论团队级别的依赖关系,并持续地进行梳理。他们坐在同一个房间里,这是一个持续的对话。

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

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

二、Scrum实施过程中常用的管理工具/软件

1、国内顶级 Scrum 管理工具PingCode

这是国内最好用的敏捷开发Scrum工具之一,在2022年度获得由36氪企服点评发布的企服口碑产品TOP36,被广泛用于敏捷开发项目管理。

在Scrum 项目管理方面具备如下能力:

  • 需求管理:史诗/特性/用户故事三级体系,根据优先级、故事点形成待办列表
  • 产品规划:根据产品目标及项目需求排期,有序规划产品路线图、迭代和版本
  • 迭代管理:将需求和Bug分配到迭代,通过燃尽图、速率图等跟踪迭代进度
  • 版本管理:支持多版本共存,新增功能和修复对应版本,让发布更有计划
  • 开发管理:拆分用户故事为任务,开发人员领取任务完成Coding
  • 构建部署:工作项关联代码托管、CI/CD工具,跟踪开发、构建及部署进度
  • 工时统计:估算、填报任务工时,可视化度量项目和团队工作量

PingCode官网

2、国外顶级Scrum管理工具Jira

Jira是全球范围内软件开发的先驱。该品牌于2002年由Atlassian公司在澳大利亚创立,最初是一个问题跟踪工具,此后逐渐发展为多任务的项目管理软件,能够很好的支持敏捷开发项目管理。

Jira 同样是国外能够实施Scrum方法的知名软件,Jira提供了丰富的功能,其中包括:可用于backlog的自定义过滤器、项目报告的可视化表示、以及可定制的Scrum板。

当然,如果您不太熟悉Scrum的话,可能需要花上一定的时间来测试,熟悉和掌握该软件的各项功能,因为Jira 上手会比较难,这也是很多人诟病的点。

除此以外,自从2020年停售国内本地版后(一定意义上对国内用户禁售),所以这可能会带来一定的风险,但也丝毫不影响其地位。

不得不说,Jira 在国外使用的体验比在国内使用要好很多,因为售后服务国内是没有原厂的,所以如果有国外团队,Jira是个不错的选择。

【官网:Atlassian.com】

内容来源:ShineScrum捷行

智齿客服