一、拿到原型图,先自我解析需求,画出思维导图,流程图
? 在未拿到 UI 给定的 PSD 时,可以先理清我们的需求
- 依赖的外部资源
- 后端提供的接口
- UI出图的大概布局
- 后期频繁改动的地方
- 需要实现的效果
- 下拉刷新
- 动画效果
- 吸顶效果
- 懒加载、预加载、防抖、节流
二、产品召集项目相关人员,开需求讨论会,产品讲解原型
- 理解产品的需求,提出质疑:这是什么功能,怎么做,为啥这么做
- 评估实现难度和实现成本,是否有潜在技术问题/风险
- 对比自己整理的需求图,如果有和自己想的不符合的,提出疑问
- 理解PM提出此次需求的目的,明白哪些内容是重点,哪些次要,可以适当取舍
- 如果产品要求提供时间,简单项目可以预估,复杂项目不可马上给出时间,需要仔细评估,评估时间包含开发、自测、测试人员测试、修复bug、上线准备
三、会后进一步整理需求
- 细化细节,整理有疑问的地方,与产品、设计等其他人进行确认
- 评估项目完成时间–影响因素
需要的人力、 中间插入的需求、 开发、 自测、 测试人员测试、 修复bug、 上线准备、 其他风险(如技术选型错误等) - 初步制定排期表
四、需求二次确认(开发中遇到不确定的,依旧需要找相关人员进行需求确认,杜绝做无用功)
- IM工具沟通确认
- 邮件确认
- 小型需求/项目相关讨论会
- 确定最终排期表
五、开发
- 技术选型
- 搭建开发环境
- 工具链
- 搭建项目架构
- 业务模块划分
- 优先级排序
- 新项目介入,需要当前项目和介入项目的相关负责人Pk优先级,随后调整项目排期
- 开发过程中发现工作量与预期有严重出入,需要尽早向其他项目人员反馈,方便其修改时间安排
- 定制开发规范
- 开发规范
- commit提交格式
- 单分支开发或者多分支开发
- 小项目、并行开发少,则只在master主分支开发
- 中大项目,需求复杂,并行功能多,则需要分为master、developer、开发者分支;需要开发者自创一个分支开发,合并到developer,确认无问题后,发布到master,最后上线
- 代码规范
- jsconfig.json
- .postcssrc.js
- .babelrc
- .prettierrc(vscode插件prettier-code fomatter)— 注意与eslint要保持一致
- .editorconfig
- .eslintrc.js(强制开启验证模式)
- JavaScript开发中常用的代码规范配置文件
- 源码管理
- 版本管理
- 安全管理
六、自测
- 手动测试
- 单元测试
- mocha
- 集成测试
七、提测—测试人员测试
- 开发人员修复bug
- 期间不可接手耗时大的需求
- 有不确定优先级高低的需求,需要各个需求方互相pk优先级,再确定做与不做,不能因此拖延项目完成点
- 测试修复bug时间可能比开发时间还长,因此开发者预估开发时间不能乐观
八、上线
- 上线准备
- 域名申请
- 备案申请
- 服务器申请
- 部署
- 测试线上环境
- 有bug回到修复bug环节
- 日志监控
- 调用栈
- sourcemap
- 本地日志
- 用户环境、IP
- 低成本接入
- 统计功能
- 报警功能
九、维护
技术创新(对现有的技术领域以及具体项目实现方法进行优化)
- 提高效率
- jenkins构建部署
- 减少成本
- 提升稳定性
- 安全性
|