敏捷开发流程整理

背景：按照工作要求，整理了一份组内项目管理流程文档。不过很遗憾，实际工作中无法每一步都做到。

需求分析#

1. Sprint开始前两天，产品经理给出用户故事，完成原型设计
2. 建议产品先进行内部评审，明确后发到群里。
3. 项目成员熟悉原型，提前整理问题

需求评审#

1. 产品说明业务背景、目的、重要性、演示具体功能（针对主干流程和核心功能进行详细讲解）
2. 用户故事评审
3. 明确验收标准

注：如果用户故事或原型设计不通过，需要修改的，建议修改后再次评审

排期#

明确以下几点：

1. 优先级
2. 故事点数
3. 工时
4. 处理人
5. Sprint目标
6. 测试确认测试范围、哪些用户故事需要编写测试用例

设计稿评审#

1. 确认页面风格、交互、用户体验等

注：没有设计稿，前端和产品自己把控。建议明确页面设计和交互后再开发

开发阶段#

1. 前后端开发

2. 测试根据验收标准编写功能点、测试用例。和产品确认后上传至jira

3. 测试用例和用户故事绑定（需要覆盖到每一条验收标准）

4. 开发自测，执行绑定的测试用例

5. 模块负责人确认功能都测试完成后，提测，在测试服发布版本。

6. 测试进行冒烟测试，通过则进入系统测试；不通过退回给研发，研发修复流程阻塞的BUG后再次提测。

7. 测试完成后提交BUG，进入BUG修复阶段

8. 研发确认该缺陷是否有效，如果有效则修复，无效则拒绝修复并备注原因

9. 开发修复后，测试进行BUG回归

注意：系统测试阶段，如无特殊情况不要在测试服发布新版本，避免重测的情况。

产品验收#

1. Demo会上产品按照每个用户故事的验收标准进行验收，评判完成情况，给出验收结果

发布#

1. 当前版本在测试服进行测试后，确认无严重BUG，只遗留少数轻微BUG后，可发布该版本
2. 内部测试通过后，找老板/客户过一遍，再发版

补充#

1. 版本发布后，建议进行业务文档、技术文档整理。
2. 如有需求变更的情况，建议在jira上说明。若变更影响范围较大，需进行评审
3. 每日站会，项目成员汇报进度，用时10-15分钟。