专栏首页ThoughtWorksTW洞见 | 是否使用故事点,并不是重点

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),作者:Juliano

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【好文分享】别再提“估算”了

    估算一词具有某种特定的含义。 提到这词,人们就会联想到费用和时间。回想下你上次找技工为你修车,或找油漆工为三楼的窗子刷新油漆的场景。你正在考虑时间和费用,不是吗...

    ThoughtWorks
  • TW洞见 | 敏捷开发中的故事点数

    什么是故事点数? 故事点数是敏捷团队估算用户故事使用的一种主观的计量单位。 故事点数代表了什么? 故事点数代表了完成一个用户故事所要付出的工作量。一些敏捷开发人...

    ThoughtWorks
  • 企业敏捷转型道路|洞见

    企业不敏捷就out了 很多企业已经走在敏捷转型的路上,首先始于电信和互联网公司,然后是金融行业,现在连零售这样的传统行业都在尝试转向敏捷。 从2001年敏捷...

    ThoughtWorks
  • SAP成都研究院安德鲁:自己动手开发一个Chrome Extension

    各位好,我叫何金鑫(He Andrew), 团队同事亲切地称呼在下为安德鲁。如果你在附近找到wifi热点名为 「安德鲁森面包房5g」,可能是我就在附近,我们可以...

    Jerry Wang
  • canvas动画-跟着鼠标移到的小球 原

    小球可以跟着鼠标移到,点击小球时会按既定的坐标移到小球(不再跟着鼠标移到),鼠标移出canvas,此时动画停止,鼠标进入动画时动画开始

    tianyawhl
  • 安全测试工具(连载1)

    在本书上卷中介绍了软件安全测试,本章介绍软件安全测试工具。软件安全测试工具不像性能测试工具,类型比较多,由于每个产品的功能比较多,本书仅对关键用法进行介绍,进一...

    小老鼠
  • MAVEN学习笔记之Maven插件的应用(4)

    王小雷
  • R语言做复杂金融产品的几何布朗运动的模拟

    几何布朗运动(GBM)是模拟大多数依赖某种形式的路径依赖的金融工具的标准主力。虽然GBM基于有根据的理论,但人们永远不应忘记它的最初目的 - 粒子运动的建模遵循...

    拓端
  • 【2020腾讯广告算法大赛】TI-ONE 平台内置框架操作案例

    2020腾讯广告算法大赛报名链接:https://algo.qq.com/index.html?rfisource=TICP0416

    腾讯智能钛AI开发者
  • DC综合5--基本的时序路径约束(上)

    时序约束可以很复杂,这里我们先介绍基本的时序路径约束,复杂的时序约束我们将在后面进行介绍。

    数字IC小站

扫码关注云+社区

领取腾讯云代金券