Scrum vs Kanban

Scrum 是一个敏捷框架（Agile Framework），旨在通过迭代和增量的方式开发适应复杂问题的解决方案，强调团队合作和适应变化的需求来持续交付价值。Scrum 由 Jeff Sutherland 和 Ken Schwaber 在1990年代初期创建，是目前全球最广泛使用的敏捷框架。

根据2024年 State of Agile 报告，约87%的敏捷团队使用 Scrum 或其某种变体。Scrum 不仅应用于软件开发，还被广泛应用于市场营销、教育、建筑和科学研究等领域。

Scrum 旨在促进团队的自我组织能力（Self-Organization）和快速决策能力，以应对复杂和不断变化的需求。该框架基于一个核心原则：最接近工作的团队最了解如何完成工作。

Scrum 中的协作体现在多个方面：

• 完全透明 — 所有团队成员可以随时查看进展情况
• 每日沟通 — 通过 Daily Scrum（每日站会）保持同步
• 共同工作 — 团队一起计划、执行和检查
• 利益相关者参与 — 通过 Sprint Review 获取反馈

Harvard Business Review 的研究发现，实施 Scrum 的团队报告生产力提高了25%，客户满意度提高了35%。

解决方案范围通过 "Sprint" 来处理——这是最长一个月的固定时间周期（通常为2周），每次迭代产生一个可交付的产品增量（Increment）。这种方法带来以下优势：

1. 快速反馈 — 客户在每个 Sprint 结束后可以看到成果并提供实时反馈
2. 降低风险 — 问题在早期被发现并在扩大前得到修复
3. 灵活性 — 可以在 Sprint 之间根据新需求调整方向
4. 早期价值 — 最重要的功能优先开发

每个 Sprint 以 Sprint Planning 开始，以 Sprint Review 和 Sprint Retrospective 结束。这个周期不断重复，直到产品达到所需水平或项目结束。

Scrum 优先交付客户最需要的最高价值特性，根据 Product Owner 在 Product Backlog 中的排序。这种方法被称为"价值驱动交付"（Value-Driven Delivery），确保资源得到最优分配。

Product Owner 负责：

• 管理 Product Backlog — 按业务价值对项目进行优先排序
• 定义产品愿景 — 确保团队理解整体目标
• 做出决策 — 批准或拒绝工作成果
• 与利益相关者沟通 — 在团队与客户和组织之间架起桥梁

Scrum 定义了三个核心角色（Accountabilities）：

Scrum Master

Scrum Master 是服务型领导（Servant Leader），负责：

• 确保团队遵守 Scrum 的实践和规则
• 消除阻碍团队的障碍（Impediments）
• 指导团队和组织采用 Scrum 方法
• 促进 Scrum 事件的顺利进行

Product Owner

Product Owner 定义产品需求并管理 Product Backlog。他们代表客户的声音，确保团队专注于正确的事情。

Developers

开发人员（Developers）是负责实现解决方案的专业人员。他们是一个3-9人的跨职能团队（Cross-functional），自组织地完成 Sprint 目标。

Scrum 的工件（Artifacts）提供透明度和关键信息：

Product Backlog

一个有序列表，包含产品所需的所有内容。每个项目包括描述、估算和业务价值。Product Backlog 是"活"的，不断变化。

承诺： Product Goal — 产品的长期目标。

Sprint Backlog

从 Product Backlog 中为当前 Sprint 选择的项目集合，以及执行计划。Sprint Backlog 属于开发团队。

承诺： Sprint Goal — Sprint 的定义目标。

Increment（增量）

已完成项目的集合，符合完成定义（Definition of Done）。每个 Increment 是之前所有 Increment 的累加，并且随时可以发布。

承诺： Definition of Done — 项目必须满足的标准才能被视为"完成"。

Scrum 定义了五个正式事件，创造规律性并减少非计划会议的需要：

Sprint

固定时间周期（Time-box）的工作循环，最长一个月。Sprint 是所有其他事件的容器。

Sprint Planning

每个 Sprint 开始时的计划会议（一个月 Sprint 最多8小时）。团队决定：

• 做什么 — 从 Product Backlog 中选择哪些项目
• 为什么 — Sprint Goal 是什么
• 怎么做 — 工作将如何完成

Daily Scrum

开发团队每天15分钟的会议，用于协调和计划当天的工作。这不是状态汇报，而是快速识别问题和协调的工具。

