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

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

关注

评论

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

出版社资源管理系统的开发

北京木奇移动技术有限公司

软件外包公司 教学资源网 资源管理系统

全面了解如何删除Mac启动台(Launchpad)的无效图标,Mac软件卸载后残留图标无法卸载的解决方法

阿拉灯神丁

mac系统清理优化软件 应用程序卸载 程序坞图标删除软件 CleanMyMac X中文版 卸载清理软件

凌晨3点的程序员,都在偷偷用这个神器续命…

测试人

人工智能

《Operating System Concepts》阅读笔记:p733-p734

codists

出版社资源管理系统的运营

北京木奇移动技术有限公司

软件外包公司 出版社 资源管理系统

生成式 AI 在电商评论场景的应用 : 场景分析和技术选型

亚马逊云科技 (Amazon Web Services)

“当月免费时长已达上限”怎么办?ToDesk:给钱

科技热闻

促销系统:促销活动、优惠券、优惠规则概念模型设计

量贩潮汐·WholesaleTide

阿里云 Elasticsearch Serverless 检索增强型 8.17 版来袭!

阿里云大数据AI技术

大数据 elasticsearch 阿里云 Serverless 向量检索

关税冲击下,全球AI向何处去?

脑极体

AI

Arthas watch (方法执行数据观测)

刘大猫

Arthas 图像处理 图像分割 光学成像 光电成像技术

1688代采系统功能深度解析:如何通过自动采集商品详情数据API接口实现高效运营

代码忍者

1688代采集运系统

超实用指南:应届生如何三步高效拿下理想实习机会

安全乐谷

面试 找工作 转行 笔试 找实习

星闪,连接智能的「最短距离」

白洞计划

AI

出版社资源管理系统的技术架构

北京木奇移动技术有限公司

出版社 教学资源网 资源管理系统

GreatSQL启动崩溃:jemalloc依赖缺失问题排查

GreatSQL

[方案讨论]怎么把大量电话号码批量导入手机通讯录,联系人号码导入苹果iphone华为小米等手机

一码平川

AI+代理IP手把手教你爬取某度

袁袁袁袁满

AI 代理IP 免费代理ip Python爬虫 爬虫实战

勒索软件介绍

天翼云开发者社区

勒索攻击

坐标上海,20~40K的面试强度

王中阳Go

Go 面经 上海

云备份技术解析:备份删除&合并原理

天翼云开发者社区

云备份

汽车上云的不可逆之路

脑洞汽车

AI

在亚马逊云科技环境上基于 Dify Agent 快速部署 text2SQL 智能数据分析助手

亚马逊云科技 (Amazon Web Services)

三句话搞定周末出行攻略!我用 AI 生成一日游可视化页面,还能秒上线!

陈明勇

MCP

出版社资源管理系统的主要功能

北京木奇移动技术有限公司

软件外包公司 出版社 教学资源网

出版社资源管理系统的技术难点

北京木奇移动技术有限公司

软件外包公司 教学资源网 资源管理系统

Apache Cloudberry™ PAX 行列混存方案技术解析

酷克数据HashData

zk源码—会话的实现原理

电子尖叫食人鱼

Java

MES助力电线电缆行业生产:从质量管控到追溯管理

万界星空科技

mes 电线电缆行业 制造业工厂 电线电缆mes 生产管理MES系统

AI智上 | 用友凭借AI之力,绘财务数智化新蓝图

用友智能财务

做Docx预览,一定要做这个神库!!

Immerse

Vue 前端 docx 文件预览

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