敏捷估算的定义、方法及知识技巧是什么

估算是对交付计划产品所需的成本、进度、投入或者技能进行的预测。对项目的可行性、商业案例的投资回报进行评估非常有必要。3种常用的估算方法是：1、专家意见；2、类比；3、分解。每一种方法都可以独立使用，但是要想得到优异的结果，应综合这3种方法。

一、什么是敏捷估算

为什么要估算？估算的目的是确定项目大小；计算投资回报率、收益率；确定哪些工作应该在哪个版本哪个迭代完成。

如何建立估算？在确定项目大小、成果、日程表、最终成本的阶段中建立估算。

如何描述估算？敏捷用故事点为单位；敏捷估算是一个范围，如4000-5000，便于管理项目不确定性。

何时进行估算？项目中持续估算，最后分解成实际的成本或持续时间。

谁来估算？涉及项目工作的团队成员，因为成员对技术了解的非常多。

二、3种常见的估算方法

1、专家意见

基于专家意见的估算方法，当专家被问道这个故事有多大，专家根据自己的主观直觉给出估算，相对传统项目，这种方法在敏捷中不是那么有效，因为敏捷一般对有价值的故事进行估算，可能需要多种技能，这些技能往往需要多个人才能全部具备。但是专家意见评估的好处是时间短，如果能配合研发人员的主观经验判断做出估算往往也是准确的。

2、类比

使用类比进行估算就是把用户故事与一个或多个故事进行比较，如果这个故事是其他故事的两倍，就分配一个两倍的估算值。

用类比法估算时，把每个新的用户故事与那些已经估算过的任意估算进行比较，也就是下文说的亲和估算。

3、分解

分解是把一个用户故事或者特性分解为更小，更容易估算的部分，然后进行分别估算，而组合则相反把很小的故事组合成大的故事，一般组合发生在修复缺陷时。

通常一些用户故事需要的时间超过了一次迭代的周期，就要把它分解。可以按照用户故事所支持的数据类型分解；可以根据故事固有的操作分解；可以按照常用的CRUD操作（建立、读取、更新和删除）进行分解很常见；可以去除横切关注点（如安全处理、日志处理隔离出去可以使用户故事变小）；忽略满足性能限制（性能可以形成独立的用户故事）；可以根据优先级进行分解。

敏捷术语中“解聚”Disaggregation也是将史诗故事或大型故事分解成小型的用户故事。

三、估算的工具技术和知识技巧

1、宽带德尔菲（Delphi）

宽带德尔菲（Delphi）是基于团队的估算方法。

这种技巧要求一组专家匿名提交估算，所以没有人知道哪个估算属于谁。匿名估算是对原有估算的一种改进，因为它将“从众效应”和“光圈效应”（人们会被专家的观点或者高级别的人的观点吸引，而不是通过自己的价值观判断）的影响减到最小。

一个宽带估算会议从规划一个问题开始。相比在一个计划中估算整个项目，团队将项目或大问题分解为更多的可管理的块。团队创建了一个问题说明书、识别出假设和约束件，并且概述后续估算周期的过程。

举例说明，诸如人们是否应该在估算中忽略文档的时间，估算单位（比如，人周、小时、美元等），以及退出标准（比如，我们想用土20%的限度作为估算范围）这样的细节都应该包括在这个计划中，并且估算团队的开踢会议也应该被列入日程。

在他们开始建立估算之前，所有参与者应读说明书，提高和讨论问题的质量。每个参与者都会得到一个空白的纸张，他们可以在上面写下为不同任务所做的估算。然后引导员收集估算并且用一张图画出它们，但不需要确定那个估算来自于哪个估算者。流程图如下图1所示

宽带德尔菲会议的初始估算图如图2所示。

主持人通过估算会议收集和绘制每一个参与人的估算。每一个参与人估算的结果都会显示在X轴的名列前茅轮的那条线上。初始的估算所覆盖的范围可能大得吓人。在讨论完初始估算后，所有的参与者都会修改他们的估算。主持人会收集这些估算并把它们贴在同样的图上，如“第二轮”的线上。而后几轮的分布会越来越接近。

宽带德尔菲法步骤如下：

1）确定需要收集意见并达成一致意见的主题，如确定项目、选择项目方案、制定项目计划、识别项目风险等。

2）挑选内部的专业人员，或者外部专业团体中具有专业知识或经过培训的个人组成专家小组，为了避免相互影响和干扰，专家们不进行会面，不进行讨论，彼此互不了解对方的想法。

3）由协调员采用书面问卷的方式，向每位专家征求对所要讨论的主题方面的意见和建议，并要求这些专家进行匿名分析后，分别将自己的意见以书面方式反馈给协调员。

4）协调员将不同专家的意见汇总，再将这些意见反馈给专家们，并要求专家们在此基础上进一步提出自己的判断或意见。

5）所有专家收到一份全组专家的集合分析意见后，再次进行匿名分析，提出赞成和反对的意见，再次将自己的意见反馈给协调员。

6)协调员再次汇总各位专家第二次反馈意见，然后进行汇总，再将第二次汇总的结果发给各位专家，要求他们在此基础上再次做出判断，如此反复，直到所有专家的意见趋于一致。

