写点什么

大规模敏捷之总体规划

  • 2018-01-15
  • 本文字数:6655 字

    阅读完需:约 22 分钟

本文要点

  • 总体规划指明了整个项目的方向,帮助所有的团队保持一致。
  • 制定总体规模将驱使关键的利益相关者对项目的方向达成共识。
  • 总体规划的制定可以遵循以下三个步骤:1. 评估;2. 定义优先级;3. 每个季度的史诗数量。
  • 史诗评估可以为我们提供概数,建立更深层次的共识也同等重要。
  • 每个季度在总体规划上花一到两天的时间,对于保证项目的成功而言,这是不错的投入。

在第一篇文章“大规模敏捷:一个真实的故事”中,我分享了一个来自特定项目的真实的大规模敏捷故事。

在第二篇文章“切片与共识”中,我描述了如何将需求切分成也许可以发布的史诗以及这样做的重要性。因此,我们现在已经准备好基于那些切片及达成的共识进行构建;我们可以一起做总体规划了。

在深入讨论之前,让我们先了解下上下文。我将把它作为大规模规划的一部分来介绍(如果你已经阅读过前面的文章,则可以跳过这一部分)。

大规模规划

大规模计划,包括切分和总体规划,是一种可以帮你应对大规模规划挑战的实用方法。大规模规划以组织的整体战略目标为出发点,包括以下四个层次的规划:

  1. 切分
  2. 总体规划
  3. 大屋规划
  4. 冲刺规划

虽然各种大规模框架为大屋规划(所有团队和利益相关者会一起在此呆两天时间)提供了可用的框架,而且大多数组织清楚如何进行冲刺规划,但是准备此类大屋规划仍要做很多的工作。这正是包含切分和总体规划的大规模规划的用途所在。

为什么要做总体规划?

让我先讲一个故事。

我曾在丹麦政府的一个部门里为一个重要的新系统做项目咨询。我到那里的时候,他们的人员是按照能力来组织的,因此,律师一间办公室,业务流程人员一间办公室,IT 人员一间办公室,诸如此类。这些办公室之间有一些合作,但是不足以在史诗及先构建什么上达成一致。

我们设法把其中的大多数人组织成了跨职能团队。然后,我们举办了一期“用例营(use case camp)”(本系列文章的第二篇“切片与共识”中有描述),我们可以借此得到史诗——大屋规划的纲领。

开始的时候,一切都看上很美好。每三个月,我们就让新成立的跨职能团队的所有成员都聚在一起进行大屋规划。他们协同工作,形成了依赖关系,开发工作开始步入正轨。感觉很棒……

直到有一天,在一次大屋规划的过程中,对于下一个季度结束时需要交付的最小可行产品(MVP),项目负责人的想法变了。他提了如此多的问题,却没有多少明确的答案。接下来,更糟糕的是,业务流程负责人上台做了些澄清,而她讲了一个完全不同的故事。和项目负责人的 MVP 看法并不相同,而后者那时候已经离开这里参加另外一个会议了。

因为无法说服项目管理人员让团队在几个月的时间里交付什么东西,从而取得一场胜利并使反馈循环继续下去,所以我决定离开。此后,我一直在暗中观察着这个项目,我知道,有 4 到 6 个团队与这些不明确的目标缠斗了一年多。一次也没有向终端用户交付。也没有任何反馈循环帮助他们向着取悦未来用户的方向前进。

这样的故事很多很多,优秀的人聚到一起想要构建优秀的产品,然后由于缺乏明确的目标、共同的前进方向及总体规划,他们的生产力非常低。

那么我们为什么要做总体规划呢?我们借总体规划促使关键的利益相关者对前进方向达成共识,帮助各个团队保持一致,更好地协作。

顺便说一下——上次,在政府项目里,我在和朋友聊天时知道,他们已经决定在一个月内完成一次实际的交付。不容易!!!

总体规划的准备工作

告诉你个秘密。一旦所有人都对恰当分片的史诗达成了共识,一旦屋里都是对的人,那么制定总体规划可以非常容易。

在开始之前,我强烈建议把每个史诗写在一张卡片上(A4/ 信纸大小)。史诗名称要加大加粗,以便人们从房间的另一边也能看清。而且,我建议限制每个卡片上的细节数量,从而确保概况和讨论都处于一个比较高的层次上(把更多的细节留给团队在稍后进行的大屋规划里讨论)。参见示例“提现——美元”。

