限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

我们应该停止使用故事点和速率吗?

  • 2012-12-19
  • 本文字数:1996 字

    阅读完需:约 7 分钟

敏捷社区的专家正在热议如何使用故事点和速率(Velocity),不少人对使用它们估算和度量总体进度产生了怀疑,打上了问号。大家普遍认为,产生问题的根本原因就是这些度量项往往不是挂羊头卖狗肉,就是浮于表面被误用,很少能用在刀刃上。

Joshua Kerievsky 详细记录了他使用故事点的经验,以及他们是如何粉饰太平的。在下面的这个例子中,他讲述了故事点走向恶性通货膨胀的过程。

2004 年的一天,Jim 想要团队加快开发速率。团队原本的平均开发速率约为每个迭代完成 52 个故事点。他们的开发速率可能有几个点的浮动,但总体保持着平稳。然而 Jim 要求团队“全速前进”。仅仅几周后,团队开发速率一跃攀升至 80 点!

我问一个同事这是怎么回事?

她用讽刺的神情看着我:“这几天在这儿打个喷嚏都算故事点。”我摇了摇头,吃惊地看着这个成熟的敏捷团队居然为了让自己看起来速率加快了,以迅雷不及掩耳盗铃之势膨胀他们的故事点估算。这可是我和两个优秀的 Industrial Logic 公司教练一起亲自培训、辅导并审核过的团队啊!

此次经历之后,我对故事点和开发速率计算的信心开始动摇了。

Joshua 还指出,用故事点来横向比较团队是非常拙劣的方式:

这些年来,我听过多个来自不同公司的经理这样问:“为什么 X 团队每个 Sprint 可以完成 24 个故事点,而 Y 团队只能完成 12 个呢?这两个团队规模差不多啊,究竟差别在哪儿呢?”

这些经理并没有把开发速率当成是团队独有的能力指标,而是掉入了一个常见的思维陷阱,把开发速率当成了绩效度量指标。

在 Joshua 的博客评论中,Bob Martin 大叔进一步确认了这一点:

许多团队确实在使用故事点时很挣扎。我遇到过有些团队的项目经理莫名其妙就要求团队加快速率,企图不劳而获,那么团队只能让故事点贬值。我也遇到过有的团队为了讨老板欢心捏造开发速率报表,因为老板更热衷于形式而非内容。对于这样的团队,其他的方法可能更靠得住些。

Scrum Alliance 邮件组的讨论中,Ron Jeffries 就批判了将开发速率作为度量项这一行为。

  • 开发速率可能并常常被误用。
  • 开发速率可能并常常被用于攀比。

尤其是这跟主流敏捷思想背道而驰。敏捷实施中,很重要的一点就是要通过优先级来决定先做哪些后做哪些,从而掌控项目,而非紧紧盯住数学公式并致力于让数字好看。

团队关注开发速率那么就并不再关注实际价值。我希望我没发明过开发速率,但我却这么做了。

沿着这个思路,他进一步做了详细说明:

我们发现这里的多数问题是关于如何改进估算,让它们更加精确的。当我们进一步分析,我们注意到团队会计划一个完成时间,然而他们会被催促着按时完成所有工作。看得出他们在度量团队预估的准确性。

我们发现产品负责人只会”遵循计划“,几乎不管不顾地分配任务。

只有当产品负责人能够创造性地使用待办事项列表,交付尽可能好的产品时,Scrum 才算物尽其用。我发现紧盯着估算对此毫无帮助。

Mike Cohn 最近发表了一篇博文,介绍了一个非常看重估算的客户的案例。援引这个客户的话:

首先,对我而言,至少为了做预算,我需要知道我们的估算可以和实际情况有多接近。当我问投资人要求追加投入时,如果我们只完成了承诺的二分之一,他们会觉得这是个无底洞。我会处理这些情况,但我需要知道我们有个合理的途径来获得一个初步的估算。第二,为了筹集后续资金,我需要了解大概的数目(这是一项需要不少前置时间的活儿)。如果估算和实际情况相差甚远,我们就不得不改进,随后我会去开辟获得资金的渠道。也就是说,没有免费的午餐,钱不可能无缘无故从天而降。我必须有某种水平的度量来反映损益情况并贯穿项目始终。换句话说,我得在项目过程中盯住燃尽图,关注项目成本。

Vasco Duarte 提出了一个故事点的代替方案通过统计故事数量来做来估算

