敏捷估算:故事点与直接估算天数的差异
帮助中心 > 敏捷开发
敏捷估算:故事点与直接估算天数的差异

作者:陈勇

出处: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天啊”)。


评论页面|
文章评论
发表评论

您还没有登录,请您登录后参与讨论:


 或 

京ICP备案证书号(京ICP备13026048号-6) Copyright 2013-2017 Yugusoft(Beijing)All Rights Reserved.

京公网安备 11010502036844号

  • 服务协议
  • 隐私条款