methodology-agile

敏捷方法论技能

提供敏捷软件开发的系统化实践指导,帮助团队实现快速迭代、持续交付和适应变化。

何时使用此技能

当用户请求以下任何内容时使用此技能:

• "敏捷开发"
• "Scrum规划"
• "Sprint计划"
• "迭代开发"
• "用户故事"
• "敏捷实践"
• "站会"
• "回顾会议"
• "持续交付"

核心原则

基于敏捷宣言的4个核心价值观:

1. 个体和互动 胜过 流程和工具
2. 可工作的软件 胜过 详尽的文档
3. 客户协作 胜过 合同谈判
4. 响应变化 胜过 遵循计划

12条敏捷原则

1. 通过尽早和持续交付有价值软件满足客户
2. 欢迎需求变更，即使在开发后期
3. 频繁交付可工作软件（几周到几个月）
4. 业务人员和开发人员每天一起工作
5. 围绕有动力的个人建立项目，给予支持和信任
6. 面对面交流是最有效的沟通方式
7. 可工作的软件是首要进度度量
8. 保持可持续的开发速度
9. 持续关注技术卓越和良好设计
10. 简洁——最大化未完成工作量的艺术
11. 最佳架构、需求和设计来自自组织团队
12. 定期反思并调整行为以提高效能

敏捷框架: Scrum

Scrum角色

1. Product Owner (产品负责人)

职责:
- [ ] 定义产品愿景和目标
- [ ] 维护和优先排序Product Backlog
- [ ] 确保团队理解backlog items
- [ ] 决定发布内容和时间
- [ ] 对产品ROI负责

关键技能:
- 业务知识
- 决策能力
- 沟通能力
- 利益相关者管理

2. Scrum Master (敏捷教练)

职责:
- [ ] 保护团队免受干扰
- [ ] 促进Scrum会议
- [ ] 移除障碍和阻碍
- [ ] 指导团队敏捷实践
- [ ] 持续改进流程

关键技能:
- 敏捷实践专家
- 促进和教练
- 冲突解决
- 仆人式领导

3. Development Team (开发团队)

特征:
- [ ] 跨职能 (包含所有必需技能)
- [ ] 自组织 (自己决定如何工作)
- [ ] 5-9人 (最佳团队规模)
- [ ] 全职投入
- [ ] 集体负责

职责:
- 将backlog items转化为可交付增量
- 自我管理和协作
- 保证质量
- 估算工作量

Scrum活动

Sprint规划 (Sprint Planning)

时间盒: 2小时/周 (如2周Sprint则4小时)

目标: 确定本Sprint要做什么和怎么做

议程:

第一部分: What (做什么)
- [ ] Review Product Backlog top items
- [ ] 团队评估capacity
- [ ] 选择Sprint backlog items
- [ ] 定义Sprint目标

第二部分: How (怎么做)
- [ ] 将选中的items分解为任务
- [ ] 估算任务工作量
- [ ] 识别依赖和风险
- [ ] 每个成员认领任务

输出:
- Sprint目标 (简洁的声明)
- Sprint Backlog (承诺完成的items)
- 任务分解和估算

Sprint规划清单:

准备工作:
- [ ] Product Backlog已refinement
- [ ] Top items有清晰验收标准
- [ ] 团队了解优先级
- [ ] 历史velocity可参考

规划中:
- [ ] 全员参与
- [ ] Sprint目标清晰且可衡量
- [ ] 工作量合理 (基于velocity)
- [ ] 风险已识别
- [ ] 依赖已明确

规划后:
- [ ] 团队承诺Sprint目标
- [ ] Sprint Backlog可见
- [ ] 任务板ready

每日站会 (Daily Scrum)

时间盒: 15分钟 时间: 每天同一时间 参与者: 开发团队 (SM facilitates, PO可参加)

三个问题:

1. 昨天我完成了什么？
2. 今天我计划做什么？
3. 有什么阻碍我的障碍吗？

目标:

• 同步团队进度
• 识别阻碍
• 调整当天计划

