[Day11] 团队系统设计 - 估点系统 (上)

2020年的 Q4 期间，我对几场面试的印象非常深刻，连续三位来自不同公司，不同领域背景的应徵者，不约而同在面试中提到：

「我目前的团队在跑 Scrum ，但总感觉很不对劲，尤其估点很花时间…」

「我们参考网路常提到的费式数列卡牌估点法，每个工程师都可以投点，但不同领域的人一起估，根本没有参考价值…」

「我的团队之前都有估点，到估出来的点数作用是什麽，其实我们也一知半解，最後 PO 就说不估了，能做多少算多少…」

这样的情况在业界肯定不少见，我经历的几个团队，也曾为此困扰不已。本文不会针对 Google 上查找得到的估点方式做详细介绍，而是透过个人观点来探讨为何许多团队在这些估点制度上会深陷泥沼。在下半部文章，我会介绍一个由我永远怀念的新创团队 (Soccii) 所共创出来的一种估点系统。

本文资讯，对许多 Scrum 专家来说，可能是异端邪说，服用注意，也欢迎留言讨论。

以下我们先探讨常见的估点方式两道难题：

难题 1：平均攻速

Fibonacci 数列估点法的点数，其实代表对 User Story 的复杂度评估，在估点的当下，不与开发时间挂勾。团队的「平均攻速」，可以用来评估产品功能的所需开发时间，我们可以透过以下的算式计算：

这里的执行难处有两个：

• 总工时 ( Hours ) 的统计对工程师来说相当琐碎，如开发过程中的暂时中断、思考时间、设计时间等计算原则；另外，工程师要养成一个新的工作习惯，会大量消秏精神。进而形成张力-舒缓系统。
• 为减少偏差，必须取得多个 Sprint 的统计结果进行平均，这个过程可能横跨数月，统计难度高。实务经验中，分秒必争的新创团队，或是交付型团队，较难承受这样的时间维度，因此仍高度仰赖 PO 的经验与领导力。

难题 2 ：异质开发团队

目前常见的产品团队，可能由多个不同领域的工程师组合而成：

• 後端工程师
• 行动开发工程师 ( Android / iOS )
• 前端工程师
• C++
• QA

一个较具规模的开发团队人数可能高达超过 20 人，违背 Scrum Guide，却真实存在於企业现场。我们想像一下，如果采用费式卡牌估点法，在极端的情况下，由 20 个人同时对 User Story 进行投点的情境，肯定是混乱，且秏时。最终带来的变形，是仅参考领域专家的观点，而其他人的投点，只是在陪榜。

上述的两个难题，常见的张力-舒缓系统如下：

因此，团队会在估点活动上遇到困难，是一种结构性问题，这种结构会自然的带团队到放弃的结论。各种微调，都无法与系统张力对抗。没错，我们需要的是一个新的估点系统。

我的经验并非否定业界有团队可以把诸如「费式卡牌」、「T-shirt 大小估点法」执行的非常好；我就曾经听过一位经验丰富的工程主管兼任 Scrum Master 分享过他的成功经验。我的重点在强调「落地」的重要性。身为工程主管，完成商业价值是我的责任；而让团队系统在实践 Scrum 的各项精神时，能有最小的阻力，是身兼 Scrum Master 的责任。没有最好，只有选择。

明天的下篇，就来正式介绍变形的估点系统。