故事点数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也提供了「工时」的填报功能，以支撑部分团队对于准确衡量人力投入的需要。

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