需求开发人日评估

简介: 随着敏捷开发在国内的风靡,越来越多的团队开始推行敏捷开发,这其中有一个关键事项就是:工时的人日评估。简单来说就是:项目经理会让开发人员自己评估自己负责的模块大概需要的开发周期。人日,即按照1人几天完成,如1/人日:表示这个需求需要1个人1天完成,如果有2个人一起做,可能就是0.5天(需求开发一般1+1 < 2,因为有代码合并的兼容性要处理)。

如何粗略评估开发人日

对于需求的人日评估,根据笔者的过往经历,假设开发是3人日,其余情况则做相对应的调整

开发周期:3人日,接口设计、数据库设计、代码开发

自测周期:1人日,约开发周期的0.3~0.5倍

联调周期:2人日,约开发周期的0.5倍,要充分考虑接口重新设计的可能性

测试周期:2人日,基本等同于联调周期,这个阶段有大量的前后端BUG需要修复

发布周期:2H左右,自动化部署平台一键部署或者Linux环境下上传jar包人工部署

常见需求开发人日参考

  • Excel导入导出:2人日
  • 单表增删改查:1人日
  • 跨服务业务逻辑
  • 远程服务调用(OpenFeign/Dubbo):3人日,需考虑对方给出接口的时间
  • 远程服务消费(MQ):3人日,需考虑对方给出MQ的时间

这里人日评估都是在只做这个需求情况下的评估,如果有多个需求并行,需要做适当的人日拓展。

天机学堂开发人日参考

目录
相关文章
|
测试技术 Docker 容器
自动化质量评估维度
上篇文章讲了下关于终端自动化的一个探索《终端自动化测试探索之路》,今天来聊聊关于自动化质量评估的维度,包括UI和接口。
751 0
|
6月前
|
数据采集 数据安全/隐私保护 开发者
|
3月前
|
敏捷开发 Dubbo Java
需求开发人日评估
需求开发人日评估
|
4月前
|
UED
如何评估LabVIEW需求中功能的必要性和可行性
如何评估LabVIEW需求中功能的必要性和可行性
30 2
如何评估LabVIEW需求中功能的必要性和可行性
|
6月前
|
监控 测试技术
深入分析软件测试中的风险评估与管理
【5月更文挑战第30天】 在软件开发生命周期中,风险无处不在,特别是在软件测试阶段。本文旨在探讨软件测试过程中如何有效地进行风险评估和管理,以确保软件质量和项目成功。文中将介绍风险评估的基本概念,提出一个结构化的风险识别和评估框架,并详细讨论如何通过定性和定量方法来管理测试风险。此外,文章还将展示一个案例研究,以说明所提策略在实际中的应用效果。
|
测试技术
如何评估软件测试的质量风险?记住这5个核心关键点
如何评估软件测试的质量风险?记住这5个核心关键点
322 0
|
机器学习/深度学习 算法
评估系统或算法质量的重要指标
准确性(Accuracy):衡量系统或算法输出结果与真实结果之间的接近程度。通常使用分类准确率、回归误差等指标来评估。 精确率(Precision)和召回率(Recall):主要用于评估分类模型的性能。精确率衡量预测为正例的样本中实际为正例的比例,召回率衡量实际为正例的样本中被正确预测为正例的比例。
294 4
|
机器学习/深度学习 JSON 自然语言处理
可复现、自动化、低成本、高评估水平,首个自动化评估大模型的大模型PandaLM来了
可复现、自动化、低成本、高评估水平,首个自动化评估大模型的大模型PandaLM来了
614 0
|
测试技术 API 持续交付
持续测试成熟度模型
持续测试成熟度模型
313 0
持续测试成熟度模型
|
数据采集 监控 供应链
谈谈生产过程数据的质量评估
在制造过程中,数据质量和产品质量一样重要。我们可以将ISO 8000中的数据质量评估应用到IEC62264中的制造过程中。
谈谈生产过程数据的质量评估
下一篇
无影云桌面