2-敏捷软件开发

第一部分：为什么需要敏捷

软件开发的现实困境

一个熟悉的场景：客户说「我要一个学生选课系统」——第 6 周需求规格说明书评审通过（400 页 UML），第 12 周编码中客户又说「其实我们还想要手机端」，第 20 周交付演示时客户皱眉：「这不是我想要的。」

灵魂拷问：问题出在哪一环？是需求没写清楚，还是流程本身就有问题？

CHAOS 报告

Standish 集团（1994–2020 长期跟踪数万个项目）：

• 需求变更是首要失败因素
• 平均超支 >40%，超期 >60%
• 大型项目失败率约为小型项目的 2 倍
• 结论：软件项目的敌人不是「复杂」，而是「不确定性」

瀑布模型的问题

瀑布模型（Royce, 1970）：需求 → 设计 → 编码 → 测试 → 运维，各阶段顺序执行、不可回退。它的隐含假设与软件开发现实对比：

瀑布的假设	软件开发的现实
需求稳定不变	需求必然随认知深化而变化
前期设计可以完备	很多设计决策只有写了代码才能验证
缺陷越晚发现越便宜	恰恰相反——越晚发现修复代价越高（10–100 倍）
客户知道自己要什么	客户往往看到之后才知道要什么

讽刺的是：Royce 本人把「一次做完、不回头」当作反面教材，主张带反馈回路，业界却把它当标准流程推广了三十年。

重量级方法论之痛

• 文档驱动：需求规格说明书、概要设计、详细设计、测试计划……文档写完已经过时
• 流程驱动：CMM/CMMI 5 级评估、ISO 9000、阶段闸门评审、变更控制委员会
• 工具驱动：UML 9 种图全套画完，工具产出被误认为价值本身
• 共同症状：团队 60% 的时间在「证明自己在做事」，只有 40% 的时间真正交付客户可用的软件

敏捷的诞生

• 1990 年代：Scrum、极限编程、动态系统开发方法等「轻量级方法」各自萌芽
• 2001 年 2 月：17 位软件开发者在美国犹他州雪鸟（Snowbird）开会，产出《敏捷软件开发宣言》
• 2005 年：敏捷联盟成立
• 2010 年代：Spotify 模型、DevOps、规模化敏捷框架
• 2020 年代：AI 编程时代，敏捷理念被重新审视

敏捷不是一种具体方法或固定流程，而是一种价值观、一组原则、一个方法家族、面对不确定性时的思维模式。

第二部分：敏捷宣言

4 条价值观

我们一直在实践中探寻更好的软件开发方法，并帮助他人也这样做。由此我们建立了如下价值观：

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

也就是说，尽管右项有其价值，我们更重视左项的价值。

价值观	解读	落地
个体和互动 > 流程和工具	再好的工具替代不了人与人沟通	每日站会、结对编程、开放办公
工作的软件 > 详尽的文档	衡量进展的首要指标是能跑起来的软件	每个迭代末演示可运行版本
客户合作 > 合同谈判	客户是队友不是甲乙方	产品负责人深度参与
响应变化 > 遵循计划	计划是假设，变化是事实	迭代计划会、需求池精炼、拥抱变更

「X 高于 Y」不代表抛弃 Y——文档、计划、合同、工具都还要，只是不再是「神」。

12 条原则（分三组）

客户与交付：

#	原则	落地实践
1	最高优先级是通过早期和持续交付有价值软件让客户满意	最小可行产品、增量交付
2	拥抱需求变更，即使在开发后期	需求池精炼、变更友好
3	频繁交付可运行的软件，周期越短越好	迭代 2–4 周
7	可运行的软件是衡量进展的首要指标	迭代评审现场演示

团队与协作：

#	原则	落地实践
4	业务人员和开发人员必须每日共同工作	产品负责人常驻、结对
5	围绕有积极性的个体构建项目，给予环境和信任	自组织团队
6	面对面交谈是最高效的信息传递方式	站会、白板、共同办公
8	倡导可持续开发，节奏应能长期维持	拒绝英雄式加班
11	最好的架构、需求和设计出自自组织团队	无强指派、集体决策

