规范是死的，人是活的，但愿本身定的规范，不要被打脸。前端
接下来从以上六个阶段进行逐一拆解。程序员
1 需求评审
做为技术人员确定都参加过需求评审会，不知道有没有遇到这样的状况？数据库
- 产品经理按照 PRD 文档读一遍，参会人员无动于衷。
- 产品经理刚讲了一个需求点，参会人员就产生了激烈的讨论，都在证实本身是对的。
- 参会人员对需求的目标不明确，对需求点进行发散思惟讨论，最终偏离方向。
遇到以上问题，确定是在参加需求评审以前未作充分准备，那么问题来了，须要提早准备什么？后端
评审前缓存
不要听产品同窗说，该需求是大老板跟进的、很是重要、很是紧急之类的，就问产品三个问题：安全
- 解决了什么问题？
- 提高了什么指标？
- 有什么商业价值？
这三个问题搞清楚了，再进行评审。架构
产品经理发出 原型 和 PRD 初稿后，开发人员要有 1-2 天时间（具体时间根据项目大小而定），熟悉文档，有任何疑问能够反馈给开发经理，由开发经理统一收集再反馈给产品经理，产品经理逐一进行答疑。框架
熟悉完文档后，开发人员和开发经理须要一块儿肯定：运维
- 技术选型（前端/后端框架、日志中间件、消息中间件、数据库...）
- 技术架构（组件与组件之间如何协同工做，如何部署）
- 技术难点预知（明确存在的技术难点，并肯定解决方案）
- 性能瓶颈预知（明确可能存在性能瓶颈的地方，并肯定应对措施）
- 上下游系统交互（明确在流程中的哪一个位置，约定接口文档提供时间、接口联调时间）
- 功能模块划分（任务拆分和分配）
技术方案肯定后，须要输出技术设计文档，包括：整体设计、概要设计、详细设计、接口设计 等。数据库设计
评审中
开发人员必须参加，有需求不明确的地方当场提出，同时开发人员也须要思考产品需求是否合理，可适当提出本身的产品意见。
通常评审至少有两次（初稿和终稿）。
评审后
评审后，若有需更新技术文档的请及时进行更新。
开发经理首先须要考虑团队现有的资源及项目的优先级，而后根据技术设计文档进行评估排期。
排期模板以下：
2 技术评审
评审前
开发人员必定要重视技术设计！
开发人员必定要重视技术设计！
开发人员必定要重视技术设计！
重要事情说三遍！
技术评审主要评审什么？
- 系统关系图、模块关系图、流程图的设计，画图工具根据本身爱好便可。
- 接口设计，须要考虑接口的 兼容性、扩展性、参数命名遵照 参数命名规范 等。
- 数据库设计，须要遵照 数据库设计规范，并记录 数据表变动文档。
- 详细设计，须要考虑公共类、公共方法、方法定义 遵照 项目框架目录规范。
评审中
开发人员和开发经理必须参加，涉及到整体设计和概要设计时，须要邀请 架构师 参与，涉及到数据库调整时，须要邀请 DBA 参与。
通常评审至少有两次（初稿和终稿）。
评审后
评审后，若有需更新排期文档的请及时进行更新。
排期肯定后，经过邮件方式进行回复排期，使用标准化的 回复排期邮件模板。
循序渐进，按计划行事。
3 需求开发
编码
开发人员编码过程当中，须要遵照团队的 编码规范，同时严格按照设计文档中的技术方案执行，除了保证代码逻辑的正确性外，还须要考虑代码封装性、可维护性、可扩展性，当编码阶段发现技术方案须要调整时，须要及时通知开发经理，通过赞成后才能实施，涉及到引入新框架和新技术，也须要提早通知开发经理。
代码审查
开发人员须要控制代码提交的频次和粒度，每次代码提交以后 24 小时内，须要主动联系代码审查人完成检查，开发经理负责检查是否执行到位。
代码审查主要审查什么？
- 规范性检查（是否符合代码规范、提交备注规范等）
- 健壮性检查（是否陷入死循环、资源未释放等）
- 安全性检查（是否存在SQL注入、XSS、SSRF、CSRF、越权、文件上传等）
- 性能检查（是否存在未加缓存频繁链接DB，是否须要链接池）
联调
开发人员积极主动地推进联调工做，若是遇到阻碍及时通知技术经理进行协调。
自测
联调完毕后，开发人员须要同时完成自测，并将标准化的 自测报告 发给测试团队。
对于有性能要求的项目，须要开发人员进行性能测试，并出具标准化的 性能测试报告。
提测
自测完毕后，经过邮件方式进行提测申请，使用标准化的 申请提测邮件模板。
开发人员根据公司运维提供的发布方式，进行部署到测试环境。
4 跟进测试
测试用例评审
开发人员必须参加，避免出现测试与开发对需求理解不一致的状况。
Bug 修复
开发人员及时关注 Bug 列表，快速修复迭代发布，若是测试进度存在延期风险，须要及时通知开发经理。
5 跟进上线
开发人员首先确认 Bug 所有关闭，同时产品人员在测试环境验收经过，而后须要主动推进相关团队理清上线依赖和上线顺序，同时肯定回滚预案，最后根据公司运维提供的发布方式，进行部署到线上环境。
线上环境部署完成后，经过邮件方式进行通知产品人员和测试人员，使用标准化的 上线完毕邮件模板，同时积极推进测试人员和产品人员完成线上验证，线上出现问题后第一时间通知开发经理。
6 线上问题复盘
需求在测试环境和正式环境，均未测试出 Bug，上线一段时候后出现 Bug，这种问题用什么制度约束？
出现问题后开发人员及时修复，修复完了就完事了。仅仅作到这些还远远不够。
建议使用以下模板进行复盘。
小结
你们能够数一数上面使用到了多少规范，这时有朋友会说了，这规范也太多了吧，这和工厂工人有什么区别，咱们程序员是有创造性的，咱们喜欢前沿性、挑战性的工做，咱们放荡不羁爱自由...
针对这个问题，首先我不否定开发人员是有创造性的，但并非全部的程序员都有创造性，在现实工做场景中大部分程序员不是作创造性工做的，也不必作创造性工做，因此必须按照规范流程执行。
团队管理和团队之间合做，必需要有规范，并严格执行。
就到这吧，以上供参考。