百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

一图搞懂Scrum与Kanban九大区别︱看板管理

ccwgpt 2024-10-14 08:38 30 浏览 0 评论


世上安得双全法,不负如来不负卿

本文由某央企信息化部门高级项目经理尚君领原创, 来自翰德恩咨询北京看板认证课学员

这里默认同学已经知道什么是Scrum,什么是Kanban,关于这二者的定义不再重复。那么新的问题出现了:同样作为敏捷开发的一个框架,同样是轻量级的方法,他们到底有哪些不同?我们应该选择他们中的哪一个作为团队级敏捷的开始呢?下面我们先尝试着来看看他们的区别,如下图所示:

计划的方式不同

Scrum要求在每个Sprint开始之初就要给接下来的Sprint做Planning,不过Kanban并没有这个要求,可以认为它是按需计划,也就是在当前工作项完成,要拉进来新的人任务的时候再进行planning。当然现在不管是理论还是实践,Kanban也在使用Cadence的概念,但本质还是按需计划。

Effort Estimation不同

Scrum要求在每个Sprint开始之前要给下个Sprint进行的用户故事给出估计(用人天、故事点等估算),如果一个用户故事大到一个Sprint无法完成,那么就应该对其进行拆分,但是Kanban对于估计并不是必须的。它仅仅是当前工作项完成以后,将新的工作项“拉”进来而已。Kanban关注的是流动。当然如果要实现可预测性,可能依然需要估计,跟上面的planning一样,按需估计。

工作范围的改变

对于Scrum来说,一个sprint一旦开始,工作内容是不能改变的,Scrum Master应该包含团队不被打扰、专注完成当前迭代承诺的任务。而Kanban则非常灵活,因为它没有时间盒的概念,所以随时可以添加修改backlog里的任务并调整他们的优先级,这样的调整能够非常快的反应到下一次的任务拉取中。

角色的不同

对于Scrum来说,我们设有全新的角色:Scrum Master,Product Owner,Development Team。尤其是Scrum Master,更是在以前任何组织中都不曾存在的一个角色。这会导致我们导入Scrum的时候,往往带来组织的较大的改变:比如组建新的team,任命新的角色,开展新的流程。而Kanban则没有定义任何新的角色,并没有一个Kanban master这样的角色,而是在使用现存的任何组织和角色的基础上开展Kanban实践,这也是Kanban方法中渐进式变革的一个体现。

会议的不同

在Scrum中,我们有Planning Meeting,daily stand-up meeting,sprint review meeting, retrospective meeting以及backlog refinement meeting。对于每个会议的形式,目的,周期甚至会议长度都有相应的说明。在Kanban中,一般会有排列优先级相关的会议(用于调整backlog里面的优先级并且明晰接下来的工作,并不是必须的),每日站会(并没有设计每日三问,用于关注看板的价值流动),以及回顾会议(这个和Scrum的retrospective meeting并没有本质区别)。

Ownership的不同

在Scrum里面,产品的拥有者是Product Owner,他来维护产品待办列表,调整优先级,并决定接受还是拒绝Sprint结束团队提交的价值增量。在Kanban方法中并没有类似的限制,根据组织的现状和需要定义谁来负责类似Prouct Owner的职责。

度量工具的不同

Scrum里面我们一般使用燃尽图来观察现状,发现偏差,预测趋势。在Kanban里面则使用累积流图来计算周期时间、吞吐率等指标。

约束方式的不同

Scrum使用固定的时间盒来作为迭代的时间约束,也是隐性的对一个迭代里面所能承担的用户故事做一个约束。Kanban则是使用WIP限制来约束团队同时可工作的任务数量。

价值核心不同

对于Scrum来说,它的根在于敏捷,也就是敏捷宣言和敏捷十二原则。是为了适应不确定性和快速变化而产生。对于Kanban而言,他的根在于精益,来自于丰田生产方法,是为了消除浪费,聚焦价值流动。当然这么说有点狭义,现在精益敏捷往往放在一起谈论,但是他们诞生之初确实是为了解决不同的问题。到现在实施起来依然有所不同,比如Scrum强调团队,而看板则强调价值流,这种区别正是因为他们的来源不一样造成的。

如何选择

两种框架有着这么多区别,那么最后的问题是“我们要选择哪一个方法来用呢”?其实两种方法并没有好坏高下之分,也没有简单复杂的区别,具体使用哪一种方法,需要结合组织自身的实际情况来判断。个人认为,Kanban对于需求变化非常快的项目更有优势,比如连一周的迭代都没办法保证的特性开发,或者属于支持/维护类的项目团队。而相对来说,对于那些有着清晰roadmap的特性开发团队,以便于按照固定的节奏提交价值增量,Scrum更加有完整的套路。此外,看板对于不喜欢对现状改变太大的企业,更加容易被接受。(文章来源:翰德恩业务敏捷)

