前提
- 此方法是在没有技术阻碍的前提条件下预估，如果有技术障碍，请先解决技术阻碍
- 此方法需要根据个人实际情况调整
- 这里以普通的以vue,element-plus,axios为基础技术的管理系统为例
- 这些都是个人见解，欢迎在评论区提出不同观点
- 请先以一个普通的CRUD界面，测算自己的基本编码速度
总原则
- 不要duang的一下，对整个界面/模块进行评估，应该对行列，表单项，逻辑点，进行评估，然后将总的时间加起来，就是这个界面的预估工时
- 要至少多估20%的时间，一个是因为你很难持续性的投入(比如：有人突然问你问题，上厕所，喝水，或有事请假)
- 请将一天的工作时间最多算6.5小时(因为你可能需要开会，可能被其他事情打断，可能有时不在状态，同时也算是给自己留点思考时间)
- 尽量不要在过了一遍需求之后，立马评估工时(不要被项目经理或业务的节奏带偏)，而是要自己再思考一遍需求，想想大概的实现逻辑，重难点等等，尽量不要当天给出工时评估
- 如果是给别人评估工时，那尽可能给别人多评点工时
- 工期紧的时候，加人有必要，但1个人干7天的活，7个人未必能1天干完
- 有公共组件和没有公共组件完成同样的功能，所需要的时间可能天差地别, 因此，请确保先完成公共组件的开发
前端有哪些地方需要耗费工时
- 思考实现方式
- 静态UI界面还原与响应式
- 业务逻辑实现
- 动态UI交互
- 后端接口mock
- 后端接口对接
- 自测
前端项目应该分成几步实现
- 整体项目搭建以及规范与约束确认
- 整体页面结构，路由结构搭建
- 统一UI风格，以及公共组件实现
- 具体的界面实现
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大部分
- 头部的搜索表单
每个表单项30分钟左右，每个功能按钮40分钟左右
因此这里是1个表单项（30分钟），2个功能按钮(80分钟)，总计110分钟
- 中间的工具栏
P.S. 这里没算右侧工具条，只算了左侧功能按钮
因为是列表页，添加角色这个按钮，只考虑是个简单按钮加个点击事件，至于点击按钮之后的角色添加界面的工时不放在列表页评估，而是在添加角色界面单独评估，因此添加角色按钮算30分钟
批量操作按钮，应该使用公共组件的下拉按钮组件，以及与分页表格组件配合实现，因此算40-60分钟
因此这里整体应该总计在70分钟内
- 主体的分页表格
应该使用公共组件的分页表格组件实现
- 普通列（直接显示字段值的列，和简单转换的列）每列算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-3小时自测时间
- 没有计算联调时间，联调时间应该另算
- 没有计算UI还原时间，对于复杂UI界面或UI还原度要求高的界面，应该单独计算UI还原时间
- 对于复杂的业务逻辑，可以将业务逻辑拆解为一条条的业务逻辑项，每个业务逻辑项以40分钟左右每条作为参考实现时间
- 没有考虑思考时间，对于复杂的业务逻辑，或者没做过的界面形态，或者复杂的界面形态等，必须将思考时间计算进来，或者说，在已经基本想明白怎么去实现的基础上，再去评估工时
被误解的敏捷开发模式
错误的敏捷开发
- 敏捷开发就是强调一个快字
- 敏捷开发就是不断的压榨工时
- 敏捷开发就是不停的加班
正确的敏捷开发
- 测试在项目之初就介入，编写完测试用例之后，共享给开发，方便开发自测
- 将一个完整的项目进行合理拆分，拆分为若干独立小迭代
- 每个小迭代完成之后，进行提测以及收集用户试用反馈，尽早反馈，以及尽早发现问题
- 在小迭代提测期间，应该让开发略作修整（改bug或修整）和总结(总结共性问题，避免下阶段，再重复出现这些共性问题)，而非让开发立马进入下阶段开发，否则容易造成，开发一边赶下阶段需求，一边赶上阶段bug
- 个人认为敏捷开发，重点在于敏捷，灵巧好掉头，分阶段交付，及早发现问题，拥抱需求变化。而非简单的抽着鞭子让程序员加班赶工996或007