敏捷开发流程整理

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

需求分析

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分钟。