接下来,在屋里放一张长桌:长到足够并排放下所有的史诗卡片——不要椅子,因为我们希望人们能够在桌边走来走去讨论规划。

还有一点需要注意,有人可能会提出,提现这个例子太小,不是史诗。那完全取决于整个项目的规模——在这个例子,如果提现是 25 个用户场景之一,那么作为史诗完全可以。如果提现是 100 或 200 个场景之一,那么你应该将其作为史诗的一个特性,或许可以命名为“现金处理”。

总而言之:

  • 史诗要印到卡片上,卡片要足够大,让人们在桌子的另一边也能够看到标题;
  • 屋里放一张足够长的桌子,所有的史诗都在上面排成一条线;
  • 每人一组评估卡,上面标上 T 恤的尺寸:S、M、L、XL 等。

对的人是指:

  • 关键的利益相关者,包括团队 Scrum 管理员和 / 或产品经理;
  • 最好是参与切分并共同寻求共识的那些人;
  • 最好是 6 到 12 人。

当具备了上述条件,你就做好了总体规划的准备工作。接下来,就可以开始总体规划了。不要等待并设法把准备工作做得更好,我见过许多这样的。事实是,可以分析准备的事情永远都做不完,你可能总会漏下什么东西,如果你不前进并开始第一次总体规划,你就永远无法准确地知道那些东西是什么。

为什么要让产品经理和 Scrum 管理员参与进来?

重要的是要让产品经理和 Scrum 管理员参与到总体规划中。这一方面是因为他们有大量应该包含在规划中的信息,一方面是因为他们参与并投入到总体规划的创建会让他们对总体规划更有主人翁精神。此外,在制定总体规划的过程中,他们会对整个项目有更深地理解。理解很重要,那不仅会在大屋规划和冲刺规划过程中发挥作用,而且还会在各个团队的日常工作中发挥作用。

为什么获得所有重要利益相关者的同意很重要?

此外,在制定总体规划时,我们会召集所有角色的代表,就什么最重要听取不同的意见。如果不在这个讨论会中消除这些分歧并达成一致,那么它们就会妨碍团队高效地工作以及后续价值的创造。如果利益相关者发出了不同的信号——如果团队只顾自己的工作而不配合——那么团队最终就会耗费大量的时间才能弄清楚要取悦内部的哪些人,而无法专注于开发让客户满意的产品或服务。

如何制定总体规划?

让我们开始总体规划的讨论。它包括如下三个步骤:

  1. 评估
  2. 区分优先级
  3. 确定每个季度的史诗

有时候,我会调换评估和区分优先级的位置,尤其是当我们进行总体规划需要涵盖的史诗过多时。在那种情况下,根据优先级重点 / 只评估最重要的史诗更有意义。

1. 评估

第一步,我们希望可以代表实际的服务开发人员的参与者可以掌控全局。我们把他们成为“交付人员”。他们使将要做这项工作的人,因此,他们最知道每个史诗需要多少开发工作量(通常,他们使 Scrum 管理员、架构师、测试经理等等)。

在这个步骤中,我们希望针对每个史诗展开充分的讨论。这是我建议采用相对估计的原因之一。相对估计似乎可以避免讨论中出现类似“真的吗?怎么可以花那么长时间……?”这样的评论,而更多地对根本需求及如何构建解决方案进行充分地讨论。

在进行总体规划时,我们通常没有足够的细节提供让人们感到满意的数值估计。因此,我觉得使用 T 恤尺寸(S、M、L 等)似乎更有效。在总体规划结束时,我们总是可以就 T 恤尺寸到估计点的转换达成一致,从而就能够计算出整个项目的计划速度和实际速度,作为项目治理的一部分。

除此之外,我们使用下面这个为人熟知的 Scrum 评估过程进行估计(如果你了解计划游戏,可以跳过这一部分)。

  1. 找一个小史诗:由承担交付角色的人推动——我们一致认为是一个相当小的史诗——并将评估结果设为 Small。
  2. 选出下一个史诗:由一名业务人员选出下一个史诗,大声读出来——并加上她此时此刻对于这个史诗的看法。
  3. 讨论史诗和解决方案:交付人员介绍他们将如何构建这个史诗。业务人员会做出评论及提出问题,他们讨论并达成一致,然后在史诗卡片上添加附注——通常是关于演示什么。该史诗特有的风险也可能会在史诗卡上标记出来。对此,我喜欢使用红色的标记。
  4. 分别评估:交付人员每人取一张 T 恤评估卡,分别与第 1 步的 Small 史诗进行对比,确定这个史诗多大——当所有人都决定好以后,他们会轮流展示自己的卡片。
  5. 倾听最小者和最大者:如果有分歧,那么给出最小估计的人和给出最大估计的人就要说明他们为什么认为这项工作如此小或大——然后重复第 4 步。
  6. 把评估结果写下来:当大家很好地达成了一致,就把评估结果标注到卡片上。
  7. 再做一次:回到第 2 步,直到没有更多的史诗卡片需要评估。

