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

一、前言

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

个人是研发出身，做过多年交付型项目经理，近些年在移动互联网行业的多家公司担任过产研团队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、4、5、6、7、8、9、10、11、12、13 ...... 或带小数的数字。回答这个问题前，我们先来看一下韦伯-费希纳定律。 

图3. 韦伯-费希纳定律

韦伯-费希纳定律是表明心理量和物理量之间关系的定律。它表明心里量的增长远远落后与物理量的增长。

简单来说，两个物体存在一定百分比以上差距的时候，我们才能够明确区分它们。并且越往大了走，这个差距量要成越大（越明显）我们才会有感觉。所以差距过小的自然数以及带小数的数字并不能让我们很好的区分其中的差距

三、关于数列的实践

在我们团队实践过程中，使用的点数数列是1、2、3、5、8、13、20、X，这看起来即不是标准的菲波那切数列1、2、3、5、8、13、21、34、55……，也不是敏捷扑克中的那一系列数字，即1/2、1、2、3、5、8、13、20、40、100、？。

这需要分两个问题来回答，第一解释一下敏捷扑克中的数字为什么不是标准化的斐波那契数列，第二说明为什么没有完全采用敏捷扑克的点数。

3.1 为什么敏捷扑克中是修正过的数列？ 

在早期敏捷实践当中的确是使用标准菲波那契数列，如1、2、3、5、8、13、21、34、55......根据韦伯-费希纳定律，21、34、55之间的差距并没有那明显，早期实践者中有人提出既然已经估不准了，那为什么还要用21而不是20或25，所以干脆约定用20代提了21，后来又尝试引入40，100代替了后边的数字，之所以这么做是因为颗粒度越粗估算就越不准确，何必较真是80、90、还是100呢，而“?”代表不确定，暂时无法估算。

3.2 为什么我们没有用40、100以及0和1/2？ 

图4. 敏捷扑克

曾有同事拿着网上找来的敏捷扑克图片来问我，为什么不用40和100呢？其实大家不了解的是，在敏捷实践中有条不成文的规定，40、100（某些情况下甚至认为13、20就已经不合适了，下文有案例）这样的需求是不能直接进入开发阶段的，它们更像是一个标志，提醒团队有一些大事儿要做，但在进入开发之前它们必须经过一系列的拆解、精炼，被拆分成大小合适的需求再进入研发阶段。

有兴趣的朋友可以了解一下《敏捷故事地图》，书中就展示出了需求层次，40和100的更像是规划，直到足够细致才能进入研发。随着研发过程推进，及相关背景条件逐步明晰，经过拆解后的需求点数之和可能远远超过或远远小于之前设定的40、100。

另外，处于互联网当中的软件敏捷团队基本上都使用一到两周一个迭代，在一个迭代中交付的需求之间的体量差异并不会像1与100那么大。并且输入给产研团队的需求也已经过了足够的精炼、细化，因此可以更为准确地去做估算。

关于“?”我们使用较为简单的X代表了它，这点仅是因为我们的管理系统中使用X会比较容易。被设置为X的需求是因为目前尚不具备进入开发阶段的条件，需要更多的信息进行评估，或者需求过大其风险不可控需要拆解。

那为什么没有0呢？我们认为即使一个业务需求不需要开发，但也存在需要产研团队配合的情况，比如过程中需要配置、验证等等，因此不存在点数为0的需求。

而1/2对我们的团队来说又过于小了，在开始任意开发工作的时候，同事们都需要完成切换上下文，准备环境，协调启动等准备工作，而往往这部分看起来“不要时间”的事情也是相当耗时的，其时间占比在越小的需求中往往会越明显。

有开发经验的同事们可以想象一下，copy 1000个1MB的文件，和copy 1个1000MB的文件哪个耗时更少？在第一种情况中会存在非常频繁的I/O开关动作，而在第二种情况中I/O开关对总时长来说几乎可以忽略，所以第二种情况会更快。 第一种情况中的I/O开关所占的比例就不能被忽略，所以我们认为当前暂时不需要1/2。

