写点什么

测算团队,而不是个人

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

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

关注

评论

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

SAP Fiori Launchpad 应用的两个实用技巧分享

汪子熙

JavaScript SAP SAP UI5 ui5 7月月更

边无际 Shifu IoT 开源开发框架 助力物联网应用开发加速十倍

亚马逊云科技 (Amazon Web Services)

开源 Kubernetes 物联网 应用开发

TPC藏宝计划质押系统开发(Dapp)

薇電13242772558

智能合约 dapp

软件研发落地实践,要从设计就开始

华为云开发者联盟

云计算 后端 开发

Okaleido或杀出NFT重围,你看好它吗?

鳄鱼视界

音视频开发进阶|第四讲:音频自动增益控制 AGC

ZEGO即构

音视频开发 AGC

不会吧!钉钉都下载了,你还不知道可以这样玩?

Jianmu

钉钉 持续集成 自动化运维 建木CI 通知

Verilog HDL

贾献华

7月月更

TiKV & TiFlash 加速复杂业务查询

TiDB 社区干货传送门

nacos注册中心之服务注册

急需上岸的小谢

7月月更

python小知识-rethinking python 生成器

AIWeker

Python python小知识 7月月更

2022年浙江省等保备案流程指南

行云管家

等保 等保备案

还在羡慕其它平台有跨店满减,其实你也可以!

CRMEB

jdbc自带MySQL连接池实践

FunTester

MySQL数据库优化

五分钟学大数据

MySQL 7月月更

模块七作业 - 王者荣耀商城异地多活架构设计

Elvis FAN

如何快速有效的定位应用抖动问题?| 龙蜥技术

OpenAnolis小助手

Linux 系统 龙蜥技术 SysAK 抖动

4 个 JavaScript 最基础的问题 —— Eric Elliott

掘金安东尼

JavaScript 面试 前端 7月月更

云计算和大数据的关系以及区别详细讲解

行云管家

云计算 大大数据

Lite Actor:方舟Actor并发模型的轻量级优化

HarmonyOS开发者

HarmonyOS

声网传输层协议 AUT 的总结与展望丨Dev for Dev 专栏

声网

传输协议 Dev for Dev

Google上网神器Ghelper

源字节1号

软件开发 小程序开发

易周金融 | 邮惠万家银行开业;微信公众号叫停四类金融营销宣传

易观分析

金融

B站挂了登上全网热搜!技术人员为你还原前因后果

雨果

查找——B-树

乔乔

7月月更

全新出品!阿里P5工程师~P8架构师晋升路线揭秘

程序员小毕

Java 程序员 面试 架构师 学习路线

JAVA编程规范之控制语句

源字节1号

后端开发

向量化执行引擎框架 Gluten 宣布正式开源,并亮相 Spark 技术峰会

Kyligence

spark Gluten

uni-app进阶之内嵌应用【day14】

恒山其若陋兮

7月月更

短视频直播系统源码——如何优化满足用户需求?

开源直播系统源码

直播系统源码 开源源码 短视频直播系统源码

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