敏捷故事点与时间

在Scrum培训中，经常有人问：故事点和时间怎么对应？忘记了那本书上曾经有个大牛举了个例子，把系统中最简单的一个功能时间作为故事基准点，比如一个网站登录功能，从开始到发布大概需要8小时也就是1个人天作为故事点。于是，在很多公司中默认以此为基准点。在之后的敏捷计划会议上直接用时间进行估算，甚至干脆把敏捷扑克中的一个点作为一个小时，反正自己知道这是个1：8的关系。

Mike大叔，曾经就此专门撰文指出：故事点和小时之间不存在等价关系；

或许我们可说，点数是工作量、风险和不确定性的函数，SP＝f(E,R,U)。重要的是，点数是关于工作量的估算。风险、不确定性、复杂度、未知因素以及其他相关的事，仅当他们会影响工作量时才应被包含进去。如果某些事确实很复杂，但却不会影响实现特性所花费的时间，那么复杂性就不应该对估算产生影响－这才是故事点。原文参见链接（

https://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours）

在Scrum中故事的作用有如下几点：

1 引起团队和PO之间的讨论，对于一些商业开发来说故事可以最为技术人员和客户沟通的桥梁，自始至终他们可以使用互相理解的语言进行沟通

2 故事是敏捷角色和仪式之间的唯一串联

3 故事能够充分的展示价值

4 相对估算，由于大部分的PO或者互联网中的产品经理并非技术出生，因此很难根据故事来估计绝对规模，事实上即使是开发人员也很难估计准确，但在相对规模上却可以估算的比较精确，至少可以估计。

例如以登录功能为1个故事点，那么搜索功能呢？PO可能会计算页面复杂度是登录的3倍工作量，搜索算法也比登录复杂可能是3倍工作量，那么搜索就是6个故事点，不管如何起码PO能有一个基准。

在这一步中完全没有使用的时间。

接下来如何使用故事点来替换时间做到项目的监控和计划的调整呢？

在一个Sprint计划会议上，绝大多数的团队会把故事拆解为任务，而任务的估算使用的是时间，假如我们选定了20个故事点进行开发，之后把他们拆分为任务并且估计每个任务的时间，再然后Sprint正常进行，每天燃尽图会根据任务进行的情况来更新，伪敏捷的典型方式是燃烧事件或者人天，我甚至在某知名软件里面看到过燃烧小时的机制。时间和人天的燃烧并不能给项目提供任何帮助，在固定迭代人天和工时是固定的，这个迭代差3个人天和5个小时反映不出任何有用信息，敏捷开发是以经验为模型的，我们期望的是上个迭代能给下给迭代提供参考信息，相反我们在上个迭代完成多少故事点（纵坐标为故事点数）却是可以作为参考的。一个长期稳定的团队的故事点一定是如下图所示的，也就是说每个迭代能完成多少故事是可以推算的，基于这种方式我们能看到项目的终点大概在什么地方。

到目前位置时间也没有显示想象中的巨大作用。

最后一个问题，如果我没有基准，那么怎么填满第一个迭代呢？不是还得依靠时间吗？应对第一个迭代一般有两种方式，一是通过分解任务直到填满第一个迭代，这个时候确实会和时间产生关系，但下一个迭代就会以该迭代的完成故事点进行任务规划，从此与时间无关；第二种方式是选取较多的故事点，第二个迭代以第一个迭代完成的故事点作为依据选择故事，有人以历史项目数据为基准进行选择其实也是一样的原理。

其实在整个的敏捷开发过程中，时间真的是无关紧要，所以请忘记时间，使用故事点吧，不仅计划会更精确，而且更具有追溯性。