写点什么

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

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

关注

评论

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

区块链数字版权管理,区块链赋能知识产权保护

13530558032

电商千万级交易的金手指:分布式事务管理

华为云开发者联盟

微服务 事务 华为云 分布式事务管理 DTM

区块链数字版权管理,区块链赋能知识产权保护

13530558032

你遇到过哪些质量很高的 Java 面试?

张小方

Java 面试 阿里 薪资

阿里P8大牛亲自教你!一个三非渣本的Android校招秋招之路,满满干货指导

欢喜学安卓

android 程序员 面试 移动开发

Kubectl Plugin 推荐(三)| 插件开发篇

郭旭东

Kubernetes kubectl kubectl plugin

NAC公链——Nirvana NA公链白皮书

区块链第一资讯

挖矿 区块链+

JDK8新特性 Fork/Join 的优化

Java小咖秀

Java java8 jdk8 forkjoin fork

有道技术沙龙 | AI 语音交互技术在语言学习场景的实践

有道技术团队

人工智能

跟公司新招的这个“同事”搭档,工作搬砖太“自动化”了

华为云开发者联盟

华为 AI RPA 自动化 员工

【LeetCode】不同的子序列Java题解

Albert

算法 LeetCode 28天写作 3月日更

看故事学Redis:再不懂,我怀疑你是假个开发

华为云开发者联盟

MySQL 数据库 redis 缓存 数据

云原生时代下,容器安全的“四个挑战”和“两个关键”

阿里巴巴云原生

容器 云原生 k8s 安全 监控

智慧公安二维码定位报警系统开发,微警务平台解决方案

源中瑞-龙先生

二维码定位报警系统开发 智慧公安 智慧公安扫码

带你走进与千万数据通信者共成长的“家园”

华为云开发者联盟

华为 开发者 网络 华为数据通信 社区

多端框架开发 | 拼团商城项目开发说明

YonBuilder低代码开发平台

小程序云开发 大前端 移动终端 APP开发 多端开发

寻找被遗忘的勇气(十七)

Changing Lin

3月日更

数据驱动业务:一张大屏掌控城市运行,效率提高95%

一只数据鲸鱼

物联网 数据可视化 智慧城市 智慧园区 智慧交通

SDK 是如何存储事件数据的?

神策技术社区

ios 大数据 存储 数据采集 神策数据

阿里P8大牛亲自讲解!2021年Android网络编程总结篇,醍醐灌顶!

欢喜学安卓

android 程序员 面试 移动开发

OpenKruise v0.8.0 核心能力解读:管理 Sidecar 容器的利器

阿里巴巴云原生

容器 微服务 云原生 k8s 应用服务中间件

私藏干货 | 实现分布式锁的三种方案对比

架构精进之路

分布式锁 3月日更

区块链电子证照应用赋能政府服务

13530558032

一招让Kafka达到最佳吞吐量

万俊峰Kevin

kafka go-zero Go 语言

沙龙报名 | 云计算进入多元架构,云原生时代的挑战与机遇

京东科技开发者

云计算 云原生

LeetCode题解:647. 回文子串,动态规划,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

C语言中“野指针”、“悬空指针”是什么?

不脱发的程序猿

c 指针 编程之路 bug 3月日更

您的客户管理决策是否低于10毫秒?

VoltDB

5G 物联网 解决方案 电信

Oracle Sql性能优化

大数据技术指南

oracle 大数据 28天写作 3月日更

架构师训练营第十一周作业 - 命题作业

阿德儿

拍乐云创始人&CEO赵加雨:深耕18载,打造全景式音视频服务

拍乐云Pano

音视频 WebRTC 在线教育 RTC 实时通信

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