上述 7 个步骤要花很长时间,除非加以严格的限制。时间盒非常有效。我最喜欢的时间盒方法是在前两到三个史诗评估结束时,自己算一下时间,然后分享给参与者。我会问一个典型的问题:“我们现在已经评估了前两个史诗,用了一个半小时——如果我们继续以这个速度进行下去,我们需要花三天的时间才能评估完所有的史诗。你们愿意我帮助限制时间吗?”。答案一直都是“是”,那时,我通常设置一个 10 分钟的计时器,加速评估进展。

记住,这是整体规划。我们不希望过多地触及细节,因为我们希望得到一个总览,因为我们希望把更多细节规划留给所有实际做这项工作的人在大屋规划和冲刺规划里完成。

在这个评估过程中,有些史诗会被分割,有些史诗会被合并成一个史诗,这很正常。也很可能会有一些基础 / 使能史诗(也称为管道史诗或架构史诗)被识别出来加以讨论。我建议使能史诗使用不同颜色的卡片,使业务史诗和使能史诗可以很容易地区分开。那在下一个步骤“区分优先级”中就派上用场了。

2. 区分优先级

在这一步中,我们希望业务人员掌握决定权。他们是最了解客户和市场的人,因此,最适合决定首先构建和发布什么。

从流程的角度看,这相当容易:

  1. 对业务史诗进行排序:业务人员详细介绍史诗,并按照他们希望的史诗交付顺序对史诗卡片进行排序。这可能主要是依据业务价值,有时候是量化的,但更多的时候没有量化。
  2. 考虑风险、依赖关系和使能史诗:交付人员倾听并提出澄清问题,经常是建议重排其中部分史诗的顺序。通常,他们也会针对使能史诗的位置提出建议,以便能及时为业务史诗打下基础。而且,他们经常会识别出额外的使能史诗——这是由于和业务人员一起做规划而让他们有了更深入的理解。
  3. 变更顺序或不变更:业务人员和交付人员在一起讨论,然后,业务人员根据讨论和业务优先级决定是否希望变更顺序。这是要记住,业务人员掌握决定权,这很重要。因此,虽然交付人员可能会建议做些变更,但业务人员有最终发言权。
  4. 过一遍计划:当事情基本定下来以后,我们会一起“过一遍计划”。每个人都聚集到计划的早期史诗(优先级最高的史诗),然后由一名业务人员讲解这个故事,说明为什么那些优先的史诗最重要,然后是下一个史诗,诸如此类。在这个过程中,每个人都会跟着她一直到目前为止我们所做的所有计划结束。这个过程可能会因为一些新观点、讨论和决定而中断,在这种情况下,就需要重复前面的部分步骤,然后再“过一遍计划”。

虽然从流程的角度看区分优先级很容易,但是要让业务人员和交付人员达成一致却非常困难,尤其是让不同业务的利益相关者达成一致。我们有时候会碰到的其中一个陷阱是,这些从根本上不同的优先级没有区分出来,于是,这些没有区分出优先级的史诗就会搞乱整个项目,并导致延期(有时候甚至是毁掉)。

这就需要推动者非常强势,让各方讨论协商,直到他们妥协并达成一致——这样,总体规划就可以作为一个清晰的方向从关键的利益相关者传达给项目的其他人员。

我记得有一次,在一家银行的总体规划中,零售金融服务主管向我抱怨:“对于我自己的史诗,我知道如何区分优先级,但把他们和企业金融服务放在一起时,我怎么能区分出优先级?”我什么也没说。我只是看着他背后的 Peter,他是企业金融服务主管,他正在房间的另一端。他又抱怨了一会就停下了,他安静了好一会。然后,他突然说:“啊,我这就过去和 Peter 聊聊。我们需要就对这个银行而言最重要的东西达成一致。”对!!

3. 确定每个季度的史诗

最后一步,我们再次让交付人员掌握决定权,因为他们是真正构建产品或服务的人。这里最大的问题是:“我们觉得三个月之后会达到什么程度?再三个月之后呢?”

