写点什么

测算团队,而不是个人

  • 2008-02-01
  • 本文字数:1730 字

    阅读完需:约 6 分钟

Michael Dubakov 的公司最近发布了 Target Process ——一个针对敏捷项目管理和生命周期的产品。作为对该产品用户的问题和要求的回应,Dubakov 对于敏捷项目中测算个人开发速率和个人估算准确率的活动提出了警告。他认为:由于已经有了针对团队的等价物,对于个人的测算标准和活动不但无法获取更多有价值的信息,而且有可能使得团队做出影响生产力和效率的行为。

在一篇 2007 年岁末的帖子中,Dubakov提出了关于敏捷团队希望测算个人开发速率的议题。他以两个开发人员——Ted 和 Jerry——为例说明:一系列的历史“个人开发速率”测算数据,对于团队未来的迭代规划以及团队的整体开发速率测算,没有任何帮助作用:

在一个迭代中,如果 Ted 完成了预估要花费 40 个小时的多个任务,而 Jerry 只完成了预估 25 个小时的多个任务,我们就可以说在该迭代中 Ted 的开发速率要更快。那么是不是意味着 Ted 是一个更快、更好的开发人员呢?不尽然。有无数原因可以解释 Jerry 为什么完成的任务量较少……好吧,那么多个迭代核算下来,两人的平均开发速率各是多少呢?令人惊讶的是,Jerry 的平均开发速率是每个迭代完成 54 个小时的工作量。天哪!Jerry 在上两周里怎么了?他的平均开发速率能够帮助我们制定准确的迭代计划吗?如果我们把团队的全部个人开发速率累加在一起,是不是可以帮我们制定更好的迭代计划呢?不行,因为我们已经有了“迭代开发速率(Iteration Velocity)”这个测量标准,而且它是不会发生变化的。

为了进一步说明他的观点,Dubakov 指出,针对个人进行测算这种行为,会对敏捷团队的理想运作目标造成两种危害:

  1. 错误地关注个人的绩效,而不是团队的成果;这样会导致团队成员不愿意花费时间互相帮助
  2. 倾向于注重个人工作的分配,而不是达成团队的承诺

受到 Michael 的观点和最近一个论坛讨论贴的激发,James Carr 很快就提醒大家开发速率的通常用法

使用开发速率不是为了(评估)绩效……是要让客户更清晰准确地知道当前的迭代可以完成多少个功能“点数”。要牢记这一点。

最近的一个帖子中,Dubakov 回顾了这个话题,这次他加入了对于测算个人估算准确率这一活动的警告。他首先指出这个测量标准不具备可行性,除非做到以下两点:一、估算由个人给出;二、团队追踪记录所有任务的完成时间。正像敏捷社区反复强调的,这两个条件的主要问题在于它们都违反了敏捷的基本原则:促进团队合作以及让工作变得更简单。

为了例证测算个人估算准确率会导致的错误后果,Dubakov 又以假设的开发人员 Ted 为例:

我们可以计算 Ted 的全部任务分配和花费时间,并计算出下个迭代的估算准确率,假定为 0.7。 好,那我们又该如何使用这个测算标准呢?如果 Ted 估算这个迭代的任务要花费 60 个小时,就是说他将会实际花费 85 个小时,对时长为两周的迭代来说,他至少要加班 5 个小时。Ted 应该考虑这个因素,并从他的 ToDo 列表中去掉一些任务。如果 Ted 的估算准确率不变,这样做没有问题,可是真能这样理想吗?在现实中,Ted 的估算准确率从 0.5 到 0.9 浮动不等,在下个迭代中,准确率可能为 0.9,这样他就可以及时完成所有的工作。

InfoQ 的 Deborah Hartmann 进一步阐述了 Michael 的观点,她质疑任何针对基于时间的估算准确率进行测算的有效性,无论这样的测算是针对团队还是个人:

