敏捷估算：故事点与直接估算天数的差异

清疚 2023-08-17 15:50 86阅读 0赞

作者：陈勇

出处：blog.csdn.net/cheny\_com

在敏捷中直接估算天数最大的好处是直观，坏处是很难衡量是否有故意的高估和低估，也不能比较生产力是否在提升，于是基于故事点的估算应运而生。

# 基本使用方式 #

故事点的基本做法是：把一些常见的“标准任务”给出一个“标准点数”，形成比较基线，估算的时候只要是同一类型的任务，直接写上故事点数而非天数。比如：

1. 对单个表进行增删改查

2. 为一个已经存在的数据表增加一个复杂报表

3. 修改一个中等难度的BUG

……

在刚开始的时候，“点数”可以就是以往完成任务的平均天数。比如曾经有4次对单个表进行增删改查，查看历史记录发现天数大约是15天，则可以定为15点。以后再碰到类似任务，直接写下“15点”，而不再做太细节估算。

若故事点使用了6个月，假设团队人数不变，而每个月完成的故事点分别为76/82/92/81/102/98，则表明开发效率不断改进。

当然导致故事点生产率变化的不只是开发效率，比如到末期可能测试/部署占用了一些可用开发时间导致故事点减少。因此一般会同步跟进可用时间的变化。

# 目标 #

使用故事点后团队工作可能发生一些有益的变化，这是主要的目的，比如：

1. 团队间会横向比较标准点数，并因此获得一定动力

尽管不同团队会选择不同的标准任务，但其间难免有所重合，若一方设置某任务为10点，而另一方为20点，则双方需要进行一定的沟通。

当然不能粗暴地认为两者点数应该相同，但与其说其间的差异反映了团队人员生产率的差异，更可以认为表明了双方架构的易维护性/已有模块的可复用性等方面的差异。对这些差异的合理分析和处理，会带来积极的改进。

2. 估算过程整体可以不太纠结于人员能力差异，而在于“这是什么任务”

在敏捷生态系统（将另有博文详述）中曾提到，估算的目标不在于一个数字，而在于“这是什么任务”及“用什么方式实现最优”。故事点在这一点上比天数更好一些。

一个附加价值是：若一个任务看上去比某标准任务难一些，可以在点数上额外估计几点，防止错过明显的差异。这一点数差异是建立在任务的差异上的，而任务差异的评价过程对未来确定这个任务的范围/标准/方法是很有用的。

3. 借助故事点生产率的变化，可以观测实际生产率的变化

在本文开始已经提到，这是直接用天数无法实现的。

4. ……（任何用直接天数达不到的目标）

倘若在实施故事点后并未达到上述目标（甚至在实施故事点前并没有想好有哪些目标），实施故事点基本上会失败。

# 使用难点 #

国内在业界极少见到使用故事点成功的案例，难点包括：

1. 故事点的项目或产品特征很明显，几乎无法跨团队比较

2. 若没有历史数据，很难设定标准任务

3. 在标准任务没有那么多种类时，很难判断一个新任务到底像哪个标准任务；而太多的标准任务又令人迷惑

有鉴于此，笔者觉得在尝试故事点前，不妨先使用一种中间状态的估算过程：

1. 每个迭代后都记录所有任务的实际完成情况，并形成所有任务的历史完成情况集合

2. 每个计划会仍只估计天数，但大家要随时可以感觉新任务像以往哪个任务，并迅速查找历史（打印一个小册子），根据任务差别在历史数据上增减天数

这种方式无法直接打到故事点的目标，但却可以逐渐建立标准故事集（那些最常被查找的故事），或至少可以帮助大家在脑海中把生产率具象化（“哦，单表增删改查原来要花费15天啊”）。

点击下载免费的敏捷开发教材：《[火星人敏捷开发手册][Link 1]》

![0_1311055886783t.gif][]![0_1311055987UN6B.gif][]

转载于:https://www.cnblogs.com/JPAORM/archive/2011/03/04/2510538.html

[Link 1]: http://blog.csdn.net/cheny_com/article/details/6616794
[0_1311055886783t.gif]: http://hi.csdn.net/attachment/201107/19/0_1311055886783t.gif
[0_1311055987UN6B.gif]: /images/20230810/c5f5d7fcb33242b6b570710624cb1453.png

发表评论取消回复

表情：

评论列表（有 0 条评论，86人围观）

还没有评论，来说两句吧...

相关阅读

相关度量、测量和估算

在现实世界中，人们对事物性质的描述大致可分为二类：定性描述和定量描述。例如，人们通常会说某某个子很高，某个软件的成本非常高等等。此类描述通常运用一些形容词来描述事物的性质，属于

心已赠人/ 2024年03月31日 17:08/ 0 赞/ 36 阅读

相关敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算）

这是敏捷开发绩效管理的第五篇。（[之一][Link 1]，[之二][Link 2]，[之三][Link 3]，[之四][Link 4]，[之五][Link 5]，[之六][Li

今天药忘吃喽~/ 2023年08月17日 15:52/ 0 赞/ 91 阅读

相关敏捷开发“松结对编程”实践之三：共同估算篇（大型研发团队，学习型团队，139团队，师徒制度，敏捷设计，估算扑克，扑克牌估算）...

本文是“松结对编程”系列的第三篇。（[之一][Link 1]，[之二][Link 2]，[之三][Link 3]，[之四][Link 4]，[之五][Link 5]，[之六][

柔光的暖阳◎/ 2023年08月17日 15:51/ 0 赞/ 80 阅读

相关敏捷估算：故事点与直接估算天数的差异

作者：陈勇出处：blog.csdn.net/cheny\_com 在敏捷中直接估算天数最大的好处是直观，坏处是很难衡量是否有故意的高估和低估，也不能比较生产力是否在

清疚/ 2023年08月17日 15:50/ 0 赞/ 87 阅读

相关【项目管理】三点估算

三点估算最可能持续时间：最可能持续时间是在为计划活动分派的资源、资源生产率、可供该计划活动使用的现实可能性，对于其他参与者的依赖性，以及可能的中断都已给定时，该计划活动的持

妖狐艹你老母/ 2022年11月13日 05:28/ 0 赞/ 164 阅读

相关【实用】批量成本估算

批量成本估算【前言】单个物料的成本估算我们使用事务代码CK11N，标记/发布使用事务代码CK24，那么若有大批量新建的物料需要做成本估算，怎么办？这里

水深无声/ 2022年11月13日 05:20/ 0 赞/ 181 阅读

相关费米估算的思考

![bee38f771bf5cb988f6a80e2be554f05.png][] 前段时间在分析大厂产品面试题，发现估算题目出现的概率蛮大。比如估算北京一年出租出去的房子数

系统管理员/ 2022年09月03日 07:26/ 0 赞/ 167 阅读

相关由两点的经纬度估算距离

由于项目中要估算两点距离，所以找了下由经纬度估算距离的公式： private const double EARTH\_RADIUS = 6378.137; privat

系统管理员/ 2022年04月01日 10:56/ 0 赞/ 337 阅读

相关软件项目中的功能点法估算-原理

Function Point Estimation 功能点估算是一种用来估算项目大小的技术。功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应

分手后的思念是犯贱/ 2022年03月27日 21:18/ 0 赞/ 213 阅读

相关 TPS&QPS的估算

概念 PV（Page View）：页面访问量，每次用户访问或者刷新页面都会被计算在内。 QPS（Query Per Second）：每秒查询数，每秒系统能够处理的查询请

梦里梦外;/ 2021年06月10日 20:38/ 0 赞/ 580 阅读