图：流沙的萌宠。
敏捷培训课程笔记：
1.Sprint开始前
团队制定：
Work Agreement (比如：不迟到早退，每日提交代码、更新ticket状态、Log时间)
DOR：Definition of Ready.可以开始干活的标准。（比如：Story描述有Who, What, Why. AC覆盖至少一个正常流和异常流。）
DOD：Definition of Done.要包括结果和过程。（比如：有QA,有Code Review）
依据敏捷五大价值观：Focus, Courage, Openness, Commitment, Respect
2.Refine Meeting
重点：
梳理Product Backlog
团队估算
时长：Sprint 10%
时间：上一Sprint进行到2/3时
备注：
Product Backlog重点是理解，团队每一个人对需求都理解
Sprint Backlog重点是承诺，团队作为一个整体承诺该Sprint的交付物
User Story =用户可明白的Item. Story需要包含Who, What, Why以及AC（清晰的验收标准）. Story的特点INVEST (独立，可协商，有价值，可估算，Size不能超出一个迭代，可测试)
当Story不好估算时，需要想办法降低需求不确定性或技术不确定性
Product Backlog需要包含优先级，以及关联到产品卖点/产品愿景。产品愿景需要针对典型用户描述具有画面感的愿景。
3.Plan Meeting
重点：
团队定义Spring Goal (该Sprint所有或大部分Story/Task都为某目标服务)
对Story进行拆分，Task颗粒度建议1人天左右
承诺
时长：一周的Sprint不超过2小时
时间：Sprint第一天上午
备注：
如需要，可以在该会议中Review DOD和Update DOD，以作为完成Sprint Goal的标准
团队承诺之前可以参考团队的容量和速度
所有事项必须经过PO才能加到Product Backlog
在Plan Meeting可以认领迭代前几天，比如第一天到第二天或第三天的任务
4.Daily Scrum
重点：
团队一起做目标，进度和风险管理
时长：15分钟
时间：Sprint每一天
备注：
Daily Scrum之后有一个人总结Team离Sprint Goal还有多远、趋势怎样、风险在哪里、大家做得开不开心
5.Sprint Review
重点：
根据产品增量和客户反馈修正Product Backlog
PO建议下一Sprint的Candidates
时长：一周的Sprint不超过1小时
时间：Sprint最后一天上午——因为下午要开Retrospective
备注：
PO可以建议下一Sprint做什么，但是只有团队具有决定权（在Sprint Plan时才最终决定）
6.Retrospective
重点：
持续改进（可以Team写小纸条，Scrum Master随机抽讲）
Scrum Master维护&更新Improvement Backlog
时长：一周的Sprint不超过0.75小时
时间：Sprint最后一天下午
备注：
Manager不能参加Retrospective
可以在Retrospective会议上Review DOD、DOR和Work Agreement
改进范围可以超越Sprint
Improvement Backlog可以参考Team Goal, Team Norm, Value
其他：
学习三境界：遵守、突破、脱离。
自组织CDE模型：边界、人的差异带来的价值、交流转换
把透明做到极致
每个环节有各自的专注
Motivation --> Relationship --> Output
Forming --> Storming --> Norming --> Performing循环。团队规范可以通过一些仪式来强化引导。
阅读原文