合理的项目迭代流程是软件高质量可持续生产的保障，只有拥有一套完整合理的项目迭代流程才能确保即使是不同团队开发不同项目，也能最大限度的保障项目开发质量。
汇总流程图如下，后面是各阶段的详细介绍：
图片
1.需求评审阶段：
需求评审是从理论上对项目可行性进行评审，着重于需求的合理性、价值点、投入产出比分析，同时确保PD和开发方对于项目的相关信息认知一致，以免产生不必要的资源损耗。
项目需求一般由产品经理进行提出，以PRD(需求文档)的形式进行呈现，需求文档以清晰完整的描述整个项目需求为准，具有一定的规范，通常应包括需求背景、需求目标、原型图、动线图、需求概括、功能点、数据分析等内容。
为提高需求评审质量以及效率，评审会议建议按照以下流程进行：
- 在评审会议开始前1天将相关会议文档发送到各参会者，进行提前阅读留评
- 会议开始时首先快速的过一遍整体会议内容，然后再针对留评内容进行重点讨论
- 在评审过程中参会人提出的针对需求内容无法在评审时解决的问题，或者待确认的点需要记录会议Action，会议Action一般情况下又可分为非阻塞型Action以及阻塞型Action，非阻塞型Action一般为参会人对于需求的建议、或者疑问，产品可选择性听取，阻塞型Action为参会人针对需求提出的产品在会后必须要确认解决的问题，评审会议的通过最终以所有阻塞型Action都已解决为准。
区分阻塞型Action以及非阻塞型Action的原因如下：
根据以往需求评审的会议经验，在会议时参会者往往会提出很多关于需求方面的建议、疑问，产品往往在会后会优先确认解决那些自己认为比较重要的问题，这样就在参会者以及产品经理之间出现了信息差，导致会后对于需求而言重要的问题没有解决就进入开发阶段或者是将大量的精力用在不重要的问题上造成资源浪费。
1.1需求初评：
产品经理产出需求文档后，产品团队内部成员对需求进行的评审称之为需求初评，需求初评可以很大程度上提前识别那些价值不够高的需求，以免进入后续的流程，提高迭代效率，主要着重于评审需求的价值点以及合理性，评审会议应按照规定根据上面的评审会议流程进行，当所有阻塞型Action解决后方可进入下一流程。
1.2正式评审：
正式评审是产品、交互、开发、测试核心针对需求实现难度以及性价比进行的评审，当然开发人员根据以往上线功能的数据，认为本次需求价值、合理性存在问题的地方也可以提出建议或疑问作为阻塞型Action，阻塞需求评审不予通过。
这里说一点自己的看法，现在软件开发推崇的敏捷迭代一个开发周期只有2-3周的时间，特点是迭代周期短需求数量多，很多没有进行长期规划的项目上线后往往会造成效果不理想或者破坏整个产品完整性的情况，所以一定要投入更多的精力在需求评审中，对于开发人员而言切记并不是所有评审的需求都需要投入开发，要结合实际情况进行判断。
1.3交互评审：
针对交互稿进行评审，评审时核心关注交互实现的难易度、完整性、性价比，To B需求应优先以现有的组件库进行交互设计，提高开发效率。
2.项目开发阶段：
项目评审阶段结束时应确保以下两件事都已完成：
- 项目需求文档、交互文档关于项目所需开发功能点描述都已清晰完整，边界情况都有涉及
- 项目所有待开发功能点相关信息等产品和开发都已达成一致
- 与开发内容所依赖的二方业务资源都已就位，不会在开发过程中因其他资源问题导致项目延期等问题
2.1确定排期
在项目需求都已清晰完整后接下来就进入了排期阶段，各端开发需要根据需求文档进行人日预估，确定设计时间、开发时间、联调时间、bugfix时间、提测时间，之后项目PM再根据各端预估人日和资源排期情况，确定项目用例评审时间点、冒烟时间点、验收时间点、发布时间点、放量节奏等来完成项目最终的Roadmap，接下来就是各端开发根据项目Roadmap进行开发了。
2.2设计评审
对于耗费人日较多的项目一定要遵循设计先行原则，先有完整的设计文档然后再投入开发写代码。根据以往的经验开发前先完成方案设计可以很大程度上避免开发过程中的返工、线上故障、代码质量不高的问题，提高开发效率，减少资源浪费，尤其对新同学很有帮助，同时项目设计文档也可作为公司资源的一部分沉淀下来，为后续开发人员接手项目提供帮助。
设计评审一般由服务端进行发起评审人员包括各端开发，核心确认项目实现方案完整合理，以及将各端需要对接的资源进行同步，这其中比较重要的就是项目接口评审，好的接口设计应遵循一定的规范，比如大小写命名方式、是否具有语义化。
补充一点就是对于各端开发来说，如果遇见耗时较久或者开发较复杂的项目建议也最好先提前做好要开发内容的设计，这样对最终的代码可维护性很有帮助。
2.3用例评审
在正式投入开发的2-3天后，测试应根据本次迭代所要开发内容完成用例文档并向开发提供，最终项目开发完成所有交付功能以满足用例文档所有用例为准。
3.项目测试阶段：
3.1冒烟预演
在项目所有功能开发完成后，开发应根据用例文档对项目所有功能进行预演，当所有用例通过后交付给测试进行其他内容回归、边界测试等内容，此时便进入提测阶段。
3.2项目验收
当项目测试完成后便来到了最终的上线验收阶段，该过程是最后一次对项目所有功能点进行check，除此之外还需要确认清楚各相关应用的发布顺序、发布流程、回滚方案、灰度节奏，发布顺序的确认可以有效避免因应用发布顺序有误导致项目出现故障。
4.项目上线阶段：
4.1数据观察
在项目上线后开发人员应及时根据项目当中的相关数据埋点对项目功能的使用情况进行统计分析，该数据将对后续该产品迭代的相关决策提供帮助。
4.2项目迭代Reivew
以月为周期，在月底的时候我们一般会针对这一个月内的相关项目开发情况进行项目迭代Reivew会议，希望通过Review会议找出在这一个月的项目开发过程中，项目开发流程本身是否存在改进的地方，项目迭代流程是否存在执行不到位的情况，从而对项目迭代流程不断地进行优化，提高产研效率，同时对在开发中做的比较好的点进行倡导鼓励。
最后
刚开始工作时个人也对项目迭代流程产生过困惑，为什么一定要有这么复杂的流程，是不是有些过于形式主义了？但后来理解从大的方向上讲公司任何流程相关的东西本质上都是为了生产可以规范标准化的进行，核心是可持续生产价值，从实际出发在经历一年多的项目开发后也深刻的明白了上面所讲的每一步都是为了保障项目迭代开发可以安全、高效的进行，每一步都具有存在的意义：比如设计评审就是因为在我们的代码中经常出现因没有提前的设计导致代码的维护性、健壮性出现问题，从而导致更多的bug，严格进行用例评审的原因是往往会出现在进行提测时开发所开发的功能与最终PD所设想的内容不符，后来就增加了这一环节，比如我们也曾因发布顺序未进行约定好而导致线上故障，后来就在项目验收时增加了这一流程。