Sprint Review

Sprint 结束时向利益相关者展示成果并获取反馈的会议。这是协作性事件，不是单向演示。

Sprint Retrospective

Sprint 结束时团队审视自己的流程并识别改进机会的会议。这是 Scrum 中最重要的持续改进事件之一，体现了 Kaizen（改善）的精神。

Scrum 基于五个核心价值观：

1. 承诺（Commitment） — 团队承诺实现 Sprint 目标并相互支持
2. 勇气（Courage） — 团队成员勇于面对困难问题
3. 专注（Focus） — 团队专注于 Sprint 工作和既定目标
4. 开放（Openness） — 对工作和面临的挑战保持透明
5. 尊重（Respect） — 团队成员互相尊重，视对方为有能力的专业人士

这些价值观创造了一个信任和协作的环境，是 Scrum 成功的基础。

Scrum 基于三个经验主义支柱（Empirical Pillars）：

透明度（Transparency）

流程和工作必须对所有参与者可见。没有透明度，就无法有效地进行检查和适应。看板是实现透明度的常用工具。

检查（Inspection）

定期检查工件和进展，以发现偏差和问题。Scrum 事件提供了定期检查的机会。

适应（Adaptation）

当发现偏差时，团队尽快调整流程或产品，防止进一步偏离。

Scrum 和 Agile 有什么区别？

Agile（敏捷）是一种广泛的哲学，而 Scrum 是实现敏捷原则的特定框架（Framework）。Scrum 是最流行的敏捷框架之一，但不是唯一的。

一个 Sprint 持续多长时间？

Sprint 最长一个月，但大多数团队使用两周的 Sprint。Sprint 的长度由团队决定，并在一段时间内保持不变。

Scrum 只适用于软件开发吗？

不是。Scrum 已经成功应用于市场营销、人力资源、教育、建筑、研究等众多领域。透明度、检查和适应的原则适用于任何复杂项目。

如果 Sprint Goal 没有实现怎么办？

如果 Sprint 目标未达成，团队在 Sprint Retrospective 中讨论并找出可以改进的地方。Sprint 不会延长——未完成的项目返回 Product Backlog。

可以将 Scrum 与 Kanban 结合使用吗？

可以！"Scrumban" 是一种流行的组合方式，使用 Scrum 的结构和 Kanban 的实践，如限制在制品（WIP）和关注流动。

Scrum 指南提供了敏捷框架的基本和实用理解，格式易于获取。最新版本（2020年）使 Scrum 更加简洁、更少规定性，并添加了 Product Goal 和 Sprint Goal 等概念。免费下载 Scrum 指南。

• Sprint — Scrum 的基本工作周期
• Product Owner — 定义产品价值的角色
• Scrum Master — 促进 Scrum 实践的服务型领导
• Backlog — 优先排序的需求列表
• Kanban — 工作流管理的替代方法
• DevOps — 开发与运维的结合
• CI/CD — 持续集成与持续交付

Kanban 是一种基于精益（Lean）的方法，用于管理和改善生产、开发和服务流程中的工作流。它专注于持续交付价值而不给团队带来过重负担，通过可视化系统来跟踪任务进展。"Kanban"（看板）一词来自日语，意思是"视觉信号"或"卡片"。

Kanban 是全球最流行的敏捷方法之一，与 Scrum 并列。根据2024年 State of Agile 报告，约13%的团队使用 Kanban 作为主要方法，更多团队将其与 Scrum 结合使用（"Scrumban"）。

Kanban 最初于1940年代由丰田公司的大野耐一（Taiichi Ohno）开发，作为丰田生产系统（Toyota Production System）的一部分。其目标是通过可视化工作、减少浪费（Muda）和使生产与实际需求相匹配来优化生产流程。

原始系统使用在工作站之间流动的物理卡片，每张卡片代表一个工作项目。当一个工作站完成任务后，卡片被发回到前一个工作站作为生产另一个项目的信号——这就是拉动系统（Pull System）的基础。

Kanban 在2000年代从制造业扩展到软件开发领域，主要得益于 David J. Anderson 的工作。他的著作《Kanban: Successful Evolutionary Change for Your Technology Business》（2010年）成为该领域的里程碑。

Anderson 定义了 Kanban 的六个核心实践：

