敏捷开发与项目管理¶
Scrum/Kanban/Sprint/项目管理——高效交付的方法论
📋 本章目标¶
完成本章学习后,你将能够:
- 理解敏捷开发的核心价值观和原则
- 掌握Scrum框架的角色、仪式和产出物
- 学会使用Kanban进行可视化工作管理
- 理解Sprint规划和执行流程
- 掌握常用的项目管理工具和方法
- 学会团队协作和沟通的最佳实践
1. 敏捷开发基础¶
1.1 什么是敏捷开发¶
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。它强调快速响应变化、持续交付价值。
┌─────────────────────────────────────────────────────────────┐
│ 敏捷开发核心价值观 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ 个体和互动 ═══╪═══▶ 流程和工具 │
│ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ 可工作的软件 ══╪══▶ 详尽的文档 │
│ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ 客户合作 ══════╪═══▶ 合同谈判 │
│ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ 响应变化 ══════╪═══▶ 遵循计划 │
│ └─────────────────┘ │
│ │
│ 左侧更有价值 ──────────────▶ │
└─────────────────────────────────────────────────────────────┘
1.2 敏捷十二原则¶
敏捷开发十二原则 (精选)
══════════════════════
1️⃣ 最高优先级:通过尽早和持续交付有价值的软件满足客户
2️⃣ 欣然面对需求变化,即使在开发后期
3️⃣ 经常交付可工作的软件,周期越短越好
4️⃣ 业务人员和开发人员必须每天一起工作
5️⃣ 围绕有激情的个人构建项目
6️⃣ 面对面交谈是最有效的沟通方式
7️⃣ 可工作的软件是进度的首要度量标准
8️⃣ 可持续的开发速度,能够长期维持
9️⃣ 持续关注技术卓越和良好设计
🔟 简洁——以最少的工作量最大化艺术
1️⃣1️⃣ 最好的架构、需求和设计出自自组织团队
1️⃣2️⃣ 团队定期反思如何提高效率并调整
1.3 敏捷 vs 瀑布¶
| 维度 | 瀑布模型 | 敏捷开发 |
|---|---|---|
| 开发方式 | 顺序进行 | 迭代增量 |
| 需求变化 | 难以应对 | 欣然接受 |
| 交付周期 | 项目末期 | 频繁交付 |
| 客户参与 | 前期和后期 | 持续参与 |
| 文档 | 详细完整 | 足够即可 |
| 风险暴露 | 后期暴露 | 早期暴露 |
2. Scrum框架¶
2.1 Scrum概述¶
Scrum是最流行的敏捷框架,提供了清晰的角色、仪式和产出物定义。
Scrum框架全景图
══════════════
┌─────────────────────────────────────────────────────────┐
│ │
│ 产品待办列表 │
│ (Product Backlog) │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Sprint │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Sprint计划 │ ──▶ │ 每日站会 │ │ │
│ │ │ 会议 │ │ (Daily) │ │ │
│ │ └─────────────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Sprint待办 │ ──▶ │ 产品增量 │ │ │
│ │ │ 列表 │ │ (Increment) │ │ │
│ │ └─────────────┘ └──────┬──────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────┐ │ │
│ │ │ Sprint评审 │ │ │
│ │ │ Sprint回顾 │ │ │
│ │ └─────────────┘ │ │
│ │ │ │
│ └──────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 可发布增量 │
│ │
└─────────────────────────────────────────────────────────┘
2.2 Scrum角色¶
| 角色 | 职责 | 关键活动 |
|---|---|---|
| 产品负责人 (PO) | 定义产品愿景、管理需求 | 维护产品待办列表、确定优先级 |
| Scrum Master | 服务型领导、流程守护 | 移除障碍、促进会议、辅导团队 |
| 开发团队 | 交付产品增量 | 设计、开发、测试、文档 |
2.3 Scrum仪式¶
Scrum仪式 (5个)
════════════════
1. Sprint计划会议
─────────────────
时间: Sprint开始时 (最长8小时/2周Sprint)
参与者: 全员
目的: 决定这个Sprint要做什么
输出: Sprint待办列表
2. 每日站会 (Daily Scrum)
─────────────────
时间: 每天固定时间 (15分钟)
参与者: 开发团队
目的: 同步进度、发现问题
三个问题:
• 昨天完成了什么?
• 今天计划做什么?
• 有什么阻碍?
3. Sprint评审会议
─────────────────
时间: Sprint结束时 (最长4小时)
参与者: 全员 + 干系人
目的: 展示成果、获取反馈
输出: 反馈意见、更新的产品待办列表
4. Sprint回顾会议
─────────────────
时间: Sprint评审后 (最长3小时)
参与者: Scrum团队
目的: 改进流程和团队协作
输出: 改进计划和行动项
5. Sprint (Sprint本身)
─────────────────
时间: 固定周期 (1-4周)
目的: 产出可交付的产品增量
2.4 Scrum产出物¶
产品待办列表 (Product Backlog):
描述: 产品所有需求的有序列表
负责人: 产品负责人
特点:
- 动态的,持续更新
- 按优先级排序
- 顶部条目更详细
Sprint待办列表 (Sprint Backlog):
描述: 本Sprint要完成的工作
负责人: 开发团队
特点:
- 团队自主承诺
- 只包含本Sprint工作
- 每天更新
产品增量 (Increment):
描述: 可交付的产品版本
特点:
- 满足定义的完成标准
- 理论上可发布
- 是之前增量的累加
2.5 用户故事¶
用户故事格式
════════════
作为一个 [用户角色]
我想要 [完成什么功能]
以便于 [达到什么目的]
示例:
─────────────────────────
作为一个 购物用户
我想要 将商品加入购物车
以便于 之后一起结算
验收标准 (Acceptance Criteria):
─────────────────────────
✓ 点击"加入购物车"按钮后商品数量+1
✓ 购物车显示正确的商品数量和总价
✓ 未登录用户提示先登录
✓ 商品库存不足时显示提示信息
故事点估算 (Story Points):
─────────────────────────
使用斐波那契数列: 1, 2, 3, 5, 8, 13, 21...
考虑因素:
• 复杂度
• 工作量
• 风险/不确定性
3. Kanban看板¶
3.1 Kanban核心原则¶
Kanban六大实践
══════════════
1️⃣ 可视化工作
- 让工作流程可见
- 使用看板展示状态
2️⃣ 限制在制品 (WIP)
- 控制同时进行的任务数量
- 防止过载,提高效率
3️⃣ 管理流动
- 优化工作流程
- 减少瓶颈和等待
4️⃣ 显式流程规则
- 明确定义流程规则
- 团队共同遵守
5️⃣ 实施反馈循环
- 定期回顾和改进
- 基于数据决策
6️⃣ 协作改进
- 全员参与改进
- 实验和学习
3.2 看板设计¶
典型看板结构
════════════
┌─────────────────────────────────────────────────────────────┐
│ 看板 │
├──────────┬──────────┬──────────┬──────────┬────────────────┤
│ │ │ │ │ │
│ 待办 │ 进行中 │ 代码 │ 测试 │ 完成 │
│ (Todo) │(In Progress) Review│ (Testing)│ (Done) │
│ │ │ │ │ │
│ ═════ │ ═════ │ ═════ │ ═════ │ ═════ │
│ WIP:∞ │ WIP:3 │ WIP:2 │ WIP:2 │ WIP:∞ │
│ │ │ │ │ │
│ ┌────┐ │ ┌────┐ │ ┌────┐ │ ┌────┐ │ ┌────┐ │
│ │TASK│ │ │TASK│ │ │TASK│ │ │TASK│ │ │TASK│ │
│ ├────┤ │ ├────┤ │ ├────┤ │ ├────┤ │ ├────┤ │
│ │TASK│ │ │TASK│ │ │TASK│ │ │ │ │ │TASK│ │
│ ├────┤ │ └────┘ │ └────┘ │ └────┘ │ ├────┤ │
│ │TASK│ │ │ │ │ │TASK│ │
│ └────┘ │ │ │ │ └────┘ │
│ │ │ │ │ │
└──────────┴──────────┴──────────┴──────────┴────────────────┘
WIP (Work In Progress): 在制品限制
3.3 Kanban vs Scrum¶
| 维度 | Scrum | Kanban |
|---|---|---|
| 迭代周期 | 固定Sprint (1-4周) | 连续流动 |
| 角色 | PO/SM/Team | 无强制角色 |
| 在制品限制 | 按Sprint限制 | 按列限制 |
| 变更 | Sprint内不变更 | 随时可变更 |
| 适合场景 | 产品开发 | 运维/支持/持续交付 |
4. Sprint实践¶
4.1 Sprint计划¶
Sprint计划会议流程
══════════════════
Part 1: 做什么? (What)
─────────────────────────
1. PO介绍优先级最高的条目
2. 团队提问澄清需求
3. 确定Sprint目标
4. 选择要完成的用户故事
Part 2: 怎么做? (How)
─────────────────────────
1. 团队分解用户故事为任务
2. 估算任务工作量
3. 确认团队能力
4. 最终承诺Sprint待办列表
输出物:
├── Sprint目标
├── Sprint待办列表
└── 任务分解
4.2 每日站会¶
# 高效站会模板
class DailyScrum:
"""每日站会最佳实践"""
def __init__(self):
self.duration = 15 # 分钟
self.questions = [
"昨天完成了什么?",
"今天计划做什么?",
"有什么阻碍?"
]
def run(self):
"""执行站会"""
# 1. 准时开始
self.start_on_time()
# 2. 每人回答三个问题
for member in self.team:
member.update()
# 3. 发现阻碍,会后解决
if self.has_blockers():
self.schedule_follow_up()
# 4. 控制时间
assert self.elapsed_time <= 15 # assert断言:条件为False时抛出AssertionError
# 站会注意事项
tips = """
✅ DO:
- 站着开,保持简洁
- 聚焦进度和阻碍
- 对着团队说,不是对着Scrum Master
❌ DON'T:
- 不要详细讨论技术问题
- 不要变成汇报会
- 不要超时
"""
4.3 速度与燃尽图¶
Sprint燃尽图示例
════════════════
剩余故事点
│
150 │●
│ ╲
120 │ ●
│ ╲
90 │ ●
│ ╲
60 │ ●───● 实际
│ ╲
30 │ ●
│ ╲
0 │______________________●___ 时间
D1 D3 D5 D7 D9 D11
─────────────────────── 理想
● ● ● ● ● ● 实际
速度 (Velocity) 计算:
══════════════════════
Sprint 1: 完成 30 故事点
Sprint 2: 完成 35 故事点
Sprint 3: 完成 28 故事点
Sprint 4: 完成 32 故事点
平均速度 = (30 + 35 + 28 + 32) / 4 = 31.25 ≈ 31 点
5. 项目管理工具¶
5.1 常用工具对比¶
| 工具 | 特点 | 适合团队 |
|---|---|---|
| Jira | 功能强大,可定制性高 | 中大型团队 |
| Trello | 简单易用,看板风格 | 小团队/个人 |
| Notion | 灵活全能,知识管理 | 知识型团队 |
| Linear | 现代简洁,速度快 | 技术团队 |
| 飞书/钉钉 | 国内协作,集成度高 | 国内团队 |
5.2 任务管理最佳实践¶
任务状态流转
════════════
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 新建 │───▶│ 进行中 │───▶│ 代码 │───▶│ 完成 │
│ (New) │ │(Progress)│ │ Review │ │ (Done) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 取消 │ │ 阻塞 │ │ 返工 │
│(Canceled)│ │(Blocked) │ │(Rework) │
└──────────┘ └──────────┘ └──────────┘
5.3 会议效率¶
## 高效会议清单
### 会前
- [ ] 明确会议目的和议程
- [ ] 邀请必要的人员
- [ ] 提前发送资料
- [ ] 准备好会议室/工具
### 会中
- [ ] 准时开始
- [ ] 指定主持人/记录人
- [ ] 控制时间
- [ ] 聚焦主题
- [ ] 鼓励参与
### 会后
- [ ] 发送会议纪要
- [ ] 明确行动项和负责人
- [ ] 设定跟进时间
6. 团队协作¶
6.1 高效团队特征¶
高效敏捷团队特征
════════════════
┌─────────────────────────────────────────────────────────────┐
│ │
│ 🎯 共同目标 │
│ 团队对目标有清晰一致的理解 │
│ │
│ 🤝 信任与尊重 │
│ 成员相互信任,敢于表达意见 │
│ │
│ 💬 开放沟通 │
│ 信息透明,问题及时暴露 │
│ │
│ 🔄 持续改进 │
│ 定期反思,不断优化 │
│ │
│ 🎓 自组织 │
│ 团队自主决策,承担责任 │
│ │
│ 📈 持续学习 │
│ 鼓励学习,分享知识 │
│ │
└─────────────────────────────────────────────────────────────┘
6.2 团队沟通¶
| 沟通方式 | 适用场景 | 频率 |
|---|---|---|
| 每日站会 | 同步进度 | 每天 |
| 周会 | 计划与回顾 | 每周 |
| 一对一 | 个人反馈 | 定期 |
| 文档 | 知识沉淀 | 持续 |
| 即时通讯 | 日常沟通 | 随时 |
6.3 冲突解决¶
团队冲突处理框架
════════════════
1. 识别冲突
──────────────────
• 技术分歧
• 优先级争议
• 沟通问题
• 资源竞争
2. 分析原因
──────────────────
• 利益冲突?
• 信息不对称?
• 个性差异?
• 流程问题?
3. 解决策略
──────────────────
• 面对面沟通
• 数据驱动决策
• 寻求共识
• 必要时升级
4. 跟进验证
──────────────────
• 确认解决方案
• 持续关注
• 总结经验
7. 面试题精选¶
Q1: Scrum和Kanban有什么区别?¶
参考答案: | 维度 | Scrum | Kanban | |------|-------|--------| | 迭代 | 固定Sprint | 连续流动 | | 变更 | Sprint内不变 | 随时可变 | | 角色 | PO/SM/Team | 无强制 | | 度量 | 速度 | 周期时间 |
Q2: 如何处理Sprint中新增的紧急需求?¶
参考答案: 1. 评估优先级:是否真的紧急? 2. 沟通影响:说明对Sprint目标的影响 3. 权衡取舍:可能需要移除等量的其他工作 4. 团队决策:团队共同决定是否接受 5. 更新计划:如接受,更新Sprint待办列表
Q3: 什么是好的用户故事?¶
参考答案: 遵循INVEST原则: - Independent:独立的 - Negotiable:可协商的 - Valuable:有价值的 - Estimable:可估算的 - Small:足够小的 - Testable:可测试的
8. 最佳实践¶
8.1 Sprint检查清单¶
Sprint开始 - [ ] Sprint计划会议完成 - [ ] Sprint目标已确定 - [ ] Sprint待办列表已创建 - [ ] 任务已分解和估算
Sprint期间 - [ ] 每日站会正常进行 - [ ] 阻碍及时处理 - [ ] 燃尽图正常更新 - [ ] 团队沟通顺畅
Sprint结束 - [ ] 评审会议完成 - [ ] 回顾会议完成 - [ ] 产品增量可交付 - [ ] 改进项已记录
8.2 常见反模式¶
敏捷反模式 (避免)
════════════════
❌ Agilefall
名义敏捷,实际瀑布
❌ 每日站会变成汇报会
只对Scrum Master汇报
❌ Sprint没有增量
结束时没有可交付物
❌ 需求持续涌入
Sprint内随意变更
❌ 技术债务累积
只关注功能,忽视质量
9. 学习检查清单¶
完成本章学习后,请确认你能够:
- 解释敏捷开发的核心价值观
- 描述Scrum的角色、仪式和产出物
- 使用Kanban进行工作可视化管理
- 规划和执行一个Sprint
- 使用燃尽图追踪进度
- 编写高质量的用户故事
- 促进团队高效协作
10. 参考资料¶
推荐书籍¶
- 《Scrum敏捷软件开发》— Ken Schwaber
- 《看板方法》— David J. Anderson
- 《敏捷估计与规划》— Mike Cohn
在线资源¶
相关教程¶
最后更新日期:2026-02-17 适用版本:产品管理教程 v2026