某种程度上说，我们的方法类似于通过相对估算，把尺度放大了2倍，1/2和3转换为为1和5。但这是我们自己团队的实践，是否需要1/2也需要在实践后决定。

四、关于估算的实践

4.1 估算涉及的因素 

在估算相对大小的时候需要综合考虑一下几个方面：

l工作量

l风险及不确定性

l复杂程度

也就是说，是否做过类似的事情，有没有明确的信息？仅仅是属于“体力活”还是需要攻关？可以在当前团队内完成还是有大量的对外协作？

4.2 锚定基准点 

为了确保每次估算的一致性，团队必须做一些锚定的工作，确定一些基准点，比如固定一个需求代表1个点，另一个需求代表了5个点。可以每次都拿出这些标兵需求来进行比较，得出当前这次估算中需求的大小。

每个团队根据自己的业务不同，设定的基准点也有所差别。如部分团队认为其所处理的需求差别没有那么大应避免使用13和20两个数字，而有的团队则认为13和20是必要的。

因此需要团队内部一起来约定点数定义。而这样的标准并非一次性搞定，是需要经过多个迭代磨合和调整才能完全适配当前团队。 如下图，团队对齐后，最小的杯子叫中杯不是小杯。

图5. 锚定基准点

对于缺乏经验的团队，确定基准点的事情可能让整个团队比较迷茫，找不到合适的对象作为参考，因此产研PMO或其他研发管理相关职责的同事最好能根据公司的特点制定评估推荐标准，方便团队参考。

需要强调的是，这种推荐标准只是一种参考方式，并非唯一真理。点数定义是团队内的管理方式，不同团队间会有所不同，因此公司内各团队横比点数是件并不太现实的事情。

4.3 估算基准案例 

如前文所述，对于缺乏经验的团队，确定基准点的事情可能让整个团队比较迷茫，在这里给大家举个例子。

下面的基准表是某个业务研发团队基于实践总结而得。该团队主要支撑业务运营销售系统，不涉及APP发版班车的情况，也就说他们基本上是SAAS服务，上线比较灵活。

注意，下表所说的工作量时长是指理想时长。考虑理想时长的时候先不要把重点放在要配具体投入多少人在这个工作上，我们是对量的估算并非对速度的估算，估算时团队考虑的理清情况是，所参与的各角色上都有一个人，而实际工作的时候可能是一个角色一个人，半个人，或多个人。

原表内也包含了各基准点案例需求，因涉及公司内部信息而被隐藏。 这个案例未必是符合敏捷估算的好例子，可贵之处在于，这是团队的自发约定。

图6. 某团队的标准

需要注意，在估算过程中常见的错误是，分角色估算，然后汇总。例如，前端估1个点，后端估2个点，而测试估2个点，汇总后这个点数就变成了5个点。这样估算是不合理的，这基本上就相当于工时汇总了，合理的方式是团队整体估算，参见下文估算实践。

4.4 何时开展估算

业内各司，对产品需求生命周期管理不尽相同，有两个节点值得一提：

一、需求预评审，非必要评审会议，仅Tech Leads（包含测试Lead)与产品经理参加的评审，目的是对部分有必要的产品方案进行快速扫坑，保障后续评审通顺利通过；

二、需求评审，相关产研同事共同参加的评审，会讨论到一些细节的设计和实现。

这两个节点都点适合做PRD大小（点数）的估算：

l在需求预审当中，Tech Leads和产品经理对PRD大小有一个初步判断,会记录一些点数推荐。

l在需求评审中，当一个需求经过评审后，我们现场改变协作系统中需求的状态（代表研发接受了需求）并且现场估算（如果预评审估算过，则看是否需要修正）。

