Software is quickly becoming integral part of human life as we see more and more automation and technical advancements. Just like we expect car to work all the time and can't afford to break or reboot unexpectedly, software industry needs to continue to learn better way to build software if it were to become integral part of human life. In this course, you will get an overview of how software teams work? What processes they use? What are some of the industry standard methodologies? What are pros and cons of each? You will learn enough to have meaningful conversation around software development processes. After completing this course, a learner will be able to 1) Apply core software engineering practices at conceptual level for a given problem. 2) Compare and contrast traditional, agile, and lean development methodologies at high level. These include Waterfall, Rational Unified Process, V model, Incremental, Spiral models and overview of agile mindset 3) Propose a methodology best suited for a given situation
Kanban
Loading...
来自 University of Minnesota 的课程
Software Development Processes and Methodologies
140 个评分
从本节课中
Software Development Models: Agile and Lean
In this module, we will learn about agile and modern techniques of software development. We will also learn about techniques that helps you learn faster about your market, your users, and your product.
与讲师见面
Praveen MittalAdjunct Professor
College of Science and Engineering
Kevin WendtTeaching Specialist
Department of Computer Science and Engineering
In this lesson, we're going to learn about a technical Kanban,
which is a practice that was borrowed from [inaudible] production system.
And basically, helps team optimize their software development process.
So let's take a look at what Kanban is.
To understand Kanban, let's put it next to a screen process.
So we know how different it is.
So in Scrum, we work in one to four weeks iterations.
So In the first iteration,
let's say one to four weeks,
we will take part of the product, we'll define it,
design it build it,
and test it and then there will be some product that will come out of it.
And then we will just continue that cycle until we are done, all right?
As you can notice that the product changes over time.
The style and the color is changing.
That has to reflect the adaptive nature of Scrum.
Which means that, as we complete each of these cycles,
we may get feedback from the client,
and we may change what we want to build.
Now, Kanban doesn't prescribe any of these fixed iterations or any new practices.
It's just a set of properties and principles that
help optimize software development process as long as that process is a continuous flow.
What do we mean by continuous flow?
So by continuous flow,
I mean like things from the backlogs are moving through
this software development pipeline and its finished product is
coming out at the other end of the pipeline.
So, for example, the first item got done,
then the another item, then a couple items.
And as you can see, this is also an adapter process,
where as things are getting completed,
we can get feedback from the customer and feed it into the backlog but at the end,
we get the whole product.
And so, Kanban basically,
then optimizes the software development pipeline by a set of principles and properties.
So let's see how these properties and principle play.
So let's say a team has a process where
the work items goes from backlog to the analysis or analyze,
then develop, then test, and then to release.
And we have asked this team to build a job website and which has these features.
So let's apply Kanban to the situation.
So first thing that Kanban suggest or
the first property of Kanban is to visualize your workflow.
So let's see how we are going to visualize the workflow.
To visualize the workflow,
you basically create a visual board.
It can be an electronic or it could be a physical board.
And you move all your columns,
or all your states,
or all your steps of your process into one column.
And then in some columns,
you will see doing and done.
That means, if the item is being processed or being analyzed then will be in the doing,
if it is done, then you will move it to the done sub-column.
So once you create this board,
then as you move each,
as you work on each of these items, for example,
let's say the team is working on post a new job,
so then they will move the item to the analyzed because they're doing the analysis.
And then let's say, they started analyzing the create profile also.
So they'll move it to the analyze and so on.
So, as the work is being done,
the work item is moved on the board to represent where that each item is.
So let's see what the board is going to look like after a few days.
So our board after a few days look like this.
So, do you see any problem with this board?
Well, if you see in the test column,
there is lot of item pending, all right?
So that is if we don't do anything right now,
the items in the test column will pile up and will become a bottleneck,
and it will slow down the delivery.
So, how do you solve this?
So, Kanban support another property called limit work in progress.
So what you do is for each of your state,
you define what's the maximum number of items that can stay in that state.
So for example, in this case,
in the analyze state,
we can have only one item and in the develop state,
we can have only three items.
So far in the analyze state and in the develop state we are good,
because we have only one in the analyze,
and we have two in the develop. So far so good.
But then, when we look at the test, the limit,
let's say we set as two,
so we have four items.
So that is a no no,
like it should not happen.
So if the team has this WIP limits and they were following it,
this situation won't have happened.
So let's go back in time and see how this will flow if it was falling Kanban property.
So let's say this end on tenth day,
the board looks like this.
And developer just got done with make payment,
and they want to pick another item from the analyze.
So, can they move update job into the develop column?
No, because the number of items in develop are only three and the WIP limit is three.
So the WIP limit calculates both doing and the done.
So we cannot move update job.
Well, maybe we can move the make payment and login into
the test because they are done. No, we can't.
Because the test column also has a WIP limit of two,
and we already have two cards over there.
So in this case,
what developers are going to do?
Or the team is going to talk about is like, what is happening?
Why the things are not moving from test?
Well, there could be many reasons.
One reason could be that the code is very buggy or lay a lot of defects and so,
that's why it is taking a lot of time,
or they may not have enough people in the test tip.
So here developer can go okay,
if there is too many bugs like,
maybe I can do a better job and maybe fix it or if it is a resource issue,
then I can help test one of those things and so that you can move it.
So let's say the developer help them.
So in that case, let's say sign up was done and then we'll move it to release.
Now, the test column has only one,
so now we can move the login into the test column.
Now, the developer can move
the update job into the doing column, and they can work on it.
So look, we sorted out the flow issue by collaboration and working with each other.
Now, if this is a temporary situation, this is perfectly fine.
You don't need to do anything.
But if it is a permanent problem that will happen again,
then you want to manage the flow.
You want to fix it permanently,
and that's where comes the property number three which is manage the flow.
So we want to find out.
If it is a permanent resource issue,
then add more people to the test or if it is buggy code,
then what can we do in the development so that we don't
have that many defects and then it moves faster.
So, whatever you do but you try to manage your flow.
Now, this board will work good only if team members
are moving the card from one state to another state consistently.
But everyone may have different understanding of the policies of when to move or not.
So Kanban suggest another property called "Make Process Policies Explicit" which means,
we define exactly, what are the policies that the team will follow.
So one example could be,
the definition of done for each of the states.
So the definition of done would be,
when can I move? When is something done?
So for the analyze phase,
when the update resume is done well,
when we have requirements defined or
whatever we need to be done for that story to move from doing to done.
Similarly, in the develop state.
So that gives a very clear understanding to the team members as
to when they can move items from one state to another state.
So here, we just went through some of the core properties of Kanban,
but there are a couple more principles and properties that are
defined in Kanban. Let's look at those.
So, Kanban defines three principles and five properties.
We already talked about the four properties.
So let's talk about the principles and the properties.
The first principle is, start with what you do know.
So as you saw,
that we didn't really created a whole new process.
We just said whatever is the current process,
let's start from here.
And then, we agree that as we are going to manage the flow,
we are going to pursue incremental and evolutionary change.
So slowly finding out where the roadblock is?
Or where the bottleneck is?
We're going to fix that.
And then, respect the current process,
roles, responsibility and it's titles.
So, if somebody whatever roles people had or whatever titles they have,
they can continue to have that.
We change it only when we find an issue with the current flow.
And then, one of the property is improve collaboratively.
So, as you can see that when people find problems,
they have to work collectively or collaboratively.
Like everybody has to know what are the constraints?
How each of the process works?
So if they have shared understanding of what the process is and how it works,
then they will be able to have meaningful conversation and
fix the issues in the flow. So, that's Kanban.
