10 月 23 - 25 日,QCon 上海站即将召开,现在购票,享9折优惠 了解详情
写点什么

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

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

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

关注

评论

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

Linux RPM包安装、卸载和升级

芯动大师

设计模式-责任链模式

开发者眼中的向量数据库应用领域

三掌柜

亚马逊云科技

超越服务器:VPS 在开发领域的崭新前景

E₀=mc²

AWS 虚拟化 亚马逊 Amazon Lightsail

鸿蒙组件化构建

SkyFire

鸿蒙 OpenHarmony

合成数据如何改变制造业

3D建模设计

机器学习 机器视觉 合成数据 人工自能 合成数据生成

稳定扩散AI 纹理生成器

3D建模设计

AI Stable Diffusion AI自动纹理 AI 绘图 AI贴图

Macos数据备份工具:BeLight Get Backup Pro 3 附 注册机

繁星

数据备份 数据备份工具 Get Backup Pro 3

MySQL 数据库查询与数据操作:使用 ORDER BY 排序和 DELETE 删除记录

小万哥

Python 程序员 软件 后端 开发

业务负债与身体负债

胖胖

什么是UV贴图?

3D建模设计

人工智能 UV贴图 AI纹理

2023年10 种用于最佳稳定扩散最佳方案

3D建模设计

人工智能 Stable Diffusion Ai绘图 AI纹理 AI 贴图

2023-11-11:用go语言,字符串哈希+二分的例题。 给定长为 n 的源串 s,以及长度为 m 的模式串 p, 要求查找源串中有多少子串与模式串匹配, s‘ 与 s 匹配,当且仅当 s‘ 与 s

福大大架构师每日一题

福大大架构师每日一题

架构实战营-模块六作业

王朝阳

VPS:搭建自己的私有云

薛定谔的皮皮虾

Nextcloud

ZkSync是不可错的Layer 2 四大龙头之一

币离海

以太坊 layer2 zkSync

最高2000万元扶持!2024 年度宁波市甬江人才工程公告

科兴未来News

宁波甬江 甬江工程 人才政策 创业政策 创业资源

Macos音乐制作工具:Ableton Live 11 Suite 附 完整安装教程

繁星

音乐制作 Ableton Live 11

合成数据加速机器视觉学习 合成数据即将改变人工智能。如今,机器学习被用于各种基于视觉的

3D建模设计

机器学习 机器视觉 合成数据 合成数据生成

设计模式-建造者模式

es笔记七之聚合操作之桶聚合和矩阵聚合

Hunter熊

elasticsearch 聚合操作 桶聚合 矩阵聚合

tools-重命名

如果有一款专门用于3D纹理贴图的工具,大家会愿意用吗?

3D建模设计

Stable Diffustion AI纹理 AI 贴图 稳定扩散模型

Oracle的to_date()函数解决sql语句日期格式问题

知识浅谈

Java oracle

写在 Chappyz 即将上所之前:基于 AI 技术对 Web3 营销的重新定义

股市老人

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