写点什么

对超高生产力的度量是浪费时间吗?

  • 2009-06-03
  • 本文字数:1424 字

    阅读完需:约 5 分钟

在一个关于超高生产力与电击疗法的演讲中, Jeff Sutherland 提到:超高生产力(Hyper-Productivity)至少应该达到丰田的绩效水准,也就是四倍于行业平均水平。他认为:正确进行敏捷开发的团队,应该可以在 3 个为期两周的迭代中体现出 300% 的进步。最近在 Scrum Development group 的讨论中,成员们争论有无可能准确度量多个 sprint 体现出来的生产力,以及这样做是否有益,还谈到是否有可能看出团队已经到达超高生产力状态。

Adam Sroka 认为要想度量多个 sprint 体现出来的生产力或工作效率很困难,甚至不可能。很多时候,团队的生产力建立在故事点数基础之上,而这个数字在各个 sprint 之间是不断变化的。他觉得:

故事点数未必可以比较,即使它们看起来是随时间推移不断稳定下来的(比如在迭代 1 中的 5 个故事点数与迭代 5 中的 5 个故事点数就没有可比性。不过,迭代 5 中的 5 个故事点数与迭代 6 中的 5 个故事点数就比较接近)。因此,一个敏捷项目在过程中体现出来的生产力提升类似于没有实际证据的轶事 。我们见过这样的状况,也知道它确实存在,但我们找不到确定的方式来度量它。

Tobias Mayer 同意 Adam 的意见,他也指出:

对“超高生产力”的度量纯属浪费时间——而且就跟卖“大力丸”差不多。对故事的估算不是一成不变的,团队交付软件的能力会随着时间推移提升,也会改变他们估算故事的结果。正如 Adam 指出的,对于同等复杂的故事,我们估算的准确度会越来越高。
我认为这样的“量化”会给 Scrum 造成伤害,正如最初的帖子指出的,如果你将底线设得足够低,所有的事情看起来像是达到了“超高生产力”。要是团队在第一个 sprint 中什么都没有完成呢?在此后的第二个 sprint 中完成的 1 个故事点数就像是增长了无数倍啊。真是荒谬透顶!

Joseph Little 指出:尽管很多关于“超高生产力”的谈话都是白费口水,“超高生产力”本身还是有意义的。他建议:团队应该知道自己的速度,这样才能不断改进。他也同意:速度可能会随着迭代的推进而改变,所以在不同 sprint 中,大小相同的故事可能分配的点数不同。要解决这个问题,应该计算 3 个 sprint 下来的平均速度,而不是就拿一个 sprint 中的速度来说事儿。接下来应该要做的,就是让团队的开发速度翻番了,这就需要对开发流程进行大大小小的调整,移除遇到的障碍,多多益善。Joseph 认为:

让我说得更明白点儿:软件开发这件事儿现在做得真不怎么样,要想让团队的工作效率翻番没那么困难。

Roy Morien 补充道:要想精确度量个人或团队的生产力,难上加难。因此,团队应该把注意力放在交付有效的、可工作的软件之上,力图改善上个 sprint 中做事的方法,而不是去考虑如何度量生产力。

与他的观点相同, Adam Sroka 指出:团队不应该浪费时间度量生产力、分析团队是否到达“超高生产力”状态,而是应该将焦点放在:

  1. 我们是不是正在交付有价值的、可工作的软件?是不是持续不断地、每个迭代都是这样?
  2. 我们现在是不是把精力都放在可持续的工作方式之上?我们能一直按照这个步调交付软件么?我们还能改进么?
  3. 我们有没有把精力浪费在对于直接交付价值没有贡献的事情上?我们应该怎么消除这些浪费?

综上,通过这些讨论,大部分人都认为:在敏捷开发中,相对于比较不同 sprint 之间的生产力数字以查看是否达到“超高生产力”状况,还有更重要的事情要做。而且,由于没有收集不同 sprint 之间生产力数字的标准计算方法,去比较这些数字也就不怎么靠谱了。

查看英文原文: Is Measuring Hyper-Productivity a Waste of Time?

2009-06-03 04:261086
用户头像

发布了 479 篇内容, 共 157.9 次阅读, 收获喜欢 49 次。

关注

评论

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

李飞飞力荐:阿里巴巴高可用数据库解决方案

博文视点Broadview

Perforce用户文章转载:用了P4这一招,九成问题能自救

龙智—DevSecOps解决方案

报错 perforce

Go语言逆向技术:恢复函数名称算法

华为云开发者联盟

二进制 函数 go语言 逆向分析 恢复函数名称

好习惯影响孩子的一生

Tiger

28天写作

Flutter 详解 CupertinoSegmentedControl 分段控制器

阿策小和尚

28天写作 0 基础学习 Flutter 内容合集 签约计划第二季 12月日更

Go语言学习查缺补漏ing Day6

恒生LIGHT云社区

golang 编程语言

大厂面试算法题之链表

程序员学长

2.react心智模型(来来来,让大脑有react思维吧)

buchila11

React

人人都能读懂的react源码解析(大厂高薪必备)

buchila11

React React Hooks

【量化】实战获取资产组合理论模型的数据源

恒生LIGHT云社区

资源 量化投资 量化

dart系列之:浏览器中的舞者,用dart发送HTTP请求

程序那些事

flutter 浏览器 dart 程序那些事 12月日更

【报名中】我们把你对 ShardingSphere 的好奇,都放在这场 Meetup 中

SphereEx

数据库 开源社区 ShardingSphere Meetup SphereEx

Android C++系列:Linux网络(二)通信过程

轻口味

c++ android 28天写作 12月日更

管人理事

张老蔫

28天写作

如果TGO是经纪人,我们会怎么办?(9/28)

赵新龙

28天写作

架构师实战营模块一作业

圈圈gor

「架构实战营」

第三天用 Mac,我安装了这些玩意

悟空聊架构

Mac 28天写作 悟空聊架构 12月日更

给弟弟的信第7封|离开大学的喜与悲

大菠萝

28天写作

基于MRS-Hudi构建数据湖的典型应用场景介绍

华为云开发者联盟

数据仓库 数据湖 华为云 Apache Hudi MRS-Hudi

通过接口上传文件到百度网盘

为自己带盐

28天写作 百度网盘 签约计划第二季 12月日更

高效设计一个LRU

bigsai

数据结构 算法 LRU

python scrapy极细拆解,打开Spider类看内容,顺手爬了一下优设网

梦想橡皮擦

12月日更

万众提供素材,万众联合创作

mtfelix

28天写作

前端面试题之模块化开发

@零度

大前端 模块化

API标准化对Dapr的重要性

行云创新

模块一课程作业

李晓笛

数据分析从零开始实战专栏导航@老表

老表

Python 数据库 数据分析 pandas 数据分析从零开始实战

了解 Flutter 的Timer类和Timer.periodic【Flutter专题19】

坚果

flutter 28天写作 签约计划第二季 12月日更

年度重磅!华为云2021应用构建技术实践精选集,免费下载!

华为云开发者联盟

数据库 大数据 云原生 数字化 华为云

java开发之java开发环境的快速构建

@零度

Java java开发环境

【LeetCode】二叉搜索树中的搜索Java题解

Albert

算法 LeetCode 12月日更

对超高生产力的度量是浪费时间吗?_研发效能_Vikas Hazrati_InfoQ精选文章