最佳实践:

✅ 准时开始，准时结束
✅ 站着开 (保持简短)
✅ 聚焦Sprint目标
✅ 识别协作机会
✅ 快速记录阻碍

❌ 不是状态报告
❌ 不解决问题 (会后单独讨论)
❌ 不讨论技术细节
❌ 不超时

Sprint评审 (Sprint Review)

时间盒: 1小时/周 (2周Sprint则2小时) 参与者: Scrum团队 + 利益相关者

目标: 检查增量，适应Product Backlog

议程:

1. PO介绍Sprint目标和完成情况
2. 开发团队演示完成的工作
3. 讨论遇到的问题和解决方案
4. PO讨论Product Backlog状态
5. 整个团队协作下一步工作
6. 回顾时间线、预算、市场变化

输出:
- 更新的Product Backlog
- 调整的发布计划
- 利益相关者反馈

演示最佳实践:

✅ 演示可工作软件 (不是PPT)
✅ 展示业务价值
✅ 鼓励互动和反馈
✅ 庆祝成就
✅ 诚实面对未完成事项

❌ 演示未完成功能
❌ 技术演示 (除非相关)
❌ 责备团队成员

Sprint回顾 (Sprint Retrospective)

时间盒: 45分钟/周 (2周Sprint则1.5小时) 参与者: Scrum团队

目标: 检查和改进过程

议程:

1. 设定基调 (安全、开放的环境)
2. 收集数据
   - 什么做得好？
   - 什么需要改进？
   - 有什么困惑？
3. 产生洞察
   - 为什么发生？
   - 模式是什么？
4. 决定行动
   - 下个Sprint改进什么？
   - 谁负责？
5. 关闭回顾

输出:
- 改进行动项 (1-3个)
- 负责人和deadline
- 下次回顾检查点

回顾技术:

- Start-Stop-Continue
- Mad-Sad-Glad
- Sailboat (帆船回顾)
- 4Ls (Liked, Learned, Lacked, Longed For)
- Timeline回顾

Scrum工件

1. Product Backlog (产品待办列表)

定义: 产品需要的所有功能、增强、修复的有序列表

特征:

- 动态的 (持续演进)
- 有优先级的 (PO负责)
- 估算的 (团队参与)
- 精炼的 (定期refinement)

条目类型:

• 用户故事 (User Story)
• 技术任务 (Technical Task)
• Bug修复
• 知识获取 (Spike)

用户故事格式:

作为 [角色]
我想要 [功能]
以便 [业务价值]

验收标准:
- [ ] 标准1
- [ ] 标准2
- [ ] 标准3

估算: [故事点]
优先级: [High/Medium/Low]

INVEST原则:

I - Independent (独立的)
N - Negotiable (可协商的)
V - Valuable (有价值的)
E - Estimable (可估算的)
S - Small (小的)
T - Testable (可测试的)

2. Sprint Backlog (Sprint待办列表)

定义: Sprint中选中的Product Backlog items + 实现计划

包含:

• Sprint目标
• 选中的用户故事
• 任务分解
• 每日进度

可见性: 任务板

3. 增量 (Increment)

定义: Sprint结束时所有完成的Product Backlog items总和

完成的定义 (DoD - Definition of Done):

代码层面:
- [ ] 代码已review
- [ ] 符合编码规范
- [ ] 单元测试覆盖率>80%
- [ ] 集成测试通过
- [ ] 无已知P0/P1 bug

部署层面:
- [ ] 已部署到测试环境
- [ ] 通过验收测试
- [ ] 文档已更新
- [ ] 可演示

质量层面:
- [ ] 性能测试通过
- [ ] 安全扫描通过
- [ ] 可访问性检查通过

敏捷实践

1. 迭代开发

迭代节奏:

Sprint长度: 1-4周 (推荐2周)

为什么短迭代?
- 快速反馈
- 降低风险
- 保持焦点
- 适应变化

迭代结构:

Sprint规划 → 每日开发 (每日站会) → Sprint评审 → Sprint回顾
    ↓                                      ↓
   2小时                                  2小时
                                           ↓
                                    下个Sprint开始

