项目开发流程
为什么写这篇文章
知乎上有人邀请我回答这个问题，一直拖稿中……正好近期公司的新人培训已经组织完了，也有这个话题，决定把这个坑填上。
综述
项目流程，说重要，其实对研发同学来说没啥“技术含量”；说不重要，很有可能造成项目失控，比如：
- Bug很多，修复的速度赶不上出现的速度
- 花时间做出来的成品根本不符合需求，或者需求本身就不合理
- 已开发的功能总是对开发新功能没有任何帮助甚至造成障碍
- 项目无限期delay，经常反工，永远无法诞生出可用的产出
我们的项目开发流程，脱胎于百度。
我们采用主流的敏捷开发方式，特点就是小步快跑，注重计划和总结。
一个大型的项目或产品会拆分成 版本 > story > 模块 这样的三层进行开发，针对一个story或者大型功能模块，流程是这样的：
下面会详细讲一下每个阶段的：
- 阶段目标
- 每个阶段我们最终想达到一个什么效果
- 要做的准备
- 进入这个阶段前，需要有哪些准备动作
- 解决的问题
- 这个阶段过程中，需要解决哪些问题
在这个流程中，必须完成每个阶段的项目目标，才能进入下个阶段。
需求评审
一般由PM发起，项目组所有成员都参与。
阶段目标
所有成员详细了解需求方案
要做的准备
- 提前一天发评审会邀和相关文档
- 提前看需求文档，了解需求内容
- 熟悉相关业务和代码
解决的问题
- 项目组所有成员统一需求认知
- 初步评估需求方案，技术可行性
- 预估项目容量
设计评审
这里说的设计，不是UI/UE的设计，而是技术方案的设计，一般由RD/FE发起。
阶段目标
梳理所有技术点的实现方案
要做的准备
- 提前一天发评审会邀和相关文档
- 提前评估各自的实现方案
- 复杂的技术点，需要提前沟通
解决的问题
- 项目组成员间沟通技术实现方案
- 确定各端交互的方式，以文字的形式留存
- 评估详细排期
评估排期
项目组成员各自评估排期，最后merge到一起。
阶段目标
产出全员无异议的开发计划，以文字形式留存
这个阶段有几个注意点：
- 对需求进行尽量细的功能点拆分，有助于准确评估排期（精确到0.5天）
- 根据实际项目情况，预留适当的buffer时间（大约为项目总时长的5% ~ 10%）
- 排期一旦确定，视为对所有成员的承诺，非极端情况不可更改
排期规范
- 内容包含：项目名称、参与项目人员、日期、开发功能点简述、项目天数
- 排期邮件一般由项目负责人汇总
- 邮件需知会参与项目各方同学及leader
项目开发
阶段目标
各自开发，达到可联调状态
前端开发方式
我们采用分支开发分支发布的方式，而不是分支开发主干发布，是因为我们有现成的平台（百度效率云）支持这种开发方式。
一般项目都是前后端独立开发，前端采用本地devserver + proxy/mock的方式（接口有现成的就用proxy，没有则用mock平台伪造数据）
用例评审
一般由QA同学发起，项目组成员全部参加，评审测试用例的准确性和完整性，一般在项目开发过程中进行，没有固定时间。
阶段目标
所有成员详细了解并产出最终的测试用例
要做的准备
- 提前一天发评审会邀和相关文档
- 明晰需求细节
解决的问题
- 关注测试用例是否覆盖到所有情况，是否有欠妥的部分
- 可以借助测试用例review已经开发的内容
联调
由RD/FE发起，仅开发人员参与，尽可能利用一套统一的环境，进行联调。
阶段目标
各端调通完整流程
联调规范
- 需各端功能开发均已完毕才可开始
- 有QA的项目，在联调过程中覆盖大多数测试用例
- 无QA的项目，需自己整理测试用例，并在联调过程中尽可能覆盖
项目验收
由RD/FE发起，邀请PM/UI/UE等角色，对产品进行全方位的验收
阶段目标
完整流程通过，保证无遗漏需求
验收规范
- 项目联调、自测结束后可发起验收，UI/UE进行视觉交互验收，PM进行功能验收
- 中大型项目排期时至少预留1天验收时间
测试
有QA的项目，由QA发起，利用1套或多套环境进行项目测试。
阶段目标
项目达到可上线状态
测试阶段规范
- 提测给QA的代码必须通过自测和验收
- 提测分支若落后主干，同步之后再提测
- 提供编译后代码，保证与上线代码一致性
- 严禁使用QA环境调试bug
- 阻塞测试流程的bug及时修复
- 其余bug可定期统一修复
上线
最后的阶段，由RD/FE发起，把项目代码部署到线上。
阶段目标
项目代码部署到线上所有机器
上线规范
- 参与上线人员：项目组所有成员
- 上线代码有问题时立即回滚，处理完问题重新上线
- 一般会规定上线窗口时间，甚至固定每周统一时间进行上线
- 一般会有预上线环境（与线上机器完全一致，对外无流量）进行测试回归
文章被以下专栏收录
