敏捷开发

5 minIntermediate2026/6/14

Scrum框架、Kanban方法、Sprint规划、Backlog管理与敏捷实践。

1. 敏捷宣言与原则

1.1 敏捷宣言四价值观

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

1.2 十二原则(核心摘要)

  1. 最高优先级是尽早持续交付有价值的软件
  2. 欢迎需求变化,即使开发后期
  3. 频繁交付可工作的软件(周期越短越好)
  4. 业务人员与开发者每日协作
  5. 以积极的人为核心,提供所需环境和信任
  6. 面对面沟通是最有效的信息传递方式
  7. 可工作的软件是进度的首要度量
  8. 可持续的开发节奏
  9. 持续关注技术卓越和良好设计
  10. 简洁——最大化未完成工作量的艺术
  11. 最好的架构、需求和设计出自自组织团队
  12. 团队定期反思和调整

2. Scrum框架

2.1 三个角色

角色职责关注点
Product Owner管理Product Backlog,定义需求优先级做正确的事
Scrum Master移除障碍,确保Scrum实践正确地做事
Development Team自组织完成Sprint目标高效地做事

2.2 五个事件

事件时长(2周Sprint)参与者目的
Sprint2周全员交付增量
Sprint Planning4小时全员规划Sprint目标
Daily Standup15分钟开发团队同步进度和障碍
Sprint Review2小时全员+利益相关者展示成果
Sprint Retrospective1.5小时全员改进流程

2.3 三个工件

工件说明负责人
Product Backlog所有需求的有序列表Product Owner
Sprint Backlog当前Sprint的任务Development Team
Increment可交付的产品增量Development Team

2.4 Sprint流程

Sprint Planning → Daily Standup(每日) → Sprint Review → Retrospective
     │                    │                    │              │
     ▼                    ▼                    ▼              ▼
  确定目标          同步进展障碍          展示成果        改进流程
  选择Backlog项     更新看板             获取反馈        下Sprint改进
  制定计划          识别阻塞             更新Backlog

3. Kanban方法

3.1 核心原则

  1. 可视化工作流:看板展示所有工作项
  2. 限制WIP(Work In Progress):限制每列在制品数量
  3. 管理流动:优化工作项从左到右的流动
  4. 显式策略:明确”完成”的定义
  5. 反馈环:定期评审和改进
  6. 协作改进:团队共同优化

3.2 Kanban看板

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│  Backlog │  To Do   │ In Progress│ Review  │  Done    │
│          │   (3)    │    (2)    │   (2)   │          │
│ ┌──────┐ │ ┌──────┐ │ ┌──────┐ │ ┌──────┐│ ┌──────┐ │
│ │ T-12 │ │ │ T-05 │ │ │ T-03 │ │ │ T-01 ││ │ T-08 │ │
│ │ T-15 │ │ │ T-07 │ │ │ T-04 │ │ │ T-02 ││ │ T-09 │ │
│ │ T-18 │ │ │ T-06 │ │ └──────┘ │ └──────┘│ │ T-10 │ │
│ └──────┘ │ └──────┘ │          │         │ └──────┘ │
└──────────┴──────────┴──────────┴──────────┴──────────┘
                              WIP Limit: 2

3.3 Scrum vs Kanban

维度ScrumKanban
迭代周期固定Sprint无固定周期
变更Sprint内不变随时可变
WIP限制Sprint容量每列WIP限制
角色PO/SM/Team无规定角色
度量速度Lead Time/Cycle Time
适用产品开发运维/支持

4. Backlog管理

4.1 用户故事

格式:作为[角色],我希望[功能],以便[价值]

作为 注册用户,
我希望 能够重置密码,
以便 我忘记密码时可以重新访问账户

4.2 验收标准

验收标准:
1. 用户点击"忘记密码"链接
2. 输入注册邮箱
3. 系统发送重置链接到邮箱
4. 链接30分钟内有效
5. 重置密码需满足复杂度要求

4.3 故事估算

方法说明
故事点相对复杂度估算(斐波那契数列)
T恤尺码S/M/L/XL粗粒度估算
理想天数假设无干扰的完成天数

规划扑克:团队成员同时出牌,讨论差异后达成共识。

4.4 优先级排序

方法说明
MoSCoWMust/Should/Could/Won’t
WSJF加权最短作业优先
价值/成本比ROI排序
Kano模型基本/期望/兴奋需求

5. 敏捷度量

5.1 速度(Velocity)

Velocity=iSprintStoryPointsi\text{Velocity} = \sum_{i \in \text{Sprint}} \text{StoryPoints}_i

5.2 燃尽

剩余故事点
100 ┤╲
    │ ╲
 75 ┤  ╲
    │   ╲  理想线
 50 ┤    ╲
    │     ╲
 25 ┤      ╲ 实际线
    │       ╲
  0 ┤────────╲──→ Sprint天数

5.3 Lead Time vs Cycle Time

指标定义含义
Lead Time需求提出到交付客户感知的响应时间
Cycle Time开始工作到完成团队的执行效率