各位参加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、上手难度较低。按正常思维情况，估算一般都按小时/天开始。所以理想日的上手难度比较低一些，但是也仅限于初始阶段，在用了几次以后故事点数的优势还是远远高于理想日。
好了，写了那么多，如果给您选择会是选择理想日还是故事点数呢？
下一篇预告：估算方法