我们要求人们在回答这些问题时考虑目前为止谈论的所有内容,结合他们之前的经验,他们所了解到的项目体量以及他们的直觉。

通常,这一步不像前面两个步骤那样有良好的结构,但如果要有一个结构的话,可能就像下面这样:

  1. 确定哪些史诗归入第一个季度——设定第一版演示程序的日期和时间。
  2. 从业务的角度讨论这是否合适,分割、合并史诗,直到从业务的角度来看是合适的。
  3. 确定哪些史诗归入下一个季度,依次类推,直到我们从时间的角度安排好我们所知道的所有史诗。
  4. 对规划做一致性检查,即检查一下,确保没有哪一个季度比其他季度的工作多(或少)许多。这时候,T 恤尺寸向评估点转换就派上用场了,转换并汇总每个季度的史诗估计。通常,这会导致某些季度目标的变更。

一个小小的警告:在我们一个季度一个季度地评估和估计我们自信可以达到什么程度时,最重要的是要由做这项工作的人推动这些决策。他们是最了解的人,因此,应该由他们把工作划入将来的季度里,根据他们自认为可以达到的目标。这样,他们就对规划产生了很大的影响,也就会因此更有主人翁精神。

由管理人员或其他利益相关者把工作推到他们的规划中通常会产生相反的效果:更少的主人翁精神以及更不现实的规划。

人们经常会问我,总体规划应该涵盖未来多长时间。根据我的经验,我觉得,最好是把我们目前了解到的所有内容都放进规划,然后以这些内容为指导确定总体规划的时间表。就这样,我们把总体规划用于讨论,用于和周边组织的协作,包括管理部门 /PMO,他们需要对此有所了解,并能够提前进行更高层面的规划。不过,我还是建议尽可能少地涉及细节,否则花费的时间就会更多。每个季度,我们还会回顾总体规划,因此,当我们接近未来的史诗时,我们有时间进行足够深入的讨论,明确项目内容。

现在,总体规划已经有了,我们就可以知道,在接下来的大屋规划、冲刺规划环节以及日常工作中,需要对哪些工作进行细化,进一步明确项目内容。

使用燃尽图进行项目治理

如果你像下面的“项目燃尽图”图示一样把 T 恤估计转换成了数值,那么就很容易看出项目的总体进展。我喜欢把这些点叫做“项目点”,以便和团队在大屋规划和冲刺规划中使用的规划扑克点区分开来。

在这个例子中,我们在项目之初确定了 7 个史诗,3 个蓝色史诗、2 个红色史诗和 2 个绿色史诗。借助转换后的估计值,我们看出,总计有 150 个项目点,我们希望用 3 个季度完成这项工作。平均下来,我们每个季度应该完成 50 个点,但是,1 季度我们只做了 30 个项目点。2 季度我们回到正轨,但又发生了其他的事情。我们新发现了两个黄色史诗,据估计都很大。因此,在 2 季度末,我们觉得,项目总计包括 190 个项目点。

有人喜欢把所有团队的所有详细的规划扑克点全部加起来来看项目的总体进度,这是可以的:至少理论上是可以的。

如果收集并统计所有的规划扑克估计值有困难,那门我建议你尝试下这种 T 恤尺寸转换方法,它有下列有点:

  • 你可以非常迅速地掌握项目进展,因为它主要包含来自关键利益相关者的信息,而不是整个项目中每个单独的团队成员;
  • 团队可以保证团队讨论的规划速度和实际速度,在团队层面上改进规划及工作方式。

小结

当你完成了切片并达成共识后,你就做好了总体规划的准备了。

总体规划准备——操作指南:

详情

好处

卡片上的史诗

卡片上的字要足够大,确保整个房间里的人的可以看清标题

在传递实物卡片时,可以让人们都参与进来。

配有长桌的房间

空间足够大,容许所有人走动。桌子必须足够长,可以把所有史诗排成一条线。

纵览可以帮助人们区分优先级并达成一致。

评估卡

为每个人准备S、M、L、XL 等规格的T 恤评估卡片。

让人们参与到更深入地讨论中。在不了解细节的情况下,人们更容易将T 恤大小和故事联系起来。

执行总体规划:

步骤

谁掌握控制权

做什么

好处

1. 评估

交付人员

使用 T 恤尺寸评估所有史诗

更深层次的共识

2. 区分优先级

业务人员

