专栏首页ThoughtWorksTW洞见 | 敏捷开发中的故事点数

TW洞见 | 敏捷开发中的故事点数

什么是故事点数?

故事点数是敏捷团队估算用户故事使用的一种主观的计量单位。

故事点数代表了什么?

故事点数代表了完成一个用户故事所要付出的工作量。一些敏捷开发人员认为,它是一种衡量复杂度的方式。不过,只有把故事开发过程中的复杂性和风险量化并计入估算中时,这种观点才能成立。

估计的故事点数包含哪些部分?

它应该包含了完成这个用户故事的工作量。当然,它不仅应该包含完成用户故事的开发工作量,也应该包含该用户故事在类产品环境中的测试工作量。

为什么用点数比用小时和天数更好?

故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式,在有大量样本数据的情况下,比独立估算每个用户故事要准确得多。

举个例子,我们可以很容易的说出,从(印度)德里到(印度)班加罗尔的距离是从(印度)孟买到(印度)班加罗尔的两倍,而不是德里到班加罗尔的距离是2061千米。

这样,团队不用花太多的时间来估算每个用户故事所要花费的准确时间和天数,就可以快速完成所有用户故事的估算。

我们应该如何估点呢?

最常用的方式,就是我们把估算的单位分成1,2,4,8,16...等。有些团队则更喜欢用斐波那契数列(1,2,3,5,8,13)去估算。一旦用户故事准备好了,团队就可以开始先挑选一个代表最小复杂度的用户故事,然后把其他的故事与之对比。

例如,团队可能会把“用户登录”的故事估算2个点,而把“自定义搜索”故事估算4个点,那是因为它是“用户登录”故事工作量的2倍。用这种估算的方式,就可以得到所有的用户故事的点数。

谁应参加故事点数估算?

理想情况下,团队中只要是有职责完成用户故事的,就应该参加点数估算。团队中的测试人员应该参加故事点数估算,并且把用户故事中额外的测试工作量估算进去。

举个例子,我们的搜索用户故事,界面部分要支持2种新的浏览器,可能需要1个点的开发工作量,但需要大量的测试工作。这时,测试人员就需要指出来,把必要的测试工作量计入故事点数中。

在对用户故事进行估点时,应不应该做一个最好情况、最可能、最差情况估计?

这可以通过提供三个不同的点数来做到:最好情况点数、最可能点数以及最差情况点数。当在第一个交付期,还没写什么代码,又需要估计大量的用户故事时,这是非常有效的一种估算方式。这种方式,依据不同的假定结果,提供了一个点数范围。例如,“用户登录”故事,最简单的情况,假定我们需要和本地的LDAP系统集成,估计2个点;但如果假定是和第三方提供的系统集成,就成为最差的情况,估计是8个点。

我们如何用故事点数来计划一个项目?

如果要做项目计划,那么需要计算出团队大致的交付速率,即一个迭代整个团队能交付多少个点。典型做法是使用历史数据来预测,如计算过去3个迭代的交付速率平均值。

如果这是一个刚刚组建的团队,那么我们就需要做一个小练习。首先团队成员需要达成共识,在一个迭代里能够完成多少个用户故事。选取(已经估算过点数)一些故事样本,让团队找出可以在一个迭代内完成的故事,计算它们的点数和,这样重复若干轮。最后计算出每一轮完成故事点数的平均值,从而得出一个迭代的交付效率。

例如,两周为一个迭代,进行了三轮,结果是6,8和10点,那么就可以计算出8点就是我们团队大致的迭代交付速率:(6+8+10)/3=8。

这样,就可以假定我们团队在以后每两周,可以完成8个点,排出一个计划。

不同的开发团队,是否可以使用统一的故事点数基准?

不同的开发团队,对于故事点数有不同的度量基准,取决于各个团队所要估计的用户故事。除非他们是在开发相同的系统,否则团队A开发1个点的工作量和团队B在不同系统中开发1个点的工作量是不同的。这种差异将会影响团队的迭代交付速率。

如果有一个很大的项目,需要分成多个小团队来共同开发,人们很可能想去尝试定义一种点数标准应用到所有小团队。这有悖于估算用户故事点数的目的,每个小团队都会有自己的主观衡量标准。

我们如何估算试探性研究(Spike)的用户故事?

为了弄明白如何实现一个特定的功能,或者验证某种概念,我们需要试探性研究故事(Spike)。由于很难知道到底总共需要多少工作量,通常我们要提前在团队中达成共识,对这种研究做出一定时间限制。这些用户故事可是通过观察交付速率趋势图,转换成大致的点数。

