Scrum vs Kanban - What's the Difference?

Development That Pays
18 Jan 201705:07

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

00:00

😀 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

Scrum是一种敏捷软件开发方法论,它通过短周期的迭代开发(称为Sprint)来交付价值给客户。在视频中,Scrum被用来与Kanban进行比较,展示了不同的工作流程和实践。例如,Scrum团队通过Sprint Planning Meeting来选择优先级高的产品待办事项列表(Product Backlog)中的项,计划在接下来的Sprint中完成。

💡Kanban

Kanban是另一种敏捷软件开发方法论,它强调可视化工作流程和限制在进行中的工作(Work In Progress, WIP)的数量以提高效率。与Scrum不同,Kanban是一个持续的流程,没有固定的Sprint周期。视频中提到,Kanban通过设置WIP限制来实现拉动系统,促进工作从产品待办事项列表到客户的流动。

💡敏捷

敏捷是软件开发中的一个概念,它强调快速迭代、灵活性和客户反馈。敏捷方法论,如Scrum和Kanban,旨在通过小的增量交付价值,并从客户那里收集反馈以改进产品。在视频中,敏捷是Scrum和Kanban共同遵循的核心原则。

💡产品待办事项列表(Product Backlog)

产品待办事项列表是敏捷开发中的一个重要概念,它是产品所有者根据客户和利益相关者的需求整理的优先级列表。它包含了产品特性和用户故事。在视频中,无论是Scrum还是Kanban,产品待办事项列表都是工作的起点,团队从这个列表中选择工作项进行开发。

💡Scrum Master

Scrum Master是Scrum框架中的一个角色,负责帮助产品所有者和开发团队采用和维护良好的工作习惯。在视频中,Scrum Master负责运行Sprint Planning Meeting,并在整个Sprint过程中提供支持。

💡敏捷教练(Agile Coach)

在Kanban中,敏捷教练的角色类似于Scrum中的Scrum Master,他们帮助团队采用敏捷实践并持续改进。视频中提到,在Kanban中,这个角色被称为敏捷教练,而不是Scrum Master。

💡拉动系统(Pull System)

拉动系统是一种工作流程管理方法,它确保工作从产品待办事项列表到客户的流动尽可能短。在视频中,Scrum和Kanban都使用拉动系统,但实现方式不同。Scrum通过Sprint来拉动工作,而Kanban通过WIP限制来实现。

💡Sprint

Sprint是Scrum中的一个核心概念,指的是一个有时间限制的迭代周期,通常为两周。在Sprint期间,开发团队致力于完成选定的产品待办事项列表中的项。视频中提到,每个Sprint开始前都有Sprint Planning Meeting,结束时有Sprint Review和Sprint Retrospective。

💡Sprint Backlog

Sprint Backlog是Scrum中的一个术语,指的是在Sprint Planning Meeting中选定的,开发团队承诺在一个Sprint中完成的产品待办事项列表中的项。视频中提到,Sprint Backlog是开发团队在Sprint期间专注的工作内容。

💡Scrum Board

Scrum Board是Scrum团队用来跟踪工作进度的工具,通常是一个可视化板,上面有代表不同工作状态的列。虽然在视频中提到Scrum Board有时也被错误地称为Kanban Board,但它是Scrum特有的实践之一。

💡每日站立会议(Daily Stand-up)

每日站立会议是Scrum和Kanban中都存在的一个实践,团队成员每天聚集,分享他们的进度和面临的障碍。在视频中,无论是Scrum还是Kanban,都提到了每日站立会议作为团队沟通和协调工作的一部分。

💡Sprint Review

Sprint Review是Scrum中的一个仪式,它在每个Sprint结束时举行,目的是向利益相关者展示新功能。在视频中,Sprint Review被描述为Sprint结束时的两个仪式之一,另一个是Sprint Retrospective。

💡Sprint Retrospective

Sprint Retrospective是Scrum中的另一个仪式,它允许团队回顾Sprint中哪些做得好,哪些做得不好,以及如何改进。视频中提到,Retrospective的目的是确保下一个Sprint比上一个更有效。

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

play00:00

If you've found this video, the chances are that you've just done a search for the difference

play00:03

between Scrum and kanban,

play00:06

you've come to the right place.

play00:07

Not only do I have a great video for you,

play00:09

I also have a cheat sheet for you to download.

play00:13

Hi this is Gary Straughan

play00:14

Welcome to Development That Pays

play00:16

Scum and Kanban are perhaps the best known of a number of Agile software development

play00:24

methodologies

play00:25

Let's break that down.

play00:27

Software Development looks like this:

play00:30

The Product Owner decides what to build

play00:34

The Development Team builds it

play00:38

