工作量评估之小马过河
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
老邓聊开发
扫码关注公众号
扫码阅读
手机扫码阅读
在软件开发中,工作量评估至关重要,但使用绝对时间(如人天或人时)进行评估时,往往会遇到困难,因为团队成员能力和技术偏好的差异会导致评估结果的不一致性。例如,高级工程师可能4小时完成的功能,初级工程师可能需要超过8小时。
另一个问题是人脑对于事物的绝对大小估计通常不准确,而对相对值的估计则相对准确。这是因为我们的大脑更擅长处理相对值;只要参照物的比例不是太悬殊,我们通常能够作出较为接近的估计。
基于这种相对值估算的优势,用户故事点数估算方法应运而生,解决了团队在估算工作量时遇到的问题。通过选择一个中等难度的用户故事作为基准,并将其复杂度设为1,然后将其他用户故事与之比较,来确定它们的点数。这种方法既可以减少不同开发人员能力差异带来的偏差,也利用了人脑对相对值估计的优势,从而得到更客观的工作量评估结果。
将用户故事点数转换为实际时间的方法是基于经验。通过进行1-2个冲刺,可以确定团队在一个冲刺周期内能完成的用户故事点数,从而准确预测生产力。随着团队的变化和生产力的提高,用户故事点数可能会有所波动,但通常能够控制在一个可预测的范围内,使得团队可以更好地掌控生产力,做出承诺并确保完成。
老邓聊开发
老邓聊开发
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
老邓聊开发的其他文章
软件项目中几大幻觉
幻觉一:需求分析完成了产品辛辛苦苦花了很长时间对用户需求进行分析,画了原型图、出了PRD文档,长出一口气,总
检查项驱动开发CheckList Drive Development
我找一个木匠订做一个饭桌。几天后,木匠做好了找我验收,我一斧子劈上去,桌子开了个口。我说这测试没通过,你这不
业务模型驱动需求编写
王大锤老师在上BA课的时候,经常会用一个俄罗斯方块的例子:请描述俄罗斯方块旋转的逻辑。由于俄罗斯方块有好几种
如何提升代码质量
好的代码都有一些共同的特征,如可读性、较少的方法行数、高内聚低耦合、职责单一。但这只是一个结果,作为一个工程
如何进行测试驱动开发(TDD)
从我的面试经历来看,或许是我见过的优秀公司还不够多,几乎没有公司能正确使用TDD的。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线