scrum敏捷框架回顾
- 迭代定义
scrum 敏捷按迭代执行，每个迭代的长度敏捷团队自己定义，给出的建议是1～4周。
敏捷成熟度低的团队、习惯按项目制的团队转型可以暂时选择较长的时间周期。
稳定后，建议使用2周做一个周期，这样能有一个比较舒服的节奏。 - 迭代日历
稳定的、有节奏的团队，是会按照一个固定的迭代日历来进行敏捷活动。
下表是一个迭代日历的excel事例，固定安排每个敏捷活动的具体日期和时间。
固定的原因是让团队养成统一的习惯。
image.png
scrum敏捷会议的高效执行
scrum 框架下的会议：早会、需求梳理会（PRD评审会）、迭代计划会、迭代评审会
团队可以按照自身的特点来设计和简化，毕竟很多人吐槽，与原来的项目管理方式比较，会议太多了。开会是个成本非常高的事情 ，提前定义好规则，做好计划就显得尤为重要。
需求梳理会：
时间：迭代第二个周三 1h30min
注意点：
[小需求]集中评审
大需求（>10人天），建议周三前召集研发提前参与讨论，合作及时落地
技术方案，鼓励在团队中自主浮现，大需求的负责人应该轮流
目标：
根据准入标准，评定通过的需求
明确需求的研发负责人
初评需求优先级
初定上线日期
迭代计划会（含迭代评审）：
时间：迭代第二个周五 ：1h30min
注意点：
识别成员的工作均衡程度
优先级合理安排（根据需求大小、业务紧迫程度、内外部资源）
大需求研发负责人提前准备概要设计
目标：
PO对迭代内需求卡片状态明确（跨迭代、待上线、完成），通晒本迭代的交付情况
针对PRD和概要设计对需求进行描述和讨论，再进行故事点估计
确定进入迭代的技术债
明确任务分派：确定需求的参与人员（研发、测试等）
初版排期确定：研发联调、提测、UAT、上线时间等
迭代回顾会：
时间：迭代第一个周一 1h30min
注意点：
全员参与并发言，鼓励提前维护回顾会看板；提前准备好效能分析
尽量发现Good，剖析自己的不足（自省）
尽量让所有人都能愿意说
目标：
效能分析复盘包括但不限于（完成阶段时长，人均吞吐量，超时未关闭需求）
上个迭代落实项检查
对迭代内事件评价分析
定出计划改进项，明确改进项负责人
按月进行质量问题复盘
每日站会：
时间：每日09:30 ：10~20min
注意点：
每日对着敏捷看板召开
主持人全员轮流，提前检查敏捷看板，异常情况同步
控制时长，避免深入细节
但注意不要轻易打断，可以会后沟通
目标：
识别内外部风险项
是否有资源释放
是否有待定项、需要内外部协调的内容
