菜单

是否使用故事点,并不是重点

我曾经连续做过三个项目,没有对用户故事估点,而仅是简单的计算用户故事数量。我非常倡导这种方法,接下来我来解释下为什么。

我也算是一个“估算通”,有十年以上的估点经验,使用过功能点,用例点,构造性成本模型(COCOMO),故事点等进行过估算。随着时间流逝,我渐渐感觉到在早期估计的越多,反而估计的越不准确。除此之外,耗时的、所谓的“科学”的估点实践,往往会对需求的确定性产生错误的期望。下面这个场景是否很熟悉?

PM:你原来的范围是100个点,但是现在变成130个点了,所以你们要砍掉30个点以确保能够按照原定的时间发布。

客户:但是范围并没有变啊,从一开始就是这30个故事,没有变化啊!

PM:是的,但100个点已经变成130个点了,因为我们现在对复杂度有了更多的了解。

客户:但这是同样的范围和业务目标啊,我们并没有改变什么。等等,我不觉得这个故事值5个点,我觉得它更像3个点。我们重新过一下之前的估算结果吧……

我们都知道这个场景是什么样的,业务人员觉得被我们“膨胀”出来的点愚弄了(在他们看来,这跟范围无关)。

在过去的三个项目里,我计算了平均一个点所需要的天数及用户故事的标准差。然后,再计算平均一个故事所需要的天数及标准差,结

现在,我更倾向于使用下面两种方法和客户沟通:

1. 在确定发布范围时,不是依据用户故事来确定,而是依据我们将要达到的业务目标和交付的特性确定。

故事点数代表着三个方面的范围:

(1)特性/功能

(2)丰富程度/可用性/深度

(3)技术复杂性

然而客户通常只考虑第一点。当因为另外两点,我们说“范围增长”的时候,客户往往迷惑不解,因为他们觉得自己的业务目标并没有改变。

2. 依据我们预测可以交付多少个故事来讨论范围,并规定所有的用户故事不能超过某个阈值(X天)。

举例来说,当发现一个故事的交付时间可能要超过X天时,团队就不要去开发这个故事。所以,如果“范围”(上述三方面之一)增长时,故事就要拆分,排在最后面的就要丢弃。

这种方法不仅仅使这种沟通更为顺畅,而且能够让人们关注于简化后两方面的需求——它们并不“直接”与业务目标挂钩。这样以来,客户实际上得到了更多他们所认为的“范围”(特性/功能);而我们则不用陷入无休止的关于点数和尺寸的讨论中。

总结

我的确认为,团队采用估算的方法是一个逐步演进的过程:

1. 按工作量(天,周等)来估计

2. 按点数来估计(用例,故事点等)

3. 按故事/卡片数量来估计。为了让这种转变更为顺畅,我通常会说,“让我们假设所有故事都是3点,如果不是,就拆分。”,然后用3乘以故事数目。这种方式引导团队走向正确的方向——使用更小的工作单元,更易做到持续交付。

4. 彻底抛弃估算,持续交付,关注交付周期(cycle time)。

要迈向一个新的阶段,必须要得到相关决策人的认同。我曾经跟客户有过非常开诚布公地讨论,“我们可以一直玩这种点数游戏,但最终您的业务目标无法达到,您更愿意采取哪一种方法呢?”有时,他们不置可否,还持续在点数上做斗争,所以就这样一直争,直到某一天我们能改变这种情况为止。

常见问题:

我喜欢用交付周期和特性做度量。但是,在交付周期趋于稳定之前那段时间(通常很长)你如何处理?

 

没有银弹。(预计的)交付速率(velocity)或者(预计的)交付周期可以帮助你预测在一定时间内,可以交付多少。

1.     如果故事大小各异,那么我常常会与开发人员模拟两三个迭代,问他们可以交付哪些用户故事,通过计算每个迭代所交付的总点数,推算出每个迭代的交付速率。

2.     如果故事的大小都差不多,我会只计算故事的数量,并让开发人员估计一个故事需要多长时间能完成开发(dev cycle time)。然后通过

(开发人员数目x 给定的工作天数)/估计的交付周期

来推算出我们能够完成多少用户故事 (需要考虑到关键路径以及故事之间的相互依赖)。这种方法也可以用来验证交付速率。

论如何,我都会询问客户对于现有已知的范围和复杂度,他们所看到的交付风险;他们对当前用户故事的理解是什么?有哪些未知的工作?他们觉得应该预留多少点/故事/范围预防风险?我通常的经验是,0-10%的预留是不现实的,20-30%是可以接受的,如果项目中一切都是未知的则需要大于30%的预留。然后他们会提供一些数据,我会给出一些建议。当一些未知的事情逐渐摆上台面时(故事数量或点数发生变化),往往更容易展开相关对话。

在做发布计划的时候,我一般会使用与业务产出目标相关联的史诗故事(epic)或者特性(feature),然后将它们拆分成用户故事,并检查拆分出的用户故事是否真正能带来相应的业务价值。

因此,用户故事的选择性淘汰就会很自然地发生。当这一切趋于稳定的时候,我会开始持续交付和交付周期相关的沟通。

 

每个人都建议你将用户故事拆分成同等大小,但我发现通常这些故事之间还是会有不小的差异。你做到了均等地拆分了吗,还是你觉得无所谓?

某种程度上,我认为其实无所谓。我发现这种差异从0.33天/点到3天/点不等,而且越后期的故事,相对于点数所意味的复杂度,越显得简单(因为有了更强的确定性)。这种落差令我深思。从项目范围管理的角度讲,单纯的讨论点数并没有实际价值,因为我通过计算故事的数目一样可以得到大概相同的结果(如上图)。并且这种只计算故事数目的方法,还不会让客户对我们已经确认的东西产生错误的期望。

如果某些人还是怀疑上述这种观点,那么试试“把每个故事标为3个点(我假设平均起来每个故事大概是3个点),这样就不会有差异了”。这种方法用起来效果就好像我们要争论2个点和3个点之间的差别一样好(或者坏)。而且,我不会把大于8个点的故事(或者需要多于5天才能完成的故事)放到backlog里,因为这样的故事大小更多地反映了风险而不是复杂度。

对于我来讲,估算会议的价值在于让整个团队对于项目范围,解决方案,风险和复杂度有个整体统一的认识,因为不同的人在讨论和评估同一个故事时,所理解的点和大小是不同的;并不在于最终所得到的实际数字。