技术与改进：

#	原则	落地实践
9	持续关注技术卓越和良好设计	重构、测试驱动开发、持续集成
10	简洁——最大化未完成工作量的艺术	「你不会需要它」原则、最小可行产品
12	团队定期反思如何更有效，然后调整行为	迭代回顾会、持续改善

第三部分：主流敏捷框架

Scrum：3-3-5 骨架

• 3 个角色：产品负责人（管需求优先级、代表客户）/ 敏捷教练 Scrum Master（服务型领导，移除障碍、守护流程）/ 开发团队（3–9 人自组织）
• 3 个工件：产品待办列表 / 迭代待办列表 / 产品增量
• 5 个事件：迭代（Sprint）/ 迭代计划会 / 每日站会 / 迭代评审会 / 迭代回顾会

Scrum 迭代节奏（2–4 周，时间盒固定）：

迭代 N
├── 迭代计划会（≤8h）→ 确定迭代目标 + 拆解任务
├── 每日站会（15min/天）→ 昨天做了啥 / 今天做啥 / 有啥阻碍
├── 开发工作（编码 + 测试 + 集成 + 文档同步进行）
├── 需求池精炼 → 为下个迭代准备候选用户故事
├── 迭代评审会（≤4h）→ 向客户演示可运行增量，收集反馈
└── 迭代回顾会（≤3h）→ 团队自省 + 承诺改进行动

迭代目标比具体任务更重要——任务可以调整，目标不能轻易改。 完成定义：代码合并 + 单元测试通过 + 代码评审完成 + 集成测试通过 + 文档更新 + 演示可跑。不达成完成定义 = 不算完成，不进增量。

极限编程（XP）

核心价值观：沟通 · 简单 · 反馈 · 勇气 · 尊重（Kent Beck, 1999）

关键实践：结对编程 / 测试驱动开发（红→绿→重构）/ 持续集成（每天多次合并）/ 重构 / 简单设计 / 集体代码所有权 / 编码规范 / 可持续节奏（每周 40 小时）/ 现场客户 / 小版本频繁发布

Scrum 与 XP 的关系：Scrum 管「做什么、何时做、谁来做」（管理框架），XP 管「怎么做才能做好」（工程实践）。业界常见「Scrum 骨架 + XP 肌肉」。

看板方法

五大核心属性：可视化工作流 / 限制在制品数量 / 管理流动 / 明确过程策略 / 协作改进

「停止启动，开始完成」——在制品上限逼你先完成手头工作再启动新任务。

维度	Scrum	看板
节奏	固定迭代（2–4 周）	持续流动，无固定节奏
变更	迭代中锁定	随时可加入新任务
度量	燃尽图、速率	前置时间、累积流图
适用	产品迭代开发	运维、技术支持、持续交付

三框架对比

维度	Scrum	极限编程	看板
定位	管理框架	工程实践	流动管理
节奏	2–4 周迭代	1–2 周迭代	无固定节奏
强项	结构清晰、易上手	代码质量高	灵活、适合运维
弱项	仪式易形式化	门槛高、纪律严	缺乏节奏感

本课程建议：Scrum 骨架 + XP 工程实践 + 看板可视化 = 16 周项目实践的混合方案。

第四部分：关键实践与工具

用户故事与 INVEST 原则

模板：作为 <角色>，我想要 <功能>，以便 <价值>

例：作为学生，我想要用学号登录系统，以便快速查询他的课表

INVEST 六条标准（Bill Wake 提出）：

字母	含义	反例
I 独立	故事之间尽量独立可交付	登录+选课+成绩全塞一个故事
N 可协商	故事是讨论起点，不是合同	写成规格说明书，字字不能改
V 有价值	对客户有可感知的价值	「重构数据库连接池」客户无感
E 可估算	团队能估算其规模	「支持大数据量」无法量化
S 足够小	一个迭代内能完成	一个故事 = 一个月工作量
T 可测试	有明确的验收标准	「界面美观」无法判定通过

验收标准与估算