例如,如果需要计划一周的时间来完成一个试探性研究,而交付速率是16个点(迭代周期为两周),那么就可以估算这个故事为8个点。

是否有一种方式可以计算每个点的成本?

每个点的成本可以如此计算:一个迭代的总成本/一个迭代完成的总点数。一些情况下,我们会有一个额外的迭代去准备发布或者是做回归测试,那么这个迭代的成本也应该被计算在内。

用户点数是否是团队不能估计出准确工作天/小时数的借口?

问这个问题,其实就是认为估计每个用户故事所需要的准确工作量和时间(开发天数/小时数),比用相对点数估算更好。而且,按开发天/小时数来估计,会给团队带来过度的压力。迫使在规定时间内交付用户故事,可能导致团队不能够达到一种匀速前进的状态,而是彻底累垮。

用户点数是否和业务价值有关?

用户故事点数是对实现用户故事所需要工作量的团队内部度量。无论如何,与用户故事所能提供多少业务价值没有关系。 很可能在同一个系统中,1个点数的用户故事会比4个点的故事有更大的业务价值。业务价值最好是留给产品经理和相关的业务决策者来衡量。

如果用点数来估计,我们如何知道团队的估算是否是在提升?

业界普遍认为,用人天数去估算工作量更加容易跟踪(估算比较准确的前提下),可以对比每个故事实际消耗的天数和所估计的天数。但是这种方式实际是反作用于工作效率的,因为迫于必须在预计天数完成的压力,团队会花好几个小时来估算很少几个用户故事,以确保每个故事都能有个准确预计的天数。

当团队的用相对的点数来估计的时候,就会慢慢形成一种趋势,开发相同大小点数的故事会有非常近似的开发时间。如果有个故事点数差得离谱,就会非常明显地暴露出来。

随着团队对所开发的系统更加得熟悉,开发人员是否应该修改故事点数?

如果用户故事A被定义为2个点,一个相似的用户故事B在几个月后开发也应该被估算为2个点。当团队完成故事A后,团队因为了解到更多,故事B可以很容易实现,这种情况应视为是团队交付效率的提升。

挑选最初估计时各个尺寸的用户故事,建立起一个“故事大小基准板”,作为估计新用户故事时的对比基准,是非常有帮助的。

本文分享自微信公众号 - 思特沃克(ThoughtWorks),作者:Anand

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-01-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【好文分享】别再提“估算”了

    估算一词具有某种特定的含义。 提到这词,人们就会联想到费用和时间。回想下你上次找技工为你修车,或找油漆工为三楼的窗子刷新油漆的场景。你正在考虑时间和费用,不是吗...

    ThoughtWorks
  • 速度(Velocity)不背这个锅

    不管是故事点还是理想人天的估算方法,估算的都是用户故事的相对大小,跟实际完成时间没有直接关系。估算是为了更好的计划,不能把估算当做一种承诺;速度是可变化的,可以...

    ThoughtWorks
  • TW洞见 | 估算的目的

    我第一次与敏捷软件开发的邂逅,是在极限编程刚刚兴起时,跟Kent Beck一起工作的经历。其中让我印象深刻的事情之一,就是我们如何做计划的方式。这里面包括一种估...

    ThoughtWorks
  • 软件正在重组世界 云端社区有望实体化

    Marc Andreessen 曾预言“软件将吞噬世界”,越来越多的传统行业被卷入到数字革命之中,我们的生活方式、社会结构经历着深刻的变化。Wired专栏作者 ...

    静一
  • MySQL通过内部XA事务,保持了binlog与redo log之间数据一致性

    参考:http://www.linuxidc.com/Linux/2015-11/124942.htm

    二狗不要跑
  • leetcode: 14. Longest Common Prefix

    JNingWei
  • Ajax+Servlet实现智能搜索框

    技术从心
  • 简单易学的机器学习算法——SVD奇异值分解

    一、SVD奇异值分解的定义 image.png 二、SVD奇异值分解与特征值分解的关系     特征值分解与SVD奇异值分解的目的都是提取一个矩阵最重要的特征。...

    zhaozhiyong
  • 【每日播报】ONOS预热篇之ONOS简介

    1 ONOS诞生背景 1.1 ONOS诞生的利益分析 随着移动设备的不断普及,OTT服务和内容分发的兴起导致服务提供商网络迫切的需要一次网络变革。为了应对日益增...

    SDNLAB
  • 使用Kotlin 和 Jsoup库实现一个极简的HTML Parser库《Kotlin极简教程》正式上架:

    当我们有了一个网页的源代码HTML,这个时候我们很想像在JavaScript中的DOM API一样操作解析这个页面的元素。

    一个会写诗的程序员

扫码关注云+社区

领取腾讯云代金券