要计算这样的估算准确率,团队必须要耗费精力获得详细的“实际”工作小时数,我可从没有见过哪个敏捷实践倡议说要这样做。经典的“规划的工作计量单位”与“全部完成的工作计量单位”,是以对客户更有价值的工作单位——交付的工作(故事点数、理想工作小时数、香蕉等等)进行估算准确率测算的。 通过追踪实际工作小时数来追踪估算准确率,不能为团队提供更多有价值的信息,而且造成了一种新形式的浪费。我同意 Dubakov、Carr 和其他人的观点:对大多数团队来说,我认为这种测算毫无价值,而且很高兴看到:由于该观点的提出,它很快就从 TargetProcess 中移除掉了。此种负责任的改变,正是我们期待敏捷团队所展示出来的行为。

Dubakov、Carr 和 Hartmann 都同意:针对敏捷项目中个人开发速率和个人估算准确率进行测量活动,不但无法获取更多有价值的信息,而且有可能使得团队做出与敏捷核心思想相违背的行为。

查看英文原文: Measure Teams, Not Individuals

2008-02-01 19:15813
用户头像

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

关注

评论

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

flutter 开发中 vscode 插件推荐 3

坚果

flutter 11月日更

Java将增加虚拟线程,挑战Go协程

编程宝库

Java golang 并发

数字藏品是什么?有风险吗?谁来监管?

CECBC

Java编程中忽略这些细节,Bug肯定找上你

华为云开发者联盟

Java 编程 对象 垃圾回收 switch语句

在浏览器里使用 SAP GUI

汪子熙

SAP abap SAPGUI 11月日更

SAP UI 搜索分页技术

汪子熙

JavaScript Web SAP 11月日更

从原理带你掌握Spring MVC拦截处理器知识

华为云开发者联盟

Spring MVC 拦截器 拦截处理器 HTTP请求

前端开发:Node版本引起的报错问题

三掌柜

11月日更

研发效能提升的八项实践建议

博文视点Broadview

建设区块链基础设施,加速区块链等新技术与传统行业深度融合发展

CECBC

货币“大动作”,中国数字货币DCEP即将落地!

CECBC

Vue进阶(贰佰):前端UI框架介绍

No Silver Bullet

Vue UI 11月日更

【高并发】ScheduledThreadPoolExecutor与Timer的区别和简单示例

冰河

Java 并发编程 多线程 高并发 异步编程

2021 年中国敏捷行业现状调查全面启动

爱吃小舅的鱼

敏捷开发 敏捷转型 问卷调研

Android C++系列:Linux文件系统(一)

轻口味

c++ android jni 11月日更

dart系列之:创建Library package

程序那些事

flutter dart 程序那些事 11月日更

只需10分钟,让你的企业应用具备OCR能力

明道云

北京智博会主题展|2022第十五届北京国际物联网展览会

InfoQ_caf7dbb9aa8a

论文解读丨文本行识别模型的再思考

华为云开发者联盟

数据集 文档 文本 文本识别 语言模型

WebRTC DTLS | 谈谈 DTLS Fragment

泰一

DTLS

复杂JSON结构创建语法

FunTester

Java json 接口测试 测试开发 FunTester

【Flutter 专题】04 图解第一个程序遇到的安装依赖问题

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 11月日更

部署Apollo

小鲍侃java

11月日更

直播 | 大数据能力体系构建的技术方法全在这了!

百度开发者中心

大数据 百度 直播 开发者沙龙

精选案例 | YRCloudFile 引领自动驾驶存储技术新趋势

焱融科技

自动驾驶 云计算 分布式 高性能 文件存储

明道云初学者如何速成报表管理系统

明道云

Supersonic Superstars挑战赛,FeoFun、Black Candy斩获大奖

【LeetCode】整数替换Java题解

Albert

算法 LeetCode 11月日更

北京主题展|2022第十五届北京国际物联网展览会

InfoQ_caf7dbb9aa8a

Hi,Contributor,有一份专属周边礼包等你领取!

SphereEx

开源社区 ShardingSphere SphereEx Contributor 周边

提升RTC音频体验 - 从搞懂硬件开始

Wilber

音视频 RTC 3A 音频技术 音频3A

测算团队,而不是个人_研发效能_Mike Bria_InfoQ精选文章