【本文翻译自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 的内部讨论，我感觉到如今这仍然是一个热门话题，所以我很想知道您的想法。您是否为多个团队估算过？您的方法是什么？什么有效，什么无效？请在下面的评论中分享您的经验。
网友评论