如果是估算以及监控那些长期项目(提示:这只适用于长期项目,例如在未来至少有三个以上 Sprint),你可以假设所有的故事大小都一样,因此就可以通过度量每个 Sprint 完成的故事数量来跟踪进度了。

Mike Cohn 也提出来类似的观点:

我承认用看板的团队相对较少做很具体的估算。这往往是由于他们已经默认了所有的工作的规模都相当的缘故。

Neil Killick 提供了另一种不需要估算的定价方式。他以自己做网站的例子做比照。他的供应商会根据公布的可用预算给出最可能实现的方案,而 Neil 如果在任何一点上感到不满意,随时都可以选择终止合作。

他认为,这个选择

不需要估算。随着项目推进,不断改进设计、慢慢成形。它拥抱变化,因为我看得到网站的进展。并且这种模式也体现出我的供应商公司很期待和我密切合作,达成我想要的结果。这种方法也正是为面对特殊风险(按合同规定会亏钱)而准备的,因为他们对自己完成工作的质量信心满满,对他们和客户建立的良好关系坚信不疑。

你有没有发现类似开发速率和故事点估算在团队中助长了不良作风的事情呢?对于社区专家提出的代替方案,读者,你怎么看?

查看英文原文: Should we stop using Story Points and Velocity ?

2012-12-19 09:052506
用户头像

发布了 114 篇内容, 共 36.9 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

Hybrid技术的下一站是什么?

FinFish

Hybrid 小程序技术 小程序容器技术 Hybrid App

华为与二十多家伙伴达成游戏先锋合作,共筑鸿蒙生态繁荣

最新动态

一条SQL如何被MySQL架构中的各个组件操作执行的?

砖业洋__

MySQL MySQL架构 MySQL优化器 MySQL执行器 MySQL存储引擎

golang trace view 视图详解

蓝胖子的编程梦

golang Profile pprof Trace go tool

使用TransBigData快速高效地处理、分析、挖掘出租车GPS数据

TiAmo

数据可视化 交互式可视化工具 TransBigData

以数驱动 | 智能分析云助力流程制造行业绿色高效运营

用友BIP

智能分析

亚信科技AntDB数据库与库瀚存储方案完成兼容性互认证,联合方案带来约20%性能提升

亚信AntDB数据库

数据库 AntDB AntDB数据库 企业号 8 月 PK 榜

平台赋能技术创新,和鲸科技持续助力气象顶尖算法大赛

ModelWhale

人工智能 算法 气象 大气科学 在线编程

华为阅读与商务印书馆达成全面合作 携手传承中外经典名著

最新动态

软件测试 | Java设计模式——适配器设计

测吧(北京)科技有限公司

测试

C4D软件都应用在影视后期什么领域?

Finovy Cloud

解锁Spring组件扫描的新视角

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 8 月 PK 榜

实时入库不用愁,HStore帮分忧

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 8 月 PK 榜

什么是CAE软件?哪个CAE软件好用?

智造软件

CAE 仿真软件 CAE软件

利用uplugin对比Webpack和Rollup插件系统

OpenTiny社区

前端

速度提升10倍,腾讯基于Iceberg的数据治理与优化实践

腾讯云大数据

数据湖

软件测试 | Java接口的实际应用—制定标准

测吧(北京)科技有限公司

测试

软件测试/测试开发丨Python 内置库 日期与时间处理

测试人

Python 软件测试 内置库

技术创新、鸿蒙赋能,华为阅读带来全新商业机会

最新动态

搭载KaihongOS的工业平板、机器人、无人机等产品通过OpenHarmony3.2 Release版本兼容性测评

极客天地

AI概念引爆ChinaJoy,聆心智能助力数字娱乐产业新应用

硬科技星球

仅使用 CSS 创建打字机动画效果

互联网工科生

CSS JavaScript 前端

软件测试 | Java抽象类的实际应用——模版设计

测吧(北京)科技有限公司

测试

杭钢集团:以一体化管控赋能为引领提升五大能力

用友BIP

数智化转型

Hybrid App 性能优化的一些技术探讨

Onegun

性能 Hybrid

常见的CAE软件有哪些?

思茂信息

仿真软件 仿真技术 abaqus有限元仿真 CAE软件 结构分析软件

软件测试 | 设计模式——代理设计

测吧(北京)科技有限公司

测试

我们应该停止使用故事点和速率吗?_研发效能_Anand Vishwanath_InfoQ精选文章