全过程图参与者和职能描述产品经理（PM）：需求规划师和设计师。收集用户诉求和反馈，确定需求收益，设计系统功能和交互细节。一线的业务需求，经过PM的消化确认后输出给开发者。必须为每个需求生成准确详细的需求文档。（需求文档需涵盖交互图）开发人员（RD/FE）：根据需求文档，制作技术方案设计文档，开发具体功能。有关所有开发详细信息，请参阅需求文档。如果PM不写，你可以要求它完成。每一个需求都会有一个对应的开发负责人，也叫主开发RD，负责协调和反馈整个开发周期的进度，通常由更改后台主内容的人负责。交互和视觉设计（UI/UE）：负责制作交互图和设计图。交互最终会体现在需求文档中，需要研发人员严格执行，而UI设计图提供了单独的前端，具体实现层面与前端开发协同。很多时候项目中是没有UE的，都是PM自己设计的交互图。测试人员（QA）：根据需求文档制作测试用例，并依靠测试用例对发现的问题进行测试和反馈。主要流程节点需求的划定决定了哪些具体需求可以在本次迭代中开发。每个部门的划定方式不同，但结果是确定了本次迭代的需求池和优先级，返回的业务价值相对较低。或明显不符合规范要求的要求。圈定的意义在于每次迭代都根据产能确定合理的需求，保证整体商业价值最大化。具体实现详见需求描述和执行总结需求评审（以下均为单项需求）发起人：产品经理（PM）参与人：产品经理（PM）、开发人员（RD/FE）、设计师（UI）/UE)），测试人员（QA）需要准备：草稿需求文档（PM），草稿交互图（PM/UE）主要输出：最终确定的需求文档（包括交互），各方时间表和预计上线时间，技术评审时间节点讨论内容：各方需要在需求文档草案的基础上确认各个功能点是否可以/应该实现。在这个环节，所有的异议都需要表达出来，与PM讨论后，确定最终的实施方案，并最终确定为需求文档。此外，还需讨论各方参会人员的排期情况，确定各环节的大致时间节点和投放时间。对于设计和前端的协同，也需要给出一个交付前端设计图的时间节点。最后这个需求的主要开发者需要给出一个技术方案评审，也就是下届会议的具体时间。需要注意的是，如果需求文档定稿后有任何（非细节补充）变更，需要启动需求变更流程，重新安排和预估时间。一般来说，发起需求变更的技术方案评审并不容易。发起人：本二次需求开发负责人（主RD）参与人：开发人员（RD/FE）（包括其他技术骨干，通常是组长等），测试人员（QA）需要准备：技术方案设计稿（RD），接口设计稿的主要产出：技术方案设计定稿、接口设计定稿、前后端联调时间节点、测试时间节点。方案科学合理，最终形成技术方案。同时需要与前端确认界面设计方案，最终确定界面文档。QA也需要参与进来，以便加深对实现的理解，便于编写更有针对性的测试用例文档。方案确定后，才能明确调度方案，所以还需要确定前后端联调时间和测试时间（精确到半天）开发/联调/测试用例编写测试案例评审发起人：测试人员（QA）参会人员：测试人员（QA）、开发人员（RD/FE）、产品经理（PM）所需准备：测试用例草稿（QA）主要输出：测试用例定稿讨论内容：QA依赖对自己的需求文档和技术方案理解并产生系统的测试用例文档。在这次会议上，需要逐案确认PM和RD是否符合预期。会议结束后，需要完成测试用例。定稿后，可以要求RD严格执行用例中每个case项的自测。RD根据测试用例完成自测工作，可以参考提高开发质量，降低测试bug率的讨论。项目测试和测试对测试动作有要求。不同部门不一样。可能是状态管理系统的任务状态修改，也可能是测试邮件。确认。如果QA测试后仍然发现问题，需要提出bug并分配给相应的RD。QA有权回调测试，一般是因为问题太多，主流程跑不通等问题修复四方验收（可选）发起人：本需求开发负责人（主要RD）参与人员：产品经理（PM）、开发人员（RD/FE）、设计师（UI/UE）、测试人员（QA）（可选）需要准备：测试通过后要上线的功能主要输出：确认上线可行性讨论：本次会议是上线前的功能确认，以及设计图的效果确认（也可以提前做设计确认）。一般都是直接运行显示功能。确认通过后，就可以开始准备上线和回归测试了。上线前，RD需要整理CheckList文档，确保上线后的功能符合预期，其他相关功能不受影响。上线成功后，需要配合PM依赖CheckList进行线上验收。验收通过后，整个流程结束。关键文档需求文档（包括交互图）：整个研发流程的核心，定型后不能轻易修改，是整个研发流程的核心基石技术方案设计文档：大部分为后端技术方案，用来保证这个实现是科学合理的，也方便以后查阅测试用例文档：需求评审之后就可以开始写了，测试前一定要完成评审，这是系统性的保证测试也是开发者自测的依赖。OnlineCheckList文档：在线回归需要覆盖的范围。此表格用于避免遗漏
