“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:052018
用户头像

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

关注

评论

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

祝福加载中,签收你的新年好“饰”! 老庙与你共启“富余年”

科技大数据

初识TiDB Data Migration迁移工具及实践

TiDB 社区干货传送门

迁移 7.x 实践

零售业海量场景下 ToC 系统的数据库选型和迁移实践

TiDB 社区干货传送门

实践案例

PingCAP 故事|势高,则围广:TiDB 的架构演进哲学

TiDB 社区干货传送门

质量管理QMS系统实施的好处是什么?

万界星空科技

质量管理 万界星空科技 QMS 质量管理QMS系统 生产质量管理

喜讯!云起无垠上榜《CCSIP 2023中国网络安全行业全景册(第六版)》

云起无垠

软件公司定制开发的软件有哪些?

天津汇柏科技有限公司

软件开发定制

关于如何优化TiDB中的写热点问题

TiDB 社区干货传送门

实践案例 7.x 实践

为什么说TiDB在线扩容对业务几乎没有影响

TiDB 社区干货传送门

TiDB 底层架构 数据库架构选型 TiKV 底层架构

用 Footprint 的交易类型标签揭秘链上交易

Footprint Analytics

区块链 加密货币

打造工业4.0的5G+边缘云服务产业生态,艾灵完成1.5亿元A轮融资

Geek_2d6073

构建 Streaming Lakehouse:使用 Paimon 和 Hudi 的性能对比

Apache Flink

大数据 flink 实时计算

揭秘C语言的心脏:深入探索指针与数组的奥秘

不在线第一只蜗牛

Java C语言 开发语言

TiDB 在全球头部物流企业计费管理系统的应用实践

TiDB 社区干货传送门

实践案例

基于生成式人工智能的平台 Cognizant Flowsource™ 发布,旨在为现代工程提供动力

财见

Java 程序员的待遇为何一直居高不下?

伤感汤姆布利柏

从 20 多套 MySQL 到 1 套 TiDB丨骏伯网络综合运营管理平台应用实践

TiDB 社区干货传送门

实践案例

签约勃肯BIRKENSTOCK 第七在线助力智能商品数字化管理

第七在线

火山引擎边缘云2023年度回顾,挑战与创新的交响乐章

火山引擎边缘云

边缘计算 火山引擎 火山引擎边缘云

MES和QMS怎么选?

万界星空科技

mes 万界星空科技 QMS 质量管理QMS系统 生产管理

WMS仓储管理系统的作用是什么?

万界星空科技

wms WMS仓库管理 万界星空科技 扫码出入库管理

【服务器搭建】快速完成幻兽帕鲁服务器的搭建及部署【零基础上手】

恬静的小魔龙

服务器 幻兽帕鲁

如何通过ETL实现快速同步美团订单信息

RestCloud

美团 ETL 数据集成工具

作业帮 x TiDB | 多元化海量数据业务的支撑

TiDB 社区干货传送门

每日一道Java面试题:说一说Java中的异常

EquatorCoco

Java 面试 前端 开发语言

TiDB 事务心跳超时机制测试

TiDB 社区干货传送门

故障排查/诊断

使用无代码/低代码平台进行开发的 5 大挑战

NocoBase

开源 低代码 低代码开发 无代码 无代码平台

京东物流基于 StarRocks 的数据分析平台建设

StarRocks

数据仓库 StarRocks 数据分析平台

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