Document

一 参加需求对称(评审)会议

时间：在产品设计完成以后，进入正式的开发流程之前
组织者：产品&项目经理
目的：统一大家对产品的认识，及时发现产品设计缺陷，尽可能降低后续修改需求的频率
参与者：产品，项目经理（有的话），小组长/小领导，后端开发、前端开发、交互设计（有的话）、视觉设计（有的话）；需求来源方（有可能的话）
形式：会议

二 自行需求分析梳理

主要是分析关键功能、应用场景等；基本上在需求评审和分析阶段就对项目的整体实现方案有个基础设计；
对核心功能的实现难度有个清晰的认识、方案不清楚的时候需要提前做好技术调研；
一方面可以给出一个比较准确的排期；另一方面避免了自己在真正开发的时候遇到难以解决的方案，推倒重来，非常狼狈

举例：需要实现7个tab的table数据展示，包括分页及排序功能，其中对其中1个tab的表格某字段进行排序，其他几个tab的表格数据也跟着排好。

1. 研究竞品/类似功能是如何实现的
   如：实现多个表格联动排序
   前端通过请求1个接口接收7个tab的数据，在前端实现分页排序。
   

   得出实现思路：7个tab表格数据放到1个tableData

2. 网上搜索/项目代码里面查找/自行思考类似功能如何实现：
   如：实现表格分页展示
   

3. 备忘：
   和后端沟通，敲定通过1个接口请求7个tab表格数据方案是否可行

三 拆分任务&定排期

1. 产品在需求管理网站上建需求，小组长分配任务
2. 后端、前端分别拆分任务，进行排期

四 参加迭代设计会议

1. 产品展示完整原型，确认要做的需求
2. 后端展示接口设计
3. 敲定排期

五 开发阶段

按排期开发，中间有任务延期合理评估，如有需要提前通知各方(小组长、后端、测试、产品)；
中途测试方会有测试用例文档产出，尽可能留意，完善开发细节点，后续也可以参照测试用例文档适当自测

六 测试阶段

开发进行自测后提测，提前预留修改bug时间

七 产品验收阶段

提前预留修改验收问题时间

八 上线

处理分支代码，前端负责人review代码，处理分支(合并分支等)，部署上线

九 参加迭代回顾会议

测试输出文档，全员参加