2. 持续集成 (CI)

定义: 频繁将代码集成到主干，自动构建和测试

实践:

- [ ] 每天至少集成一次
- [ ] 自动化构建
- [ ] 自动化测试
- [ ] 快速反馈 (<10分钟)
- [ ] 保持主干可部署

CI流程:

代码提交 → 自动构建 → 自动测试 → 通知结果
            ↓              ↓
       如果失败      如果失败
            ↓              ↓
       立即修复      立即修复

3. 测试驱动开发 (TDD)

循环: Red → Green → Refactor

1. Red: 写失败的测试
2. Green: 写最少代码让测试通过
3. Refactor: 重构代码保持测试通过

好处:
- 更好的设计
- 更高的测试覆盖
- 更快的调试
- 自信的重构

4. 结对编程 (Pair Programming)

定义: 两人共用一台电脑编程

角色:

• Driver (驾驶员): 写代码
• Navigator (导航员): 审查、思考、建议

好处:

- 知识共享
- 实时代码审查
- 更少的bug
- 更好的设计
- 团队凝聚力

何时结对:

✅ 复杂问题
✅ 关键功能
✅ 新人培训
✅ 知识转移

❌ 简单重复任务
❌ 个人学习时间

5. Backlog Refinement

定义: 持续细化Product Backlog items

频率: Sprint中间 (1-2小时)

活动:

- [ ] 澄清需求
- [ ] 分解大故事
- [ ] 估算故事点
- [ ] 定义验收标准
- [ ] 识别依赖和风险

目标: Sprint规划前，top items都ready

6. 估算技术

故事点估算

相对估算 (不是绝对时间):

1点: 非常简单
2点: 简单
3点: 中等
5点: 复杂
8点: 很复杂
13点: 极其复杂 (考虑拆分)

Planning Poker:

1. PO描述故事
2. 团队讨论澄清
3. 每人秘密选择点数
4. 同时亮牌
5. 讨论差异
6. 重新投票直到共识

Velocity (速度):

Velocity = 每个Sprint完成的故事点总和

用途:
- 规划未来Sprint
- 预测发布日期
- 监控团队稳定性

中文输出格式

所有输出必须使用中文,遵循以下结构:

# 敏捷实践指南: [项目名称]

## Sprint规划

### Sprint信息
- **Sprint编号**: Sprint #X
- **时间范围**: [开始日期] - [结束日期]
- **Sprint长度**: X周
- **团队Velocity**: X点 (平均)

### Sprint目标
[1-2句话描述本Sprint要达成的目标]

### Sprint Backlog

| ID | 用户故事 | 优先级 | 估算 | 负责人 | 状态 |
|----|---------|-------|------|--------|------|
| US-001 | [故事描述] | P0 | 5点 | [姓名] | Todo |
| US-002 | [故事描述] | P1 | 3点 | [姓名] | Todo |

**总估算**: X点
**Team Capacity**: Y点
**承诺比率**: X/Y = Z%

### 任务分解

