报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

测算团队,而不是个人

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

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

关注

评论

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

用 TDengine 3.0 碰到“内存泄露”?定位问题原因很关键

TDengine

时序数据库 内存泄漏 ​TDengine

一款Redis可视化工具:ARDM | 京东云技术团队

京东科技开发者

redis 可视化工具 企业号10月PK榜 ARDM

精彩议程抢先看 | 第四届 CID 大会线下参会报名启动!

OpenAnolis小助手

云计算 架构 深圳 龙蜥社区 CID

源码, AST, IR, CFG之间的关系梳理

华为云PaaS服务小智

云计算 软件开发 华为云

80、90童年回忆之小霸王游戏机网页版

echeverra

小霸王

Databend 开源周报第 113 期

Databend

什么是K-均值算法

小魏写代码

全国5000家金融单位将加入信创建设大军,未来数年发展关键期

没有用户名丶

如何利用动态配置中心在JavaAgent中实现微服务的多样化治理

华为云开发者联盟

云计算 后端 云服务 华为云 华为云开发者联盟

深入理解java和dubbo的SPI机制 | 京东物流技术团队

京东科技开发者

Java spi Dubbo SPI 企业号10月PK榜

全流程多元化适配服务,OPPO Android 14 适配率高达98%!

科技热闻

运维 | Nginx Proxy Manager反向代理工具

Appleex

运维 nginx反向代理

聊聊什么是厂商绑定

冯骐

开源 供应链 战略思考 技术 优化体系 厂商绑定

Programming abstractions in C阅读笔记:p166-p175

codists

Eclipse、IntelliJ IDEA、PyCharm三种IDE区别

小齐写代码

IntelliJ IDEA安装教程

小齐写代码

Perforce发布《2023游戏开发与设计现状报告》,为游戏开发行业提供参考

龙智—DevSecOps解决方案

perforce 游戏开发与设计现状报告

当 FineReport 遇见 CnosDB

CnosDB

开源 时序数据库 CnosDB FineReport

从问界单日7000台,聊聊智能汽车成熟时

脑极体

问界

Python 元组完全指南2

小万哥

Python 程序员 软件 后端 开发

代码检查过程中为什么需要涉及到编译呢?

华为云PaaS服务小智

云计算 软件开发 华为云 代码检查

小灯塔系列-中小企业数字化转型系列研究——CDP测评报告

人称T客

Hugging "Hugging Face"

数由科技

低代码 huggingface 大语言模型 huggingfists 多模态模型

深入浅出MySQL MRR(Multi-Range Read)

Java随想录

Java MySQL

如何正确使用多线程和锁机制来构建可靠的程序

华为云开发者联盟

后端 多线程 开发 华为云 华为云开发者联盟

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