Explore
For Enterprise
Join for Free
Log In

artes y humanidades
Negocios
Ciencias de la Computación
Ciencia de Datos
Tecnología de información
salud
Matemáticas y Lógica
Desarrollo Personal
Ciencias Físicas e Ingeniería
Ciencias sociales
Aprendizaje de un idioma
Grados
Certificados

Explorar todo lo que Coursera tiene para ofrecer

Explorar
Buscar
For Enterprise
Inicia Sesión
Únete de forma gratuita

2.4.1B: Agile Variations and Lean Software Development

Loading...

Software Processes and Agile Practices

Universidad de Alberta

4.7 (2,736 calificaciones) | 50K estudiantes inscritos

Curso 1 de 6 en Gestión de productos de software Programa Especializado

This course delves into a variety of processes to structure software development. It also covers the foundations of core Agile practices, such as Extreme Programming and Scrum.

Destrezas que aprenderás

Lean Software Development, Agile Software Development, Software Development Process, Scrum (Software Development)

Revisiones

4.7 (2,736 calificaciones)

5 stars
2,023 ratings
4 stars
611 ratings
3 stars
70 ratings
2 stars
23 ratings
1 star
9 ratings

MD

Nov 20, 2015

Great course, now i have a really clear idea about the many choices in processes to make a better software in a quality and timely manner. I´m enjoying so much this specialization, Thanks!

MB

Jun 02, 2017

Very well done! The instructors covered a lot, their course notes are incredibly helpful, and plenty of supplementary material is provided. One of the better Coursera courses I've taken.

De la lección

Module 4: Other Practices

Almost there! In this last module, we will dive into Lean Software Development and Kanban. Being the most complex tools which we will cover in this course makes them the “spike-driving machines” from our railroad-building analogy. Lean and Kanban are a cumulation of many lessons learned, and are widely used in some form in the industry today.

2.4.1: Agile Variations and Lean Software Development10:12

2.4.1A: Agile Variations and Lean Software Development9:26

2.4.1B: Agile Variations and Lean Software Development8:05

2.4.1C: Agile Variations and Lean Software Development4:33

Impartido por:

Kenny Wong
Associate Professor

Transcripción

[MUSIC]

The fifth principle of Lean software development is the concept of empowering

the team.

Here's a quote from Teddy Roosevelt, which sums up everything I'm about to say.

The best executive is one who has sense enough

to pick good people to do what he wants done, and

self-restraint enough to keep from meddling with them while they do it.

That's what this principle of empowering the team is all about.

If you believe your development team has the skills necessary to get the job

done right, then why would you spend your time trying to tell them how to do it?

Your efforts as a software product manager are best applied to other things

like understanding your client's needs.

Remove your developers' roadblocks and get out of the way.

Does this sound contrary to traditional management?

Often, when we think of management, we think of an overbearing person

telling their team in detail what needs to get done and how to do it.

This says a lot about how little those managers trust their team, doesn't it?

And of course, the team members can sense that.

It's draining to be micromanaged and told what to do day after day.

This is why Lean software development aims to empower the teams which

follow its practices.

Instead of telling your developers how to do things,

Lean software development encourages managers to listen to their developers.

As a software product manager, you're encouraged to let your developers

imagine solutions that satisfy client requirements.

Your goal should be to listen to what your developers have to say and

offer suggestions.

After all, they should be your allies.

This practice of believing in your development team

allows your team to work how they want to work.

Trust them to make the right technical decisions.

Not only does this make sure that your developers are using the most productive

method for them, it also serves as a huge boost to their morale.

When your development team feels as though they're in control and

they're given the freedom to complete their tasks without being micro-managed,

things go so much more smoothly.

This is the rationale behind empowering the team.

A happy development team is a productive and an efficient one.

Let's test your knowledge on these principles.

What is one of the main reasons that a software development team, and client,

should decide as late as possible when developing a software product?

A. it buys them more development time.

B. it allows them to explore other product designs.

C. the client never knows what they want.

And/or D. it allows the team to build working software quickly.

The correct answer is B.

Deciding as late as possible allows your developers and

your client to explore other potentially better product designs.

This doesn't extend product deadlines or make anything go faster.

And it definitely doesn't mean that your client never knows what they want.

Remember, just because you present your client with the best possible option

by deciding late, it doesn't mean that you don't have to be on time.

The sixth principle of Lean software development

is a principle of building integrity in.

This is a broad, all-encompassing principle.

What it really aims to do is ensure that your development team

is using the best practices available to them in order to avoid errors.

So how does this look?

Well, I mentioned briefly in the practice of

test driven development in a previous module.

This means writing tests before you actually need them.

Instead of building your product and

then testing, where developers write tests around existing code,

you want to focus the actual problem that the code is meant to solve.

Basically, building your tests first

means you're actually testing if your code solves your problem.

And not only if your code works.

Another way of building quality in, is one that borrows from Extreme programming,

which Morgan talked about in the last module:

Pair programming.

I would encourage you to re-watch that lesson if you need a refresher.

However, I will say that pair programming is a way for

developers to really increase the quality of their product.

Basically, it's like having an intelligent guide by your side as you build.

I will warn you that pair programming is also

very costly in terms of developer time.

So while it's a wonderful tool for

developing great software, don't rely on it to build your entire product.

If you do, you may just end up violating the deliver as fast as possible principle.

There are other ways of building quality into your products as well.

Things like well commented code,

good documentation, refactoring code to be more efficient, and automated testing.

They are all ways in which you can do this.

If you would like more information on these topics specifically,

please see the course resources.

We have included some readings for your reference.

All of this serves the purpose of making your product better.

One of the core values of Lean is to eliminate as much waste as possible.

So by reducing the amount of time developers have to fix code,

you reduce the amount of waste present in your projects.

By building quality in, you drastically reduce the number of post release defects and

fixes.

So by building quality in,

you drastically reduce the amount of waste present in your product.

The final principle of Lean,

which I'll cover in this course, is the principle of seeing the whole.

What it means to see the whole, is to see your software from more than just a lot of

little components put together.

After all, what the end user sees is more than just some features strung together.

What the end user should see is a cohesive product

with components that flow into each other logically and smoothly.

So in Lean software development,

it's important to think about your product as a whole before releasing it.

This means that your developers must be constantly aware of how

their piece of the puzzle fits into the big picture.

The big picture could be the whole product, but

it could also be how that product fits with other products by the same maker.

Without this perspective, things can come out disjointed, illogical, or

just plain awkward.

Seeing the whole allows your development team to build a product as a cohesive

well-designed whole.

Ross is building a software product for medical research.

Since the work he does everyday saves lives,

he is continually trying to improve his software development processes.

He recently came across Lean software development,

and has begun implementing some of its principles.

He tries to encourage his team to see the project as part of a larger purpose, and

gets them to create many different versions of the software before committing

and focuses on building quickly.

In order to save time, he has asked his development team not to develop

unit tests, document code, or use any specific programming practices.

What aspect of Lean Software Development is Ross

actively omitting from his project?

A. eliminating waste.

B. amplifying learning.

C. deciding as late as possible.

Or D. building integrity in.

The answer is D, building integrity in.

By actively avoiding these best practices in programming,

Ross is actively choosing not to build integrity in.

By proxy, this may create waste, but not directly.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play

Coursera
Acerca de
Liderazgo
Empleo
Catálogo
Certificados
Certificados MasterTrack™
Grados
For Enterprise
For Government

Comunidad
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
Youtube
Blog de Tecnología

Más
Términos
Privacidad
Ayuda
Accesibilidad
Prensa
Contacto
Directorio
Afiliados