写点什么

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

  • 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:052477
用户头像

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

关注

评论

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

借助 NGINX 实现 QUIC+HTTP/3 对 OpenSSL 的支持

NGINX开源社区

nginx API openssl HTTP/3 QUIC TLS

实时数仓Hologres V2.2发布,Serverless Computing降本20%

阿里云大数据AI技术

大数据 阿里云 实时数仓 hologres

Microsoft Office LTSC 2021 v16.86最新许可证版 office2021mac资源

Rose

网络的下一次迭代:AVS 将为 Web2 带去 Web3 的信任机制

TechubNews

科普:嵌入式代码软件在环(SiL)测试的可靠性

DevOps和数字孪生

嵌入式 SiL

高清视频下载器4K Video Downloader Plus,适用于macOS和Windows系统

Rose

QLab Pro v5.4.0激活版 mac演出控制软件

Rose

多种类型的思维导图 Simplemind pro for Mac v2.4.0中文激活版

Rose

视频如何转换为mp3格式?4K YouTube to MP3 for Mac(在线视频转Mp3软件)中文版

Rose

文献解读-农业系列-第八期|《有害突变在多倍体棉花中积累速度快于二倍体棉花,且在亚基因组间不平衡》

INSVAST

基因数据分析 生信服务

一文带你搞清楚Python的多线程和多进程

华为云开发者联盟

Python 华为云 华为云开发者联盟 企业号2024年6月PK榜

快速删除Win10、Win11恼人的英文键盘

程序员与厨子

windows 键盘 输入法

深度解读数据库引入LLVM技术后如何提升性能

华为云开发者联盟

数据库 华为云 华为云GaussDB 华为云开发者联盟 企业号2024年6月PK榜

【论文速读】|当LLM遇见网络安全:系统性文献综述

云起无垠

网络安全 大语言模型

电商商品数据采集的智能化:淘宝/天猫商品详情API接口的AI应用

技术冰糖葫芦

API Explorer API 接口 API 策略 pinduoduo API

PS亮度蒙版工具 Lumenzia for Mac 支持ps2024 v11.7.7最新版安装

Rose

苹果mac电脑 全新的macOS 15.0测试系统发布,快来体验一下吧!

Rose

A Better Finder Rename(ABFR):Mac平台上的批量重命名工具

Rose

专门为Mac用户设计的强大视频下载工具:iTubeGo YouTube Downloader

Rose

JetBrains WebStorm 2024激活码永久使用 JavaScript开发工具

Rose

项目管理软件ClickUp - 使用技巧分享 | 5款替代软件推荐!

彭宏豪95

效率 项目管理 职场 在线白板 办公软件

NFTScan 正式上线 Sei NFTScan 浏览器和 NFT API 数据服务

NFT Research

NFT NFT\ NFTScan

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