1. 可视化工作流 — 使工作可见
2. 限制在制品（WIP） — 防止过载
3. 管理流动 — 跟踪和优化流动
4. 使政策明确 — 让规则对所有人可见
5. 实施反馈循环 — 定期检查和审查
6. 协作改进，实验进化 — 渐进式发展

团队使用看板（Kanban Board）来可视化工作并跟踪进展。典型的看板包含以下列：

• 待办（To Do） — 等待开始的任务
• 进行中（In Progress） — 正在执行的任务
• 审查（Review） — 等待审查的任务
• 完成（Done） — 已完成的任务

每个工作项目由一张卡片（Card）表示，从左到右移动通过各列。看板提供了团队所有工作的即时全景。

研究表明，可视化的看板可以减少团队沟通时间30%，并提高发现瓶颈的能力50%。

Kanban 倡导持续改善（Kaizen）——在工作流程中持续发现和解决问题。与要求革命性变化的方法不同，Kanban 鼓励进化式变革——小的、渐进的改进随时间积累成显著的变化。

Kanban 的理念是"从你现在的地方开始"——不需要改变现有的角色、流程或头衔。取而代之的是在工作中逐步实施改进。

Kanban 最核心的实践之一是限制在制品（Work In Progress）——设定每个阶段同时进行的最大任务数量。

为什么 WIP 限制很重要？

• 提高专注力 — 更少的并行任务 = 每个任务获得更多关注
• 缩短交付时间 — 减少多任务处理，任务完成更快
• 发现瓶颈 — 当某列达到限制时，表明存在问题
• 提高质量 — 每个工作项目获得更多关注

2023年的研究发现，实施 WIP 限制的团队，Cycle Time 减少了40%，Bug 数量减少了25%。

数字示例

如果一个5人团队将"进行中"列限制为5个任务，每个开发者在任何时刻只专注于一个任务。如果某个开发者遇到困难，他们寻求帮助而不是开始另一个任务。

Kanban 的拉动系统（Pull System）鼓励在开始新任务前完成现有任务，关注团队的实际能力和需求。这种方法与"推动系统"（Push System）有本质区别——推动系统不考虑团队能力就将工作分配给团队。

拉动系统的原则：

• "停止开始，开始完成"（Stop Starting, Start Finishing） — 完成优先于开始
• 按需工作 — 只有当有空间时才引入新任务
• 减少浪费 — 更少的不必要工作和上下文切换
• 平滑流动 — 工作持续流过系统

Kanban 依赖定量指标来改进流程：

前置时间（Lead Time）

从请求进入系统到完成的总时间。Lead Time 包括等待时间。

周期时间（Cycle Time）

从开始工作到完成任务所需的时间。Cycle Time 是衡量团队效率的重要指标。

吞吐量（Throughput）

团队在单位时间（周/月）内完成的工作项目数量。

累积流图（CFD）

累积流图显示了不同阶段的工作项目数量随时间的变化。它可以识别趋势、瓶颈和流动问题。

实施 Kanban 的流行数字工具：

• Jira — 最流行的专业工具，提供高级 Kanban 支持
• Trello — 简单直观，适合小团队
• Asana — 任务管理与看板的结合
• Azure DevOps — 适合 DevOps 团队
• Notion — 灵活，适用于不同类型的工作

Kanban 需要专门的培训吗？

不需要。Kanban 的一大优势是可以从现有流程开始，逐步添加实践。但也有 KMP（Kanban Management Professional）等认证可供选择。

Kanban 适合大型团队吗？

是的。Kanban 非常适合各种规模的团队和整个组织。"Kanban at Scale" 允许在组织层面实施该方法。

看板和 Scrum 板有什么区别？

看板是持续的——任务无限期流动。Scrum 板在每个 Sprint 结束时重置。此外，看板有明确的 WIP 限制。

如何确定 WIP 限制？

常见的起点：团队成员数 × 1.5。例如，4人团队从 WIP 限制6开始。根据经验调整限制。

可以不使用数字工具来使用 Kanban 吗？

当然可以！用便利贴的物理看板是很好的起点。物理看板提供即时可见性，鼓励面对面互动。

• Scrum — 领先的敏捷框架
• Lean — Kanban 的源头哲学
• Kaizen — 持续改善
• Cycle Time — 任务执行时间
• Lead Time — 从请求到交付的总时间
• DevOps — 开发与运维的结合
• Jira — 项目管理工具