故事点数VS工时,研发工作量到底怎么算?

  最近一段时间,伴随着「工时登记」功能上线LigaAI,越来越多的小伙伴在问:工时和点数,到底有何异同,各自又应该如何使用?

  在很长时间里,工时(或者人天/人时)是研发团队中更常用的概念。这个简单粗暴的指标,能直接反映出:完成某项工作需要几个人做多长的时间。 这一指标确实让许多研发团队获得了评估项目人力成本的基础数据。

  然而在实际操作中,人们逐渐发现,开发者的工作几乎无法被标准量化。不同的开发人员,其能力本就有所差距;更重要的是,每一项具体的开发任务,它的难度、复杂度、业务价值、风险等系数可能有着巨大差异。单纯的统计工时,并不能反映团队的开发速率。

  因此,在硅谷浓厚极客文化中,一群开发者首先提出了:敏捷开发中,应当用「故事点数」来估算工作量。

  到底什么是故事点数

  点数,即「1标准单位」的工作量,是对工作规模的相对度量。

  它是综合了需求的复杂度、工作量、风险及不确定性等多项因素后,估算出的对于完成此需求所要的开发规模的大小。这个单位,并不能直接指代该项需求需要的开发时间。

  如果说「工时」是绝对的度量单位,那么「点数」则是一种相对的。「1标准单位」所指代的工作量/规模可能因每个团队的工作习惯而有所区别。

  对于初次接触「故事点数」的人来说,可能还是有点难理解。我们可以举个通俗的例子~

  小明经常跑步,他跑一段指定的5km道路只需30min;小军极少运动,跑完同一路段可能需要60min。那么对于跑步速度不同的两个人,究竟如何描述跑5km所包含的“运动量”才合理呢?

  如果说这是“30min”的运动量,显然对于小军不公平;但如果说这是“60min”的运动量,对小明来说就是浪费时间。

  在「点数」概念里,我们约定这一路况下跑5km计为1点运动量,并在两人中达成共识。之后,小明就会知道他完成1点的运动量大概需要30min,而小军也会知道自己完成1点需要60min。那么现在如果让他们去跑一段路况差不多的10km的路,他们就能估算出那是2个点的运动量,并能根据自己的速度,大概评估所需要的时间。

  同理,当采用故事点数估算开发工作量时,团队需要先选定一个可以作为标准度量单位的需求,约定其规模=1。 其他需求的规模,与之相比较,通常用“斐波那契数列”(1,2,3,5,8,13...)来相应的表示。估算值为2的需求,其工作规模应该是1标准单位的2倍。 (想知道为什么是斐波那契数列?请见此前文章:敏捷扑克,让评审会变身快乐牌局……)

  点数VS工时,好在哪里?

  A.量化团队的生产速率和产能

  「点数」,能更好地评估研发团队在单位时间内的实际产能。 在一个成员开发速度不一致的团队,用直接估算某项工作的开发时长,其实很麻烦。同一条需求,A开发只需1天,而B可能要做3天。在这种常见情况下,项目经理只能基于对开发者技能水平的主观把握来排期。

  假如项目经理将需求指派给A,并分配1人天,这个「1人天」只是对个人工作的估算。如果将该工作分给团队中其他人去做大概需要多久,就很考验项目经理的判断了。而在团队中,我们不可能永远把任务指派给擅长这项工作的人,这时以「工时」评估工作量就更难准确。

  在引入「点数」概念后,只要评估好各项需求的点数,试行1-2个迭代,就可以基本估算出每位成员在单位时间内能完成的「点数」。开发组长或者项目经理,也能直观量化团队的整体产能,更合理地计划排期。

  B.有效评估团队的成长性

  「工时」所反应的只是时间和人力投入,而不包含工作的难度、重要性等信息。 一个10人团队,每周总工时是固定的,我们除了主观判断这一周团队完成了3个功能,上一周完成4个功能以外,几乎没办法从这「工时」指标获知究竟这个10人的团队一周的产出是增加了还是减少了。毕竟功能有复杂有简单,不能简单靠计数解决。

  而「点数」反应的恰是「产出」。我们可以从单位时间内团队完成点数的变化,知道团队产能的变化。除此以外,每1点的开发工作对应的缺陷数量、需求的点数分布等指标,也能反应目前团队存在的问题。

  C.避免需求盲点

  在实际的项目管理过程中,「工时」更多是由上至下的分配。但「点数」则是开发团队自下而上进行工作量估算的方式。

  通过点数估算,研发团队的成员能参与到需求分析中,培养更多参与感和目标感,同时提前暴露产品设计的不确定性,避免需求盲点。郑州精神病在线咨询https://jbk.39.net/yiyuanfengcai/tsyl_zzjsyy/25899/

  看完上述内容,你一定会发现其实「点数」和「工时」并不是互斥的。它们一个用于评估工作复杂度,一个用于计算工作时长。组合使用,还能碰撞出许多有意思的效能指标。

  「点数」最重要的作用,是大家在产能上形成了一个参考基准。一旦团队通过迭代捕捉到了产能容量,就可以以此为切入点,与产品方、业务方达成交付效率的共识。既能避免拍脑袋给日期又给不准的尴尬局面,还可数据化地呈现研发团队的效能变化,可谓一举两得。

  在LigaAI,我们推荐研发团队,特别是践行敏捷的团队,可以使用「点数」作为主要的工作量估算方法。同时LigaAI也提供了「工时」的填报功能,以支撑部分团队对于准确衡量人力投入的需要。

  最后,不管黑猫白猫,能抓到老鼠的就是好猫。工作量估算亦是如此。不论采用「点数」还是「工时」又或者二者兼备,都需要每个团队不断探索更适合自己的工作方法,找到能有效评估并呈现自身产能的最佳路径。

故事点数VS工时,研发工作量到底怎么算?

上一篇:AT5749 Subarray Sum


下一篇:系统集成项目管理工程师高频考点(第十章)