多团队如何评估故事点 (译) ——来自 Mike Cohn 的建议

关注

发布于: 2020 年 11 月 08 日

当组织进行规模化敏捷时，他们面临管理多个团队的挑战。如果您有多个团队在同一个项目上工作，那么协调就会变得更加复杂，特别是在进行评估时。团队需要评估和计划，然后根据计划跟踪进度，这样 PO(Product Owner)就可以对工作进行优先排序，并在交付的时候和干系人进行沟通。但是与多个团队一起工作增加了一些额外的挑战，包括:

你如何与拥有不同技能水平和经验的团队打交道？
你能在不涉及每个团队的每个人的情况下准确地评估工作吗?
在不知道哪个团队将最后完成实际的工作的情况下，你能提前给出一个评估吗？

我即将分享给你一个解决方案，但是在此之前，让我们看一下大多数组织在多团队评估中容易犯的两个关键错误（根据我的敏捷导师论坛Agile Mentors Community中的讨论来看，这些错误今天仍然非常广泛）。

错误一：估算无法反映所有团队能力？

第一个错误往往发生在公司精心挑选一组人员来评估整个代办工作列表的时候。这本身并不是一个坏主意(事实上，稍后我将提倡您这样做)。这肯定比让大团队中的每个人都评估每个项目更快、更有效。你可能会想，如果你能选择正确的人，结果将是富有洞察力的。

但是，这正是事情容易出错的地方，因为如果您没有熟悉要完成的工作的人，并且没有能力代表所有团队的跨部门能力，那么您将从一个非常狭窄(而且不准确)的角度创建评估。

不幸的是，这种情况在当今的公司中确实会发生：评估是由那些不了解要完成的工作的人创建的，他同时也不了解将要进行这项工作的团队。

这样做的一个结果是，评估的目标远大于团队可能实现的目标(特别是当这些评估用于投标固定价格的合同时)。虽然较低的评估最初可能会让客户和利益相关者感到高兴，但随着项目不可避免地推迟，客户会感到不安，信任会受到侵蚀，工作关系也会破裂。

更糟糕的是，人们很少会责怪估算。相反，面对越来越大的压力反而批评的是团队，而团队不得不接受在不可能的期限内完成任务。

错误二：把用户故事等同于小时数

第二个错误是，当组织试图通过坚持所有团队采用统一的故事点定义来创建一致性和可预测性时。一种流行的(但不正确的)方法是强制所有团队为一个故事点使用一定数量的小时，例如一个故事点为 3 小时，或者 3 个故事点为 8 小时。

同样，我可以看到这背后的逻辑：这似乎是一种非常简单的方法，可以让管理层一目了然地了解团队的绩效。

但是，这并不起作用。

将故事点与小时数等价会消除故事点的主要好处，即给予某件事的故事点的数量并不取决于谁来做这项工作。不管跑得快还是慢，一英里就是一英里。所以你不应该把故事点数等同于时间。

更糟糕的是，当故事点被定义为所有团队的小时数时，管理层可能会假设团队可以简单地仅根据团队的速度进行比较，但事实并非如此。

大项目应该怎么做呢？

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

要按比例进行评估，为所有团队建立一个共同的基准评估，用于评估和跟踪共享目标的进展。

但是您需要以一种能够代表所有团队的方式来做这件事，而不是简单地强迫人们接受一个评估。下面我们就来聊聊：

让对的人在一起

跨多个团队建立公共基准评估的最佳方法是将每个团队的一个或多个代表聚集在一起。人数取决于项目中团队的规模和数量。如果你只有两到三个团队，可以考虑让每个人都参与，但如果团队数量更多，每个团队更有可能是两到三个人。

团队应该选择他们认为最能进行评估的人。通常是更资深的成员，但情况并不总是这样。团队也应该考虑混合他们的代表所拥有的技能。例如，如果只有一部分工作是 JavaScript，就不要派出三个优秀的 JavaScript 开发人员。

评估各种类型的待办事项

一些代表聚在一起玩计划扑克，最好是面对面，但如果有些代表离得很远，也可能是虚拟的。这个代表团队不会评估整个产品待办事项列表，因为它很可能是一个大型项目。是的，他们只会估计 10-20 个项目。这意味着，当会议结束时，每个人都会带着一份 10-20 项的清单离开，其中包括每个人都同意的估算。每个团队都将有一个或更多的人参与这些评估，并可以分享做出的任何细微差别或假设。

但重要的是，这些人要评估不同种类的代办任务。当团队使用这个基准评估作为相对估算的基础进行估算时，这将使其变得更容易。您肯定不希望估算 20 个非常相似的产品待办事项，因为当其他团队使用此引用来为完全不同的待办事项列表项创建估算时，这将毫无帮助。

要知道，你不需要让每个人都了解每一个事项

我推荐的大约 10 到 20 个产品待办事项列表项并不需要每个代表都能理解。例如，一个核心的科学计算可以代表这个多团队努力的总体工作。但房间里的一些评估人员却与那个工作不相关。这很好。并不是每一个估算者都需要与每一项相关。相反，我们的目标是让大多数项目都能被大多数团队理解这意味着选择大约 10 到 20 个项目是与会者的责任。他们是最合适的人选来决定他们选择的评估项目，这些项目代表了最广泛的产品范围，并且大多数参与评估的人员能够参与大多数项目的评估。使用这样创建的基准评估，并通过每个团队的代表达成一致的评估，将使所有团队能够以一致的方式进行评估。

译者观点

综合上面的译文，结合我自己的实际工作经验说一下我自己的看法：

估算涉及到绝对估算与相对估算两种估算方式，故事点估算属于相对估算。相对估算的好处主要是更容易达成一致。如果映射成为具体的小时数，那就变成了绝对估算。失去了他的优势了。
相对估算需要有合理的基准评估作为参考。选择基准评估不考虑数量而应该尽可能覆盖多种类型的用户故事，这样当不同用户故事出现的时候，团队可以更快速的做出估算。
需求梳理会最为人诟病的就是会议又臭又长。一个主要原因就是参与的人太多，为了达成一致需要花费大量的时间。单团队的时候因为是 5~9 人，所以全员参与没有问题。而当多团队开发，人数>12 人的时候，所有人参加讨论就变得低效了。团队代表将会是一个好的方式。