我们推荐现场的估算，不过也有的团队是在评审会议后，先各自去做需求拆解，然后再进行估算的情况。无论哪种情况，都需要尽量在迭代排期前完成。因为估算会影响到迭代范围。

4.5 实践中的估算方法 

常见的估算方法包括：专家意见、类比、分解、三点估算、基于代码行数估算、自上而下、自下而上、德尔菲估算、扑克估算......它们从不同的角度提供了估算的建议，在实际使用中，我们并不需要这么复杂的方式，而是应该采用基于团队的估算方法,需要注意以下事项：

l参与的角色一起做团队估算，但应适当控制团队规模

l从整体的复杂度、风险、工作量的方面估算，避免分角色估算后再汇总

l专家意见很重要，但应避免“光环效应”带来的负面指向

l可以采用本质上基于德尔菲估算的简化版“扑克估算”，即在同时给出估算，可以直接用手势表示

l尽管我们需要认真对待估算，但应避免在估算过程中追求100%准确

每个参与的同事现场给出需求的点数，当大家对点数认知差距较大时，主持人让会让各成员给出一些解释。比如，开发同事认为这是一个小的修改就应该给1个点，而测试同事认为这个修改动到了主要流程，并且有很多对外的协作和影响，因此需要考虑更多的情况，所以应该给5个点。

经过短暂沟通后，开发同事了解了自己需要更谨慎对待这个改动，而且要编写简单的技术方案。而测试同事的担心也被开发同事的解释所化解。因此团队一致认为这个需求的大小为3。

现实情况中，很难将所有团队都完美地拆分成7-8的小团队。根据业务的形态，我们划分了一些30人左右的大团队。在这样的大团队中包含了几个子业务方向的小团队。

在估算过程中，团队共同的Tech Leads将会起到对齐各团队点数标准的作用。例如，前一个需求可能是ABC三人估算，而下一个需求是DEF三人评估，Tech Leads凭借对工作的了解和全局意识，在过程中合理引导各子团队，确保他们估算的一致性。

同时Tech Leads在此过程中也应该避免“光环效应”带来的负面影响，从公正的角度出发。经过多次磨合后，整个团队会对评估更有感觉。

五、关于估算的作用

5.1 团队速率Velocity 

在完成对需求的估算后，接下来就是该确定当前迭代能交付哪些需求的事情了。对于新团队的前几个迭代来说，很难判断一个迭代能完成多少需求，因为缺乏对团队能力基线的了解。

这期间常用的方法是，根据排好优先级需求列表（已完成估算），按优先级逐个挑选需求加入迭代，每加入一个就问团队是否能够在当前迭代完成，是否还能够再增加其他的需求进来。通常会尝试排入比“能做完”稍微多一点的需求。这样即有利于确定团队的能力范围在哪里，又能保证全力输出。

经过几个迭代后，团队算出平均每个迭代能够完成多少个点数，这样就得到了团队的交付速率Velocity。在以后迭代安排上作为一条能力基线给团队以参考。如果团队不能一下子消化这么多需求的时候，就用优先级、大小、速率来进行综合判断。

例如，某团队在迭代第一周必须开始1个大小为5的需求，下周才能完成交付。如果这周再安排1个大小为3的需求可能消化不了，但是可以尝试把大小为1的需求见缝插针似地往前安排，这样即能保证团队输出的合理性分布，也能为业务团队带来更好的体验，及时支持及时响应。

在团队基线成熟相对成熟后，甚至在需求评审过程中就会考虑这个迭代的需求太多了是否有必要全部评完，因为即使评完了，当前迭代消化不了的需求需要2周后才能处理，到那时候情况可能已变，说不定PRD要再调整，又来评审一道。

图7. 团队速率

5.2 团队效能指标 

在研发效能指标当中，交付速率是非常重要的指标。下图是一个理想的指标变化趋势。绿色线代表每周团队交付需求的大小，而黄色线代表每周团队接受需求的大小。

