敏捷开发模式 （小步快跑，注重计划和总结）
大型的项目或产品会拆分成， 版本 > story > 模块 这样的三层进行开发，针对一个story或者大型功能模块，流程是这样的：
需求评审
一般由PM发起，项目组所有成员都参与，目标是所有成员详细了解需求方案：
- 产出原型交互稿和UC实例
- 项目组所有成员统一需求认知
- 初步评估需求方案，技术可行性
- 预估项目容量
设计评审（简单项目可忽略）
这里说的设计，不简单指UI/UE的设计，包含技术方案的设计，一般由RD/FE发起，目标是敲定所有技术点的实现方案：
- 项目组成员间沟通各技术点实现方案（具体针对复杂业务逻辑）
- 确定各端交互的方式，以文字和设计稿的形式留存
- 评估详细排期
用例评审（测试用例）
一般由QA同学发起，项目组成员全部参加，评审测试用例的准确性和完整性，目标是所有成员详细了解并产出最终的测试用例。
在过程中我们需要：
- 关注测试用例是否覆盖到所有情况，是否有欠妥的部分
- 可以借助测试用例review开发的内容
评估排期
- 根据需求功能点划分出：Story（用户故事）,AC（验收标准）和对应的TC（测试案例）
- 对需求进行尽量细的功能点拆分，有助于准确评估排期
- 根据实际项目情况，预留适当的buffer时间
一个 Feature（功能）会由几个Story组成。若Story过大，还可能会拆分成子Story。若Story描述的比较具体，则可以直接拆分出几个AC。每个AC又可以拆分出几个TC来作为实际编码与测试的准则。不论是Story,AC还是TC，都应尽可能满足这些特点：完整性，正确性，可行性，可验证性，无歧义性，一致性，必要性，划分优先级
Story
作为用户故事：其描述的是用户的需求，是功能的简短描述，细节应该在客户团队和开发团队的讨论中产出。也就是说，用户故事不是确定不变的详细设计说明书。
2. AC
AC一般作为User story（用户故事）卡的一个重要组成部分出现，针对user story内容进行说明和解释。每一条AC都应体现出业务价值，是story的功能集，是story交付时必须满足的一组条件
作为验收标准：不是大而全的详细设计，AC只是故事完成的必要的条件。AC的内容也只是关于关键或重要事情的简短描述，是客户或PD验收功能的主要依据。
AC应当具有完整性（完整列出Story的验收标准），正确性（应符合自然逻辑），可验证性（可以很方便的进行验证），无歧义性（所使用的描述语言应尽量严谨，规范，通用，标准，专业），一致性（AC或Story之间不能有逻辑冲突）。
AC点辅助团队理解需求，提高需求质量，减少理解不一致造成的分歧、返工。AC还可以控制Story可以完成什么，不用完成什么，甚至该怎么完成。
3. TC
TC：也是User story的一个重要补充，是AC的具体实现。TC应该比AC更加详细，不止包括AC的所有内容，还应包括很多异常测试用例，以确保系统对异常能正确的处理。
故事卡开发
-
采用分支开发分支发布的方式，而不是分支开发主干发布,一般是项目组各成员独自开发，目标是达到可联调状态。\
-
一般项目都是前后端独立开发，前端采用本地devserver + proxy/mock的方式（接口有现成的就用proxy，没有则用mock平台伪造数据）
联调
- 需各端功能开发均已完毕才可开始
- 在联调过程中覆盖大多数测试用例
求助与风险
验收
- 由RD/FE发起，邀请PM/UI/UE等角色，对产品进行全方位的验收，目标是完整流程通过，保证无遗漏需求
测试
- 提测给QA的代码必须通过自测和验收
- 提供编译后代码，保证与上线代码一致性
- 严禁使用QA环境调试bug
- 阻塞测试流程的bug及时修复
- 其余bug可定期统一修复
- QA验收通过后，交付PM验收（可以同步进行，无时间节点区分）
上线
- QA通知可以发布线上，由RD/FE发起，目标是把项目代码部署到线上
