Scrum vs Kanban - What's the Difference?
Summary
TLDR本视频脚本由Gary Straughan提供,介绍了敏捷软件开发方法中的Scrum和Kanban两种框架。Scrum通过Sprint周期、Sprint规划会议、Scrum看板、每日Scrum会议、Sprint评审和回顾等流程,确保价值快速交付给客户并持续改进。Kanban则采用持续流程、工作在进行中限制和拉动系统,以不同的方式实现价值的快速交付和流程优化。两者都强调团队自我组织和适应性,但实施细节有所不同。视频还提供了一个备忘单,帮助观众更好地理解这两种方法。
Takeaways
- 😀 Scrum和Kanban是敏捷软件开发方法论中最著名的两种。
- 🛠️ 软件开发的敏捷性体现在通过小增量向客户提供价值,并从客户那里收集反馈。
- 📋 产品负责人负责将客户和利益相关者的输入组织成优先级列表,即产品待办事项列表。
- 🤹♂️ Scrum中有一个角色称为Scrum Master,而Kanban中有一个角色称为敏捷教练。
- 🔁 Scrum和Kanban都是拉取系统(Pull System),确保工作从产品待办事项列表到客户的最短时间和发现瓶颈。
- 🏃 Scrum团队以一系列冲刺(Sprints)进行工作,通常是两周长。
- 📝 Scrum中有一个冲刺计划会议,团队从产品待办事项列表中选择高优先级项作为冲刺待办事项。
- 📊 Scrum团队使用冲刺板来跟踪工作进度,并且每天会有一个站立会议来讨论进展和识别障碍。
- 📦 冲刺结束时,完成的工作被打包准备发布,未完成的项目返回产品待办事项列表。
- 🔍 Kanban是一个持续的过程,没有两周的冲刺,也没有冲刺待办事项,而是通过工作进行中的(WIP)限制来实施拉取系统。
- 🔄 Kanban也有每日站立会议、向利益相关者演示和回顾会议,但与Scrum的实施方式不同。
- 🔄 无论是Scrum还是Kanban,高效团队都会发现适合他们的方法,并适当地调整系统。
- 📄 视频提供了一个备忘单,涵盖了视频中讨论的所有内容以及一些额外的有用笔记。
Q & A
Scrum和Kanban是什么?
-Scrum和Kanban是敏捷软件开发方法论中的两种框架,它们帮助团队以更灵活和响应变化的方式进行软件开发。
敏捷软件开发的核心是什么?
-敏捷软件开发的核心是持续向客户交付价值,并从客户那里收集反馈,将反馈整合到开发过程中。
产品负责人在敏捷开发中扮演什么角色?
-产品负责人负责收集客户和利益相关者的需求,并将这些需求组织成一个优先级列表,即产品待办事项列表。
Scrum Master和Agile Coach分别在Scrum和Kanban中扮演什么角色?
-Scrum Master在Scrum中帮助产品负责人和开发团队采用和维护良好的习惯,而Agile Coach在Kanban中扮演相似的角色。
Scrum和Kanban如何实现拉动系统?
-Scrum通过Sprint来实现拉动系统,而Kanban通过工作进度(WIP)限制来实现拉动系统,确保工作从产品待办事项列表到客户手中尽可能快。
Scrum中的Sprint是如何运作的?
-Scrum中的Sprint通常是两周长,每个Sprint开始前会有一个Sprint计划会议,团队成员会从产品待办事项列表中选择高优先级项作为Sprint待办事项,并在接下来的两周内专注于完成这些事项。
Scrum团队如何跟踪工作进度?
-Scrum团队通常使用Scrum板(或敏捷板)来跟踪工作的进度,这是一个可视化工具,帮助团队成员了解当前的工作状态。
Scrum中的每日Scrum会议有什么作用?
-每日Scrum会议是一个站立会议,团队成员在最多15分钟内讨论进展情况,并识别任何阻碍进度的问题。
Kanban与Scrum的主要区别是什么?
-Kanban没有固定的Sprint周期,它是一个持续的过程,并且通过设置工作进度限制来实现拉动系统,而不是通过Sprint待办事项。
Kanban如何通过拉动系统来控制工作进度?
-在Kanban中,当一个功能测试完成并移动到'完成'列时,它会触发前一列发送另一个待办事项,这就是拉动系统在Kanban中的运作方式。
Scrum和Kanban的共同点有哪些?
-Scrum和Kanban的共同点包括每日站立会议、向利益相关者展示新功能以及回顾会议,目的是提高团队效率和效果。
为什么Scrum和Kanban都不是非常规定性的框架?
-因为高绩效团队会发现适合自己的工作方式,并相应地调整系统,使得Scrum和Kanban可以根据团队的特定需求和环境灵活应用。
如何获取关于Scrum和Kanban的额外信息和笔记?
-可以通过访问Gary Straughan的博客下载他提供的关于Scrum和Kanban的备忘单,其中包含了视频讨论的所有内容以及一些额外的有用笔记。
Outlines
😀 Scrum和Kanban介绍
本段介绍了Scrum和Kanban作为敏捷软件开发方法论的基础知识。Scrum和Kanban都是以小增量交付价值给客户,并从客户那里收集反馈来优化开发流程。产品负责人负责将客户和利益相关者的输入组织成优先级列表,即产品待办事项列表。Scrum和Kanban的主要区别在于产品待办事项列表和客户之间的处理方式。Scrum中有帮助产品负责人和开发团队维持良好习惯的角色,称为Scrum Master,而Kanban中称为敏捷教练。两者都是拉取系统,确保工作从产品待办事项列表到客户的时间尽可能短,并帮助发现流程中的瓶颈。
🏃 Scrum的工作方式
Scrum团队以一系列通常为两周的Sprint进行工作。每个Sprint开始前会有一个Sprint计划会议,由Scrum Master主持,产品负责人和开发团队参加,共同选择高优先级的产品待办事项列表中的项目,开发团队认为可以在单个Sprint中交付。这些选定的项目被称为Sprint待办事项列表。接下来的两周,开发团队专注于完成Sprint待办事项列表中的项目,并且除了最特殊的情况外,任何新的需求都必须等待下一个Sprint。Scrum团队通常使用看板来追踪工作的进度,称为Scrum看板或敏捷看板。在Sprint期间的每一天,都会有一个Scrum会议,即站立会议,团队用最多15分钟讨论进展并识别任何阻碍。Sprint结束时,完成的工作被打包准备发布,未完成的项目返回产品待办事项列表。Sprint以两个仪式结束:Sprint评审,向利益相关者展示新功能;Sprint回顾,检查哪些进展顺利,哪些不顺利,以及可以改进的地方。
🔄 Kanban的工作方式
Kanban与Scrum有几个不同之处。Kanban没有两周的Sprint,是一个持续的过程。Kanban没有Sprint待办事项列表,它的拉取系统通过工作进行中(WIP)限制来实现。Kanban看板上的每个列都有与团队容量相关的WIP限制。例如,有两名开发人员的团队会将限制设置在两到四个项目之间。当某个特定功能的测试完成时,相应的票据移动到“完成”列,空列是向前一列发送另一个票据的信号,这是拉取机制的体现。当“构建”列几乎为空时,是向团队发出选择产品待办事项列表中的另一个高优先级项目的信号,这是拉取机制的再次体现。像Scrum一样,Kanban也有每日站立会议、向利益相关者的演示和回顾。
📚 Scrum和Kanban的灵活性
最后,需要强调的是,Scrum和Kanban并不像介绍中那样规定性。高效的团队会发现适合他们的方法,并相应地调整系统。视频提供了一个备忘单,涵盖了视频中讨论的所有内容,以及一些额外的有用笔记。观众可以从博主的博客上获取这份备忘单的副本。
Mindmap
Keywords
💡Scrum
💡Kanban
💡敏捷
💡产品待办事项列表(Product Backlog)
💡Scrum Master
💡敏捷教练(Agile Coach)
💡拉动系统(Pull System)
💡Sprint
💡Sprint Backlog
💡Scrum Board
💡每日站立会议(Daily Stand-up)
💡Sprint Review
💡Sprint Retrospective
Highlights
Scrum和Kanban是最著名的敏捷软件开发方法论之一。
敏捷软件开发的核心在于向客户交付小的价值增量,并收集反馈。
产品负责人负责根据客户和利益相关者的输入,组织优先级列表。
产品负责人创建的产品待办事项列表是Scrum和Kanban之间的区别之一。
Scrum中帮助产品负责人和开发团队维护良好习惯的角色称为Scrum Master。
Kanban中相应的角色称为敏捷教练。
Scrum和Kanban都是拉取系统,确保工作以最短的时间从产品待办事项传递到客户。
Scrum团队以一系列Sprint工作,通常长度为两周。
每个Sprint开始前会有一个Sprint计划会议,由Scrum Master主持。
Scrum团队从产品待办事项中选择高优先级项作为Sprint待办事项。
Scrum团队在Sprint期间专注于完成Sprint待办事项中的任务。
Scrum团队使用Scrum板或敏捷板来跟踪工作的进展。
Scrum团队每天进行Scrum会议,讨论进展和识别阻碍。
Sprint结束时,完成的工作被打包准备发布,未完成的项目返回产品待办事项。
Sprint以Sprint评审和Sprint回顾两个仪式结束,目的是提高下一个Sprint的效率和效果。
Kanban与Scrum不同,没有两周的Sprint,是一个持续的过程。
Kanban通过工作进行中的限值实施拉取系统,每个栏目都有与之相关的限值。
Kanban的拉取系统通过完成测试后,相应票据移动到“完成”栏目来实现。
Kanban也有每日站立会议、向利益相关者演示和回顾。
Scrum和Kanban都不是非常规定性的,高效团队会根据自己的需要适当调整系统。
作者提供了一个涵盖讨论内容和额外有用笔记的备忘单供下载。
Transcripts
If you've found this video, the chances are that you've just done a search for the difference
between Scrum and kanban,
you've come to the right place.
Not only do I have a great video for you,
I also have a cheat sheet for you to download.
Hi this is Gary Straughan
Welcome to Development That Pays
Scum and Kanban are perhaps the best known of a number of Agile software development
methodologies
Let's break that down.
Software Development looks like this:
The Product Owner decides what to build
The Development Team builds it
and Customers use it, experience it, benefit from it in some way
What makes software development AGILE
is that VALUE is delivered to the customer in small increments
And, IMPORTANTLY, feedback is gathered from customers and fed back into the process.
It's the Product Owner's job to take input from customers
- and from stakeholders -
and organise it into a PRIORITISIED list of features and User Stories.
This list is known as the Product Backlog.
What happens between the Product Backlog and the Customer
is what distinguishes Scrum from Kanban.
As we'll see, each has its own routines and rituals
it's this person's job to help the Product owner and Development Team to adopt and maintain
good habits.
In Scum, the role is known as the Scrum Master.
In Kanban, the role is known as the Agile Coach.
Something that Scrum and Kanban have in common is that both are PULL systems.
Without getting into two much detail, the pull system ensure that work gets from Product
Backlog to Customer in the shortest possible time.
The pull system also helps to uncover bottlenecks in the process
Which helps to ensure that work gets from Product Backlog to the Customer
in the shortest possible time!
As you'll see in a moment, Scum and Kanban implement the pull system in two strikingly
different ways
Scrum teams work in a series of SPRINTS, most commonly two weeks in length.
Each Sprint it proceeded by a "Sprint Planning Meeting"
run by the Scrum Master and attended by the Product Owner and the Development Team
Together they select high priority items from the product backlog that the Development Team
believe it can commit to delivering in a single Sprint.
This is the "pull" I was talking about earlier.
The selected items are known as the SPRINT BACKLOG.
For the next two weeks, the Development Team focuses on working through the items in the
Sprint Backlog.
And ONLY those items in the Sprint Backlog:
in all but the most exceptional circumstances,
any new requirements that arise have to wait for the following Sprint.
It's common practice for Scum teams to use a board to track the progress of the work.
It's called a Scrum Board... or an Agile Board...
or even (slightly confusingly) a Kanban Board.
Each day during the Sprint there is a Scum Meeting:
it's a stand up meeting where the team takes a maximum of 15 minutes to discuss progress
and identify any "blockers".
At the end of the sprint, the work completed during the sprint is packaged for release
Any incomplete items are returned to the Product Backlog
The Sprint ends with two rituals:
The Sprint Review, which is a demonstration of new functionality to Stakeholders.
The Sprint Retrospective, which is an examination of what went well, what went badly and what
could be improved.
The aim of the Retrospective is to ensure that the next sprint is more efficient and
effective than the last.
And that's Scrum
Kanban does a few things differently.
There's no two-week sprint: Kanban is a continuous process.
There's no Sprint Backlog.
The "pull" system in Kanban happens in a different way, via Work In Progress limits.
Each column on the Kanban board has a Work in Progress limit
related to the team's capacity.
For example a team with two developers would set a limit between two and four items.
The lower the better.
Let's see the pull system in action.
When testing of a particular feature is complete, the corresponding ticket moves to the "Done"
column
The empty column is a signal to the previous column to send another ticket.
That's the "pull"
And when the in "Build" column is almost empty
is a signal to the team to select another high priority item from the Product Backlog.
That's the "pull" again.
Like Scrum, Kanban has :
Daily Stand-up
Demo for stakeholders
Retrospective
So now you know the key differences between Scrum and Kanban.
Two important things to say at this point:
Neither Scrum nor Kanban are as prescriptive as I may have made them appear.
High performing teams discover what works for them
and flex the system appropriately.
I've put together a CHEAT SHEET for you
that covers everything that we're talked about today
plus some additional notes that I think you will find useful.
You can grab your copy from my blog
浏览更多相关视频
![](https://i.ytimg.com/vi/bdSzvnccLQk/hq720.jpg)
Scrum DOES NOT Equal AGILE
![](https://i.ytimg.com/vi/moP9VtkoyjY/hq720.jpg)
Intro to Design Systems | FlutterFlow University
![](https://i.ytimg.com/vi/CoAXKgNo-QM/hq720.jpg)
Do you understand ALL this French menu ? Real French conversation at the restaurant (+subtitles)
![](https://i.ytimg.com/vi/nAh7mCEk3Ws/hq720.jpg?v=63e82550)
【创业】超实用!3个自动化系统让你的效率倍增!|一人公司如何既节约成本又提高效率?
![](https://i.ytimg.com/vi/tjH674NI61A/hq720.jpg)
How to Make Extra Money as a Software Engineer in 2023??
![](https://i.ytimg.com/vi/CY7DYraxRKg/hq720.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGGUgZShlMA8=&rs=AOn4CLCLfqn2IvR4f13MXMvaOjh-JqF3Ew)
Requirements Analysis
![](https://i.ytimg.com/vi/XrDv22XSwwU/hq720.jpg)
How We Launched A $30,000 Product in 20 Days
5.0 / 5 (0 votes)