开发流程
从产品立项到项目验收完成，整个流程分为四大阶段：需求阶段、设计阶段、开发阶段、测试阶段。
需求阶段
需求分析
这个阶段主要是产品主导，主要工作有：
- 收集本期需求。
- 满足业务需要。
- 归集往期待改善痛点。
- 制定需求目标。
- 与架构师讨论方案可行性。
- 评估业务价值与优先级。
- 控制整个产品功能规划的设计
需求评审
需求评审是一个让所有参与人员明确需求的背景和意义、提前确认和统一产品需求实现的过程和方法、知道工作内容和预估交付时间的会议，通常需要2～3次才能完成一个最终版本的需求实现，如果立项版本过于复杂，可内部评审后再进行跨部门需求评审会。
需求评审的参与方包括但不限于：产品、设计、开发、UI、测试、运营等。研发与测试需要理解需求，更要挑战需求。挑战需求的目的是确认产品在需求分析阶段的工作完备程度，比如产品逻辑的遗漏、对当前系统的影响层面、当前技术的实现冲突等。只有经过充分讨论，才能理解需求，完善需求，防止后期需求返工。
UI阶段
各部门对需求达成了共识，此时就需要根据产品优先级，排期开发。一般产品和UI的迭代周期是先行的，早于开发和测试循序周期。这样避免出现等需求和UI而造成开发和测试空挡。设计师确定评审时间，按时交付 UI。
设计评审
设计评审有两大种，一种是设计师的评审(参与人员全是设计师)，另一种是项目组的设计评审。这里的评审是针对后一种，主要是面临产品和开发的挑战：设计是否否符合产品的需求定位、是否有遗漏、能否在有限的时间内开发完成等。
开发阶段
开发内部分化任务，确定排期时需预留自测时间，然后进入开发阶段，后端部门要在开发后端实现前，给出接口文档和 mock 数据，接口评审意义不大，一般在开发联调中会最终确定接口数据类型。
开发前要明确系统关系、模块关系、流程，然后接口设计并实现，为确保质量，在开发完成后需要进行组内 code review ，通过后才能合并开发分支，进行冒烟测试，如果周期短，代码审查可在项目完成后进行。
冒烟全量通过是提测的前提，确保流程无误而不浪费测试时间，如有客观原因未能全量通过，备注原因后提测。
在测试阶段，尽量做到 bug 日清，不影响测试后续流程。
测试阶段
冒烟如未通过，打回提测申请，直到冒烟通过才开始测试流程。期间如有 delay ，核算入开发时间。
预发测试期间同步进行UI验收和产品验收，各环境测试完成，出具测试报告，评估产品上线发布的可行性和风险点，协助产品和业务人员撰写产品验收报告。
上线收尾
收尾工作，这个阶段，主要进行复盘分析：
- 产品对需求进行总结，收集数据，分析效果，总结设计经验和优化迭代建议，并撰写相关的分析优化报告。
- 开发需要对代码进行整理，比如未进行的 code review 、删除为灰度而生的无用代码等。
一个完整的需求开发流程到此结束，当然，瀑布模型只是理想状态，也有着天生的缺点：每个阶段的严格性，缺乏灵活性，而现实需求却是经常变化的。
所以在实施过程中，改需求和加需求是必现的场景，在开发过程中可以均可以接受，但为了确保按时交付和质量保证，需准守以下约束：
- 提测后原则上禁止需求变更和UI变更，但是可以与开发人员协商，发邮件确认。
- 测试报告提交后禁止任何需求和UI变动，开发封包，禁止改动代码。
