[Day12] 团队系统设计 - 估点系统 (下)

上一篇文章分析了 Scrum 团队在估点活动的遭遇的困难，以及滞碍难行之处。今天来分享我时常采用的变形估点系统。在设计系统时，首要考量是要消除常见的估点方法带来的内部张力，因此我认为必须包含以下的特性：

• 减少琐碎：
  让脑力密集工作者能专注在最重要的事上；避免记录工作时数成为开发团队的心理与精神负担。
• 专业分工：
  领域相关的工程点数，交由领域团队评估，而不采用全体共议。
• 容错：
  「估」这个字的意含就是「不凖」。因此不把追求精准当作目标，而是以培养团队经验为原则。一个由专家给出的参考评估值，仍然会比 PO 用经验评估来得有参考价值。
• 实践方式指引：
  对如何将 User Story 拆分成小颗粒的工程项目，提供实践方式供团队参考。缩短团队的摸索期。

接下来介绍具体的估点系统实践方式：

123 估点法

我们定义一天的工作负担为 3 点；并切成 3 个时间区段，每个区段分配到 1 点，如下图：

举几个例子：

• 把握度高、简单的任务 (例如更换字串) = 1 点
• 感觉需要阅读 1 天的技术文件 = 3 点
• 感觉不到 2 天就可以完成的程序 = 5 点

感觉，其实就是大脑根据经验在进行评估，我们最终得到的，是一个和「时间」与「复杂度」有相关性的量化数字；虽然不可能精准，但是一个有参考价值的指标。

刻意不用「时间」做时间段的分隔，这是因为我们深信脑力密集工作者必须保有一定的弹性，软件开发活动，不适合采用工厂式的时间管理。因此，我们采用「心情转换事件」的抽象方法来定义时间区段；设计程序是一种创作活动，即使不在座位上，一个短暂的散步，一个闭目养神都可能是灵感来源，这些行为的「计时」，是某种程度的琐碎与负担。而 123 估点法，可以有效的解决这个问题。

另外，这个方法也是刻意的在回避进行太细节的时间估算。曾经合作过一些 PM，在产品专案的时间管理上，用「小时」为单位在挤开发时间，长久下来，会伤害 PM 与工程师之间的互信。

拆解 User Story

前篇文章提到过，在线上 Refinement 会议，PO 与设计师已经介绍完 User Story 的细节，此时工程团队已经知道开发范围，各领域开发人员也知道各自负责的内容，User Story 已被初步拆分成不同领域的工作内容，如下图所示。

在线下 Refinement 活动，各领域开发人员就开始将分配到的项目，再进行细步拆解。以 Android 开发者分配到的任务为例，可能拆成下面的工程项目：

• 刻 UI
• 设计架构
• API 串接
• 商业逻辑撰写与测试
• 技术文件阅读

然後再用 123 估点法给与点数，此时若 Android 开发者为 2 人以上，就可以采用「扑克估点」的讨论精神，来对齐相同领域专家的看法，降低杂讯。结果如下图：

在这个案例，我们得知这个 User Story ，Android 开发需要点数为 15 点，也就是大约需要 5 个工作天。当其他的领域开发者完成估点任务後，可能得到下图的结果：

至此，我们得到了该 User Story 需要 51 点的评估结果，若每个领域都同时开始进行开发，完成这个 User Story 的所需时间也就可以推估。直观的看，也就是 Android 开发完的时间就是 User Story 的完成之时，但，实务上肯定不会这麽完美 (微笑)，我们之後的文章再来探讨如何透过点数进行专案管理。

这个估点系统，我在 5 个产品团队导入过，不敢说它是完美的方式，但对系统层面来看，的确形成一个能让估点活动顺利进行的结构。而 PO / PM 也对专案有了具有参考价值的量化数据，对风险控管产生帮助。