kanban vs. scrum · 2013-10-22 · scrum kanban burndown chart prescribed no particular type of...

Metodologías Ágiles de Desarrollo de SoftwareDomingo Gallardo, DCCIA, Univ. Alicante

Kanban vs. ScrumSesión 6b


• Libro de Henrik Kniberg y Mattias Skarin

• Disponible en InfoQ• Muy buena comparación

de ambas metodologías• Contiene un ejemplo

completo de aplicación de Kanban

2

http://www.infoq.com/minibooks/kanban-scrum-minibook



Scrum prescribe roles

• Scrum prescribe 3 roles relacionados con el proceso:• Product Owner• Team• Scrum Master

• Kanban no prescribe ningún rol en el proceso

3


Scrum prescribe iteraciones acotadas

• Las iteraciones de Scrum imponen una determinada cadencia al desarrollo• Al comienzo de la iteración: se planifica y se decide qué ítems del backlog

entran en • Durante la iteración el equipo se centra en completar esos ítems en una

fecha determinada (el final de la iteración)• Al final de la iteración el equipo demuestra el código que funciona (que

debe estar terminado, probado y ser potencialmente entregable) a los stakeholders apropiados. El equipo tiene una retrospectiva para discutir y mejorar el proceso.

• En Kanban no se prescriben las iteraciones• Se pueden planificar de forma regular (“lanzamos una release cada lunes”)

o bajo demanda (“lanzamos una release cuando tengamos algo útil que lanzar”)

4


Ejemplos de posibles iteraciones

HacemosScrum

Tenemos tres cadencias diferentes

Hacemos las reuniones y

releases cuando ha sucedido algo

relevante

© Henrik Kniberg, Kanban and Scrum5




Kanban limita el WIP por estado de flujo, Scrum el WIP por iteración• En Scrum el límite de trabajo lo impone la carga de trabajo (puntos) del

sprint y se mide con la velocidad

• En Kanban el límite se defiene en cada columna del tablero (estado del ítem de trabajo)

6© Henrik Kniberg, Kanban and Scrum




Ambos son empíricos

• Tanto en Scrum como en Kanban es necesario experimentar, probar pequeños cambios y comprobar los resultados

• Bucle de retroalimentación:Cambiar algo => Comprobar cómo ha funcionado => Aprender de ello => Volver a cambiar

• Los bucles de retroalimentación se aplicana todas las facetas: desarrollo, diseño y proceso

• En Kanban podemos experimentar conel límite de WIP y medir los resultados:

• Tiempo de ciclo• Cuellos de botella (la columna X está llena y la X+1 está vacía)

7

Bucles de retroalimentación en Scrum + XP© Henrik Kniberg, Kanban and Scrum




Scrum resiste el cambio en una iteración

• En Scrum el PO no puede tocar el tablero una vez que haya empezado una iteración

• En Kanban podemos introducir nuevos ítems siempre que se respete el WIP

8


El tablero de Scrum se borra después de cada iteración

9

© Henrik Kniberg, Kanban and Scrum




Scrum prescribe equipos multi-funcionales

10





Los ítems del backlog de Scrum deben encajar en un sprint

11

Scrum

Kanban





Scrum prescribe estimación y velocidad

12





Ambos permiten trabajar en varios productos simultaneamente

13

Scrum Kanban





Ambos son lean y ágiles

• Ambos utilizan un sistema de scheduling basado en pull• Ambos están basados en procesos de mejora continua• Ambos enfatizan la respuesta al cambio frente seguir un plan (aunque

Kanban permite respuestas más rápidas que Scrum)• Ambos se basan en iteraciones cortas en las que se integran los

cambios en el producto final

14


Resumen: similitudes

• Ambos son lean y ágiles

• Ambos implementan un sistema pull

• Ambos limitan el WIP

• Ambos usan la transparencia para dirigir la mejora del proceso

• Ambos se centran en entregar software que funciona pronto y con frecuencia

• Ambos se basan en equipos auto-organizados

• Ambos requieren partir el trabajo en trozos más pequeños

• En ambos el plan de release se optimiza continuamiente basándose en datos empíricos (velocidad / tiempo de ciclo)

15


Resumen: diferencias

Scrum Kanban

Timeboxed iterations prescribed Timeboxed iterations optional

Team commits to a specific amount of work for this iteration Commitment optional

Uses Velocity as default metric for planning and process improvement

Uses Lead time as default metric for planning and process improvement

Cross-functional teams prescribed Cross-functional teams optional. Specialist teams allowed.

Items must be broken down so they can be completed within 1 sprint No particular item size is prescribed.

16



Scrum Kanban

Burndown chart prescribed No particular type of diagram is prescribed

WIP limited indirectly (per sprint) WIP limited directly (per workflow state)

Estimation prescribed Estimation optional

Cannot add items to ongoing iteration

Can add new items whenever capacity is available

A sprint backlog is owned by one specific team

A kanban board may be shared by multiple teams or individuals

17



Scrum Kanban

Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles

A Scrum board is reset between each sprint A kanban board is persistent

Prescribes a prioritized product backlog Prioritization is optional.

18


Agile Product Ownership in a Nutshell

• Vídeo muy interesante que usa muchos conceptos de estas primeras clases

© Henrik Kniberg - Blog post y transcripción en inglés - YouTube

19

http://www.youtube.com/watch?v=502ILHjX9EE



http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell




Lecturas

• Henrik Kniberg, Kanban and Scrum, pp. 1-51

• Transcripción del vídeo de Henrik Kniberg Agile Product Ownership in a Nutshell

20



http://livepage.apple.com/




kanban vs. scrum · 2013-10-22 · scrum kanban burndown chart prescribed no particular type of...

Documents