相关推荐

RACI矩阵:项目管理中的角色与责任分配利器

作者:赵小燕RACI矩阵RACI矩阵是项目管理中的一种重要工具,旨在明确团队在各个任务中的角色和职责。通过将每个角色划分为负责人、最终责任人、咨询人和知情人四种类型,RACI矩阵确保每个人都清楚自己...

在弱矩阵组织中,如何做好项目管理工作?「慕哲制图」

慕哲出品必属精品系列在弱矩阵组织中,如何做好项目管理工作?【慕哲制图】-------------------------------慕哲制图系列0:一图掌握项目、项目集、项目组合、P2、商业分析和NP...

Scrum模式:每日站会(Daily Scrum)

定义每日站会(DailyScrum)是一个Scrum团队在进行Sprint期间的日常会议。这个会议的主要目的是为了应对Sprint计划中的不断变化,确保团队能够有效应对挑战并达成Sprint目标。为...

大家都在谈论的敏捷开发&Scrum,到底是什么?

敏捷开发作为一种开发模式,近年来深受研发团队欢迎,与瀑布式开发相比,敏捷开发更轻量,灵活性更高,在当下多变环境下,越来越多团队选择敏捷开发。什么是敏捷?敏捷是一种在不确定和变化的环境中,通过创造和响应...

敏捷与Scrum是什么?(scrum敏捷开发是什么)

敏捷是一种思维模式和哲学,它描述了敏捷宣言中的一系列原则。另一方面,Scrum是一个框架,规定了实现这种思维方式的角色,事件,工件和规则/指南。换句话说,敏捷是思维方式,Scrum是规定实施敏捷哲学的...

敏捷项目管理与敏捷:Scrum流程图一览

敏捷开发中的Scrum流程通常可以用一个简单的流程图来表示,以便更清晰地展示Scrum框架的各个阶段和活动。以下是一个常见的Scrum流程图示例:这个流程图涵盖了Scrum框架的主要阶段和活动,其中包...

一张图掌握项目生命周期模型及Scrum框架

Mockito 的最佳实践(mock方法)

记得以前面试的时候,面试官问我,平常开发过程中自己会不会测试?我回答当然会呀,自己写的代码怎么不测呢。现在想想我好像误会他的意思了,他应该是想问我关于单元测试,集成测试以及背后相关的知识,然而当时说到...

EffectiveJava-5-枚举和注解(java枚举的作用与好处)

用enum代替int常量1.int枚举:引入枚举前,一般是声明一组具名的int常量,每个常量代表一个类型成员,这种方法叫做int枚举模式。int枚举模式是类型不安全的,例如下面两组常量:性别和动物种...

Maven 干货 全篇共:28232 字。预计阅读时间:110 分钟。建议收藏!

Maven简介Maven这个词可以翻译为“知识的积累”,也可以翻译为“专家”或“内行”。Maven是一个跨平台的项目管理工具。主要服务于基于Java平台的项目构建、依赖管理和项目信息管理。仔...

Java单元测试框架PowerMock学习(java单元测试是什么意思)

前言高德的技术大佬在谈论方法论时说到:“复杂的问题要简单化,简单的问题要深入化。”这句话让我感触颇深,这何尝不是一套编写代码的方法——把一个复杂逻辑拆分为许多简单逻辑,然后把每一个简单逻辑进行深入实现...

Spring框架基础知识-第六节内容(Spring高级话题)

Spring高级话题SpringAware基本概念Spring的依赖注入的最大亮点是你所有的Bean对Spring容器的存在是没有意识的。但是在实际的项目中,你的Bean必须要意识到Spring容器...

Java单元测试浅析(JUnit+Mockito)

作者:京东物流秦彪1.什么是单元测试(1)单元测试环节:测试过程按照阶段划分分为:单元测试、集成测试、系统测试、验收测试等。相关含义如下:1)单元测试:针对计算机程序模块进行输出正确性检验工作...

揭秘Java代码背后的质检双侠:JUnit与Mockito!

你有没有发现,现在我们用的手机App、逛的网站,甚至各种智能设备,功能越来越复杂,但用起来却越来越顺畅,很少遇到那种崩溃、卡顿的闹心事儿?这背后可不是程序员一拍脑袋写完代码就完事儿了!他们需要一套严谨...

单元测试框架哪家强?Junit来帮忙!

大家好,在前面的文章中,给大家介绍了以注解和XML的方式分别实现IOC和依赖注入。并且我们定义了一个测试类,通过测试类来获取到了容器中的Bean,具体的测试类定义如下:@Testpublicvoid...

取消回复欢迎 发表评论: