AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

测算团队,而不是个人

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

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

关注

评论

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

公链系统开发全指南:从规划到实施,详解每个步骤

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

Wicrypt:赋有激励的 DePIN 互联网共享生态

股市老人

2024-03-23:用go语言,一张桌子上总共有 n 个硬币 栈 。每个栈有 正整数 个带面值的硬币, 每一次操作中,你可以从任意一个栈的 顶部 取出 1 个硬币,从栈中移除它,并放入你的钱包里。

福大大架构师每日一题

福大大架构师每日一题

AWE2024,中国家电智能化的《山海经》

脑极体

AI

深入理解 C++ 语法:从基础知识到高级应用

小万哥

程序人生 编程语言 软件工程 C/C++ 后端开发

农业物联网的3大系统、4大功能、对应的模式

执于业务

《自动机理论、语言和计算导论》阅读笔记:p1-p4

codists

自动机

Segment Anything(SAM)的哪些后续方法,又快又好?

AI帅辉

深度学习 计算机视觉 图像分割

初级Go工程师训练营第0期总结

刘博

Go 极客时间 课程总结

动力底盘域的“一小步”,智能汽车的“一大步”

脑极体

AI

关于 .NET Core 中的 Host

雄鹿 @

ASP.NET Core

产品开发的工具分析

执于业务

产品经理 需求

【分布式技术】分布式协议和算法

L L

分布式技术 分布式算法 Java 技术栈

"数字货币市场回归价值导向:Somle预售事件的启示"

区块链软件开发推广运营

区块链浏览器 dapp开发 链游开发 NFT开发 公链开发

定制Dapp开发:快速上线您的去中心化应用

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

产品经理常用的6个画原型需求工具

执于业务

LED显示屏:体育馆的现代科技之光

Dylan

LED显示屏 全彩LED显示屏 led显示屏厂家 体育

构建多语言数字资产交易平台和秒合约系统:从概念到实现

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 公链开发 FT开发

DAPP钱包燃烧质押合约挖矿项目系统开发

l8l259l3365

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