2、计划扑克

敏捷团队优异的估算方法是计划扑克，由JamesGrenning和MikeCohn进行推广的，计划扑克把专家意见、类比和分解结合到一种令人愉快的估算方法，可以产生快速可靠的估算。

宽带德尔菲技术通常用“计划扑克”来实施。这个技术的变化使用了一个快速的合作的过程，并结合了所有基本的宽带德尔菲元素。计划扑克通过卡片中的数字实现了估算。

这些数字代表故事点。“计划扑克”估算是Scrum和其他敏捷过程的核心实践。这个过程意味着要估算故事的大小，例如：要花费多长时间、要实施多少工作、花费是多少等。在Scrum中，需要估算团队的活动。

对于每一个故事，团队的每一个参与者都应该参与到估算的过程中。计划扑克（有时也叫Scrum扑克）能使团队’快速地进行估算、更加的准确和有意思。

现在想象一下团队的每一个成员都手持一副牌，如下图所示（采用斐波拉契数列的数字）

说明：斐波拉契数列由整数构成，每一个数都等于前两个数的和，1、2、3、5、8、13、21、34、55，以此类推。卡片0意味着“这个故事已经做完了”或者“这个故事几乎什么都没有仅仅需几分钟就能完成；？代表不知道，这时要请PO讲解；咖啡杯代表我很累，需要休息。

计划扑克估算会议步骤：

1）一名调停人，主持会议，不参与估算。

2）产品负责人/管理人员对用户故事作概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。

3）当被问道“这个故事需要花费多长时间？”，每一位估算师抽取一张扑克卡片来估算工作量。

4）每人抽取一张卡片后，同时将他们的卡片翻转；

5）持高和低估算的估算师各有一个机会作立场辩护。

6）达成共识前，不断重复以上流程。持有用户故事的开发者往往拥有较高可信度。

一般情况下，估算的轮数不超过三轮，如果在第三轮的时候，数值还不能收敛，则可能是团队成员对故事还不够清晰，需要产品负责人的进一步澄清，所以为了不耽误估算的时间，可以将其放入下一次的估算中。每次估算会议的总体时长不超过2个小时，否则大家会有疲惫感。

Tips：项目实战中优异是结合宽带德尔菲的计划扑克，因为扑克法有一点要吐槽就是太浪费时间，虽然不允许一直打牌打下去，不过讨论起来也是耗费大量的时间，甚至演变成了交流会偏离主题。在估算时进行适当的预先设计讨论是必须的，然而讨论太过就会越走越远，有一种有效的方法可以鼓励一定量的讨论，同时避免太久就是2分钟沙漏，当讨论开始翻转沙漏，沙子漏完进行下一轮扑克。

3、相对估算

“相对估算”是使用“比较”的原则，通过用户故事（story）之间的大小对比进行估算，估算后的结果没有时间单位。

1）咖啡杯

在项目中经常有一些不重要的工作花了比预期更多的时间；而有时还会出现新的和未知的任务，整个过程花费比我们预期的时间更长。我们尽可能地在估算中考虑这些情况，

但是我们还是会因为错误的估算受到指责，所以较好做一个相对的估算，做敏捷估算时，请先忘掉人天或人时，因为对于人天或人时来说，人与人的能力是不太一样，在敏捷中，我们更加看重的是团队的整体。

而敏捷估算关注的是工作量的规模（大小），而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位一一故事点，故事点是一个相对值，是一个相对倍数，和人天、人时没有关系，在进行故事点估算时，我们先找到可能最简单的故事，将它的点数设为1点，接下来用其他的故事与它进行比较，如果另一个故事比这个更复杂，那个故事可能就是3点。

2）T-Shirt

T恤尺码分类法顾名思义，通常用于非常大的事项来确定积压工作的大小，度量单位通常是XS、D、M、L、XL、XXL；

Scrum团队聚集在一起，对积压事项进行公开讨论，通常会考虑时间（一般以人天为单位）注意T恤法本质上不是数字，目的是为了让技术团队发挥创造性的一面，保持开放心态更容易接受其它团队成员的观点，适合刚开始进行敏捷项目管理的团队。

产品经理会对每一条需求评估上业务影响力的尺寸，如：XXXL 影响一千万人以上或是可以占到上亿美金的市场，XXL，影响百万用户或是占了千万金级别以上的市场，后面还有XL，L，M，S，这样下来。

　开发团队也一样，要评估投入的人员时间成本，XXXL表示要干1年，XXL干半年，XL干3个月，L干两个月，M干一个月，S干两周以下。等等。于是，

当业务影响力是XL，时间人员成本是S，这是较高优先级。
当业务影响力是M，时间人员成本是M，这是低优先级。
当业务影响力是S，时间人员成本是XL，直接砍掉这个需求。因为是亏的。
当业务影响力是XXL，时间人员成本是XXL，需要简化需求，把需求简化成XL，时间人员成本变成M以下。

相对估算步骤：

1）寻找一个参照故事A作为1个故事点（用来度量完成1个story所需工作量的相对单位）。

