写点什么

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

2012 年 12 月 19 日

敏捷社区的专家正在热议如何使用故事点和速率(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:051301
用户头像

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

关注

评论

发布
暂无评论
  • 第 22 讲 | 验证研发团队价值的绩效考核机制

    我们需要有一套合理的绩效考核机制,衡量并验证自己的价值。这套机制需要简单易懂、操作方便,而且需要通过数据说话。

    2018 年 5 月 22 日

  • 构建产品需要多久?

    这是客户常常提出的问题,也是让敏捷团队感到不爽的问题。一方面,在没有开始动手前就估算整个产品功能的工作量,等于无头苍蝇到处乱撞。然而,很多情况下,这是一个很现实的问题,团队不能将其抛在脑后。

  • 当敏捷团队遇上固定价格合同

    固定价格合同很有害,这是敏捷实践者经常说的。从另一个角度来说,这些合同是很多敏捷团队必须面对的现实。但是,如果我们试着去驯服它而不是去反对它,那结果又会如何?一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险?这篇文章试图回答这些问题。

  • 对于有经验的团队,有没有一种更好的估算方法?

    软件估算的结果对于利益关系人进行人员和预算安排而言是很重要的。敏捷中,流行最广泛的估算技术就是基于共识的计划扑克。这种估算方式是不是太花时间了?对于有经验的团队,是不是有别的可供使用的估算方法呢?

  • 第 43 讲 | 通过积分考核提升技术团队的绩效

    技术团队考核一向是个大难题,合理的考核机制加上奖励制度,能极大激发团队成员的热情,提升团队效率,本文将跟大家分享一个综合了不同考核方法优点的方法——积分制。

    2018 年 6 月 27 日

  • 敏捷团队应对打扰的七种方法

    每个团队都必然会遇到工作被干扰的情况,如果不能合理应对,那么很可能会影响到团队的交付能力。最近,在Agile Advice网站上,Mishkin Berteig发表了一篇文章,讲述了当Scrum或者其他一些采用迭代方式的敏捷团队遇到工作被干扰的情况时,可能可以采用的七种应对方法。

  • 测算团队,而不是个人

    最近,Michael Dubakov提出了针对个人开发速率和个人估算准确率进行测算活动的警告。他的观点是:由于已经有了针对团队的等价物,对于个人的测算标准和活动不但无法获取更多有价值的信息,而且有可能使得团队做出影响生产力和效率的行为。

  • 第 162 讲 | 王海亮:提升技术团队效率的 5 个提示(上)

    清晰你当前的团队和所做的事在哪个度上,再根据不同的度选择最适用的方法。

    2019 年 1 月 23 日

  • 专访软件交付专家 Doc Norton:速度和更好的指标

    速度不适用于预测或诊断。它是一个过于波动的复杂系统的滞后指标,无法知道我们未来的表现如何。

  • 出色的速度

    Buddha Buck最近向Extreme Programming讨论组提出这样一个问题:对于由7个人构成、迭代持续两周的团队,速度处于什么范围才算是“出色”呢?在他看来,少于或等于8点的速度就表示团队的故事可能太大了。由此引发的讨论提供了一些答案,还揭示出问题背后的问题。

  • 效能度量:效果不好甚至有副作用,怎么回事?

    我分析了度量难题的几个原因,并列举了三个失败案例,希望能对你有所启发,并避免再犯类似的错误。

    2019 年 8 月 26 日

  • 第 85 讲 | 游舒帆:敏捷力,拥抱不确定性,与 VUCA 共舞

    当所有部门都正确理解了敏捷,而非把敏捷视为研发团队的责任,企业才可能真正敏捷,面对多变且不确定的环境时,才能同舟共济,以达成目标为首要。

    2018 年 9 月 11 日

  • 测试左移:测试如何应对新的开发模式?

    测试左移,指的是将测试向左扩展,让测试介入代码提测之前的部分。

    2019 年 9 月 30 日

  • 为什么有些公司敏捷实施不成功?

    常听说有公司实施敏捷失败?本文研究探讨了那些经常被忽视,却导致敏捷实施失败的组织级原因,也讨论了为什么这些组织级原因并不是很容易能发现,并提出了一些处理此类组织障碍的潜在策略。本文的目标读者是负责预算的管理人员,尽管技术人员可能也会对此感兴趣。

  • 敏捷项目估算:什么是故事?什么是点数?

    有没有想过在敏捷项目中我们该如何以及为什么要进行估算?在David Morris为InfoQ写的第一篇文章中,他描绘了自己从90年代以来的经验和其它几位主要敏捷作者的论述,对敏捷估算这个话题进行了探讨:它是什么?我们通常怎么做?为什么要做?对#NoEstimates(不要估算)争论的简要评价,以及最后为初学者提出了一些建议。

  • 书评与访谈:Software Development Metrics

    《Software Development Metrics》的作者是Dave Nicolette,这本书对如何使用度量指标来跟踪和指导软件开发进行了探讨。它解释了不同的开发方法和过程模型,比如传统的基于瀑布式或者迭代敏捷软件开发,是如何影响度量指标的选择和使用的。它还描述了一些可以用于指导工作和管理改进的度量指标。

  • 比较不同团队的速度毫无意义

    敏捷项目管理中经常被诟病的一点是:由于故事点因团队而异,所以无法确定一个团队相较于其它团队在进度上的快慢。敏捷人士们普遍认为:比较团队间的速度并非明智之举,作为一种反模式,大家最好敬而远之,免得祸及总体生产率。

  • 为什么说软件估算现在前所未有的重要

    当前人们日渐疏远传统的瀑布式开发,并转型为敏捷开发方法。有观点认为,开发中已不再需要做软件项目估算。这个观点看上去合情合理,但并不正确。实践中,即便是那些已经采用敏捷方法的企业,软件估算依然十分有价值。

  • 敏捷中的不良观点

    Christopher Goldsbury考察了一些敏捷中的“不良观点”——一些常见的关于管理、文档、测试、团队及进度的论断,但这些论断与事实不符。这些不良观点在敏捷中寻找庇护和辩解理由,尽管事实上这些观点是不正确的。这些观点可能会把健康的敏捷运动弄糟,因此在此之前纠正它们是很有必要的。

  • 估算工具箱​

    不论你开发的是哪种类型的软件或你所在公司的规模大小,你都可能需要为某人提供估算。​敏捷团队能运用许多技术来指导他们的​投入估算。本文中描述的估算工具包中包含一些​新奇的方法,用于敏捷软件项目估算,这将帮你回答一个问题——“我们什么时候能够完成?”。

发现更多内容

如何基于 OAM 编写一个扩展 Trait?

钱王骞

云原生 k8s OAM

大中台模式下如何构建复杂业务核心状态机组件

奈学教育

中台

Kafka零数据丢失的配置方案

奈学教育

kafka

[架构师训练营] Week01 - 食堂就餐卡系统设计

谭方敏

学习

做产品少走弯路:上帝视角(2)

我是IT民工

产品 方法 路径 知识体系

机器学习算法评估指标—2D语义分割

做技术BP的文案Gou

学习 2D 评估标准 语义分割

2020年5月云主机性能评测报告

BonreeAPM

云计算 服务器 公有云 机房 云主机

原创下载 | TDD工具集原创开源代码免费下载!

编程道与术

Java 开源 TDD 下载 代码

由一次管理后台定时推送功能引发的对RabbitMQ延迟队列的思考(一)

LSJ

Java RabbitMQ 延迟队列

2w字长文!手撸一套 Java 基础面试题

cxuan

Java 后端 Java25周年

Zookeeper Watcher 流程分析(结合源码)

CoderLi

Java zookeeper 源码分析 后端 Watcher

SpringMVC中Http请求方式转换(post转换为put/delete等方式)

知春秋

springmvc post post到put方式请求 post到delete方式请求

如何用日记提升写作能力?

石云升

学习 方法 写作

架构师训练营作业(第二周)

王海

极客大学架构师训练营

迄今为止讲解最详细的Tomcat架构解析与JVM、GC详解及调优文档

周老师

Java tomcat 程序员 Web

Libra白皮书解读

程序那些事

区块链 facebook 数字货币 libra

Zookeeper 序列化

CoderLi

Java zookeeper 源码分析 后端

Libra教程之:Libra协议的关键概念

程序那些事

区块链 libra blockchain 协议

游戏夜读 | 如何面对前景渺茫?

game1night

面向对象的三个基本特征(要素)

彭阿三

三要素 三个基本特征 封装、继承、多态

ZooKeeper 数据模型:节点的特性与应用

CoderLi

zookeeper 源码分析 数据模型 节点

食堂就餐卡系统架构设计文档

dony.zhang

拙见/ 什么是自驱力?

ZoomQuiet大妈

自我提升 大妈 是也乎 IMHO 蟒营®

游戏夜读 | 如何制作游戏?

game1night

自由是不是随心所欲?

Neco.W

个人成长 自由 控制

小师妹学JavaIO之:NIO中那些奇怪的Buffer

程序那些事

io nio Java 25 周年 小师妹 buffer

互金总结系列(1)--开篇

互金从业者X

大中台模式下如何构建复杂业务核心状态机组件

古月木易

副业月赚 10 万的程序员是如何做销售的?

非著名程序员

程序员 独立开发者 程序人生 提升认知 程序员成长

Java 序列化

CoderLi

Java 程序员 后端 序列化

Zookeeper-Access Control List(ACL)

CoderLi

Java zookeeper 源码分析 后端

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