根据业务价值、风险和依赖关系进行史诗排序

尽早创建业务价值

3. 史诗 / 季度

交付人员

确定每个季度的史诗

符合现实的规划及主人翁精神

下一篇文章

截至目前,我们已经讨论了切片和总体规划,我们已经为大屋规划做好了准备,对此,我将在“让大规模敏捷有效运作”系列文章的下一篇和最后一篇文章中进行讨论。我将分享我的经验以及注意事项,我将分享我在这个艰难的旅程中获得的要诀和技巧。敬请期待。

关于作者

Ole Jepsen 是一名敏捷转型顾问,和组织一起引领变革。利用在敏捷方法论、基于意图的领导 & 引导模式方面的专业知识,Jepsen 与企业及其领导者一起创建开发组织和工作场所,让身在其中的人们保持活力并交付价值。

查看英文原文: Scaling Agile - Master Planning Together

2018-01-15 16:303706
用户头像

发布了 1008 篇内容, 共 389.5 次阅读, 收获喜欢 344 次。

关注

评论

发布
暂无评论
发现更多内容

碎片化NFT系统开发模式定制智能合约部署详情

开发微hkkf5566

行云管家免费吗?安全吗?好用吗?

行云管家

安全 行云管家 行云管家堡垒机

植根中国,开放合作,英特尔中国开源技术委员会成立

科技之家

webpack热更新原理(面试大概率会问)

Geek_02d948

JavaScript 前端

堡垒机采购注意事项说明-行云管家

行云管家

网络安全 数据安全 堡垒机

美团前端面试题集锦

coder2028

JavaScript 前端

字节前端经典面试题(附答案)

hellocoder2029

JavaScript 前端

webpack配置优化,让你的构建速度飞起

Geek_02d948

软件测试 | 持续集成的开源方案攻略(二)jenkins pipeline

测吧(北京)科技有限公司

测试

js函数式编程讲解

hellocoder2029

JavaScript 前端

PingCAP 唐刘:一个咨询顾问对 TiDB Chat2Query Demo 提出的脑洞

PingCAP

TiDB

NGINX QUIC & HTTP/3 最新进展

NGINX开源社区

nginx HTTP 企业号 2 月 PK 榜

如何整理自己的前端面试题库

Geek_02d948

JavaScript 前端

利用规则引擎的M2M实现设备之间联动——实践类

阿里云AIoT

小程序 物联网 智能硬件 网络性能优化

NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试

NGINX开源社区

nginx NGINX Ingress Controller 企业号 2 月 PK 榜

PGLBox 超大规模 GPU 端对端图学习训练框架正式发布

百度Geek说

百度飞桨 框架学习 企业号 2 月 PK 榜

不会用“函数选项模式”的朋友看过来,这么写很优雅

王中阳Go

Go golang 高效工作 学习方法 后端

如何应对突发的流量激增和服务器过载问题

NGINX开源社区

nginx 流量 应用交付 企业号 2 月 PK 榜

ATC:一个能将主流开源框架模型转换为昇腾模型的神奇工具

华为云开发者联盟

人工智能 华为云 昇腾 企业号 2 月 PK 榜 华为云开发者联盟

MatrixOne 0.7.0: 更稳定,性能更优

MatrixOrigin

数据库 分布式 MatrixOrigin MatrixOne

js作用域、作用域链和它的一些优化

hellocoder2029

JavaScript 前端

Kyligence 出席全球人工智能开发者先锋大会并成功主办分论坛

Kyligence

数据服务 人工智能大会

Memblaze 联合 OpenCloudOS 完成技术兼容互认证

OpenCloudOS

Linux SSD

koa实战

coder2028

JavaScript 前端

跬智信息全新推出云原生数据底座玄武,助力国产化数据服务再次升级

Kyligence

云原生 大数据分析

中创中间件:基于鲲鹏DevKit开发统一监管平台,性能提升55%

Geek_2d6073

Nodejs:ESModule和commonjs,傻傻分不清

coder2028

JavaScript 前端

2023秋招前端面试必会的面试题

coder2028

JavaScript 前端

前端二面经典面试题指南

hellocoder2029

JavaScript 前端

使用JAVA读取和写入EXCEL文件

石臻臻的杂货铺

Java

2022年度中国一级市场融资事件数量下降52% ;红杉中国、腾讯投资最活跃|2022年全球投融资年报

创业邦

大规模敏捷之总体规划_文化 & 方法_Ole Jepsen_InfoQ精选文章