PMI-ACP相关知识点——敏捷估算

各位参加PMI-ACP的考生大家好,今天来写一下关于敏捷估算的一些的内容。敏捷估算主要有两种度量方法:故事点数、理想日。但是并不是只有这个两个,比如说在《敏捷项目管理2019》中提到了价值点估算。只能说每个估算方法各有各的好处,项目主要说下故事点数和理想日两个。

首先,我们先来了解一些关键术语,有助于没看过教材的考生进行理解。

故事点数:故事点数指的是:用于表达用户故事、功能或者其他工作总体规模的度量单位。

用户故事:一个或多个给用户增加价值的商业需求,撰写用户故事所需的工作量相对较小。典型做法是将用户故事记录在故事卡上。

速度:对开发小组的进度率的度量。

我们知道了故事点数和理想日的大致意思,我们应该怎么样进行运用呢?

首先,推荐使用的是故事点数。具体有两种常见的方法:1、从小开始:我们可以从用户故事中找到一个团队认为最小的一个故事,定为1个点。然后拿这个故事为基准,推算其他故事的故事点数。2、折中法:从用户故事中挑出一个中等大小的用户故事,定为5个点,同理推算出其他故事点数。这里需要注意一点,在团队估算时,确认的故事点数并不是不可修改的。在使用故事点数的时候,有必要引入速度一词来判断故事点数的合理性。我认为:可以简单的用(故事点数/速度=迭代周期)的公式来进行判断。举个例子:团队将A的故事点定为10,但是团队速度为15。那么可以认为这个故事太小,没有必要单独进行估算。同理,团队将一个用户故事定为300点,团队需要20个迭代完成。那么我们可以认为这是一个史诗故事。并不是说不允许存在史诗级故事,而是应该和干系人一起拆分细化史诗级故事。史诗级故事之所以“宏伟”,个人认为还是信息不足导致的。在初始估算的时候是允许史诗级故事存在的,特别是那些还并不需要马上实施的特性,完全可以给一个300点的估算。但是要注意敏捷提倡的“渐进明细”的估算方法。

其次,我们可以使用理想日。理想日很好理解,我相信很多团队使用的都是“理想日”。这里为什么要使用双引号?这里就需要注意一下,这里的理想日指的是:如果没有什么事情干扰或引起分心的话,完成一项任务所需耗费的时长。而我们的“理想日”可能是加载了很多的其他事项。比如说:询问一个开发工程师完成这个软件多少时间。工程师可能回答15天。项目经理询问为什么要15天。答:因为先要完成手上的项目要花10天,然后才能写软件。包括一些日常的维护工作还要处理,所以大概到交付要15天左右。如果没有这些干扰我只需要2天就能完成。在这里2天就是理想日。

好了,我们了解了故事点数和理想日的具体使用方法。那么两个的区别在哪里呢?下面我们就说下两个估算方法的优劣势。

使用故事点数的优势有:1、故事点数有助于驱动跨功能的行为:这个是书上的说法,但是我认为太拗口。简单的说,就是在一个项目内标准统一,通用性高。比如说:贴一个100㎡的瓷砖,不管是A团队还是B团队,它都是100㎡。如果换为理想日,完成一个A团队三个理想日的贴瓷砖工作。A团队速度远远高于B团队,B团队需要6个理想日才能完成。2、故事点数变化性较小:简单的说除非更改了故事,否则很少会变更故事点数(不排除初始估算的不合理,如果规模不算不合理,换为理想日估算还是会估算为不合理)。而理想日可能受到的限制比较多,例如:环境、新技术等等。3、故事点对规模估算更加纯粹、估算更加快:这个也很好理解,如果说我把一个贴100㎡瓷砖的工作定为5个点,那么200㎡就是10个点。300就是15点。相比理想日,要考虑人数、熟练度、大小等等因素计算得出,3倍规模的故事理想时常并不是3倍。

使用理想日的优势有:1、在团队外更加的容易理解。这个也很好理解,比如说客户问你这个项目多少规模,回答10个理想日比10个故事点数容易理解多了。2、上手难度较低。按正常思维情况,估算一般都按小时/天开始。所以理想日的上手难度比较低一些,但是也仅限于初始阶段,在用了几次以后故事点数的优势还是远远高于理想日。


好了,写了那么多,如果给您选择会是选择理想日还是故事点数呢?

下一篇预告:估算方法

你可能感兴趣的:(PMI-ACP相关知识点——敏捷估算)