TW洞见 | 是否使用故事点,并不是重点

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

我也算是一个“估算通”,有十年以上的估点经验,使用过功能点,用例点,构造性成本模型(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里,因为这样的故事大小更多地 反映了风险而不是复杂度。

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

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2015-02-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏人工智能快报

高通称其终端语音识别准确率达95%

高通公司人工智能研究人员表示,该公司正在研制用于智能终端的语音识别系统,通过综合采用循环神经网络和卷积神经网络,该系统语音识别准确率可达95%。

1151
来自专栏大数据文摘

深度学习趋势:云计算or高性能计算

2113
来自专栏大数据挖掘DT机器学习

在线学习行为分析建模及挖掘

在日趋精密数字技术条件下,学习模式已通过互联网、社会化媒体实现数字化。海量的学习信息以数据的形式蕴含着学习者的隐性行为特征。文章从数据挖掘与领域应用...

6826
来自专栏专知

深度学习为什么需要工业化标准

【导读】近日,深度学习作者Carlos E. Perez发表一篇博客,讨论了深度学习的工业化标准问题。我们知道,深度学习是当前AI领域的一个利器,其标准也不能照...

3785
来自专栏人工智能快报

IBM新软件为深度学习提供支持

“supercomputingonline.com”发布消息称,IBM公司正在利用其新软件为深度学习提供支持。 IBM发布了基于Power Systems平台的...

2773
来自专栏腾讯大讲堂的专栏

理解指尖上的浏览场景:从一次眼动测试说起

移动端产品的迅猛发展为用户提供了越来越多新的使用场景,设计者和运营者该如何理解这些新场景,打造贴近用户习惯的产品,成为至关重要的问题。本文以用户装饰QQ空间手机...

2277
来自专栏技术翻译

关于机器学习的顶级认证课程

什么是机器学习(ML)?根据斯坦福大学的说法,它是“让计算机在没有明确编程的情况下采取行动的科学”。

6402
来自专栏CDA数据分析师

想入门数据科学领域?明确方向更重要

我在一家数据科学培训公司工作。对于学员,我常常给出的建议并不是推荐库或者工具,而是让他们首先明确自己想成为什么样的数据科学家,确定自己的方向。

842
来自专栏ThoughtWorks

如何实现假设驱动开发 | TW洞见

今日洞见 文章作者来自ThoughtWorks:Barry O'Reilly,图片来自网络。 感谢ThoughtWorks校对小组:钟源、Adam、何璐、姚琪琳...

3538
来自专栏大数据文摘

机器学习的本质是人类学习?5大要素详解个性化推荐的商业化之路

2459

扫码关注云+社区

领取腾讯云代金券