整体流程
这个流程整体分为三个大阶段:需求阶段,开发阶段,上线阶段
需求阶段
需求分析
这个阶段主要是产品主导,收集痛点,归集需求,制定目标,与架构师讨论架构方案,与安全评估业务安全性
这儿可根据需求大小,具体行事,比如有些需求涉及方比较多,可能需要多次分组开会,不管是可行性分析,还是讨论方案,不是一次就能完成的
需求评审
当产品已经确定好这些方面,开始输出PRD,与研发、测试一起评审需求
研发与测试需要理解需求,更要挑战需求;
挑战需求的目的不是砍需求,而是确认产品在需求分析阶段的工作完备程度,比如遗留数据处理,对当前系统的影响层面,是否与当前系统重复度过高,业务价值
只有经过充分讨论,才能理解需求,完善需求,防止后期需求返工,某个细节没有考虑,影响整体设计实现
这儿各个团队实践方式各不相同,比如有些是所有团队成员都要参与,而有些只有具体参与开发测试参与
个人推崇所有成员都参与,这样一是讨论可以更充分,二是信息共享,防止因某成员个人原因,推迟需求进度
需求排期
对需求大家都达成了共识,此时就需要产品去需求确定优先级,排期开发
确定开发周期,这儿也有很多具体做法,有些团队是TL根据需求难易程序,变动大小,结合具体开发人员直接给出时间;有些团队是具体开发自行评估时间
一般都是由开发人员自行评估,只要在合理范围内,都给予认同
当然在确定开发周期时,必须给出依据,依据来源于详细设计,对于详细设计文档具体形式后面再谈,至少开发人员知道需要增加多少接口,修改多少接口,大概逻辑;不然评估时长就是一个空谈,造成整个项目的失控
开发阶段
需求阶段,从产品需求分析到开发人员评估出开发周期就已经结束了;下一个阶段进入开发阶段
开发阶段的进度,可以说八成是依赖第一阶段的成果。编码速度,实现手段只要是正常业务需求,一般都不会拖延时长
第一阶段成果,对于开发人员来讲,就是详细设计文档,文档中有了相应流程图,伪代码,具体涉及接口也有了,此时就是一个代码翻译过程
此阶段测试,需要输出测试用例,进行冒烟,回归测试;
自动化脚本完善
上线阶段
测试完成之后,就准备上线了。
根据确定的上线日期,提前核对checklist
对一些需要提前的变更开始申请审批流程
配合监控系统,需要对一些业务监控项进行配置
产品开始对预发布环境进行验收,验收成功后;发布正式环境
收尾工作,这个阶段,还有大量工作需要去做
- 产品对需求进行总结,收集数据,分析效果,为下一期需求做准备
- 开发需要对代码进行整理,比如有些是为了灰度而生的无用代码可以删除
一个完整的需求开发流程到此结束,当然这只是理想状态,还有很多不可预测问题,当然你也会吐槽,这是典型的瀑布开发模型,在敏捷大行其道时,是不是太守旧,太迟钝。好比敏捷开发的参与者是一群开发经验丰富和才华横溢的开发人员,而这样的团队有多少?强硬为了敏捷而敏捷会不会造成项目的不可控呢?
当然瀑布模型也有天生的缺点:每个阶段的严格性,缺乏灵活性,而现实需求却是经常变化的
所以单纯地选择哪个模型是不可取的,只能根据实际情况出发,为业务提供最大化服务
产品需求评审注意事项
- prd,只字不差的阅读。
- 评审提问题
- 在wiki列列排期(细分任务)
- 写伪代码,做设计
- 思考难点,提出来,提前调研
- 有问题,主动协商
- 需要什么样的接口,梳理出来
- 检查有没有方案不妥的地方,找出解决方案,去和产品协商
- 提炼难点,写demo跑通,保证主流程能通
- 让配合人明确提供相关需求的时间点
- 提测时:把master分支的代码合并到自己的分支上面
- 测试完毕准备上线时:再次把master分支的代码合并到自己的分支上面
- 上线完毕:回归完成后,把分支merge到master
项目开发注意事项
- 项目中sentry要区分,测试,开发,线上环境
- 解决完sentry后要点,已经解决
- 异常,或业务场景需要主动上报到sentry(方便定位问题)
- 数字不允许写在业务代码中
- 超过三层嵌套思考一下,是否有其它方案
- commit信息,尽量描述清晰,让阅读者,能直观阅读到做的事情。
- 提测前,要经过leader审核。
- 抽离可配置的参数到配置文件中
- 命名要有意义
- 逻辑性需要重点说明,务必加上注释
- 在开发过程中,尽量减少报错。
- 业余时间,多看看自己组的项目,有问题及时提出。
- 任何按钮要考虑,函数节流,防抖 (调用api)
- 不要把没用的注释代码提交
- 不要提交 无用的console.log 代码
- 修复bug 使用 fix分支
- 增加新特性的时候,使用feature
- 不要想当然,反复确认最终结果是不是自己想要的。
- 有效及时沟通
- 培养owner主动意识
- review code 培养起来
- 反思一下自己的交付质量
- 约束一个时间