InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

Story points vs. Working hours

作者 乔梁 发布于 2008年4月13日

领域
过程 & 实践
主题
敏捷技术 ,
敏捷
标签
人力资源 ,
用户故事 ,
标准化 ,
值和度量 ,
预算

在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的热心读者,发表一下您的意见吧。

乔梁 有十多年软件开发及项目管理经验,专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。

無題 发表人 dapeng li 发表于
Re: 無題 发表人 dapeng li 发表于
  1. 返回顶部

    無題

    发表人 dapeng li

    个人愚见:

    1.Story Point:针对大多数我们没有办法是用WorkingHours精确评估出完成某个Story所花费的时间,所以使用相对评估方式评估。

    2.Working hours:对于单一项目,如果已经能使用Working Hours评估,就没有意义在使用Story point了。


    但我们往往会根据以往历史记录来预测进行中项目规模和完成时间,这就需要使用同一的计量单位,个人推荐使用Story point,至于谁好谁劣就仁者见仁智者见智了。
    但对于作者在文章结尾出,提出关于“如何看待Stroy point和Working hours的联系?”一句,个人觉得并不恰当。我们在此讨论Stroy point和Working hours的目的并不是要告诉大家Stroy point和Working hours的联系,而是希望大家能思考一下评估的目的和方法。

  2. 返回顶部

    Re: 無題

    发表人 dapeng li

    小平同志告诉我们:不论黑猫还是白猫,只要抓到耗子就是好猫。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。