事情是这样开始的。。。

   这个sprint，我们挑选了4个story，并且每个story的point都是一样。PO看了很奇怪，因为在她看来有些story明显大于别的。我就给她把这些story不同的难点分析了一下，她大约理解了。不过在解释的时候，我特地提到一点就是有一个技术上的考虑，主要是考虑到比较后的一个story的需求，所以现在在架构上作了调整，确实比单纯完成这个story要复杂一些。这个话题我们并没有继续，但是我却自作聪明的解释了一下通常意义上3个point可以换算成2-3天，而5个point可以换算成3-5天。这下被抓住了...

  其实，想想看，还是自己不够专业，潜意识里还残留着传统项目管理的观念。正如公司负责流程优化的VP所言，敏捷里面不存在duration的概念，只有point，而point反应的只是story之间的相对复杂度，这个复杂度囊括了完成story需要的各项任务，是一个综合考量。

  我这两天一直在思考这个问题，因为自己对软件工程的度量属于长期思考加实践，包括复杂无比的功能点度量。我想VP误会我的意思，她可能觉得我在用duration作度量，其实不然，我只是分析了每个冲刺的结果，进行的换算，这两个是不同的概念，不过即使这样，对于一个在全公司负责推广敏捷的人来说也显得分外扎眼。

  敏捷强调的是对个人的尊重，它积极的排除了项目经理分配制，所有的任务都是各人自行挑选、安排。对于个一个story的大小，需要让每个人都心悦诚服，而非口服心不服。另外，敏捷一直强调自己是一个轻量级的过程，希望把很多管理上的事情简化。所以，故事点是一个比较好的选择，因为它反映的只是一个内心的感受，而非真实的结果。原因很简单，敏捷的人不需要精确的计划数据，因为反正会有需求变化，反正计划永远赶不上变化，与其浪费时间在细节的讨论上，还不如等到作的时候再说。对，所以我们在plan meeting的时候从来不决定task的时间，只有等到真正开始着手做了，等到需求再变要走变更流程了，我们才真正的拿出精力去思考到底需要多长时间来完成这个任务。即使这个任务和原先想的有出入，也未必就真的会影响到story的整体相对度量，因为一个story由多个task构成，说不定别的task变得复杂抵消了别的task难度降低的变动，这就是一种reconciliation。我相信故事点的提出，也是基于这样一种情境的假设。

  的确，传统的项目管理中对于duration的评估，是非常花时间的，耗费大量的成本。尤其是在做两个星期的计划时，想要提出duration，基本上已经想好代码量，测试case数量等等了。PMBOK里有一堆基本技术供参考，这里不予赘述。这些的基础都是基于需求稳定的情况。当然，变更是需要走综合管理的变更流程的。这些一套一套的都是敏捷所不齿的急于打破的。

  我想，正是由于这些地方水火不相容，才让故事点和duration的争论在业界也从未停歇把。因为，理论依据不同。

  综上所述，在plan meeting的时候，我们只需要考虑相对难度，尊重内心的直观感受，所以只要给出故事点就行；到了领取这个story下的task的时候，则需要给出一个时间，这个时间是一个承诺，每个人都应该非常慎重，即使如此，也不表示真正需要的时间是不能变的，因为敏捷的过程管理上不关心你的计划时间，因为那已经是过去，最关心的其实是完成这个任务还慎多少时间，因为这个时间点能决定后续的任务什么时候能接上，大家还有没有信心去完成这个story，毕竟不是一个人在战斗。