本文介绍了 Scrum 和 Kanban 两种敏捷开发理论,为您和团队在两者之间抉择时提供一些关键的考虑因素。
Scrum 和 Kanban 是关于敏捷开发和项目管理的两种不同理论框架。Kanban 是灵活的持续交付模式,而 Scrum 是结构化的短期工作模式。
敏捷是一套价值观和原则,对敏捷团队具有指导意义。DevOps 是一组实践、方法与系统的总称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。在实施敏捷开发和 DevOps 时,Scrum 和 Kanban 提供了不同的方法。
表面来看,很容易发现 Scrum 和 Kanban 之间的区别,但其实两者的原则大体上是相同的。这两个框架都将帮助您更高效地打造好的产品和服务。 那么,对于两者我们应该怎么作选择呢?
敏捷是一种结构化的迭代项目管理和产品开发方法。它根据开发需求不断变化的特点,指导团队在不偏离轨道的情况下应对变化。如今敏捷开发理论已经普遍应用于大多数开发团队,因为没有谁可以在固定的黑匣子中开发一种产品数年甚至数月。 Scrum 承诺通过固定的迭代交付完成增量工作。他们的目标是通过不断循环固定周期来快速收集和实现客户反馈。Scrum 团队采用特定的角色,并定期举行特定会议来保持进展。
Kanban 将团队工作流程可视化,限制每个流程的工作数量,最大限度地提高工作效率。Kanban 团队专注于提升研发效能。他们通过使用看板并不断改进工作流程来做到这一点。
Scrum |
Kanban |
|
起源 |
软件开发 |
精益制造 |
原理 |
从经验中学习,自发性复盘来不断迭代改进 |
通过可视化来发现问题、改进工作 |
节奏 |
定期、固定周期的迭代工作(一般为两周) |
持续工作 |
实践 |
迭代计划会、每日站会、迭代演示会、回顾会 |
可视化工作流程,管理在制品限制,不断循环 |
角色 |
产品负责人(Product owner)、敏捷教练(Scrum master)、开发团队 |
不规定角色 |
通过 Scrum 敏捷开发,团队承诺在每个迭代结束时交付一些有价值的工作增量。Scrum 建立在经验主义之上,专注于小的工作增量。以下是它的工作特点:
Scrum 工作进展迅速,迭代周期通常持续一至四周,有明确的开始和结束日期。由于开发周期较短,复杂任务通常被拆分为小的用户故事。同时对研发团队发布代码的质量和速度有一定要求。
Scrum 迭代工作由迭代计划会、每日站会、迭代演示会、回顾会构成,这些会议随着一个个迭代持续反复地进行。
Scrum 具有三个明确定义的角色:
产品负责人(Product owner)代表业务需求方,管理产品待办列表,并帮助开发团队规划工作优先级
敏捷教练(Scrum master)指导开发团队遵循 Scrum 敏捷开发原则
开发团队 负责计划完成的工作并交付增量,体现集体责任感
那是谁管理 Scrum 团队呢?其实没有任何人。Scrum 团队是自发组织的,尽管职责不同,但每个角色都是平等的。团队以向客户提供价值为目标而聚集到一起。
Scrum 指标是 Scrum 团队可以用来提高工作效率和有效性的依据。数据指标可以为工作决策提供参考信息,并帮助团队提高执行效率。在迭代规划阶段,团队可以参考迭代目标、团队速率、团队容量等维度的数据。在每日站会上,团队还可以从迭代目标的进度、迭代燃尽图、工作负载分布等指标中帮助了解工作进展,及时调整工作安排。
Scrum 团队一般会在固定迭代周期中承诺交付多少的价值增量。但是,Scrum 团队也可以在迭代中采纳客户反馈,鼓励团队调整和改变迭代计划来提供最大的客户价值。但不是说团队可以在冲刺中频繁更改工作范围,因为变化会使可交付增量潜在风险。团队会因为没有充分理解迭代计划的工作,或者被业务或计划外工作扰乱了进度。因此在迭代回顾期间,Scrum 团队可以讨论变化的边界、如何更好地控制和拥抱变化。
Kanban 有助于将工作进展可视化,限制在制品 (WIP) ,并且快速将工作从“开始”转移到“完成”状态。Kanban 非常适合有大量优先级工作的团队。相比 Scrum 流程对工作范围严格控制,看板让团队工作更加顺其自然。以下是 Kanban 五个要素,可以帮助您了解更多。
Kanban 基于持续交付的工作原则,让团队时刻准备和应对不断变化的工作优先级。工作内容(以卡片为载体)在看板工作栏上按团队规定的工作流程移动。常见的工作流程是“待办”、“进行中”、“被阻止”和“已完成”,但这不是固定的。
看板最灵活的是可以根据团队工作方式自定义工作流程。比如我们团队需要交付某项工作,看板上会进行待办事项列表优先级梳理、补充详细描述信息,再到计划、设计、开发、测试、发布等活动。而看板会帮助我们了解大概什么时间段会进行交付,以及我们当前工作中是否存在交付瓶颈。
在看板中,工作内容一旦完成即可发布,没有固定的截止日期。理论上,Kanban 没有规定工作交付的发布时间。如果工作较早(或较晚)完成,则可以根据需要发布,无需像 Scrum 迭代那样等待发布的里程碑节点。
Kanban 团队每位成员都有权利查看看板工具上的内容。与 Scrum 团队会聘请敏捷教练指导团队工作不同的是,Kanban 团队不需要“看板教练”来让工作顺利进行,因为整个团队的集体责任是协作完成板上的任务。
交付周期是衡量 Kanban 团队速率的重要指标,这是指工作从开始到结束所花费的平均时间。改进交付周期可以促进团队发展。
累积流图 (CFD) 是 Kanban 团队用来了解每个状态的工作项数量的另一种分析指标。累积流图有助于团队识别特定流程中需要解决的工作,帮助团队获得更好的工作吞吐量。
处理瓶颈的另一种方法是在制品限制(WIP)。在制品限制可以控制在任何流程中的工作卡片数量。当工作达到限制额时,工作会禁止进入该流程,这有利于推动团队共同解决问题,加快工作进程。
看板工作流程可以随时更改。新的工作内容可以添加到待办列表中,现有的工作卡片可以根据优先级暂停或停止。此外,如果团队容量发生变化,可以重新校准在制品限制并相应地调整工作量。这一切都与 Kanban 项目的灵活性有关。
敏捷团队经常先选择了项目管理的工具而被动选择开发框架,从而固定了团队采用的开发原则。其实选择的顺序应该是相反的,我们第一步应该选择适合团队的敏捷开发框架。比如,一旦确认了团队采用 Scrum 框架,就可以找到一个可以更好为团队服务的 Scrum 工具了。Kanban 也是如此。作为专注国内敏捷团队的研发管理工具,我们 PingCode 可以满足您的需求。我们提供使用 Scrum 或 Kanban 专用项目类型,您可以任意选择并实践。
编辑切换为居中
添加图片注释,不超过 140 字(可选)
Scrum 和 Kanban 是被无数研发团队实践总结出来的工作方式。团队不会因为选择了 Scrum 或 Kanban 而无法开展工作。而且我们不是只能选择一种。目前有数百个团队正在使用 Scrum 和 Kanban 的混合模式,我们 PingCode 也不例外。另外 PingCode 研发管理工具还支持在 Scrum 项目中融入 Kanban,满足团队更多的敏捷研发场景:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
当同时管理多个项目时,团队可以根据不同项目的敏捷特性来选择不同的模式:无论是 Scrum、Kanban 还是两者兼而有之,毕竟团队的项目不是一天就能适应一种模式的,我们可以先让团队尝试哪个模式更有效再做选择。
因此,您可以放心地选择Scrum 和 Kanban,因为这两种模式都可以发展以满足研发团队的工作需求。 不管团队最终选择哪种模式,我们都要坚持实践一段时间。从待办工作一直到交付完成,然后团队要去讨论和总结过程中哪些工作做得好,哪些做得不好。通过不断尝试 Scrum 和 Kanban 提出问题并分析原因,这样的话,团队可以更快地掌握敏捷开发的秘诀。
Scrum 开发指南: Scrum 框架详解 | Scrum 四个会议及正确召开方式 | 正确的计划和执行Sprint的方式 | 做好迭代计划的4大关键点 | 做好这4点让每日站会更适配敏捷团队 | 开好迭代评审会的3个关键步骤 | 为什么要召开迭代回顾会 | Scrum 3大角色及其岗位的具体职责 | Scrum三大工件在敏捷开发中的作用 | 2022年14个最佳 Scrum 敏捷项目管理软件 | 更多
Kanban 敏捷指南: 使用看板(Kanban)管理方法的5大好处 | 看板 VS Scrum:如何选择? | 看板和 Scrum 的混合模式适合在哪些场景使用 | 更多
规模化敏捷: 规模化敏捷的价值及五大规模化敏捷框架 | 规模化敏捷之 Spotify 模型 | 规模化敏捷框架之LeSS框架 | 更多