前端项目如何准确预估个人工时_前端工时评估怎么做

• 不要duang的一下，对整个界面/模块进行评估，应该对行列，表单项，逻辑点，进行评估，然后将总的时间加起来，就是这个界面的预估工时
• 要至少多估20%的时间，一个是因为你很难持续性的投入(比如：有人突然问你问题，上厕所，喝水，或有事请假)
• 请将一天的工作时间最多算6.5小时(因为你可能需要开会，可能被其他事情打断，可能有时不在状态，同时也算是给自己留点思考时间)
• 尽量不要在过了一遍需求之后，立马评估工时(不要被项目经理或业务的节奏带偏)，而是要自己再思考一遍需求，想想大概的实现逻辑，重难点等等，尽量不要当天给出工时评估
• 如果是给别人评估工时，那尽可能给别人多评点工时
• 工期紧的时候，加人有必要，但1个人干7天的活，7个人未必能1天干完
• 有公共组件和没有公共组件完成同样的功能，所需要的时间可能天差地别, 因此，请确保先完成公共组件的开发
• 请先将业务逻辑理顺，把工作进行拆分，直至自己能正确预估的范围内

前端有哪些地方需要耗费工时

• 思考实现方式
• 静态UI界面还原与响应式
• 业务逻辑实现
• 动态UI交互
• 后端接口mock
• 后端接口对接
• 自测

前端项目应该分成几步实现

1. 整体项目搭建以及规范与约束确认
2. 整体页面结构，路由结构搭建
3. 统一UI风格，以及公共组件实现
4. 具体的界面实现

1，2点应该由项目组长完成 3点应该由项目组长以及技术较强的组员共同完成

常见的公共组件工时

组件	工时
查询按钮	60 分钟
提交按钮	60 分钟
confirm按钮	60 分钟
下拉按钮	60 分钟
分页表格	360 分钟
JSON配置分页表格	240 分钟
动态表单	360 分钟
JSON动态表单	360 分钟
模态框	90 分钟
抽屉组件	90 分钟
select组件	90 分钟
tree组件	120 分钟
cascade组件	90 分钟
日期选择组件	60 分钟
日期范围选择组件	120 分钟
axios封装	360 分钟
卡片组件	60 分钟
面包屑组件	60 分钟

列表页拆分与编码工时预估首先做总体拆分，分成3大部分

1. 头部的搜索表单

每个表单项30分钟左右，每个功能按钮40分钟左右

因此这里是1个表单项（30分钟），2个功能按钮(80分钟)，总计110分钟

1. 中间的工具栏

P.S. 这里没算右侧工具条，只算了左侧功能按钮

因为是列表页，添加角色这个按钮，只考虑是个简单按钮加个点击事件，至于点击按钮之后的角色添加界面的工时不放在列表页评估，而是在添加角色界面单独评估，因此添加角色按钮算30分钟

批量操作按钮，应该使用公共组件的下拉按钮组件，以及与分页表格组件配合实现，因此算40-60分钟

因此这里整体应该总计在70分钟内

1. 主体的分页表格

应该使用公共组件的分页表格组件实现

• 普通列（直接显示字段值的列，和简单转换的列）每列算20分钟
• 操作列按每个操作按钮另算
• 复杂转换列按40-60分钟算
• 排序列按40-60分钟算
• 分页表格组件调用30分钟

从界面看，这里有6列，checkbox列和序号列，是分页表格组件实现的，无需再算工时，除操作列和创建时间外，其他都属于普通列算20分钟每列，创建时间列算40分钟，因此总共100分钟

操作列角色成员，角色权限和修改，都需要打开一个抽屉界面（抽屉界面里的东西另算，不算在列表页中），删除需要调后端接口以及确认，因此

• 角色成员按钮: 20分钟
• 角色权限按钮: 20分钟
• 修改按钮: 20分钟
• 删除按钮: 30分钟

总计: 100 + 20*3 + 30 = 190分钟

因此整个列表页工时

列表页需要mock 1个接口，列表接口，算20分钟

110 + 70 + 190 + 20 = 390 分钟 = 6.5小时

再在390分钟的基础上再多加20% = 390*1.2 = 468 分钟 = 7.8 小时

P.S.

1. 添加角色/角色成员/角色权限这是独立界面，需要单独计算时间。计算方式也与上面的类似
2. 没有单独计算自测时间，个人认为理想情况应该对1个界面，加2-3小时自测时间
3. 没有计算联调时间，联调时间应该另算
4. 没有计算UI还原时间，对于复杂UI界面或UI还原度要求高的界面，应该单独计算UI还原时间
5. 对于复杂的业务逻辑，可以将业务逻辑拆解为一条条的业务逻辑项，每个业务逻辑项以40分钟左右每条作为参考实现时间
6. 没有考虑思考时间，对于复杂的业务逻辑，或者没做过的界面形态，或者复杂的界面形态等，必须将思考时间计算进来，或者说，在已经基本想明白怎么去实现的基础上，再去评估工时

被误解的敏捷开发模式

错误的敏捷开发

• 敏捷开发就是强调一个快字
• 敏捷开发就是不断的压榨工时
• 敏捷开发就是不停的加班

正确的敏捷开发

• 测试在项目之初就介入，编写完测试用例之后，共享给开发，方便开发自测
• 将一个完整的项目进行合理拆分，拆分为若干独立小迭代
• 每个小迭代完成之后，进行提测以及收集用户试用反馈，尽早反馈，以及尽早发现问题
• 在小迭代提测期间，应该让开发略作修整（改bug或修整）和总结(总结共性问题，避免下阶段，再重复出现这些共性问题)，而非让开发立马进入下阶段开发，否则容易造成，开发一边赶下阶段需求，一边赶上阶段bug
• 个人认为敏捷开发，重点在于敏捷，灵巧好掉头，分阶段交付，及早发现问题，拥抱需求变化。而非简单的抽着鞭子让程序员加班赶工996或007

最后

由于文档内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

2037)]

[外链图片转存中…(img-4fZqnVDX-1714633232038)]

由于文档内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】