閱讀本文約花費: 9 (分鐘)

实施规模化敏捷时，组织管理多个Scrum团队时将面临更多的挑战。如果您已让多个团队工作于同一个项目，那么协作会变得更复杂，特别是估算的时候。

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

但多个Scrum团队共同工作会带来更多的挑战，包括：

• 团队技能和经验水平都不同时，该如何处理？
• 怎样才能在无需每位团队成员都参与的情况下准确估算工作？
• 在不知道该由哪个团队来承接工作的情况下，怎样完成估算？

我将与大家分享一个解决方案。但在此之前，让我们先来看看大多数组织在为多个Scrum团队做估算时都会犯的两个关键错误。

  错误1：估算不能反映所有团队的能力

第一个错误往往发生在公司挑选一组人员来估算整个待办项时。这本身并不是一个坏主意（事实上稍后我会建议您这么做）。与让大团队每个人都参与每个待办项的估算相比，这样么做当然会更快、更高效。并且或许您还会认为，只要选择的人员合适，估算结果就会是富有见地的。

但这正是事情容易出错的地方，因为一旦缺乏熟悉即将开展的工作且能真正代表所有Scrum团队的人员，您就会得到基于非常片面和不准确的视角而生成的估算值。

不幸的是，目前许多公司正在发生这样的事情：估算数据由那些脱节于即将开展的工作及其实施团队的人员创建。

这样做的结果之一是：得到的估算值会远远超出团队达成目标能力范围而极具挑战性（当估算用于竞标固定价格合同时，特别容易出现这种情况）。虽然一开始偏低的估算值能取悦客户和干系人，但随着项目出现了不可避免的延期，客户会变得不安，信任遭到了侵蚀，合作关系也随之破裂。

更糟糕的是，很少会有人去谴责估算的不合理。反而，就算团队基于一个无法达成的最后期限而拼尽全力赶工，也会面临愈演愈烈的压力和指责。

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

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

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

但这并不太有效。

定义一个故事点等于一定的小时数，会丢掉采用故事点的好处——为某件事情分配的点数与从事工作的人无关。无论跑快跑慢，一英里终究是一英里。因此你不应该把故事点数等同于工时数。

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

  大型项目该怎么做呢？

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

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

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

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

首先，召集合适的人员

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

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

其次，估算各种待办事项

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

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

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

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

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

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

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

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

  您怎么看？

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

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

原作者：Mike Cohn

原文链接：https://www.mountaingoatsoftware.com/blog/how-to-estimate-story-points-with-multiple-teams