AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

测算团队,而不是个人

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

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

关注

评论

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

HarmonyOS(鸿蒙)——单击事件的四种写法

李子捌

28天写作 21天挑战 鸿蒙系统 12月日更

100% 展示 MySQL 语句执行的神器-Optimizer Trace

程序员历小冰

MySQL 28天写作 12月日更

Spring核心原理之 IoC容器中那些鲜为人知的细节(3)

Tom弹架构

Java spring 源码

从渔夫和游客说到晒太阳的狗狗派

mtfelix

28天写作

kali系统之复现漏洞分析与审计

网络安全学海

黑客 网络安全 安全 信息安全 渗透测试

Kubernetes 集群部署 Metrics Server 获取集群 Metric 数据

zuozewei

Kubernetes 性能监控 12月日更

Dubbo 框架学习笔记十二

风翱

dubbo 12月日更

linux动态链接的程序如何在其他系统上运行

SkyFire

动态链接 装载器

注意:字符串substring方法在jkd6,7,8中的差异

CRMEB

HarmonyOS(鸿蒙)——双击事件

李子捌

28天写作 21天挑战 鸿蒙开发 12月日更

【Java 进阶训练营】 JVM 知识总结

wgl

前端CI/CD上如何保证依赖安装速度达到优解?

梁龙先森

前端 构建脚本

什么是 AQS 及源码分析

Ayue、

AQS

Linux之which命令

入门小站

Linux

荐书📚——《剑指Offer》专项突破版

宇宙之一粟

推荐书籍 12月日更

儿童教育有感-说话用词不当

wood

28天写作

Gin-Vue-Admin 使用gin+vue进行极速开发的全栈开发基础平台【gva第一节】

坚果

Go 28天写作 Vue 3 12月日更

[架构实战营] 模块三作业

Geek_0ed632

「架构实战营」

模块四-reids存储方案

撿破爛ぃ

「架构实战营」

Netflix系统架构

俞凡

架构 微服务 netflix 大厂实践

华为云GaussDB新产品特性亮相DTC2021,重磅新品开源预告

华为云开发者联盟

数据库 华为云 GaussDB 同城双集群 内存引擎

🍃【Spring专题】「原理系列」SpringMVC的运行工作原理(补充修订)

码界西柚

spring springmvc 12月日更 流程解析

【安全漏洞】CVE-2021-42287&CVE-2021-42278 域内提权

H

网络安全 信息安全 漏洞

程序员做技术管理需要懂哪些方面?

Seven的代码实验室

程序员 技术管理

模块三-架构文档

撿破爛ぃ

「架构实战营」

Spark-概览

xujiangniao

这一期总结

张老蔫

28天写作

HDZ城市行深圳站 | AIoT时代,如何抓住智联生活的战略机会点?

华为云开发者联盟

AIOT HarmonyOS 华为云IoT 智联生活 PLC-IoT

Linux 命令 less 全知全会

hedzr

Linux less

数据管理典范!「山东城商行联盟数据库准实时数据采集系统」入选2021中国大数据应用样板案例

DataPipeline数见科技

大数据 数据同步 数据融合 数据迁移 数据管理

在线上传图片二维码识别解析

入门小站

工具

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