#### US-001: [故事标题]
```markdown
作为 [角色]
我想要 [功能]
以便 [价值]

验收标准:
- [ ] 标准1
- [ ] 标准2

任务:
- [ ] [任务1] - [估算: Xh] - [负责人]
- [ ] [任务2] - [估算: Yh] - [负责人]

风险和依赖

• ⚠️ [风险1]: [描述] - [缓解措施]
• ⚠️ [依赖1]: [描述] - [负责人]

每日站会记录

[日期] 站会

[成员1]:

• 昨天: [完成的工作]
• 今天: [计划的工作]
• 阻碍: [无 / 描述阻碍]

[成员2]:

• 昨天: [完成的工作]
• 今天: [计划的工作]
• 阻碍: [无 / 描述阻碍]

阻碍清单:

1. [阻碍1] - 负责解决: [SM/PO]
2. [阻碍2] - 负责解决: [SM/PO]

Sprint进度:

• 完成: X点
• 进行中: Y点
• 待办: Z点
• Burndown: [趋势]

Sprint评审

完成的工作

已完成故事 (X点):

• ✅ US-001: [故事标题] - [演示要点]
• ✅ US-002: [故事标题] - [演示要点]

未完成故事 (Y点):

• ❌ US-003: [故事标题] - [原因: ...]

演示反馈

利益相关者反馈:

• [反馈1]
• [反馈2]

Product Backlog更新:

• 新增: [N个故事]
• 调整优先级: [哪些故事]
• 移除: [哪些故事]

度量指标

• 承诺点数: X点
• 完成点数: Y点
• 完成率: Y/X = Z%
• Velocity: [本Sprint vs 平均]

Sprint回顾

做得好的 👍

1. [优点1]
2. [优点2]
3. [优点3]

需要改进的 💡

1. [问题1]

   • 根因: [...]
   • 影响: [...]

2. [问题2]

   • 根因: [...]
   • 影响: [...]

改进行动 🎯

行动	负责人	期限	预期效果
[行动1]	[姓名]	[日期]	[效果描述]
[行动2]	[姓名]	[日期]	[效果描述]

实验

• 尝试: [下个Sprint尝试什么新实践]
• 假设: [期望达到什么效果]
• 度量: [如何评估效果]

发布规划

发布目标

[描述发布要达成的业务目标]

里程碑

里程碑	目标日期	Sprint	功能	状态
MVP	[日期]	Sprint 1-3	[核心功能]	进行中
Beta	[日期]	Sprint 4-6	[增强功能]	计划中
GA	[日期]	Sprint 7-9	[完整功能]	计划中

Velocity趋势

Sprint 1: 25点
Sprint 2: 28点
Sprint 3: 26点
平均: 26点

预测: 还需X个Sprint完成剩余Y点

团队健康度

团队氛围

• 协作度: ⭐⭐⭐⭐⭐
• 士气: ⭐⭐⭐⭐☆
• 技能成长: ⭐⭐⭐⭐☆

改进追踪

• [上个Sprint行动项完成情况]
• [效果评估]

## 语言要求

- ✅ **所有规划和记录**: 必须使用中文
- ✅ **技术术语**: 首次使用提供英文,后续使用中文
- ✅ **角色名称**: Product Owner(产品负责人), Scrum Master(敏捷教练)
- ✅ **Scrum术语**: 保留英文但提供中文注释

## 质量标准

- [ ] Sprint目标清晰且可衡量
- [ ] 用户故事符合INVEST原则
- [ ] 验收标准明确
- [ ] 估算有依据
- [ ] 每日站会高效 (≤15分钟)
- [ ] Sprint评审演示可工作软件
- [ ] Sprint回顾产生可行动改进
- [ ] 持续改进可见

## 敏捷转型指南

### 常见挑战

**挑战1: 伪敏捷**
```markdown
症状: 有敏捷仪式但无敏捷思维
解决:
- 培训敏捷价值观和原则
- SM积极教练
- 管理层支持
- 庆祝小赢

挑战2: 需求频繁变更

症状: Sprint中频繁加需求
解决:
- 强调Sprint承诺
- PO把关优先级
- 紧急情况有流程
- 下个Sprint再加

挑战3: 技术债务累积

症状: 追求速度忽视质量
解决:
- DoD包含质量标准
- 每个Sprint预留20%时间还债
- 可视化技术债务
- 重构计入velocity

成功因素

✅ 管理层支持和信任 ✅ Product Owner投入 ✅ 团队稳定和全职 ✅ 真正的自组织 ✅ 持续改进文化 ✅ 工具和基础设施支持 ✅ 跨职能团队

参考文档

详细实践指南请参考:

• references/AGILE_FRAMEWORK.md - 敏捷框架详解

版本历史

• v1.0.0 (2026-03-03): 初始版本
  • Scrum框架完整指南
  • Sprint规划和执行
  • 敏捷实践 (CI/TDD/结对编程)
  • 中文模板
  • 转型指导