随着团队的磨合，能够产出的点数也会慢慢增加。或者因为团队的人员增加，输出点数会呈现略降再上升的曲线，逐步回归平稳。

各团队的Tech Leads也会设置团队内对齐的成长小目标，逐步提升其产出能力。 另外，下图还反映出一个情况，无论需求输入情况如何，团队都保持了比较稳定的输出状态。

图8. 效能指标

5.3 反映问题

交付速率的异常波动，带着表团队可能遇到了困难。例如，下面这幅图，红线代表每周输入点数，而蓝线代表每周输出点数。首先这个输入输出很不稳定，而且在某一周迎来了输入高峰，后续几周都保持比较低迷的输出。看起来对这些需求的消化要到2个月后，未来有两次输出高峰，一个50点，一个104点。

图9. 团队异常示例

经过调查发现，该团队的产品经理们近期做过OKR梳理，某个新起的业务系统需要在指定时间点交付。产品经理为了赶进度，索性一次性评审了所有需求，并且认为在系统闭环前，不具备对外交付的条件。

而研发团队则遇到了关键资源依赖、外部依赖、必须整体上线这样的问题，所以才有了某个时间点一次性交付104点的计划，而中间4周内缺乏上线动作，这其中的风险不言而喻。

基于需求的特殊性，和团队商量采取一些的操作，如分阶段管理，聚焦阶段目标；按重要程度控制需求入口；接口测试作为团队间验收标准；合理调整上线时间，将输出分散到每个迭代中等，后续证明，当时的及时调整（虽然都是常规操作）的确起到了作用，保证其顺利交付。而交付速率的指标可以反映出团队可能存在的问题。

5.4 定期对齐估算标准 

在某些案例中，团队虽然已经确定了自己的估算标准，但为了外显工作成果，在估算中千方百计寻地寻找增加某个需求点数的机会，长此以往导致估算的“通货膨胀”。其中的诱因可能是多方面的，比如业务方与产研团队信任不足；内部管理风格；团队成熟度不够；估算比较随意等。

我认为其中可能存在另一个原因，就是大家没有明确估算的目的。在我们的故事中，引入估算的目的是为了实现团队的自我管理，逐步提升产研团队的效能。估算的标椎会随着团队实践而调整，通常会在定期的回顾会议当中寻学习机会，有哪些需求被低估了，有哪些需求被过分高估了，团队的估算标准和对比“标兵”是否要进行更新?

我们在迭代开发中很少进行估算调整（此时需求已在开发中），特别是将点数往大了调整，但过程中会调整需求的预计交付日期、所在迭代等信息，以保证研发过程信息准确。谨慎调整估算出发点是，随手调整的点数容易让团队错失学习机会，“痛定思痛”将有利于团队成长。

5.5 点数分布比例能看出什么？ 

业务研发的长远目标是服务于“长期高效快速地响应业务需求，交付业务价值”。以下列出三个团队某半季度的数据作为参考。

图10 点数分布示例

点数分布与业务形态和团队成熟度有关，通常小的点数占比高说明整个系统搭建已经相对比较成熟，支持小步快跑的试错中；当团队遇到新的需要兼容的业务方向时，会因为“新兴土木”而迎来比较大的点数。

从某种角度来说，这也是对产研团队成熟度的一种衡量，团队是否有能力将需求拆小？各系统之间的耦合度是否支持这种拆小的需求？是否能让业务快速获得相关功能并通过迭代将其完善？

六、写在最后

以上就是我们的一些敏捷估算实践，如开文所述，估算仅为实践之一，是基于敏捷生态而存在。 碍于能力有限，不能将各方面尽数涉及，更无奢望全面讲清楚，若能给您带来些许启发，我将倍感荣幸。

我认为敏捷的最终目的从来都不是为了一套完美的流程或管理系统。它将改变的是团队的思考方式和做事方式等。团队拥抱自我成长，一蹴而就的操作势必引起抵触和反弹，宜逐步引导，让实践在团队内生根发芽。