• 验收标准（给定-当-那么三段式）：给定学生已登录 → 当点击「我的课表」→ 那么显示本学期所有课程。每个故事至少写 3 条。
• 故事点：斐波那契数列 1, 2, 3, 5, 8, 13, 21。1 分 = 改个文案；3 分 = 新增一个简单表单；8 分 = 涉及 3 个模块；21 分以上 = 太大必须拆分。
• 规划扑克：每人同时出牌，避免「锚定效应」。
• 速率：团队每个迭代能完成的故事点数，用于预测剩余需求池。

速率是团队级指标，禁止用于个人考核。

每日站会 · 迭代评审 · 迭代回顾

• 每日站会（15 分钟，站着开）：三个问题——昨天为达成迭代目标做了什么？今天打算做什么？有什么阻碍？站会不讨论技术方案。
• 迭代评审会：现场演示可运行软件，收集反馈，更新需求池。不是 PPT 汇报会。
• 迭代回顾会：四段式——建立安全氛围 → 收集数据 → 产生洞察 → 决定行动。

回顾会黄金规则：对事不对人；每人至少说一条改进建议；每次只挑 1–2 条真正去改；下次回顾会先检查上次行动项。

工具生态（含国产方案）

类别	国际主流	国产/高校友好
项目管理/看板	Jira、Trello	Teambition、飞书项目、PingCode、禅道
文档协作	Confluence	飞书文档、语雀
代码托管	GitHub	Gitee（校园网快）
持续集成/部署	GitHub Actions	云效、Gitee Go
AI 编程助手	Copilot、Cursor	Qoder CN（阿里）、Trae（字节）、CodeBuddy（腾讯）、CodeGeeX（智谱）
即时沟通	Slack	飞书、钉钉

选型三原则：① 团队已经在用的优先 ② 免费/学生版优先 ③ 能整合的优先。16 周项目实践中，建议全组统一一套工具链。

第五部分：AI 时代的敏捷 + 16 周落地路径

AI 时代的敏捷实践

敏捷仪式	AI 如何加持
需求池精炼	大模型辅助拆解用户故事、生成验收标准
结对编程	AI 编程助手作为「第三个人」
代码评审	AI 先做静态检查和风格检查，人聚焦设计与业务逻辑
站会/回顾	自动生成进度摘要、提炼行动项
文档	从代码和提交记录自动生成接口文档、变更日志

⚠ 提示词就是新的需求文档——写不清需求，AI 生成的代码谁负责？提交者负责。AI 不是免责金牌，敏捷核心没变：个体互动、可运行软件、客户合作、响应变化。

敏捷实施的常见误区

• 僵尸 Scrum：仪式都在做但没有灵魂
• 敏捷 ≠ 没计划：敏捷做滚动式计划——长期粗、短期细
• 敏捷 ≠ 没文档：要「刚好够用的文档」，服务于沟通而非合规
• 敏捷 ≠ 更快加班：违反原则 8（可持续节奏）
• 敏捷 ≠ 换个头衔：权责必须真转移

判断一个团队是否真敏捷的唯一标准：当需求变了，团队的反应是「拥抱」还是「抱怨」？

16 周项目实践：敏捷落地路径

周次	阶段	关键活动	交付物
第 1 周	迭代 0·组建	团队组建、角色分配、工具链选型、编码规范	团队章程
第 2 周	迭代 0·探索	需求收集、撰写用户故事、初始化产品待办列表	需求池 v1（≥30 个故事）
第 3–6 周	迭代 1（4 周）	计划会→站会→评审→回顾；聚焦最小可行产品	最小可运行产品
第 7–10 周	迭代 2（4 周）	功能扩展 + 用户体验优化	v0.5 + 速率数据
第 11–14 周	迭代 3（4 周）	质量强化 + 性能优化 + 文档补全	v0.9 + 测试报告
第 15 周	迭代 4·收尾	缺陷修复、部署上线、演示准备	v1.0 + 部署文档
第 16 周	结课	项目答辩、总回顾、经验沉淀	结课报告 + 演示视频

建议：迭代 0 不写代码，先把需求池和团队规则建好；每个迭代必须有可运行的东西；站会不缺席；回顾会真的去改至少 1 条。