一文搞懂敏捷估算及实践案例分享【壕叔盘敏捷】

一、前言

在业务研发中估算一直是相对比较难以把握的事情，本文结合个人和团队的经验来谈谈对估算的认知和实践。先介绍一下个人的背景，以方便大家更好理解我们的出发点。

个人是研发出身，做过多年交付型项目经理，近些年在移动互联网行业的多家公司担任过产研团队PMO职位，其中不乏独角兽级创业公司。我们的PMO兼顾了教练赋能、协作改进、流程优化、工具演进、效能提升以及跨团队项目协作的等多项职能。

做过类似工作的朋友们会了解，估算是敏捷研发环节之一，但可能不是最初要解决的事情。比如，团队的信任如果没有建立，那么估算只能变成需求方和产研团队间的一种相互制约的工具。本文的出发点是希望敏捷估算成为产研团队自我管理的一种参考方式。

我们的实践也仅是一家之言，难免有失偏颇，请多多指教，共勉之。

1.1 什么是点数大小 

点数大小是敏捷软件开发的一种估算方式，是对一个需求的综合估算，包括了复杂度、工作量、风险及依赖等多方面。

1.2 只能用在用户故事上估算？ 

有敏捷开发经验的朋友可能会认为估算就是在Story上估算Story Point，如果你与“客户(需求提出方)”讨论和交互的是Story当然是这样。同时业内也存在采用了三级需求架构的公司，类似MRD-PRD-Story（注：MRD，Marketing Requirement Document 市场需求文档；PRD, Product Requirement Document 产品需求文档, User Story 用户故事），我们的团队就采用了这样的需求架构。

这个时候在PRD上谈论估算将会更加合适，因PRD是产品经理与业务对齐以及产品经理与研发沟通的一个中间点，将作为软件产研团队对外交付的基本单位。

图1. 三层架构

三层架构非本次的重点，仅简单介绍作为参考。它的主要目的是为了让业务、产研团队各有关注点。

业务提的需求作为MRD（包含了背景、期望、痛点、业务价值等）；产品经理在接受了业务的MRD后对其进行设计分解，形成一个到多个产品设计即PRD（包含方案描述、原型图、路径说明等）；

Story被定义为PRD内根据feature list进行合理分解后的开发单位（容器），这里尽量采用敏捷建议的纵切，也就是前后端和测试在一个Story上工作，前后端的工作可以作为Story的子任务分配到个人。

Story争取做到可独立开发、可独立测试、可独立部署，所有Story的组合完成了一次对外需求（PRD）交付。

我们在PRD上进行估算的，估算过程被称为对PRD大小的估点，原理与Story Point相通，但略有实践上的差别。

下文中出现点数、大小等信息均指PRD大小。之所以叫“大小”是因为我们的早期实践采用了服装尺码“XS、S、M、L、XL”，后因方便直观定量回归到数字序列上，但保留了约定俗成的名称。

二、关于使用点数估算

2.1 我们擅长相对估算 

在人类漫长的演化过程中，我们的逐渐进化出了一种高阶智慧——“类比”，大脑为了节省能量，在无需精确“度量分析”的情况下，仅靠直觉也能够快速地做出相对比较正确的判断。

设想，我们走在路上看到路边种的树，让我们说出这些树的实际高度是多少米，这个问题可能比较难。但是我们可以很轻松地判断出一棵树比另一棵高，也可以判断哪棵树最高，哪棵树最矮。甚至可以去猜一下，这些树中，最高的是最矮的多少倍，这要比直接说出具体高度要容易得多。

2.2 估算的尺度 

敏捷中最常用的估算尺度的是菲波那契数列(修正后的，后边会解释)，即：1、2、3、5、8、13......,为什么要使用菲波那切数列而不是自然数 1、2、3、