Defer Commitments

Loading...

Из курса от партнера University of Minnesota

Lean Software Development

36 оценки

University of Minnesota

Lean Software Development

36 оценки

Курс 3 из 4 — Specialization Software Development Lifecycle

While scrum and XP were transforming the software development industry, there were another set of ideas (derived from lean manufacturing and Six Sigma) that started to influence software development methods. These ideas around Lean Software Development forms the foundation of number of agile methods. In this course, we will explore lean concepts and cover some of the common Lean methods and techniques like Kanban, Value Stream Mapping, etc. In this course, we will also learn techniques like Lean Startup and Design Thinking that can help team learn about user and market needs much faster and cheaper. As part of this course, you will also apply the knowledge gained in this course to fictional case studies. These projects will help you gain experience to confidently apply these techniques in real world. At the end of the course, you will be able to apply lean techniques / methods to software development. You will also be able to apply methods to learn about your users and market needs much faster and cheaper.

Из урока

Lean Fundamentals

In this module, we will first learn about core lean principles from manufacturing. After that we will learn how you can apply these lean principles in software development. Finally we will learn about Lean Principles of software development in depth. At the end of this module, you will build the foundational knowledge around lean concepts.

Amplify Learning / Create Knowledge6:38

Defer Commitments6:09

Build Quality In5:55

Deliver Fast4:03

Optimize the whole3:58

Познакомьтесь с преподавателями

Praveen Mittal
Adjunct Professor
College of Science and Engineering

[MUSIC]

In this lecture, we are going to learn about one of the principles of lean

software development card defer commitment.

And this principle addresses one of the issues of software development

where we decide when we know the least about the problem.

So what is it?

It's the ability to make commitment as late as possible.

And commitment about the architecture or some decision that we have to make.

So ability to make commitment as late as possible or

make decisions when you have the information you need to make the decision.

Before commitment does not mean that you just to delay the developments but

make the decision when you have the information.

So why does it matter?

Well, if you think about it,

we have to make lots of decisions when you are doing software development,

about the architecture, about the solution that you're building.

And as you are building your solution, you have more and

more understanding of user needs.

You have better understanding of your solution.

So if you make the decision about the solution earlier without having

that information that you have, let's say, two months later,

then it may be that the chances of the decision being wrong are higher.

And so when you make wrong decision about your architecture or your design,

of course it's going to be costly and of course we don't want it.

So that's the idea that if you can delay the decision until you have

the information you need or you really require that we can move forward

until we make the decision, I think that can eliminate a lot of waste [INAUDIBLE].

So that's the idea behind this principle is to defer your decision.

I think you have all the information or until it's really needed.

So the question is how do you defer decision?

So one of the concept in traditional project management is that you

sequentially develop your software like you do all of your requirements,

all of your design, all of your development and so on.

So in this case, what happens is that you have to make all of

your design decisions in this design phase.

So you don't have all the information.

And as we know that, we know less in the early phase of the software development.

So you make all your decisions in the early phase.

Whereas, during the development, all the things you're going to learn,

we don't have that information in the design phase.

So the idea is that, if you can develop in such a way that design development, all

of those things are happen concurrently, or at least in a smaller batches,

so that we can gain more knowledge before we have to make a decision.

It's going to help you defer commitment.

At a higher level basically, what we want to do is, we want the ability

to postpone decision until the last responsible moment or make it possible.

So if you can't do that, make it possible to make changes easily.

So the change decision can be digested effectively.

So for example, let's say you're building a website, and so

you need to make a solution what tool are you going to use for the web server.

So in that case, if you can build in such a way that whatever web server you

selected in the beginning you can change it later, easily that will be effective.

Because then you're really differing decision of finally which apps are you

going to use.

The other way to do it is to keep your architecture loosely coupled.

And what we mean by loosely coupled is that there are different components of

your architecture.

And they're not too tightly dependent on each other so

change in one doesn't impact the other module weather

you like on frequent basis so really, how do you do that?

There is a lot of concept of software architecture that is beyond this course,

but at a very high level you keep modular design of your software.

And then each of these modules have the separation of concern which

means they know what are they responsible for.

And whatever the details of the implementation is encapsulation in

those modules.

And it's not kind of linked to the outside world, so

if you need to make a change in the design,

it only impacts that module and doesn't impact others.

And for the interaction between the modules, you define the interfaces,

and those are logged in.

And so what happens is that as long as the interfaces doesn't change, you can make

changes in the individual modules without impacting the whole system.

So that's one way of deferring commitment or

to make it easier to make changes.

Another thing you can do is to avoid repetition.

If your gold is at one place then you can just change once and be done with it.

If you have multiple places then if you change your mind then you have to go

multiple places to make that change.

And the another principle of leads offer is to deliver fast.

And that principle really compliments this principle because

let's say one of the process in your system is to develop budget and

right now it takes you three months to develop that budget.

So to make a decision of what budget to build and what to build,

you have to make decision before this month development time.

But if you can reduce the development time to one month,

you have two extra months to know more about what to balance.

And you can make the decision about whether to even build it or

whether you even need it.

So that's why delivering fast, which is another lean principle,

complements this principle.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2019 Все права защищены.

Загрузить из App Store

Загрузить в Google Play