and Customers use it, experience it, benefit from it in some way

play00:44

What makes software development AGILE

play00:45

is that VALUE is delivered to the customer in small increments

play00:48

And, IMPORTANTLY, feedback is gathered from customers and fed back into the process.

play00:55

It's the Product Owner's job to take input from customers

play00:58

- and from stakeholders -

play01:00

and organise it into a PRIORITISIED list of features and User Stories.

play01:05

This list is known as the Product Backlog.

play01:10

What happens between the Product Backlog and the Customer

play01:13

is what distinguishes Scrum from Kanban.

play01:17

As we'll see, each has its own routines and rituals

play01:19

it's this person's job to help the Product owner and Development Team to adopt and maintain

play01:25

good habits.

play01:26

In Scum, the role is known as the Scrum Master.

play01:28

In Kanban, the role is known as the Agile Coach.

play01:33

Something that Scrum and Kanban have in common is that both are PULL systems.

play01:38

Without getting into two much detail, the pull system ensure that work gets from Product

play01:41

Backlog to Customer in the shortest possible time.

play01:45

The pull system also helps to uncover bottlenecks in the process

play01:49

Which helps to ensure that work gets from Product Backlog to the Customer

play01:53

in the shortest possible time!

play01:56

As you'll see in a moment, Scum and Kanban implement the pull system in two strikingly

play02:00

different ways

play02:02

Scrum teams work in a series of SPRINTS, most commonly two weeks in length.

play02:07

Each Sprint it proceeded by a "Sprint Planning Meeting"

play02:10

run by the Scrum Master and attended by the Product Owner and the Development Team

play02:14

Together they select high priority items from the product backlog that the Development Team

play02:19

believe it can commit to delivering in a single Sprint.

play02:23

This is the "pull" I was talking about earlier.

play02:27

The selected items are known as the SPRINT BACKLOG.

play02:29

For the next two weeks, the Development Team focuses on working through the items in the

play02:34

Sprint Backlog.

play02:35

And ONLY those items in the Sprint Backlog:

play02:38

in all but the most exceptional circumstances,

play02:40

any new requirements that arise have to wait for the following Sprint.

play02:45

It's common practice for Scum teams to use a board to track the progress of the work.

play02:49

It's called a Scrum Board... or an Agile Board...

play02:52

or even (slightly confusingly) a Kanban Board.

play02:56

Each day during the Sprint there is a Scum Meeting:

play02:58

it's a stand up meeting where the team takes a maximum of 15 minutes to discuss progress

play03:02

and identify any "blockers".

play03:05

At the end of the sprint, the work completed during the sprint is packaged for release

play03:10

Any incomplete items are returned to the Product Backlog

play03:13

The Sprint ends with two rituals:

play03:15

The Sprint Review, which is a demonstration of new functionality to Stakeholders.

play03:21

The Sprint Retrospective, which is an examination of what went well, what went badly and what

play03:25

could be improved.

play03:27

The aim of the Retrospective is to ensure that the next sprint is more efficient and

play03:31

effective than the last.

play03:32

And that's Scrum

play03:36

Kanban does a few things differently.

play03:38

There's no two-week sprint: Kanban is a continuous process.

play03:43

There's no Sprint Backlog.

play03:44

The "pull" system in Kanban happens in a different way, via Work In Progress limits.

play03:50

Each column on the Kanban board has a Work in Progress limit

play03:53

related to the team's capacity.

play03:55

For example a team with two developers would set a limit between two and four items.

play04:00

The lower the better.

play04:03

Let's see the pull system in action.

play04:05

When testing of a particular feature is complete, the corresponding ticket moves to the "Done"

play04:10

column

play04:11

The empty column is a signal to the previous column to send another ticket.

play04:15

That's the "pull"

play04:16

And when the in "Build" column is almost empty

play04:18

is a signal to the team to select another high priority item from the Product Backlog.

play04:24

That's the "pull" again.

play04:25

Like Scrum, Kanban has :

play04:30

Daily Stand-up

play04:31

Demo for stakeholders

play04:33

Retrospective

play04:37

So now you know the key differences between Scrum and Kanban.

play04:40

Two important things to say at this point:

play04:44

Neither Scrum nor Kanban are as prescriptive as I may have made them appear.

play04:48

High performing teams discover what works for them

play04:51

and flex the system appropriately.

play04:55

I've put together a CHEAT SHEET for you

play04:56

that covers everything that we're talked about today

play04:59

plus some additional notes that I think you will find useful.

play05:02

You can grab your copy from my blog

Rate This

5.0 / 5 (0 votes)

相关标签
敏捷开发ScrumKanban产品负责人开发团队敏捷教练Scrum Master迭代产品待办清单工作进展敏捷实践