Agile 与 Scrum 入门课程
五节课打好 Agile 与 Scrum 基础：宣言原则、角色、事件、工件、规划、估算和规模化。
你将学到
- 解释 Agile 的四个价值观和关键原则。
- 描述 Scrum 的三种角色及其职责。
- 用 Scrum 事件建立检查与调整的节奏。
- 把 Scrum 工件与承诺对应起来。
- 在真实团队中运用规划、估算和规模化概念。
开始前准备
- 了解基本软件团队。
- 对项目管理或产品交付感兴趣。
- 约 75 分钟学习时间，并定期练习。
课程 1 敏捷思维与宣言原则
Agile 宣言重视个体与互动、可工作的软件、客户协作以及响应变化。十二条原则说明如何落地：尽早交付价值、欢迎需求变化、业务与开发每天协作、围绕有动力的人构建团队、使用面对面沟通并定期反思。在敏捷中，流程是工具而不是目标，团队通过检查结果快速调整。先从每个价值观对应一种可观察的团队行为开始。
价值观落地：把每条宣言价值观变成可观察的团队行为。个体与互动意味着每天进行简短交流，而不是只依赖工单。响应变化意味着获得新信息后重新排列待办列表，而不是坚持原计划。
回顾时用原则当检查清单：是否尽早交付价值、欢迎变化、每天协作、定期反思？每次评审后为下个 Sprint 提出一项改进。
示例
团队每两周交付一个小功能并根据客户反馈调整，就是在应用频繁交付与客户协作。
示例：客户在 Sprint 中提出变更需求。
团队先检查变更是否已包含在 Sprint 目标中。如果没有，就加入产品待办列表，并在下次规划时讨论优先级。
这既体现响应变化，又不破坏 Sprint 目标。
课程 2 Scrum 角色与职责
Scrum 团队包含三种职责：一位产品负责人、一位 Scrum Master 和开发者。产品负责人拥有产品待办列表并最大化价值。Scrum Master 教练团队使用 Scrum、清除障碍并帮助组织理解框架。开发者负责每个 Sprint 交付可用的增量，并自行决定如何完成工作。Scrum 中没有项目经理角色，团队围绕清晰目标自管理。
职责测试：对任何任务先问属于哪个角色。产品负责人决定价值和优先级；开发者决定如何构建增量；Scrum Master 帮助团队使用 Scrum 并清除障碍。如果任务无人负责，团队要决定放在哪里。
注意职责不等于职位：开发者可以指导其他开发者，但 Scrum Master 的职责仍由一人承担，负责框架的正确使用。
示例
产品负责人决定下一个有价值的功能；开发者选择如何实现；Scrum Master 帮助移除障碍。
示例：一个障碍阻止团队测试功能。
开发者在每日 Scrum 中说明障碍。Scrum Master 帮助清除或上报，产品负责人决定该功能是否仍是优先事项。
每个角色都履行自己的职责。
课程 3 Scrum 事件与 Sprint
Sprint 是不超过一个月的时间盒，包含其他 Scrum 事件：Sprint 规划、每日 Scrum、Sprint 评审和 Sprint 回顾。Sprint 规划创建 Sprint 目标和 Sprint 待办列表。每日 Scrum 是开发者 15 分钟的计划会。Sprint 评审与干系人检查增量并更新产品待办列表。Sprint 回顾帮助团队改进流程。每个事件形成检查与调整的节奏。
事件目的卡：Sprint 规划产生目标和计划；每日 Scrum 让开发者同步；Sprint 评审与干系人调整产品；Sprint 回顾改进流程。如果某个事件没有明确产出，就缩短时间或改变准备方式。
把 Sprint 当作容器：不要开始与 Sprint 目标冲突的新工作。范围必须变化时，先与产品负责人沟通，再决定是否取消 Sprint。
示例
Sprint 规划回答做什么和怎么做；每日 Scrum 保持团队同步；Sprint 评审调整产品；回顾改善流程。
示例：Sprint 期间团队发现代码结构的小改进。
先记入待办列表并完成 Sprint 目标。回顾时再决定下个 Sprint 是否实施改进。
这样既保护 Sprint 目标，又保留经验。
课程 4 Scrum 工件与承诺
产品待办列表是所有产品工作的有序清单，其承诺是产品目标。Sprint 待办列表是选中的工作加计划，其承诺是 Sprint 目标。增量是 Sprint 中交付的可使用产品价值，其承诺是完成的定义。这些工件让工作透明、聚焦且可衡量。团队持续梳理待办列表，让条目足够清晰以支持规划。
透明检查：任何时刻，产品待办列表都应显示接下来要构建什么，Sprint 待办列表显示团队正在做什么，增量应可正常使用。任何工件不清晰就先梳理再规划。
一致使用完成的定义：写完代码不算完成。必须经过测试、必要时补充文档，并由团队接受后才算增量的一部分。
示例
当条目清晰、有价值且足够小，团队可以估算并完成时，它才适合进入 Sprint。
示例：开发者说用户故事已完成，因为代码写完了。
团队对照完成的定义：测试通过、没有未解决的评审意见、功能在增量中可用。
任一项未满足，故事就不算完成。
课程 5 敏捷规划、估算与规模化
敏捷规划分为多个层级：产品愿景、产品目标、发布规划、Sprint 规划和每日规划。团队用故事点等相对单位估算，用速度预测容量，并在规划前梳理待办列表。好的用户故事遵循 INVEST：独立、可协商、有价值、可估算、小、可测试。规模化时，SAFe、LeSS、Nexus 等框架增加协调，但不替代 Scrum 的经验主义核心。
估算练习：用已知参考项比较故事，而不是猜测小时数。用斐波那契式故事点估算，每个 Sprint 后比较计划点数和实际速度。速度稳定时用它预测；不稳定时缩小批次。
规模化框架会增加协调层：SAFe 增加项目群和投资组合层级，LeSS 扩展单一产品团队，Nexus 协调多个 Scrum 团队。检查与调整的经验主义循环在每一层都适用。
示例
团队用最近三个 Sprint 的速度预测下一个 Sprint 大概能交付多少故事点。
示例：团队最近三个 Sprint 分别交付 18、20、19 个故事点。
平均速度是 19，因此下个 Sprint 计划约 19 点，规划后根据情况调整。
新条目较大时，先拆分再承诺。