用户故事估算

无论一个软件项目规模如何,采用何种管理方法,估算与计划对项目执行来说都是必须,很多重要的决策都要基于此来做出。在敏捷软件开发过程中要制定一个有效的计划,我们就需要知道这个软件的总体规模,进而根据团队速率推算出完成所需的时间,因此我们需要具有一种可靠的方法来快速的估算出软件规模,并根据团队历史速率来计算完成软件所需的可能时间。如下图,如果我们把所有必须特性的故事点估算加到一起,我们就得到了项目的总体大小,这时候结合团队的历史迭代速率就得到了完成系统需要经过的迭代次数,把这个时间制成日历表就得到了项目的初始进度表。

用户故事估算

故事点和理想时间

我们常见的度量故事大小的方法为故事点和理想时间方法。这两种方法各有利弊,需要在项目中根据实际情况进行选择。

故事点

类似于你去餐厅点菜,有时候你可以选择点半份,或者一份半,这都是相对大小的概念,这已经足够你根据自己的需要进行选择,你肯定不会精确到克千克。还有一种情况是我们说距离时候经常说的我离某某地方大概几站地,这也是一种典型的相对估算的方法,别人问距离时候很少有人说精确的公里数。估算故事点也一样的道理。

用户故事估算

故事点是用于表达用户故事、特性或其他工作的总体大小的度量单位,一般情况下反应了一个故事的相对大小,可以看做是工作量、风险和不确定性的函数,SP=f(E,R,U)。例如:一个估算为2点的故事的工作量应该大概相当于一个估算为1的故事的两倍。

需要注意点数本质上还是关于工作量的估算,风险、不确定性、复杂度、未知因素以及其他相关的事,仅当他们会影响工作量时才应被包含进去。如果某些事确实很复杂,但却不会影响实现特性所花费的时间,那么复杂性就不应该对估算产生影响。

使用故事点估算需要事先选择一个参照故事作为其他故事估算的参照依据。一种方法是选择一个系统内最小的故事,设定其为1个故事点。另一种方法是选择一个中等规模故事,然后给它分配一个中间点数,例如5点,然后参考它来估算剩余故事点。这两种方法可以根据自己喜好进行选择。

理想时间

一场足球赛多长时间?

用户故事估算

一般人会回答比赛分为两个相等的半场,每半场45分钟,所以一场球90分钟。对于稍有经验的人可能会考虑到一般会有中场休息、伤停补时时候,告诉你大概要两个小时。这两个答案恰好回答了理想时间和实际耗时的区别。

理想时间是理想情况下,剔除所有外围干扰因素之后所需的时间。我们选择用理想时间来进行估算是因为这样已经足够用来预测实际耗时,并且更容易估算。想象让你回答一场球赛的耗时时间,你需要考虑各种意外因素,甚至可能需要去统计历史上各类数据,最终出一个统计学意义上的精确结论,这样的估算成本太高了,对于我们来说根本没必要。

在进行理想人天估算时,我们一般做如下假设:

  1. 你所估算的故事是你将要处理的唯一工作。
  2. 处理这个故事所需一切外部条件在你开始工作时都已经准备好。
  3. 处理这个故事过程中不会被打断。

注意:
虽然不是必须,但是在估算理想人天时候,还是建议避免按照角色或者分工来估算,比如 一个故事 估算 前端需要2理想人天,后端需要1理想人天,测试需要2理想人天。这种估算方式违背了敏捷强调的”我们是一个整体“的价值观,它进一步强化了每个人的角色标签,并且为制定计划和跟踪进度增加了额外的工作量。所以除非极特殊情况,尽量避免这么做

估算方法

对于估算常用的估算方法是专家判断、类比、分解(是不是很眼熟),一般在敏捷实践过程中为了达到最佳效果我们会综合使用这三种方法,这种方法就是”计划扑克“,计划扑克把专家判断、类比、分解三种方法很好的结合到了一起,可以快速可靠的完成估算。计划扑克游戏过程将不同领域专家的意见都进行了考虑,并且促成了活跃的讨论,事实证明这对提高估算效率和准确性及其有效。

计划扑克

用户故事估算

参与者

  1. 计划扑克游戏需要团队成员全部参与估算,包括所有程序员、测试、DBA、交互设计师。
  2. 产品负责人也需要参与估算会议,但是他不参与估算,只是对团队疑问进行解答。
  3. 团队规模不能过大,最好不超过10个人,如果太大会影响估算效率。

估算过程

  1. 开始估算前,每个参与者都会领到一副估算扑克,扑克包括0,1,2,3,5,8,13,20,40,100等面值;这个扑克也可以使用APP工具代替。
  2. 估算开始后,主持人从Product Backlog顶部抽取一个要估算的故事,大声读出故事名,故事描述,验收条件等信息。
  3. 每个估算者针对该故事提出自己的疑问,产品负责人对疑问进行解答和澄清,确保大家对完成定义的理解一致。
  4. 所有问题都澄清后,每个估算者选择自己的估算值对应的扑克,在所有估算者都选好后一起亮出自己的估算值,让彼此看到。
  5. 让估算最高和最低的人分别说明自己的估算理由。大家也可以针对性进行简短讨论,然后重新出牌。
  6. 重复第四步和第五步直到大家达成基本一致,如果不能很快达成一致则取一个大多数人能接受的值,避免追求过于精确的值。

什么时候估算

基本原则就是当需要进行估算的新故事积累到你觉得需要估算时就组织一次估算游戏。下面是一些比较常见的估算时间点:

  1. 第一次迭代之前:产品第一个冲刺开始之前通常会有大量故事需要进行估算,这时可以专门组织一到多次估算会议,以便于PO可以基于这些估算成果制定产品路线图和发布计划。
  2. 在迭代过程中发现新的故事时也需要进行估算,我们一般会累积一个迭代过程发现的新故事,并且在下一迭代的梳理会时候进行估算。
  3. 在计划会上对未估算故事或者发生变化的故事进行估算。
  4. Kent Beck建议墙上放个纸袋,把发现的新故事放进去,有人有时间时就去袋里拿几个故事,叫上大家估一下。
注意
  1. 当经过两到三轮估算仍不能达成一致时,这时候可以考虑取一个大多数人能接受的值,避免在一个故事的估算上纠结太久。
  2. 估算之前团队应该具备相关领域知识,最好是对要估算的故事进行了预先的了解。
  3. 如果不具备每次全员参与计划扑克游戏的条件,让部分经验丰富的人来负责估算也是可以的,但是每次不能低于三个人。

小结

目前我们公司建议的是采用理想人天的估算方法,使用理想人天方法需要注意:

  1. 理想人天的方法很难避免不同人能力和认知不同带来的误差,在使用理想人天方法过程中应有意平衡一下这种因素可能带来的误差,比如如果你认为自己处于团队能力中上的水平,那估算时候要适当多估一些,如果你是个初学者,估算时候适当少估一些,尽量靠近团队平均水平。
  2. 随着团队能力的成长,一个理想人天所代表的实际工作量也是在动态变化的,估算开始时可以通过回顾几个标准参照历史故事的值让团队估算时尽量与历史估算一致。
  3. 估算过程尽量避免个别强势人的影响,如研发经理、架构师,如果发现这种情况,SM需要进行干预,可以让他们最后出牌,避免评论大家的估算结果。
  4. 故事估算是为了让我们更好的进行产品规划和迭代规划,为提升团队速率做度量,不是为了承诺,也不是为了考核,如果把估算结果用于承诺和考核,那就失去了敏捷的初衷。

来源:敏捷工坊,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/126078

发表评论

登录后才能评论
侵权联系
返回顶部