Scrum敏捷开发：项目流程大纲
PO 角色
- 负责需求的管理、产品路径规划、组织版本验收。维护好产品代办列表、梳理需求优先级排序，对需求ROI负责。
“Product Owner（PO）——用户/客户/业务的代言人，就是可以做出业务决策的人，所谓业务决策包括需求与优先级。”
- 需求产品端生命周期分为：原始需求、已确认需求、待评审需求。
- 版本路线规划
- 采用用户故事地图框架，定义
版本、Epic、story - 采用JIRA 进行上述三要素的规划
- 需求管理：
- 产品经理与业务方的需求采集以及内部规划的需求。（需要筛选的需求）
- 产品经理内部沟通与确认，并归入用户故事地图的需求。（确定是想做的需求，
product backlog） - PO计划组织需求评审会与DevTeam进行沟通讨论的需求列表；
- MVP 原则：起床出门的案例
- 采用用户故事地图框架，定义
- 版本路线规划
SM 角色
“Scrum Master——熟悉Scrum流程的人，指导和确保团队以Scrum的方式进行交付。”
- 指导整个项目组以敏捷和Scrum的方式交付项目，主持各种敏捷会议，比如每日例会、Sprint计划和评审会议、回顾会议等，帮助各交付团队扫除障碍
DevTeam 角色
- 负责迭代开发，为过程负责（需求拆分、工作量评估、需求流转、系统设计、规范开发、质量内建）。
- 研发人员
- 测试人员
- 版本管理员(负责版本、分支管理）
Sprint 周期节奏
Sprint Planning Meeting
- 时间
- 每个Sprint开始的前一至两天，不超过两个小时
- 输入
- 已排好优先级的PBL
- 目的
- 团队明确接下来需要工作的内容；梳理需求不清楚的问题；
- 内容
- 用户故事讲解
- 识别伪需求（什么场景、谁用、使用频次等）
- 验收条件：包括快乐路径与意外场景（DOD，如何定义这个故事开发完成了）
- 拆分用户故事（如果故事太大）
- 估算用户故事
- 距离是常量，时间是变量
- 每个故事需要评估出故事点数
- 设计分析（偏技术，PO可退出讨论）
- 流程、架构
- 用户故事讲解
- 输出
- 经过估算排序的Sprint BackLog
看板设计
- 待办列表：经过sprint planning 会议输出的用户故事清单
- 任务流转：用户故事需要拆分为研发Task进行流转，Task到了提测阶段，已用户故事为单位进行提测；
- 快速通道：第一行是紧急需求快速通道，给紧急临时需求留用，每次只允许一个需求通过。
- 看板形式：采用线上和线下看板结合的形式
- 电子看板：电子看板采用JIRA自有的流程，泳道比较粗（待开发、处理中、已完成）
- 物理看板：每天站会进行更新，泳道细分
- 开发：开发中、自测中
- 测试：待提测、测试中
- 发布：待发布、已发布
- 团队内电子看板，整个团队物理看板
每日站会
- 时间：每天早上九点十分准时开始，以团队为单位在会议室中进行；
- 内容：每人轮流发言（昨天做了什么，今天计划做什么，遇到什么问题），同时移动看板的任务；
- 标准十五分钟，不超过二十分钟
sprint 评审会议
- 什么时候开？
- 测试完成后，由PO发起邀请业务需求方一起参与需求演示；
- 内容
- 本次迭代中，哪些完成了，哪些没完成，没完成的原因是什么？计划什么时候完成。
- 需求业务方下一个迭代比较关注的需求，方便PO及时调整下个迭代的product backlog
- 时长不超过1个小时
sprint 回顾会议
- 什么时候开？
- 部署上线完成后
- 时长不超过1个小时
- 内容
- 充分沟通本次sprint迭代过程中有哪些做得好的，哪些做得不好的，后续如何改进。（PDCA）
- 利用工具：头脑风暴、5WHY法、鱼骨图分析问题
- 识别最有问题，最需要改进的问题，创建改进计划;
- 比如：
- 团队任务太多以至于迭代期间无法完成；
- 团队深陷现存的技术债； 功能开发未能确保持续性，以避免在代码库中引入新的bug；
- 团队的开发习惯没有适时调整；
- Product Owner在迭代过程中更改了优先级，而开发团队则因范围的变更陷入困境；
注意：团队在迭代中遇到困难是常有的事。迭代回顾会议时，团队可以花费点时间探讨一下为什么迭代过程中会发生变更，并制定计划在下一个Sprint中解决问题。
跟踪推进
- 每日站会跟进
- sprint计划会议-产出看板待办事项
- sprint评审会议-业务、产品和研发共同参与
- sprint回顾会议-每次迭代完成后PO、SM、DevTeam共同参与
- 指标
- 燃尽图
- 累计流量图