HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

Story points vs. Working hours

  • 2008-04-13
  • 本文字数:1477 字

    阅读完需:约 5 分钟

在 Agile 中, Story point 和 Working hours 都是用于评估完成每个 Story 所要付出劳动,只不过前者使用相对尺寸来估计,后者则使用绝对时间。那么,在实际工作中,Story point 和 Working hours 是否需要联系到一起?

最近,徐毅在 AgileChina 讨论组提出有关“究竟有没有必要或者有没有意义将 Story point 与 Working hours 牵连到一起?”的疑问。之所以有这么一问,是由于他注意到,貌似上层管理者用这些数据来进行人力资源规划。

即部门有多少人头,按照历史的 story point 消耗速率,和汇报的相关人员的 capacity 总和(working hours)来个除法,得到个系数,用这个系数来评估当前的资源状况等,如是否有足够的人力来完成项目。

同时,他认为 story point 更多的是讲求相对大小,而用 working hours 进行估算后,很容易在开发时被直接度量,有“客观标准”之嫌,想了解讨论组中其他人对这个问题的看法。 而 ifire zhang 则认为,这种联系没有太大必要,并以其所在项目的做法为例。

一般把 sprint backlog 分解为 1 天的粒度就 OK 了。然后,如果这个 sprint 里 backlog 过多,则去掉一些,少了则增加一些。

Wang Lijie 也认为,二者任选其一足矣,并指出:

出于更好的计算工作量,我们直接使用的就是 Working Hour, one task no more than 12 hours(2 days)。 个人觉得,使用 Story Point 就不应该再用 working hours, 二者还是有冲突的。

blackanger 所在的团队的做法与上述观点相反。

我们现在是把 story point 和 working hour 挂钩的。也就是说,一个 story point 代表 1 hour, 然后根据实际花费 hours 来评估团队生产力的值。 这样在一个迭代以后,可以评估团队的生产力。帮助计算团队不断的进化的程度。

Anchuan Qian 则指出,脱离特定的团队或项目泛泛地谈这两个东西没什么意义,并给出了自己的观点。

既然是估算,我有两个问题:
1、估算的目的是什么?
2、估算的标准和单位是什么? 1、不可能每个人的目的都一样。我们的目的是更清楚的了解自己的开发能力和工作进度,然后科学的做下一步的计划,更好的控制项目。

2、既然是这样,那么估算就一定要客观和一致。而且毫无疑问,前提是在目前的团队和项目中进行(或者同等的团队和项目)。否则去比较这些数据就没有任何意义了。下面是我用过的两种方式:

一、功能点数。比如说:1、2、5、8、16,这是按照一个功能的复杂度(一般是一张卡片,即 User Story)的大小给值。最重要的就是要保持一致,后面的评估,都是参照前面的相似或类似的功能。

难点就是 Story 的粒度,和评估时候保持一致。

二、真实天数。我们现在就用这个,并且用 Mingle 管理项目,很科学。在做计划的时候,开发者会评估每张 Story 的大小(真实天);然后开发者在开发之前,会再评估一下 Story 的大小;然后 Mingle 也会记录一个开发者完成这张 Story 花费的真实时间(可以根据这些数据自动生成你需要的报表)。而且,真正开发时间特别有价值,它不仅是最好的参考,还可以用来推算其它方面的成本。

针对具体项目,使用 Story point 或 Working hours 都行,只要由团队来决定就行。而且,正如 Anchuan Qian 所说,记录这些历史数据非常有意义。但有些公司倾向于使用它来衡量个体的绩效(当把这种项目管理方式上升到组织级管理时,难免会有这样的需求,这不仅仅是 Agile 遇到的问题,CMMI 也有同样的问题),结果可能势得其反,看上去得到了质量良好的数据,实际意义却并不大。

您是否应用 Agile 方法?如果是的话,您如何看待 Stroy point 和 Working hours 的联系?如果您使用了其它方法,又是如何做项目估算的呢?作为 InfoQ 的热心读者,发表一下您的意见吧。

2008-04-13 19:251626
用户头像

发布了 100 篇内容, 共 21.7 次阅读, 收获喜欢 5 次。

关注

评论

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

分布式批量任务调度、自动化运维管理监控平台Taskctl

敏捷调度TASKCTL

kettle 分布式系统 海豚调度 自动化部署 ETL

产品风控:短信验证码的风控策略

香芋味的猫丶

短信防刷 产品安全 短信验证码 短信防轰炸 短信防火墙

凭借这份Java超硬核面试 “备战” 手册!我刚面试完字节跳动、阿里、华为、小米等后端岗位

Java架构之路

Java 程序员 架构 面试 编程语言

理财之我见

三石

理财 28天写作

侵犯商业秘密罪律师提醒区块链技术与商业秘密的安全保管

CECBC

时间戳

全面开创城市数字经济新时代

CECBC

数字经济

波场链DAPP软件APP开发|波场链DAPP系统开发

系统开发

小马哥刷LeetCode 1480. 一维数组的动态和

小马哥

Java 面试 数据结构与算法 28天写作

SpringCloud 从入门到精通 05--- 订单模块

Felix

音频特征提取方法和工具汇总

行者AI

音视频

DAPP智能合约交易系统开发、DAPP系统开发的详细解释

W13902449729

DAPP智能合约交易系统开发 DAPP系统开发

案例研究之聊聊 QLExpress 源码 (三)

小诚信驿站

刘晓成 小诚信驿站 28天写作 QLExpress源码 聊聊源码

2020年度编程语言排行榜 C语言称霸,Java遭遇滑铁卢?

架构精进之路

编程语言 28天写作

助力金三银四跳槽季,《Java面试突击版》第四版强势来袭

Java架构之路

Java 程序员 架构 面试 编程语言

ArgoCD + KubeVela:以开发者为中心的 GitOps

阿里巴巴云原生

阿里云 开源 容器 云原生 k8s

数智化浪潮之中,传统企业如何抓住转型机遇?

京东科技开发者

DevOps

第1周架构方法总结

Richard

UML 需求分析 概要设计 软件架构设计 详细设计

花火交易所系统开发、雷达模式系统搭建开发

W13902449729

花火交易所系统开发 雷达模式系统搭建开发

腾讯十年,总结出这份Java架构师知识路线,保你稳拿40k+

Java架构追梦

Java 面试 架构师成长笔记 金三银四 全栈知识点

区块链技术应用新阶段有五大趋势

CECBC

比特币 区块链 数字货币

LeetCode题解:236. 二叉树的最近公共祖先,递归,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

霸榜各个网站的阿里独有的高并发高并发手册:Netty、Redis、Zookeeper,看完惊呆了!

996小迁

redis zookeeper 架构 面试 Netty

博弈论 - 海盗分金

石云升

博弈论 28天写作 海盗分金

助力ARM生态 —Dragonwell新增aarch64支持

阿里云基础软件团队

学习,不是一件一蹴而就的事情

Sandy

什么是区块链挖矿?区块链怎么挖矿?

v16629866266

分布式全链路灰度发布的探索与实践

阿里巴巴云原生

阿里云 微服务 运维 云原生 中间件

不交“人脉”交朋友:新荣耀的底气与新机

脑极体

没想到,学习带给我最宝贵的东西是底气

Sandy

赫拉利其人其书之我见(2)

石君

28天写作 简史 科技简史

跪了!Alibaba内部出品贼火的Java面试手册,全面对标蚂蚁金服、头条、拼多多等

Java架构之路

Java 程序员 架构 面试 编程语言

Story points vs. Working hours_研发效能_乔梁_InfoQ精选文章