写点什么

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

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

关注

评论

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

私有化视频会议系统, WorkPlus Meet助力企业 “面对面”安全开会!

BeeWorks

硬核!互联网资深大佬手码高并发编程速成笔记(2023版)限时开源

Java你猿哥

性能优化 系统架构 ssm 高并发 Java高并发

【机器学习入门与实践】数据挖掘-二手车价格交易预测(含EDA探索、特征工程、特征优化、模型融合等)

汀丶人工智能

人工智能 数据挖掘 机器学习 深度学习 模型融合

面对向多模态发展的趋势,为什么这些业界和学界专家说“不必追热点”

小红书技术REDtech

深度学习 专家 活动回顾

高兼容低成本,开箱即用的首页性能优化方式被我们找到了

小红书技术REDtech

前端 Andriod

使用Python实现一个简单的垃圾邮件分类器

海拥(haiyong.site)

三周年连更

投放视频广告时,如何快速与第三方播放器兼容?

HarmonyOS SDK

HMS Core

关于Blender你想了解的都在这里

Finovy Cloud

blender 3D软件

跟随项曙明走进中兴通讯,探索企业开源风险治理优秀实践

开源雨林

开源治理 中兴通讯

Kubernetes 中容器跨主机网络是怎么样的?

Java Kubernetes 云原生

京东技术专家首推:微服务架构深度解析,GitHub星标120K

Java你猿哥

数据库 架构 微服务 ssm Java微服务

阿里P8面试官让我吃透这份10W字Java面试题,终于拿下Java高级岗Offer

Java java面试 Java八股文 Java面试题 Java面试八股文

java性能优化实战:高并发系统的法宝之缓存设计

Java你猿哥

高并发 缓存并发 缓存设计 Java高并发 Java性能优化

分享:CUDB for OceanBase分布式数据库产品规模应用

OceanBase 数据库

数据库 oceanbase

人工智能基础数据服务,第一!

百度开发者中心

人工智能 数据标注 元宇宙

AI与打工人:相互补充,共同进步 | 社区征文

海拥(haiyong.site)

三周年征文

防治“虚假种草”,小红书技术团队干了这几件大事

小红书技术REDtech

架构 AI 小红书

基于IM的企业移动应用平台,支持企业定制化

BeeWorks

3000字13张图详细介绍RAID0、1、5、6、10、50、60,非常值得收藏!

wljslmz

raid 存储技术 三周年连更

数据库原理及MySQL应用 | 日志管理

TiAmo

数据库 MySQL数据库 日志管理 三周年连更

ChatGPT背后的AI背景、技术门道和商业应用(万字长文,建议收藏)

京东科技开发者

人工智能 AI ChatGPT 人工智能ChatGPT 吗? 企业号 4 月 PK 榜

数据解析NFT Q1市场表现:NFT生态正向Polygon聚拢,蓝筹项目"保值"难

NFT Research

数据分析 NFT

ONES × 中国信通院《中国企业软件研发管理白皮书》即将发布

万事ONES

2023 BAT最强Java岗面试题 !底气来源"java面试手册2023"轻松上岸

Java你猿哥

Java JVM 多线程 面经 java基础

SpringCloud 网关实现线程池异步批量保存请求日志

Java你猿哥

spring Spring Cloud Java工程师 日志表

SpringCloud 网关实现线程池异步批量保存请求日志

Java Spring Cloud 网关设计

Github最新开源!Alibaba 亿级并发系统架构(2023全彩版小册)

Java你猿哥

Java 数据库 缓存 分布式 高并发

【等保小知识】等保一级需要备案吗?

行云管家

等级保护 等保备案 等保一级 一级等保

【堡垒机小知识】堡垒机有主机监控功能吗?

行云管家

网络安全 堡垒机 主机监控

Redis源码之SDS简单动态字符串

Java你猿哥

Java redis ssm Java工程师

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