敏捷软件开发工作估算方法：故事点和工时
2022-11-12
来源：捷伴行Agile
你如果无法度量它，就无法管理它——彼得.德鲁克
软件开发组织工作估算的思考
我们人类天生不善于估算，要不就是过于乐观，要不就是过于悲观，就是很少有现实主义。尤其是我们软件开发行业，有太多的未知数：技术一直在变；新需求不断涌现；任务之间或人与人之间错综复杂的依赖关系；还有外界环境存在的各种因素。工作量主要与三方面因素有关，任务的规模，任务的复杂度以及完成该任务的人员能力水平。
为什么要做估算？
第一个原因是帮助我们做出周全的决定。有了估算，我们就知道软件产品清单上的需求是否能在指定的期限实现或需要多久才能完全实现。
第二个原因是设定目标。如果我们给自己制定了一个最后期限，就会全力以赴确保达到目标，当然，也有完全不靠谱的时候。当然，估算和设定目标毫无疑问可以帮助我们保持专注并取得最大成果。
一句话：了解团队在软件开发过程中的客户价值产能、组织投入的成本并做出更合理的交付计划和客户报价。
理解故事点和工时
在很长时间里，工时（人天/人时）是研发团队中的指标，能直接反映出：完成某项工作需要几个人做多长的时间。这一指标确实让许多研发团队获得了评估项目人力成本的基础数据。
然而在实际操作中，开发者的工作几乎无法被标准量化。不同的开发人员，其能力本就有所差距；更重要的是，每一项具体的开发任务，它的规模、复杂度和风险等可能有着巨大差异。仅仅统计工时，并不能反映团队的开发速率。因此，在敏捷开发中，提出了应当用故事点来估算工作量。
1个故事点是1个标准单位的工作量，是对工作规模的相对度量，它估算出的是对于完成此需求所要的开发规模的大小。这个单位并不能直接指代该项需求需要的开发时间。工时是绝对的度量单位，故事点是相对的度量单位。举个例子：在同一个餐桌上，同样是一碗饭，小强10分钟就能吃完了，小美需要20分钟才能吃饭。在这个例子中1碗饭就是标准单位，每个人吃饭的效能是不同的，小强20分钟可以完成2个标准单位，而小美只能完成一个标准单位。在软件开发行业，同样的用户故事，交给不同的人实现，用不同的时间，就表明每个人的产能不同。故事点作为标准单位更客观地衡量了团队产出的客户价值，而工时却无法反映这点。
价值评估和成本评估可以并行
前几天与公司的同事和领导就故事点和工时，这两种敏捷软件开发的工作量度量方式有过一些探讨，在适应公司现状的敏捷开发过
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
