写点什么

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

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

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

关注

评论

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

膜拜阿里!首次发布「10亿级并发系统设计文档」(内部绝密)

退休的汤姆

阿里 面经 Java工程师 秋招 并发系统设计

毕业设计

Asha

QCN9074 WiFi 6E Card OpenWRT, IPQ6010,802.11ax,wallys,QCN9074 802.11ax 4x4 MU-MIMO 6GHz wifi6E

wallys-wifi6

IPQ6010 QCN9074

学习总结-网关 架构演进

C++后台开发

网络编程 API 网关 C/C++后台开发 C/C++开发

提升LED显示屏散热效果的7种方式

Dylan

LED显示屏 led显示屏厂家

【计算讲谈社】第九讲|“碳中和”时代下:计算的机会在哪里?

大咖说

计算 碳中和

兆骑科创创业赛事活动服务平台,投融资服务对接,政策申报

兆骑科创凤阁

刘伟光:超大型金融机构国产数据库全面迁移成功实践

OceanBase 数据库

建木持续集成平台v2.5.3发布

Jianmu

DevOps 持续集成 CI/CD 持续交付 gitops

RabbitMQ面试29连问,看完还过不了面试,我给你一Jio

小柴说Java

Java 编程 程序员 面试 架构师

大数据毕业设计

Geek_Q

OceanBase发布“珊瑚计划”,让合作伙伴成为OceanBase成功的关键

OceanBase 数据库

武汉java培训技术学习对学历的要求

小谷哥

华为被迫开源!从认知到落地SpringBoot企业级实战手册(完整版)

Java编程日记

Java 编程 程序员 面试 架构师

Vuex与前端表格施展“组合拳”,实现大屏展示应用的交互增强

葡萄城技术团队

Vue 前端 表格 vuex

RocketMQ面试33连问,答完面试官主动要给我提薪资待遇...

Java编程日记

Java 编程 程序员 面试 架构师

元宇宙里的下个社交时代

智捷云

元宇宙

私有化部署的低代码平台 更安全的信息化解决方案

力软低代码开发平台

2022 OceanBase 年度发布会:发布四大策略,迈入4.0时代

OceanBase 数据库

X-mask神秘面具NFT挖矿dapp系统开发逻辑详情

开发微hkkf5566

科普达人丨一图看懂阿里云ECS

阿里云弹性计算

云计算 IaaS 弹性计算 ECS

网易伏羲实验室入选信通院首批大模型优秀应用案例

网易伏羲

人工智能 网易伏羲

元老级的存储类型:块存储,性能很强!

wljslmz

8月月更 块存储

大数据编程培训课程怎么选择

小谷哥

深圳web前端培训费用多少?

小谷哥

哪家web前端培训班比较好

小谷哥

开源一夏 | 如何使用谷歌浏览器 Chrome 更好地调试

海拥(haiyong.site)

JavaScript chrome 开源 Google 8月月更

22年Java面试真题整理,一共343道,每一题都很经典,堪称秋招必备

Java编程日记

Java 编程 程序员 面试 架构师

解码微盟集团2022中报:SaaS收入5.81亿逆势增长,高质量增长路径更清晰

ToB行业头条

墙裂安利!用腾讯云AI语音合成打造自己的第一本有声书

牵着蜗牛去散步

腾讯云 腾讯 语音合成 技术实践 有声读物

前端培训班排名口碑怎么样

小谷哥

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