敏捷开发与 Scrum

🏃 “别等饭做好了再问我想吃什么”

你做了一道菜，花了两小时。端上桌，朋友尝了一口——“我不喜欢吃辣的”。完了，两小时白干了。

如果在做饭的过程中，你每隔 10 分钟就问一次”咸淡怎么样？要不要加辣？“——虽然多问了几次，但最后端上桌的菜一定是对的。

这就是敏捷的核心思想：不要一次性做完所有事情再给用户看——而是做一小部分就让用户验证，根据反馈快速调整。

📐 敏捷诞生背景：2001 年，17 位软件开发者在一家滑雪度假村聚会，总结出”敏捷宣言”。他们发现：瀑布模型在需求快速变化的项目中几乎”必死”——因为等几个月做完用户才看到，需求早就变了。

敏捷不是”无计划”，而是”计划要能快速调整”。

---

📜 敏捷宣言

四个核心价值观：

个体和互动    高于  流程和工具
可工作的软件  高于  详尽的文档
客户合作      高于  合同谈判
响应变化      高于  遵循计划

“高于”的意思是：右边的东西也有价值，但左边的东西价值更高。

十二条原则（精选 6 条）：

1. 尽早、持续交付有价值的软件——让用户尽快用上
2. 欢迎需求变化——即使在开发后期——敏捷利用变化为客户创造竞争优势
3. 业务人员与开发人员每天在一起工作
4. 交付可工作的软件是衡量进度的首要标准
5. 团队定期反思如何更高效——然后调整行为
6. 最好的架构、需求和设计出自自组织团队

---

🏉 Scrum 框架——最流行的敏捷实践

Scrum 是敏捷思想的一种具体实践框架。名字来自橄榄球——“争球”（scrum）是团队紧密配合的象征。

三个角色

角色	谁来做	主要职责
Product Owner（产品负责人）	1 人（通常是产品经理）	确定需求优先级、确保做最有价值的事
Scrum Master	1 人（可以是团队一员）	确保流程顺畅、帮团队排除障碍
开发团队	3-9 人	实际设计、编码、测试

Product Owner 决定”做什么”，Scrum Master 确保”做得顺”，开发团队负责”做得成”。

五个核心事件

Sprint 周期（2-4 周）
┌─────────────────────────────────────────────────────┐
│  开始                     每天 15 分钟              结束    │
│  Sprint 计划 → [每日站会]×N  → Sprint 评审 → Sprint 回顾 │
│  定目标          同步进度        演示成果       反思改进    │
└─────────────────────────────────────────────────────┘

① Sprint 计划会议——定目标

团队和 Product Owner 一起决定：这个 Sprint 要完成哪些功能？

# 类似于：从"待办列表"顶部取出这个Sprint能做完的任务
backlog = [登录, 注册, 搜索, 下单, 支付, 评论]
# 团队评估后：这个 Sprint 做 [登录, 注册, 搜索]
sprint_goal = "用户能注册和搜索商品"

② 每日站会——同步进度

15 分钟，站着开（站着开会就不会拖太久）。

每个人回答三个问题：

1. 昨天我做了什么？
2. 今天我打算做什么？
3. 遇到了什么阻碍？

③ Sprint 评审——演示成果

Sprint 结束时，团队向 Product Owner 和相关方演示可运行的软件。

④ Sprint 回顾——反思改进

团队内部讨论：哪些做得好？哪些可以改进？下个 Sprint 尝试什么改变？

Keep（保持）：每日站会准时
Problem（问题）：代码审查太慢
Try（尝试）：PR 分配 reviewer 后 4 小时内必须审查

🏪 类比：运动会筹备

Product Owner = 体育部长（决定”要办什么项目”） Scrum Master = 辅导员（协调场地、解决冲突） 开发团队 = 各班同学（实际布置、组织、清理）

Sprint = 每周一次的”小比赛日”（迭代交付） 站会 = 每天早上 5 分钟碰头（“昨天搬了桌子，今天画加油海报”） 回顾 = 比赛完了全班讨论”下次怎么更好”

---

🆚 敏捷 vs 传统——实践对比

场景	瀑布/传统方式	敏捷方式
需求变更	走变更审批流程，可能要几周	下个 Sprint 就可以排进去
进度汇报	”完成了 80%“（到底做完没？）	“这 5 个功能已经可用了”
用户看到产品	项目结束时	每个 Sprint 结束时
发现问题	通常在测试阶段	每 2 周就有反馈
文档	需求文档 100 页	用户故事卡片

---

📝 小结

概念	一句话
敏捷（Agile）	迭代增量、拥抱变化——小步快跑
Scrum	最流行的敏捷框架——角色 + 事件 + 工件
Sprint	2-4 周的迭代周期
Product Owner	确定”做什么”
Scrum Master	确保流程顺畅
每日站会	15 分钟同步——昨天/今天/阻碍
Sprint 回顾	定期反思改进——这是敏捷能”自我优化”的关键

🎯 小练习：你和 3 个同学要做一个课程项目（学生选课系统），用 4 周时间完成。请设计一个简化的 Scrum 流程——每个角色怎么分配？Sprint 多长？站会怎么开？

为什么先学这个？ 敏捷讲”怎么管理开发过程”，但实际的协作需要工具来支撑——版本控制（Git）是团队协作的基础设施。