规模化敏捷的团队如何统一估算基线?

【本文翻译自Mike Cohn的博客How to Estimate Story Points With Multiple Teams

当多个敏捷团队为同一个项目工作中时,他们可以从故事点评估的基线中获益

实施规模化敏捷(scale agile)时,组织对多Scrum团队的管理会面临更多的挑战。如果您有多个团队在同一个项目中工作,那么协作会变得更复杂,尤其是估算的时候。

这些团队需要进行估算和制定计划,并基于计划来跟踪进度,以便PO能安排其工作优先级,在有成果物交付时与干系人进行交流。

但多个Scrum团队共同工作时会带来一些额外的挑战,包括:

  • 你如何处理拥有不同技能和经验水平的团队?
  • 怎样才能在无需每位团队成员都参与的情况下对工作进行准确估算?
  • 在不知道该由哪个团队来承接工作的情况下,是否可以提前完成估算?

我将和大家分享一个解决方案,但在此之前,让我们先来看看大多数组织在为多团队进行估算时都会犯的两个关键错误(基于Agile Mentors Community的讨论,这些错误在今天仍然很普遍):

错误1:创建不能反映团队真实能力的估算

第一个错误往往发生在公司挑选一组人员来估算整个待办事项列表时。这本身并不是一个坏主意(事实上稍后我会建议您这么做)。相比于让整个团队每个人都参与每个待办事项的估算,这样做当然会更快、更高效。你可能会觉得,如果你能选择合适的人,结果将是一个有富有洞察力的估算。

但这正是事情往往会出错的地方,因为一旦缺乏熟悉未来工作且能真正代表所有团队所有技术方向的人,您将会从一个非常片面(且不准确)的视角创建估算。

不幸的是,目前许多公司正在发生这样的事情:估算数据由那些不了解未来工作,也不了解实施团队的人创建的。

这样做的后果之一是产生了远超团队能力的、更激进的估算(特别是当这些估计用于竞标固定价格合同时)。虽然较低的估算最初可能会让客户和利益相关者感到高兴,但是随着项目出现了不可避免地延期,客户会变得不安,信任被侵蚀,合作关系也随之破裂。

更糟的是,人们很少会责怪做估算的人。相反,就算团队为了一个不可能的最后期限而拼尽全力的工作,他们也还是会面临愈演愈烈的压力和指责。

错误2:把故事点数换算成工时数

当组织试图通过强制要求所有团队都采用统一的故事点定义来实现一致性和可预测性时,可能会发生第二种错误:采用了一种流行而又不正确的方式——强制所有团队都使用某个固定时间量来代表一个故事点,例如:1个故事点为3小时,或者3个故事点为8小时。

我能明白背后的逻辑:看起来管理层能以一种非常简单的方式,一眼看出团队的绩效情况。

但这并不太有效。

定义一个故事点等于一定的小时数,会丢掉采用故事点的好处——为某件事情分配的点数与从事工作的人无关。无论跑快跑慢,一英里终究是一英里。因此你不应该把故事点数等同于工时数。(关于故事点的深入研究,可参考这篇文章一文带你掌握故事点估算

更糟糕的是,当为所有团队都定义了一个故事点等价的工时数时,管理层或许会觉得仅仅采用团队速率就能很容易地对团队进行比较。然而事实并非如此。

大型项目该怎么做呢?

那么,您该如何为涉及多个团队的项目创建有意义的估算呢?

要基于比例进行估计,为所有团队建立一个公共的估算基准,并使用该基准进行估算和跟踪共同目标的进度。

但您必须以一种能代表所有Scrum团队的方式来完成此事,而不是简单地强迫团队成员接受它。

下面是如何建立估算基准的具体做法:

首先,召集合适的人员

建立跨多团队公共基准的最佳方式是:从每个团队都召集1个或多个代表。具体多少人,可以视项目的团队数量和规模而调整。如果您只有2个或3个团队,可以考虑让每位团队成员都参与;但如果团队数量更多,可以每个团队只召集2名或3名人员。

团队应该选择其认为最适合估算的人员。通常情况下,会是些资深的团队成员,但也并不总是这样。团队还应该综合考虑他们的代表需要具备的技能。例如,如果JavaScript只是团队的部分工作,就不能派出的三个全是优秀JavaScript开发人员的代表。

其次,估算各种待办事项

这些代表聚集在一起玩“计划扑克”,最好是当面进行,但实际上,如果有些代表是远程接入的,也是可以的。这个小组不会为一个大项目估算所有的产品待办项,而是只会估算10-20个。

这就意味着,等到会议结束时,会产出一个包含10-20个具有所有人一致认可估算值的产品待办项的列表。每个团队有1个或多个人员参与创建这些估算值,并共享各自的差异或假设。

然而重要的是,这些人估算了各种待办任务。这就使得团队们使用此估算基准作为其相对估算基础而进行估算时,会更加容易。您不会想要估算20个非常相似的产品待办项,因为当其他团队以此作为基准来估算完全不同的产品待办项时,会完全没什么帮助。

再次,不必让每个人都了解每个产品待办项

对于我建议估算的这十到二十个产品待办项,并不需要每个代表都了解每个产品待办项。例如,虽然一个核心算法可能是典型的需要这多个团队共同完成的产品待办项,但是房间中少数估算人员仍然可能与此无关。

这是没关系的。并不需要每位估算人员都要了解每个产品待办项。替代的方案是:大部分团队成员应该了解大部分的产品待办项。

这意味着,由与会人员负责选择大约十到二十个产品待办项。他们最适合判断,该何时选择哪些产品待办项来覆盖代表产品广度,以及是否大部分估算人员都能参与大部分估算。

以这种方式创建估算基准,并由每个团队的代表对估算值达成一致,将使所有团队能够以一致的方式进行估算。

您与多个Scrum团队一起估算过吗?我想听听您的建议

从 Agile Mentors Community 的内部讨论,我感觉到如今这仍然是一个热门话题,所以我很想知道您的想法。您是否为多个团队估算过?您的方法是什么?什么有效,什么无效?请在下面的评论中分享您的经验。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342