2）迭代的每个story和A做比较，得出这些story需要几个A的工作量，即为几个故事点。

3）完成故事A，获得故事A的实际需要的时间，即可推算出完成所有story需要的耗时。

4、亲和估算（三角测量）

如果你刚刚开始一个项目，待开发项还没有估算，或者正在准备发布计划的时候，亲和估算将是一个非常好的技术。

对于亲和估算，其参与人包括：产品负责人、团队和ScrumMaster。来做这种估算的一种不错的方式是把不同规模大小的用户故事按顺序排列，并贴到墙上，然后再将每个故事卡移动到合适的列上。

如果新产生一个用户故事，与已经存在的故事卡做比较，然后把它贴到合适的“列框”里，如果这个新的用户故事的规模与已有的看上去能匹配，贴上去就好了。如果是相反的情形，那么我们要与团队进行一个阶段点的讨论，来确认一个故事点的含义以及重新进行单位的校准。

亲和估算步骤：

1）每个用户故事被水平贴在墙上，再在墙上从小到大贴上数列（也常常采用斐波那数列）比较成功的估算序列，这两个非线性序列反映工作大小越大估算不确定越高。·1、2、3、5、8…（斐波那数列）·1、2、4、8…（后面数是前面的2倍）

2）团队成员排成一排

3）要求名列前茅名团队成员把一个用户故事放在他认为可以正确防止故事点值的那一列上

4）名列前茅名成员完成后，排团队成员最后位置，团队安静地执⾏以上步骤，不讨论技术或者特性问题

5）下一个团队成员可以挪动已经摆好的用户故事，也可以选择另外的用户故事，挪到他认为正确的位置

6）循环这个过程，直到所有的故事摆放完毕。

7）循环过程中如果一个故事反复被挪动，需要把这个故事挪到最上面以便最后讨论，如果讨论无果则放置在较高值的位置

8）问好位置的故事需要重新进行估算

小结

花更多的时间和精力来得到一个估算值，并不一定会提高准确性，应该根据估算的目的来决定在估算中投入了多少工作量，虽然众所周知，将要做某项工作的人估算时较好的估算，但是在敏捷团队中，我们无法预知谁来做这项工作，因此估算活动时团队协作完成的。

估算应该基于一个预先定义的尺度，将会在近期处理的功能，并且功能足够小，因此他们可以使用1-10的非线性尺度来进行估算，例如1、2、3、5、8….,在最近几次迭代中不太可能需要实现的功能可以不分解，用大的单位，如13、20、10、100来估算。

得到估算值可以采用专家意见、类比、和分解法。

拓展阅读

敏捷项目管理软件推荐

1、国内专业的敏捷项目管理工具：PingCode

根据36氪企服点评发布的榜单，PingCode 是2021年国内研发项目管理榜单名列前茅的研发项目管理系统，具有国内标准的 Scrum、Kanban 等敏捷项目管理功能。

这是一款覆盖研发全生命周期的敏捷项目管理平台，被广泛用于需求收集、需求管理、需求优先级、产品路线图、项目管理（含敏捷/kanban/瀑布）、测试管理、缺陷追踪、文档管理、效能度量等领域。

并且集成了github、gitlab、jinkens、企微、飞书等主流工具，也就是说我们能在需求下面关联代码，关联集成信息，在飞书查看通知等。

有非常多团队使用PingCode 进行研发过程管理、产品管理。它可能是国内近几年较受欢迎的研发项目管理工具。

PingCode 支持私有部署、定制开发、SAAS等版本；价格仅是Jira的30%-40%。

【PingCode 官网：https://datayi.cn/w/nP2YMlzR】

2、项目管理软件：Monday.com

Monday 是国外的一款产品，在项目与团队管理方面，Monday.com提供了自定义通知、以及自动化的功能，可方便用户更加专注于需要完成的各项任务。

通过其出色的跟踪功能，我们可以跟踪与项目相关的所有任务与进度。Monday.com能够创建并可视化还各项任务，以方便团队的共享和稳步推进。同时，它还能够轻松地创建backlogging，以方便用户对手头的任务进行排序。

Monday.com的一项缺点是：

用户无法通过创建专门的燃尽图，来跟踪sprint的进度。不过，它能够提供简单的图表和报告，以方便用户粗略地了解整个sprint的状况。
国内的服务支持服务可能不如国外

主要功能：无缝的工作量管理流程、高效的协作、产品级的backlog、提供Sprint计划、提供任务依赖、优先项目管理、直观的用户界面、出色的客户支持（国外）。

官网：monday.com

3、敏捷开发管理工具：Jira

Jira 同样是国外能够实施Scrum方法的知名软件，Jira提供了丰富的功能，其中包括：可用于backlog的自定义过滤器、项目报告的可视化表示、以及可定制的Scrum板。当然，如果您不太熟悉Scrum的话，可能需要花上一定的时间来测试，熟悉和掌握该软件的各项功能，因为Jira 上手会比较难，这也是很多人诟病的点。

不得不说，Jira 在国外使用的体验比在国内使用要好很多，因为售后服务国内是没有原厂的，所以如果有国外团队，Jira是个不错的选择。