KanbanVsScrum Caste Llano FINAL-Printed

8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed

1/123


2/123

ii

2010 C4Media Inc.Todos los derechos reservados

C4Media, editores de InfoQ.com.

Este libro es parte de la serie de libros Desarrollo Empresarial de Software de InfoQ.

Para informacin sobre cmo solicitar este u otros libros de InfoQ, por favorcontacte con [email protected].

Ninguna parte de esta publicacin puede ser reproducida, almacenada en un sistemade recuperacin o transmitida en ninguna forma o por ningn medio electrnico,mecnico, fotocopia, recodificacin, escaneo u otros medios, excepto en los casos

permitidos por las Secciones 107 o 108 del Acta de Copyright de los EstadosUnidos, sin la autorizacin previa por escrito del editor.

Las denominaciones usadas por las compaas para distinguir sus productos sonreconocidas habitualmente como marcas registradas. En todos los casos en los queC4Media Inc. tiene noticia de dicho reconocimiento, los nombres de los productosaparecen con las Iniciales En Maysculas o TODO EN MAYSCULAS. Loslectores, en cualquier caso, deben contactar con las compaas en cuestin para lainformacin completa sobre la marca registrada.

Editor Jefe: Diana Plesa

Diseo de Portada: Bistrian IosipComposicin: Accurance

Datos de catalogacin de la publicacin por la Librera del Congreso:ISBN: 978-0-557-13832-6Impreso en los Estados Unidos de Amrica

Traduccin al castellano: Equipo de contenidos de Agile Spain (www.agilespain.com)Rodrigo Corral Plain Concepts - http://www.plainconcepts.com/Xavier Quesada-Allue Agilar - http://www.agilar.org/Jorge Uriarte Gailen Tecnologas - http://www.gailen.esAgustn Yage UPM - https://syst.eui.upm.es/

Teo Snchez - http://teosanchez.blogspot.comJuan Palacio - http://www.navegapolis.net/Gregorio Mena - http://eclijava.blogspot.com/ngel Agueda - http://legnita.wordpress.comLaura Morillo-VelardeJorge JimnezJavier SnchezJuan Quijano

Coordinacin de la traduccin: ngel Medinilla - http://www.proyectalis.com


3/123

INTRODUCCIN | iii

iii

Contenido

33333333333333333333333333333333333333333333333333333333333 * 3333333333333333333333333333333333333333333333333333333333333 * 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333+333333333333333333333333333333333333333333333333333333333333333333333333339

9(!#%!2,!21$(&!%(,0 333333;:'!&21"!&%!,%('%&03333333> ;%(#%&%%!& 333333333333333333333333333333333333333333333333333333333399


4/123

iv

9>&(%(*& 333333333333333333333333333333333333333333333 =9 3333333333333333333333333333333333333333333333333333333333333333333==

9?'(%-&!#%!&'& 333333333333333333333333 =?9@1!%$(!&%03333333333333333333333333333333333333333333333333 =A9A1!%"#-!&0333333333333333333333333333333333333333333333333333 >9:8!%33333333333333333333333333333333333333333333333333333333333333 >;:9(&'%!&$(#!& 333333333333333333333333333333333333333 >=::%!!&!&*!(%!& 333333333333333333333333333333333333333333 >?:;!&'%(,!#%%'%! 3333333333333333333333333333333333333333333 >A:1('%&*%'%!033333333333333333333333333333333333333333333 ??:?1"!&'%0333333333333333333333333333333333333333333333333333333333333333333 ?A:@'!&1"!'%!&%'0333333333333333333333333 @9:A!'%!(!%#%$((!3333333333333 @=;81(%033333333333333333333333333333333333333333333333333333333333333333333333 @A;9"!#-%!%&!&& 3333333333333333333333333333333 A;;:!%&%& 333333333333333333333333333333333333333333 AA

333333333333333333333333333333333333333333333333333333333398; 33333333333333333333333333333333333333333333333333333333333333333333333333333398>


5/123


6/123


7/123

Prlogo por David AndersonKanban se basa en una idea muy simple: el trabajo en curso (Work InProgress, WIP) debera limitarse, y slo deberamos empezar con algonuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra funcin posterior de la cadena. El Kanban (o tarjeta

sealizadora) implica que se genera una seal visual para indicar quehay nuevos bloques de trabajo que pueden ser comenzados porque eltrabajo en curso actual no alcanza el mximo acordado. Esto no suenamuy revolucionario ni parece que vaya a afectar profundamente elrendimiento, cultura, capacidad y madurez del equipo y de laorganizacin que les rodea. Lo increble es que s lo hace! Kanbanparece un cambio muy pequeo pero aun as cambia todos los aspectosde una empresa.

Hemos llegado a la conclusin de que Kanban es una aproximacin a lagestin del cambio. No es un proceso de desarrollo de software o degestin de proyectos. Kanban es una aproximacin a la introduccin decambios en un ciclo de vida de desarrollo de software o metodologa degestin de proyectos. ya existente El principio de Kanban es quecomienzas con lo que sea que ests haciendo ahora mismo. Comprendestu actual proceso mediante la realizacin de un mapa del flujo de valor yentonces acuerdas los lmites de trabajo en curso (WIP) para cada fasedel proceso. A continuacin comienzas a hacer fluir el trabajo a travsdel sistema comenzndolo ("pull") cuando se van generando las seales

Kanban.

Kanban ha demostrado ser til en equipos que realizan desarrollo gilde software, pero tambin estn ganando fuerza en equipos que utilizanmtodos ms tradicionales. Kanban se est introduciendo como parte deiniciativas Lean para transformar la cultura de las organizaciones yfomentar la mejora continua.

Dado que el WIP est limitado en un sistema Kanban, cualquier

elemento que se bloquea por cualquier razn tiende a atascar el sistema.Si un nmero suficiente de elementos se bloquean todo el proceso se


8/123

viii

para en seco. Esto tiene el efecto de que todo el equipo y la organizacinse concentran en resolver el problema, desbloqueando estos elementospara permitir la restauracin del flujo productivo.

Kanban usa un mecanismo de control visual para hacer seguimiento deltrabajo conforme este viaja a travs del flujo de valor. Tpicamente, seusa un panel o pizarra con notas adhesivas o un panel electrnico detarjetas. Las mejores prcticas apuntan probablemente al uso de ambos.La transparencia que esto genera contribuye tambin al cambio cultural.Las metodologas giles han obtenido buenos resultadosproporcionando transparencia respecto al trabajo en curso y completado,as como en el reporte de mtricas como la velocidad (cantidad detrabajo realizada en una iteracin). Kanban sin embargo va un paso msall y proporciona transparencia al proceso y su flujo. Kanban expone

los cuellos de botella, colas, variabilidad y desperdicios. Todas las cosasque impactan al rendimiento de la organizacin en trminos de lacantidad de trabajo entregado y el ciclo de tiempo requerido paraentregarlo. Kanban proporciona a los miembros del equipo y a las partesinteresadas visibilidad sobre los efectos de sus acciones (o falta deaccin). De esta forma, los casos de estudios preliminares estndemostrando que Kanban cambia el comportamiento y motiva a unamayor colaboracin en el trabajo. La visibilidad de los cuellos debotella, desperdicios y variabilidades y su impacto tambin promueve la

discusin sobre la posibles mejoras, y los equipos comienzanrpidamente a implementar mejoras en su proceso.

Como resultado, Kanban propicia la evolucin incremental de losprocesos existentes, una evolucin que generalmente est alineada conlos valores del Agilismo y de Lean. Kanban no pide una revolucinradical de la forma en la que las personas trabajan, sino que sugiere uncambio gradual. Es un cambio que surge del entendimiento y elconsenso entre todos los trabajadores y sus colaboradores.

Kanban, por su naturaleza de Sistema Pull ("arrastre", "tirar"; laproduccin se realiza cuando el cliente retira un elemento terminado),tambin propicia diferir el compromiso tanto en la priorizacin deltrabajo nuevo como en la entrega del trabajo existente. Tpicamente, losequipos llegarn a un acuerdo sobre la cadencia de reuniones depriorizacin con el bloque funcional que les precede en el proceso paradecidir en qu deben trabajar a continuacin. Estas reuniones se puedenmantener de forma frecuente porque habitualmente son bastante cortas.Se responde a una pregunta simple, algo como "Desde nuestra ltima

reunin hemos liberado dos huecos de trabajo, y nuestro tiempo de cicloactual es de 6 semanas para entregar. Qu dos cosas son las que ms os


9/123

INTRODUCCIN | ix

ix

gustara ver entregadas dentro de 6 semanas?". Esto tiene un efectodoble. Formular una pregunta simple generalmente proporcionarespuestas rpidas y de buena calidad, y mantiene las reuniones cortas.La naturaleza de la pregunta muestra que el compromiso acerca de en

qu trabajar se difiere hasta el ltimo momento responsable. Esto mejorala Agilidad mediante una gestin de las expectativas, un acortamiento delos tiempos de ciclo desde el compromiso hasta la entrega y eliminandolos re-trabajos, ya que las probabilidades de un cambio en lasprioridades se minimizan.

Un ltimo comentario sobre Kanban es que el efecto de limitar el WIP proporciona predecibilidad sobre el tiempo de ciclo y hace que losentregables sean ms fiables. La estrategia de "parar el proceso" ante

impedimentos y bugs tambin parece promover altos niveles de calidady un rpido descenso del re-trabajo.

Aunque todo esto se volver evidente con las increblemente clarasexplicaciones de este libro, no ocurre lo mismo con la explicacin decmo hemos llegado hasta aqu. Kanban no se concibi en una solatarde mediante una increble epifana. Surgi a lo largo de muchos aos.Muchos de sus profundos aspectos psicolgicos y sociolgicos quecambian la cultura, capacidad y madurez de las organizaciones nuncafueron imaginados en un principio. Fueron ms bien descubiertos.Muchos de los resultados de Kanban son contra-intuitivos. Lo queparece ser una aproximacin muy mecnica - limitar el WIP y retirar eltrabajo - tiene en realidad profundos efectos en las personas y en comointeractan y colaboran unas con otras. Ni yo, ni ninguno de los queestuvieron involucrado en los inicios de Kanban, previmos esto.

Implement lo que luego se convirti en Kanban como una estrategiapara la gestin del cambio que encontrase una resistencia mnima. Tenaesto claro ya en el 2003. Tambin lo implement por los beneficios

mecnicos. Como ya estaba descubriendo en aquellos das mediante laaplicacin de tcnicas Lean, si gestionar el WIP tena sentido, entonceslimitarlo tena ms sentido aun, ya que eliminaba el coste de gestinasociado. As que en 2004 decid intentar implementar un sistema pulldesde sus principios bsicos. Tuve la oportunidad cuando un Gerente deMicrosoft contact conmigo y me pidi que le ayudase a gestionar encambio en su equipo de mantenimiento evolutivo de aplicaciones TIinternas. La primera implementacin estaba basada en el Sistema Pull deTeora de las Limitaciones conocido como Drum-Buffer-Rope (tambor-

inventario-cuerda). Fue un gran xito: el tiempo de ciclo bajo un 92%, elcaudal de salida (troughput) se increment en ms del triple y la


10/123

x

predecibilidad (cumplimiento de fechas) fue de un muy aceptable 98%.En 2005, Donald Reinertsen me convenci de implementar un sistematotalmente Kanban. Tuve la oportunidad en 2006, cuando asum ladireccin del Departamento de Ingeniera de Corbis en Seattle. En 2007comenc a reportar los resultados. La primera presentacin fue en elLean New Product Development Summit de Mayo de 2007 en Chicago.Continu con un Open Space en Agile 2007 en Washington DC enAgosto de ese ao. 25 personas asistieron. 3 de ellas eras de Yahoo! :Aaron Sanders, Jarl Scotland y Joe Arnold. Volvieron a sus hogares deCalifornia, India y el Reino Unido e implementaron Kanban con susequipos, que ya estaban luchando con Scrum. Tambin crearon un grupode discusin de Yahoo! que, en el momento de escribir estas lneas,cuenta con casi 800 miembros. Kanban estaba comenzando adiseminarse y los "early adopters" empezaban a hablar de sus

experiencias.

Ahora en 2009, la adopcin de Kanban est creciendo realmente y ms yms informes de campo estn apareciendo. Hemos aprendido mucho deKanban en los ltimos 5 aos y seguimos aprendiendo todos los das. Heconcentrado mi propio trabajo en hacer Kanban, escribir sobre Kanban,hablar sobre Kanban y pensar sobre Kanban para as poder entenderlomejor y explicrselo a otros. Me he abstenido deliberadamente decompararlo con otros mtodos giles existentes, aunque en 2008

invertimos algo de esfuerzo en explicar por qu Kanban deba serconsiderada como una aproximacin gil compatible.

He dejado a otros con mayor experiencia contestar preguntas como "Enqu se diferencian Kanban y Scrum?". Me alegra que Henrik Kniberg yMattias Skarin hayan surgido como lderes en este aspecto. Usted, eltrabajador del conocimiento en el da a da, necesita informacin para poder tomar decisiones ms informadas y poder progresar con sutrabajo. Henrik y Mattias estn solucionando sus necesidades de unaforma que yo nunca pude. Estoy particularmente impresionado con lasesuda comparacin de Henrik y su presentacin equilibrada, imparcialy basada en los hechos. Sus dibujos e ilustraciones son particularmenteperspicaces y muchas veces te ahorran tener que leer muchas pginas detexto. El informe de campo de Mattias es importante, ya que demuestraque Kanban es mucho ms que una teora y nos muestra mediante elejemplo cmo podra ser til para usted en su organizacin.

Espero que disfruten este texto de comparacin entre Kanban y Scrum yque les aporte una mayor visin de Agile en general y de Kanban y

Scrum en particular. Si desea aprender ms sobre Kanban, por favor,


11/123

INTRODUCCIN | xi

xi

visite el sitio Web de nuestra comunidad, la Limited WIP Society,http://www.limitedwipsociety.org/

David J. Anderson

Sequim, Washington, USA. 8 de Julio de 2009


12/123


13/123

IntroduccinNormalmente no escribimos libros. Preferimos pasar el tiempo metidosa fondo en las trincheras ayudando a los clientes a optimizar, corregir yrefactorizar su proceso de desarrollo y su organizacin. No obstante,hemos notado una clara tendencia ltimamente, y nos gustara compartir

algunas reflexiones sobre ella. Este sera un caso tpico: Jim: Por fin hemos conseguido implantar Scrum del

todo!

Fred: Y qu tal os va

Jim: Bueno, mucho mejor que lo que tenamosantes...

Fred: ...pero? Jim: ... pero claro, est el equipo de operacin y

mantenimiento.

Fred: s, Y?

Jim: Bueno, nos encanta todo lo de organizar por prioridades en una Pila de Producto, los equipos auto-organizados, el Scrum diario, las retrospectivas, etc....

Fred: Y cul es el problema?

Jim: Seguimos fracasando en nuestros Sprints

Fred: Por qu?

Jim: Porque nos resulta muy difcil comprometernos auna planificacin de 2 semanas. Las iteraciones no tienenmucho sentido para nosotros, simplemente nos ponemos

con lo ms urgente que tenemos cada da. Quizsdeberamos hacer iteraciones de una semana?


14/123

xiv

Fred: Os podrais comprometer al trabajo de unasemana? Se os permitira concentraros en eso y trabajar enpaz durante una semana?

Jim: En realidad no, tenemos asuntos que van

surgiendo en el da a da. Quizs si hiciramos sprints de unda

Fred: Vuestras tareas tardan menos de un da ensolucionarse?

Jim: No, a veces tardan varios das

Fred: As que los sprints de 1 da tampoco funcionaran. Habis considerado eliminar por completo los sprints?

Jim: Bueno, la verdad es que eso nos gustara. Perono va eso en contra de Scrum?

Fred: Scrum es solo una herramienta. T eliges cundoy cmo usarla. No seas su esclavo!

Jim: Qu deberamos hacer entonces?

Fred: Has odo hablar de Kanban?

Jim: Qu es eso? En qu se diferencia de Scrum?

Fred: Toma, lee este libro!

Jim: Pero a mi me gusta el resto de Scrum, tengo quecambiar ahora?

Fred: No! Puedes combinar ambas tcnicas

Jim: Qu? Cmo?

Fred: Slo sigue leyendo..


15/123

INTRODUCCIN | xv

xv

Si ests interesado en el desarrollo de software gil probablementehabrs odo hablar de Scrum, y puede que tambin hayas odo hablar deKanban. Una pregunta que cada vez nos hacen con ms frecuencia esY qu es Kanban, y en qu se diferencia de Scrum? Dnde secomplementan? Hay conflictos potenciales?

El propsito de este libro es aclarar la niebla, de forma que puedas

entender como Kanban y Scrum pueden ser tiles en tu entorno.

Haznos saber si lo hemos conseguido!


16/123


17/123

1

Parte I ComparacinEsta primer parte del libro es un intento de realizar una comparacin

prctica y objetiva de Scrum y Kanban. Es una versin algo actualizada

del artculo Kanban vs. Scrum de Abril de 2009. Este artculo se hizo

muy popular, as que decid convertirlo en un libro y le ped a mi colega

Mattias que lo aliase con un caso de estudio desde las trincheras de

uno de nuestros clientes. Cosa fina! Sintete libre de saltar

directamente a la Parte II si prefieres comenzar con el caso de estudio,

no me ofender. Bueno, quizs solo un poco.

/Henrik Kniberg


18/123


19/123

3

1Bueno pero, al fin y al cabo, qu sonScrum y Kanban?De acuerdo, tratemos de resumir Scrum y Kanban en menos de 100palabras cada uno.

Scrum en pocas palabras

Divide tu organizacin en equipos pequeos, interdisciplinarios yauto-organizados.

Divide el trabajo en una lista de entregables pequeos yconcretos. Ordena la lista por orden de prioridad y estima elesfuerzo relativo de cada elemento.


20/123

4 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS

4

Divide el tiempo en iteraciones cortas de longitud fija(generalmente de 1 a 4 semanas), con cdigo potencialmenteentregable y demostrado despus de cada iteracin.

Optimiza el plan de entregas y actualiza las prioridades encolaboracin con el cliente, basada en los conocimientosadquiridos mediante la inspeccin del entregable despus decada iteracin.

Optimiza el proceso teniendo una retrospectiva despus decada iteracin.

As en lugar de un grupo numeroso pasando mucho tiempoconstruyendo algo grande, tenemos un equipo menor pasando untiempo ms corto construyendo algo menor. Pero integrando conregularidad para ver el conjunto.

138 palabras ... bastante cerca.

Para ms detalles, consulte "Scrum y XP desde las trincheras". El libroes de lectura gratuita online. Conozco al autor, es un buen tipo: o)

http://www.crisp.se/ScrumAndXpFromTheTrenches.html

Para obtener ms enlaces sobre Scrum echa un vistazo ahttp://www.crisp.se/scrum


21/123

BUENO PERO, AL FIN Y AL CABO QU SON SCRUM Y KANBAN? | 5

5

Kanban en pocas palabras

Visualiza el flujo de trabajo

o Divide el trabajo en bloques, escribe cadaelemento en una tarjeta y ponlo en el muro.

o Utiliza columnas con nombre para ilustrar dndeest cada elemento en el flujo de trabajo.

Limita el WIP (Work in Progress, trabajo en curso) -

asigna lmites concretos a cuntos elementos pueden estar enprogreso en cada estado del flujo de trabajo.

Mide el lead time (tiempo medio para completar unelemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time sea tan pequeo y predeciblecomo sea posible.

Se han agrupado enlaces tiles sobre Kanban en:

http://www.crisp.se/kanban


22/123

6

2Entonces, Cmo se relacionan Kanbany Scrum entre s?Scrum y Kanban son ambos herramientas de

proceso

Herramienta = cualquier cosa usada como medio para realizar una tareao propsito

Proceso = cmo trabajas.

Scrum y Kanban son herramientas de proceso que te ayudan a trabajarms eficazmente, en cierta medida, dicindote qu hacer. Java tambin

es una herramienta, te ofrece una forma ms sencilla de programar unacomputadora. Un cepillo de dientes tambin es una herramienta, teayuda a llegar a tus dientes para que puedas limpiarlos.

Compara herramientas para entender,no para juzgar

Cuchillo o tenedor - Qu herramienta es mejor?

Es una pregunta bien expresada? Porque la respuesta depende del contexto.

Para comer albndigas el tenedor es probablemente mejor. Para cortar las


23/123

ENTONCES CMO SE RELACIONAN SCRUM Y KANBAN ENTRE S? | 7

7

setas el cuchillo es probablemente mejor. Para golpear la mesa cualquiera

de los dos servir. Para comer un filete probablemente querrs utilizar los

dos de manera conjunta. Para comer arroz... Bueno... algunos prefieren el

tenedor mientras que otros prefieren los palillos.

As, cuando comparamos herramientas debemos ser cuidadosos. Comparar

para comprender, no para juzgar..

Ninguna herramienta es completa, ningunaherramienta es perfecta

Como cualquier herramienta, Scrum y Kanban no son ni perfectas nicompletas. No te dicen todo lo que tienes que hacer, solo proporcionanciertas restricciones y directrices. Por ejemplo, Scrum te obliga a tener

iteraciones de duracin fija y equipos interdisciplinarios, y Kanban teobliga a usar tableros visibles y a limitar el tamao de tus colas.

Curiosamente, el valor de una herramienta es que limita tus opciones. Una

herramienta de proceso que te permite hacer cualquier cosa no es muy til.

Podramos llamar a ese proceso "Hacer lo que sea" o qu tal "Hacer lo

correcto". El proceso "Hacer lo correcto" garantiza que funciona, es una

bala de plata! Porque si no funciona, es obvio que no estabas siguiendo el

proceso :o)

Usar las herramientas adecuadas te ayudar a triunfar, pero no garantizar el

xito. Es fcil confundir el xito/fracaso del proyecto, con el xito / fracaso

de la herramienta.

Un proyecto puede triunfar debido a una gran herramienta.

Un proyecto puede triunfar a pesar de una psima herramienta.

Un proyecto puede fallar debido a una psima herramienta.


24/123


8

Un proyecto puede fallar a pesar de una gran herramienta.

Scrum es ms prescriptivo que KanbanPodemos comparar herramientas viendo cuntas reglas proporcionan.Prescriptivo significa "ms reglas a seguir" y adaptativo significa"menos reglas a seguir". 100% prescriptivo significa que no te deja usarel cerebro, hay una regla para todo. 100% adaptativos significan Haz LoQue Sea, no hay ninguna regla o restriccin. Como puedes ver, los dosextremos de la escala son de alguna manera ridculos.

Los mtodos giles se denominan a veces los mtodos ligeros, enconcreto, porque son menos restrictivos que los mtodos tradicionales.De hecho, el primer principio del Manifiesto gil es "Individuos einteracciones sobre procesos y herramientas".

Scrum y Kanban son muy adaptables, pero en trminos relativos Scrumes ms restrictivo que Kanban. Scrum te da ms limitaciones, y as dejamenos opciones abiertas. Por ejemplo Scrum prescribe el uso deiteraciones de duracin fija, Kanban no.

Vamos a comparar algunas herramientas de proceso ms en la escalarestrictivo vs adaptativo:


25/123


9

RUP es muy restrictivo- tiene ms de 30 perfiles, ms de 20 actividades,y ms de 70 artefactos, una cantidad enorme de cosas a aprender.Realmente no se espera que uses todos los que hay, si bien, se suponeque seleccionars un subconjunto adecuado para tu proyecto.

Lamentablemente, esto parece ser difcil en la prctica. "Hmmmm ...Necesitaremos artefactos para la Configuracin de auditora de losresultados?Necesitaremos un perfilde gerente de Control de cambios?No estoy seguro, as que mejor los mantenemos por si acaso ". Estopuede ser una de las razones por lasque las implementaciones de RUPsuelen ser bastante pesadas en comparacin con los mtodos gilescomo Scrum y XP.

XP (eXtreme Programming) es ms restrictivo en comparacin conScrum. Se incluye la mayora de Scrum + un montn de buenas prcticas especficas de ingeniera, tales como desarrollo dirigido porpruebas y la programacin en parejas.

Scrum es menos restrictivo que XP, ya que no establece ningunaprctica especfica de ingeniera. Sin embrago, Scrum es ms restrictivo

que Kanban ya que prescribe cosas como iteraciones y equiposinterdisciplinarios.

Una de las principales diferencias entre Scrum y RUP es que en RUPtienes demasiado, y se supone que quitars aquello que no necesites. EnScrum tienes demasiado poco, y se supone que aadirs el material quefalta.

Kanban deja casi todo abierto. Las nicas normas son Visualiza tu Flujode trabajo y Limita tu WIP (Work In Progress, Trabajo en curso). A pocos centmetros de Haz lo que Sea, pero sigue siendosorprendentemente poderoso.


26/123


10

No te limites a una nica herramienta!Mezcla y combina las herramientas que necesites! Me cuesta imaginar un

exitoso equipo Scrum que no incluye la mayora de los elementos de XP,

por ejemplo. Muchos equipos Kanban hacen reuniones diarias (una prctica

de Scrum). Algunos equipos Scrum escriben algunos de sus elementos de la

pila como Casos de Uso (una prctica de RUP) o limitan el tamao de las

colas (una prctica de Kanban). Usa lo que sea que funcione para ti.

Musashi lo dijo muy bien (famoso Samurai del siglo 17, famoso por sutcnica de lucha de la doble espada)

Sin embargo, presta atencin a las limitaciones de cada herramienta. Porejemplo, si utilizas Scrum y decides dejar de utilizar iteraciones de duracin

fija (o cualquier otro aspecto central de Scrum), luego no digas que estsutilizando Scrum. Scrum es bastante minimalista en s mismo, si quitascosas y todava lo llamas Scrum entonces la palabra carecer de sentido yconfundir. Llmalo algo as como "inspirado en Scrum" o "un subconjuntode Scrum", o algo as como "Scrumish" :o)

- Miyamoto Musashi

No te cias a una nica arma o auna nica escuela de lucha.


27/123


11

3Scrum prescribe rolesScrum prescribe 3 roles: dueo de producto (establece la visin delproducto y las prioridades), equipo (implementa el producto) y ScrumMaster (elimina los impedimentos y proporciona liderazgo en el

proceso).

Kanban no establece ningn rol en absoluto.

Eso no significa que no puedas o no debas tener un papel de dueo deproducto en Kanban! Slo significa que no tienes que. En ambos, Scrumy Kanban, eres libre de aadir los roles adicionales que necesites.

Ten cuidado sin embargo al aadir roles, asegrate de que los roles

adicionales realmente aaden valor y no entran en conflicto con otroselementos del proceso. Ests seguro de que necesitas el rol de jefe deproyectos? En un proyecto grande puede ser una gran idea, tal vez es eltipo que ayuda a mltiples equipos y dueos de producto asincronizarse. En un proyecto pequeo puede ser un desperdicio, o peor,puede dar lugar a la sub-optimizacin y la microgestin.

La mentalidad general, tanto en Scrum como en Kanban es "menos esms". As que en caso de duda, comienza con menos.

En el resto del artculo voy a utilizar el trmino "dueo de producto" para representar a quien establece las prioridades de un equipo,independientemente del mtodo utilizado.


28/123


29/123

13

4Scrum prescribe iteraciones de tiempofijoScrum se basa en iteraciones de tiempo fijo. Puedes elegir la duracin dela iteracin, pero la idea general es mantener la misma longitud dela iteracin durante un perodo de tiempo, determinando as una

cadencia.

Inicio de la iteracin: Se crea un plan de iteracin, es decir, elequipo saca un nmero especfico de elementos de la pila deproducto, en base a las prioridades del dueo de producto y a cuntopiensa el equipo que puede terminar en una iteracin.

Durante la iteracin: El equipo se centra en completar loselementos a los que se comprometi. Se fija el alcance de laiteracin.

Final de la iteracin: El equipo muestra el cdigo funcionando alas partes interesadas, idealmente este cdigo debe ser potencialmente entregable (es decir, probado y listo para llevar).Entonces, el equipo hace una retrospectiva para discutir y mejorarsu proceso.

As que una iteracin de Scrum es una nica cadencia de tiempo fijo quecombina tres actividades distintas: la planificacin, la mejora deprocesos, y (idealmente) la entrega.

En Kanban no se prescriben iteraciones de tiempo fijo. Puedes elegir elmomento de hacer la planificacin, la mejora de procesos, y la entrega.Puedes elegir hacer estas actividades de manera regular ( "la entregatodos los lunes") o bajo demanda ( "la entrega cada vez que tengamosalgo til para entregar").


30/123


14

Equipo #1 (cadencia simple)

"Nosotros hacemos iteraciones Scrum"

Equipo # 2 (tres cadencias)

"Tenemos tres cadencias diferentes. Cada semana entregamos lo que

est listo para su entrega. Cada segunda semana tenemos una reunin de planificacin, actualizacin de nuestras prioridades y los planes deentrega. Cada cuarta semana tenemos una reunin retrospectiva paramodificar y mejorar nuestro proceso".

Equipo # 3 (normalmente dirigido por eventos)

"Lanzamos una reunin de planificacin cada vez que comenzamos aquedarnos sin cosas que hacer. Lanzamos una entrega siempre que hayun MMF (Minimum Marketable Feature Set, conjunto mnimo de

caractersticas comercializables) listo para entregar. Lanzamos uncrculo de calidad espontneo siempre que nos topamos con un mismoproblema por segunda vez. Adems hacemos una retrospectiva ms enprofundidad cada cuatro semanas. "


31/123

15

5Kanban limita el WIP por estado en flujode trabajo, Scrum limita el WIP poriteracinEn Scrum, la pila de sprint muestra qu tareas han de ser ejecutadasdurante la iteracin actual (= "sprint" en terminologa Scrum). Serepresenta comnmente usando tarjetas en la pared, llamada una pizarrade Scrum o pizarra de tareas.

Entonces, cul es la diferencia entre una pizarra de Scrum y una pizarrade Kanban? Vamos a empezar con un proyecto simple y comparar lasdos:

En ambos casos estamos siguiendo un grupo de elementos a medida queavanzan a travs de un flujo de trabajo. Hemos seleccionado tresestados: pendiente, en curso, y terminado. Puedes elegir los estados quequieras - algunos equipos aaden estados tales como integrar, probar,liberar, etc. No te olvides del principio de "menos es ms".

Entonces, cul es la diferencia entre estas dos pizarras de ejemplo? S,el pequeo 2 en la columna central en la pizarra Kanban. Eso es todo.Ese 2 significa que "no puede haber ms de 2 elementos en esta columnaen un momento dado".


32/123


16

En Scrum no hay ninguna regla que impida que el equipo ponga todoslos elementos en la columna en curso al mismo tiempo! Sin embargo,existe un lmite implcito ya que la iteracin en s tiene un alcance fijo.En este caso, el lmite implcito por columna es de 4, ya que slo hay 4

elementos en la pizarra. As que Scrum limita el WIP indirectamente,mientras que Kanban limita el WIP directamente.

La mayora de los equipos de Scrum aprenden finalmente que es unamala idea tener demasiados elementos en curso, y desarrollan unacultura de intentar tener los elementos actuales terminados antes decomenzar con nuevos elementos. Algunos incluso deciden limitarexplcitamente el nmero de elementos permitidos en la columna de encurso y, a continuacin - TADAAA! - la pizarra de Scrum se ha

convertido en una pizarra de Kanban!As que tanto Scrum como Kanban limitan el WIP, pero de diferentesmaneras. Los equipos de Scrum suelen medir la velocidad - cuntoselementos (o unidades correspondientes, tales como "puntos dehistoria") se hacen por iteracin. Una vez que el equipo sabe suvelocidad, sta se convierte en su lmite de WIP (o al menos unadirectriz). Un equipo que tiene una velocidad media de 10 no sueletomar ms de 10 elementos (o puntos de historia) para un sprint.

De forma que en Scrum el WIP se limita por unidad de tiempo.

En Kanban el WIP se limita por el estado del flujo de trabajo.

En el ejemplo anterior de Kanban, como mucho puede haber 2elementos en el estado de flujo de trabajo "en curso" en un momentodado, independientemente de las longitudes de cadencia. Tienes queelegir qu lmite aplicar a qu estados del flujo de trabajo. Pero la ideageneral es limitar el WIP de todos los estados del flujo de trabajo,

empezando por "lo ms pronto posible" y terminando "lo ms tarde posible" a lo largo de la cadena de valor. As, en el ejemplo anteriordeberamos considerar aadir un lmite al WIP tambin en el estado"pendiente" (o la que quiera que sea tu cola de entrada). Una vez quetenemos los lmites de WIP en su lugar, podemos empezar a medir ypredecir el tiempo de entrega, es decir, el tiempo medio de un elemento para realizar todo el camino a travs de la pizarra. Tener tiempos deentrega predecibles nos permite comprometer los SLA (acuerdos denivel de servicio, en ingls service-level agreements) y hacer planes de

entrega realistas.


33/123

KANBAN LIMITA WIP POR ESTADO, SCRUM LIMITA WIP POR ITERACIN | 17

17

Si los tamaos de los elementos varan drsticamente entonces podrasconsiderar lmites de WIP definidos en trminos de puntos de historia ensu lugar, o cualquiera que sea la unidad de medida que utilices. Algunosequipos invierten sus esfuerzos en la descomposicin de elementos de

aproximadamente el mismo tamao para evitar este tipo deconsideraciones y reducir el tiempo empleado en la estimacin de lascosas (podras incluso considerar que la estimacin es un desperdicio detiempo). Es ms fcil para crear un buen sistema de flujo si los artculosson ms o menos de igual tamao.


34/123

18

6Ambos son empricosImagina que hubiese mandos en estos contadores y t pudiesesconfigurar tu proceso simplemente girando los mandos. Quiero altacapacidad, bajo lead time, alta calidad y alta predecibilidad. Entoncesgirar los mandos a 10, 1, 10 y 10 respectivamente.

No sera maravilloso? Por desgracia no existen estos controles directos.Al menos no que yo sepa. Hacdmelo saber si vosotros los encontris.

En su lugar contamos con ese puado de controles indirectos.

Scrum y Kanban son ambos empricos en el sentido de que se esperaque experimentes con el proceso y lo adaptes a tu entorno. De hecho,tienes que experimentar. Ni Scrum ni Kanban proporcionan todas lasrespuestas simplemente nos proporcionan una serie de reglas ylimitaciones a la hora de guiar la mejora de nuestros procesos.


35/123

AMBOS SON EMPRICOS | 19

19

Scrum dice que debemos tener equipos multidisciplinares.Entonces, Quin debe estar en cada equipo? No lo s,experimenta.

Scrum dice que el equipo selecciona cuanto trabajo incluir en

un sprint. Entonces, Cunto deben incluir? No lo s,experimenta. Kanban dice que debemos limitar en trabajo en curso. Entonces,

Cul debe ser ese lmite? No lo s, experimenta.

Como he mencionado con anterioridad, Kanban impone menoslimitaciones que Scrum. Esto significa menos parmetros sobre los que preocuparse, pero ms mandos que girar. Esto puede ser tanto unaventaja como una desventaja dependiendo del contexto. Cuando abres el

cuadro de dilogo de configuracin de una herramienta de software,prefieres tener 3 o 100 opciones que ajustar? Probablemente unacantidad entre ambas. Depende de cunto necesites ajustar el software atus necesidades y cmo de bien conozcas la herramienta.

Digamos que reducimos el lmite de trabajo en curso, basndonos en lahiptesis de que esto va a mejorar nuestro proceso. Observamos cmootros factores como la capacidad, el lead time, la calidad, y la predecibilidad evolucionan. Sacamos conclusiones de los resultados yajustamos algunas cosas ms, mejorando continuamente nuestroproceso.Hay diferentes trminos para referirse a este proceso. Kaizen (mejoracontinua en terminologa Lean), Inspeccin y Adaptacin (enterminologa Scrum), control emprico de procesos o, por qu no, ElMtodo Cientfico.

El elemento ms crtico de este proceso es el ciclo de retroalimentacin,el feedback. Cambia algo => Observa cmo funciona => Aprende deello => Cambia algo de nuevo. En general, lo que buscamos es obtener

feedback en ciclos lo ms cortos posibles, de manera que podamosadaptar nuestro proceso rpidamente.

En Scrum el ciclo bsico de obtencin defeedbackes el sprint. Existenotros, sin embargo. Especialmente si combinas Scrum con XP (eXtremeprogramming):


36/123


20

Cuando se realizan correctamente, Scrum + XP nos proporcionan unbuen puado de ciclos defeedbackextremadamente valiosos.

El ciclo de feedback ms interno, la programacin en parejas,proporciona retroalimentacin en unos pocos segundos. Los errores sondetectados y corregidos en segundos desde que ocurren (He!, no sesupone que esa variable debe valer 3?). Este es el ciclo defeedbackdeEstamos construyendo bien las cosas?.

El ciclo defeedbackms externo, el sprint, nos proporciona un ciclo deretroalimentacin de unas cuantas semanas. Este el ciclo defeedbackdeEstamos construyendo las cosas adecuadas?

Y en Kanban, que? Bueno, en primer lugar, puedes (y seguramentedebes) poner todos los anteriores ciclos de feedback en tus proyectosuses o no Kanban. Lo que Kanban te proporciona es una serie demtricas en tiempo real muy tiles.

Lead time medio: Actualizado cada vez que un elementoalcanza el nivel de hecho (o como quiera que llames a tucolumna ms a la derecha).

Cuellos de Botella: Un sntoma tpico es que la columna X estabarrotada de elementos mientras que la columna X+1 estvaca. Busca burbujas de aire en tu panel.

Lo mejor de las mtricas en tiempo real es que t puedes elegir lalongitud de tu ciclo de feedback, basndote en con qu frecuenciaquieres analizar estas mtricas e introducir cambios. Un ciclo demasiadolargo de retroalimentacin significa que la mejora de tu proceso serlenta. Uno demasiado corto significa que tu proceso no podra no tenertiempo para estabilizarse entre cambios, lo que puede producir

desperdicio de esfuerzos.


37/123


21

De hecho, la longitud del ciclo de retroalimentacin en s misma es unode los aspectos con los que puedes experimentar en una especie demeta-ciclo delfeedback. OK, es suficiente por ahora.

Ejemplo: Experimentando con los lmites para eltrabajo en curso en Kanban

Uno de los tpicos puntos de ajuste de Kanban es el lmite de trabajoen curso. Cmo sabemos si lo estamos estableciendo correctamente?

Digamos que tenemos un equipo de 4 personas y que decidimoscomenzar con un lmite para el trabajo en curso de 1.

En cuanto comencemos a trabajar en un elemento, no podremoscomenzar ninguno nuevo hasta que el primer elemento est Hecho. Enconsecuencia concluiremos el primer elemento rpidamente.

Excelente!, pero resulta que habitualmente no es factible que 4personas trabajen en el mismo elemento (al menos en el contexto de este

ejemplo), entonces tenemos gente mirando. Si esto solo ocurre de tantoen cuanto no ser un problema, pero si esta situacin se da conregularidad, la consecuencia es que el lead time medio se incrementar.Bsicamente, un trabajo en curso de 1 significa que los elementospasaran por el estado En curso realmente rpido una vez llegan a estasituacin, pero permanecern en estado Pendiente ms tiempo delnecesario, de manera que el lead time a lo largo del ciclo de trabajocompleto ser innecesariamente alto.

Entonces si un trabajo en curso de 1 es demasiado bajo, por qu noincrementarlo a 8?


38/123


22

Esto funciona mejor durante algn tiempo. Hemos descubierto que, de

media, trabajando en parejas realizamos el trabajo ms rpido. De estamanera, en un equipo de cuatro personas, habitualmente, tendremos 2elementos en curso en un instante dado. El trabajo en curso de 8 es soloun lmite superior, luego tener menos elementos en progreso es correcto!

Imaginemos ahora, sin embargo que encontramos un problema con elservidor de integracin, de tal manera que no podemos completartotalmente ningn elemento (nuestra definicin de Hecho incluyeintegracin). Estas cosas pasan, no?

Como no podemos completar los elementos D o E, comenzamos atrabajar en el elemento F. No podemos integrar ninguno de estostampoco, luego cogeremos un nuevo elemento G. Tras un tiempo

alcanzaremos nuestro lmite Kanban 8 elementos En curso.


39/123


23

En este punto, ya no podemos coger ningn elemento ms. He, mejor

arreglemos ese maldito servidor de integracin! El lmite para el trabajoen curso nos impulsa a reaccionar y corregir el cuello de botella en lugarde seguir acumulando un montn de trabajo sin terminar.

Esto est bien. Pero si el lmite de trabajo en curso hubiese sido 4,habramos reaccionado mucho antes, de este modo tendramos un mejorlead time medio. Medimos nuestro lead time medio y continuamenteoptimizamos nuestro lmite de trabajo en curso para optimizar el leadtime.

Tras un periodo de tiempo podramos encontrar que los elementos seacumulan en la columna Pendiente. Quizs es el momento de aadirun lmite de trabajo en curso aqu tambin.

En cualquier caso, por qu necesitamos una columna Pendiente?.Bueno, si el cliente estuviese siempre disponible para decir al equipo

que hacer cada vez que preguntase, la columna Pendiente, no seranecesaria. Pero en el caso de que el cliente est a veces no disponible, la


40/123


24

columna Pendiente da al equipo un pequeo buffer del que cogertrabajo a medio plazo.

Experimenta o, como los Scrumistas dicen, Inspeccin y Adaptacin.


41/123


42/123


26

La respuesta de Kanban podra decir Aade con libertad E a la columnaPendiente pero hay un lmite de 2 para esta columna, en consecuenciatendrs que quitar C o D. Ahora estamos trabajando en A y B, pero tan pronto como tengamos capacidad disponible cogeremos el primer

elemento de la columna Pendiente.

El tiempo de respuesta (cunto tiempo pasa hasta que respondemos acambios de prioridades) de un equipo Kanban es tan largo como eltiempo que trascurre hasta que tenemos capacidad disponible, siguiendoel principio general de un elemento sale = un elemento entra (segnlos lmites para el trabajo en curso).

En Scrum, el tiempo de respuesta medio es la mitad de la duracin del

Sprint.En Scrum, el dueo del producto no puede tocar el tablero Scrum unavez el equipo se ha comprometido a completar un conjunto de elementosen la iteracin. En Kanban t tienes que establecer tu propias reglassobre quin puede cambiar qu en el tablero. Tpicamente el dueo del producto controla una columna del tipo Pendiente, Listo,Propuesto, Pila de Producto en la parte ms a la izquierda en elpanel, en la que l puede hacer todos los cambios que desee.

Sin embargo, estas dos aproximaciones no son excluyentes entre s. Unequipo Scrum podra decidir permitir al dueo del producto cambiarprioridades a mitad de sprint. Y un equipo Kanbanpodra decidir aadirrestricciones sobre cuando las prioridades pueden ser cambiadas. Unequipo Kanban puede incluso decidir utilizar iteraciones limitadas en eltiempo y con compromisos prefijados, exactamente igual que Scrum.


43/123

27

8El tablero sprint se limpia entreiteracionesUn tablero Scrum suele tener un aspecto similar a este durante lasdiferentes etapas de un sprint.

Cuando se finaliza un sprint, se limpia el tablero - todos los elementosson eliminados. Se inicia un nuevo sprint y tras la reunin deplanificacin del sprint tendremos un nuevo tablero Scrum, con nuevos

elementos en la primera columna. Tcnicamente esto es una prdida detiempo, pero para equipos Scrum experimentados no suele llevar mucho,y el proceso de limpiar el tablero puede dar una grata sensacin de logroy cierre. Es algo as como lavar los platos tras la cena - hacerlo resultapesado pero sienta bien al finalizar.

En Kanban, el tablero normalmente es algo persistente - no se necesitalimpiarlo y volver a empezar.

Scrum: Primer da de sprint Scrum: Mitad de sprint Scrum: ltimo da de sprint

Kanban: Cualquier da


44/123


45/123

29

9Scrum prescribe equipos multi-funcionalesUn tablero Scrum es propiedad de solamente un equipo Scrum. Unequipo Scrum es multi-funcional, contiene todos los conocimientosnecesarios para completar todos los elementos de la iteracin. Un

tablero Scrum suele ser visible para cualquiera que est interesado, peroslo el equipo Scrum al que pertenece puede editarlo - es su herramientapara administrar su compromiso para esta iteracin.

En Kanban, los equipos multi-funcionales son opcionales, y un tablerono necesita estar en manos de un equipo especfico. Un tablero estrelacionado con un flujo de trabajo, no necesariamente con un equipo.

Tablero Scrum

EquipodeScrum


46/123


30

He aqu dos ejemplos:

Ejemplo 1: Todo el tablero est al servicio de un equipo multi-funcional. Justo como en Scrum.

Ejemplo 2: El dueo de producto establece las prioridades en lacolumna 1. Un equipo de desarrollo multi-funcional realiza el desarrollo(columna 2) y prueba (columna 3). La puesta en produccin (columna 4)

es realizada por un equipo de especialistas. Existe un ligerosolapamiento de competencias, de modo que si el equipo de puesta en produccin se convierte en un cuello de botella uno de losdesarrolladores les ayudar.As, en Kanban es necesario establecer algunas reglas bsicas para quinusa el tablero y cmo, luego se experimenta con las normas paraoptimizar el flujo.

Tablero Kanban ejemplo Tablero Kanban ejemplo 2


47/123

31

10Los elementos de la pila de productodeben caber en un sprintAmbos Scrum y Kanban se basan en el desarrollo incremental, porejemplo, descomponer el trabajo en trozos ms pequeos.

Un equipo Scrum slo se comprometer con los elementos que creenque pueden terminar en una iteracin (basado en la definicin de"Hecho"). Si un elemento es demasiado grande para caber en un sprint,el equipo y el propietario del producto intentarn encontrar la manera de partirlo en pedazos ms pequeos hasta que se pueda abordar en unsprint. Si los elementos tienden a ser grandes, las iteraciones debern serms largas (aunque generalmente no ms de 4 semanas).

Los equipos de Kanban tratan de minimizar el tiempo de entrega y elnivel de flujo, por lo que, indirectamente, se crea un incentivo paradescomponer los elementos en pedazos relativamente pequeos. Pero nohay ninguna norma explcita que indique que los elementos deben ser losuficientemente pequeos como para caber en un intervalo de tiempoespecfico. En el mismo tablero podra haber un elemento que necesitaun mes para terminarse y otro elemento que necesita un da.


48/123


32


49/123

33

11Scrum prescribela estimacin y lavelocidadEn Scrum, los equipos tienen que estimar el tamao relativo (= cantidadde trabajo) de cada elemento al que se comprometen. Sumando eltamao de cada elemento completado al final de cada sprint, obtenemos

la velocidad. La velocidad es una medida de la capacidad - la cantidadde cosas que podemos ofrecer por Sprint. He aqu un ejemplo de unequipo con una velocidad media de 8.

Saber que la velocidad media es de 8 es bueno, porque entoncespodemos hacer predicciones realistas sobre los elementos que se puedencompletar en los prximos sprints, y por lo tanto hacer planes de entregarealistas.

En Kanban, no se prescribe la estimacin. As que si necesitas

comprometerte necesitas decidir la forma de garantizar la previsibilidad.

Algunos equipos optan por hacer estimaciones y medir la velocidadcomo en Scrum. Otros equipos eligen omitir la estimacin, pero tratande descomponer cada elemento en partes de aproximadamente el mismotamao -entonces pueden medir la velocidad simplemente en funcin decuntos elementos se completan por unidad de tiempo (por ejemplo, porsemana).

Algunos equipos agrupan los elementos en MMF's (caractersticasmnimas de comercializacin) y miden el tiempo de entrega promediopor MMF, y lo usan para establecer SLA (acuerdos de nivel de servicio,


50/123


34

en ingls service-level agreements) - por ejemplo, "cuando noscomprometemos con un MMF siempre ser entregado en 15 das ".

Hay todo tipo de tcnicas interesantes para el estilo de planificacin de

entregas y gestin de compromisos de Kanban- pero no se prescribeninguna tcnica especfica, as que adelante, googlea y prueba diferentestcnicas hasta que encuentres una que se adapte a su contexto.Probablemente veremos algunas "mejores prcticas" emerger con eltiempo.


51/123

35

12Ambos permiten trabajar en mltiplesproductos simultneamenteEn Scrum, la Pila de Producto es un nombre un tanto desacertado puesimplica que todos los tems deben pertenecer a un mismo producto.Aqu vemos dos productos, uno verde y el otro amarillo, cada uno con

su respectiva pila y su respectivo equipo:

Que pasa si tenemos un slo equipo para varios productos? Bien, pensemos en la Pila de Producto ms bien como una Pila de Equipo.Lista las prioridades para las siguientes iteraciones del equipo (oconjunto de equipos) en particular. De esta forma, si un equipo mantiene

ms de un producto, debe fusionar ambos productos en una sola lista.Esto nos obliga a priorizar entre productos, lo cual puede resultar til enalgunos casos. Hay varias formas de hacer esto en la prctica:

Una estrategia sera hacer que el equipo se enfoque en un slo productodurante el sprint:

ProductoVerde

ProductoAmarillo


52/123


36

Otra estrategia sera hacer que el equipo trabaje en la funcionalidad deambos productos cada sprint:

Es lo mismo en el caso de Kanban. Podemos tener varios productosfluyendo por el mismo tablero. Tal vez podemos distinguirlos utilizandotarjetas de diferentes colores:

... o mediante distintas pistas o calles (swinlanes) :

Producto Verde:

Producto Amarillo:


53/123

37

13Ambos son Lean y gilesNo voy a revisar aqu el Pensamiento 'Lean', ni el Manifiesto gil. Perose puede generalizar que tanto Scrum como Kanban estn bien alineadoscon los valores y principios de stos.

Por ejemplo:

Tanto Scrum como Kanban son sistemas de planificacin tipo"Pull", principio de gestin de inventario 'Just In Time' (JIT) propiode Lean. Esto significa que el equipo elige cundo y cunto trabajoacometer. Ellos (los componentes del equipo) "tiran" del trabajocuando estn listos, en contraposicin a que desde el exterior se"empuje" al equipo a hacerlo. Al igual que una impresora tira de lasiguiente pgina solo cuando esta lista para imprimir en ella (aunquetenga hojas de papel en la bandeja).

Scrum y Kanban se basan en procesos de optimizacin continuosy empricos, que se corresponden con el principio Kaizen de Lean.

Scrum y Kanban dan ms importancia a la respuesta al cambioque al seguimiento de un plan (aunque Kanban permite,tpicamente, una respuesta ms rpida que Scrum). Uno de loscuatro principios del manifiesto gil.

...y mas.Desde un determinado punto de vista, Scrum se puede ver como no-tan-lean, ya que contempla agrupar tareas por lotes dentro de iteraciones detiempo prefijado. Pero eso depende de la longitud de tu iteracin, ytambin de con qu se compare. En un proceso ms tradicional, en elque quizs se integren versiones unas 2-4 veces al ao, un equipo Scrumproduciendo cdigo entregable cada 2 semanas se puede considerar muyLean.

Por consiguiente, si haces iteraciones cada vez ms cortas,esencialmente te ests aproximando a Kanban. Una vez que se empieza


54/123


38

a hablar de hacer durar la iteracin menos de una semana, se deberaconsiderar abandonar definitivamente las iteraciones a tiempo cerrado.

Ya lo he dicho antes y lo seguir diciendo: Experimenta hasta queencuentres algo que te funcione! y entonces contina experimentando.


55/123


56/123


40

Siempre toma las tareas en rojo, si las hay.

En Scrum, la pila de producto tambin se puede usar al estilo Kanban.

Podemos limitar su tamao y crear las reglas de decisin sobre cmo sedebera priorizar.

En Scrum se establecen reuniones diarias

Un equipo Scrum tiene una reunin corta (de aproximadamente 15minutos) cada da, a la misma hora y en el mismo lugar. El objeto deestas reuniones es compartir informacin sobre lo que est pasando,

planificar el da de trabajo actual e identificar cualquier problemasignificativo. El trmino que se emplea a veces en ingls, 'daily standup',refleja el hecho de que normalmente se celebra de pie (para que seabreve y mantener un nivel alto de energa).

Las reuniones diarias no se utilizan en Kanban, pero la mayora de losequipos Kanban parece que lo hacen de todos modos. Es una grantcnica, con independencia del proceso que utilices.

En Scrum, este formato de reunin est muy orientado a la persona.Cada miembro del equipo va haciendo su reporte uno a uno. Muchosequipos Kanban utilizan un formato ms orientado al panel, poniendo elfoco en los cuellos de botella y otros problemas visibles. Esta ltimaaproximacin es ms escalable. Si tienes 4 equipos compartiendo elmismo panel y haciendo sus reuniones diarias juntas, puede que no seanecesario tener que escuchar hablar a cada uno en tanto y en cuanto nosenfoquemos en las partes que son cuellos de botella del panel.

En Scrum se usan diagramas de Burndown

Un grfico burndown representa,diariamente, la cantidad detrabajo restante en la iteracinactual.

La unidad del eje-Y es la mismaque la utilizada en las tareas delsprint. Tpicamente, horas o das

(si el equipo convierte la pila entareas) o puntos de historia (si el


57/123

DIFERENCIAS MENORES | 41

41

equipo no lo hace). Existen muchas variaciones de esto.

En Scrum, los grficos burndown se usan como herramienta primordialpara el seguimiento del progreso de una iteracin.

Algunos equipos tambin utilizan grficos burndown de versin quesigue el mismo formato pero a nivel de versin - tpicamente muestrancuantos puntos de historia quedan pendientes en la pila despus de cadasprint.

El principal propsito de un grfico Burndown es encontrar, fcilmentey tan pronto como sea posible, si nos encontramos avanzados oretrasados respecto a planificacin para poder adaptarnos.

En Kanban, no se prescriben grficos burndown. De hecho, no existeningn tipo particular de grfico. Pero, desde luego que se permiteutilizar cualquier tipo de grfico que se quiera (incluyendo losburndowns).

A continuacin se muestra un ejemplo de Diagrama de FlujoAcumulativo. Este tipo de grficos representan finamente la suavidaddel flujo y cmo el WIP afecta a tu plazo de entrega.

La flecha horizontal nos muestra que las tareas aadidas a la pila el da 4

costaron una media de 6 das en llegar a produccin. Aproximadamentela mitad de ese tiempo fueron Test. Podemos ver que si se limitramos


58/123


42

el WIP en Test y Pila, reduciramos significativamente el plazo deentrega total.

La pendiente del rea azul-oscura nos muestra la velocidad (por

ejemplo, nmero de tareas desarrolladas al da). Con el tiempo podemosver como velocidades mayores reducen el plazo de entrega, mientrasque un mayor WIP lo incrementa.

La mayora de las organizaciones quieren tener realizado el trabajo msrpido (= reducir el plazo de entrega). Desafortunadamente muchas caenen la trampa de asumir que esto significa contratar ms personas otrabajar horas extras. Normalmente la forma ms efectiva de hacer el

trabajo ms rpidamente es suavizar el flujo y limitar el trabajo a lacapacidad. No aadir ms gente o trabajar ms duro. Este tipo dediagrama muestra por qu. Y de este modo se incrementa laprobabilidad de que el equipo y la gerencia colaboren de forma efectiva.

Esto se ve de forma an ms clara si distinguimos entre estados 'a cola'(como por ejemplo "esperando para test") y estados de 'trabajo' (como por ejemplo "Testeando"). Queremos, minimizar de forma absoluta elnmero de actividades esperando 'a cola'. Y el Diagrama de Flujo

Acumulativo ayuda a proporcionar los incentivos adecuados para esto.


59/123

43

15El tablero Scrum vs. el tablero Kanban un ejemplo menos trivialEn Scrum, la pila de sprint es slo una parte de la foto - la parte quemuestra lo que est haciendo el equipo durante el sprint actual. La otraparte es la pila de producto - la lista de cosas que el dueo del producto

quiere tener hecho en futuros sprints.

El dueo del producto puede ver pero no tocar la pila de sprint. Puedecambiar la pila de producto en cualquier momento, pero los cambios notendrn efecto (es decir, no afectarn al trabajo que se est haciendo)hasta el siguiente sprint.

Cuando se hace el sprint, el equipo "facilita el cdigo potencialmenteentregable" al dueo del producto. De este modo, cundo el equipofinaliza el sprint lo revisa y, con orgullo, muestra las caractersticas A,B, C y D al dueo del producto. El dueo del producto puede decidir

ahora si quiere o no entregar el sprint. Esta ltima parte - el hecho deentregar el producto - no suele estar incluido en el sprint, y por lo tantono es visible en la pila de sprint.

En este escenario, un tablero Kanban podra ser algo como esto:

rode(e

te

Comprometido En curso Terminado :o)

B

C

A

D

Pila de sprintE

F

GH

E

F

G

H IJ L

KM

Pila deproducto


60/123


44

Ahora, el flujo de trabajo completo se encuentra en el mismo tablero -no slo estamos mirando lo que un equipo Scrum est haciendo en unaiteracin.

En el ejemplo anterior la columna Pila es slo una lista general de

deseos sin ningn orden en particular. La columna "Seleccionado"contiene los elementos de prioridad alta, con un lmite Kanban de 2. Porlo tanto, slo puede haber 2 elementos de prioridad alta en un momentodado. Cada vez que el equipo est listo para comenzar a trabajar en unnuevo elemento tendr que tomar el primer elemento de la columna"Seleccionado". El dueo del producto puede hacer cambios en lascolumnas Pila y Seleccionado en cualquier momento, pero no en lasotras columnas.

La columna "Des" (dividida en dos subcolumnas) muestra lo que se estdesarrollando, con un lmite Kanban de 3. En trminos de red, el lmiteKanban corresponde al "ancho de banda y el tiempo de entregacorresponde a "ping" o tiempo de respuesta.

Por qu hemos dividido la columna "Des" en dos subcolumnas "Encurso" y "Terminado"? Es para dar al equipo de produccin laoportunidad de conocer los elementos que pueden arrastrar pull aproduccin.

Seleccionado Desarrollar

Terminado

B

C

A

IL

K

Pila Produccin!En curso

R

FLUJO

Implementar


61/123

EL TABLERO SCRUM VS EL TABLERO KANBAN | 45

45

El lmite "Des" de 3 es compartido entre las dos subcolumnas. Por qu?Digamos que hay 2 artculos en "Terminado":

Esto significa que slo puede estar 1 elemento En curso". Por lo tanto,significa que habr exceso de capacidad, los desarrolladores podrancomenzar un nuevo elemento, pero no estn autorizados a causa dellmite Kanban. Esto les da un fuerte incentivo para concentrar susesfuerzos y ayudar a poner cosas en produccin, para borrar de lacolumna "Terminado" y maximizar el flujo. Este efecto es agradable yprogresivo - a ms cosas en "Terminado", menos cosas se permiten Encurso" lo que ayuda a centrar la atencin del equipo en las cosas

adecuadas.

Flujo de una sola pieza

El flujo de una sola pieza es una especie de escenario de "flujo perfecto", donde un elemento fluye a travs del tablero sin quedaratrapado en una cola. Esto significa que en cada momento hay alguien

trabajando en ese elemento. Aqu puedes ver cmo el tablero podrarepresentar este caso:

Des

Terminado

B

C

A

3En curso

Seleccionado 2Des 3

Terminado

B A

Pila En produccin

:o)En curso

X

R

FLUJO


62/123


46

B se est desarrollando en este momento, A se ha puesto en produccinen este momento. Cada vez que el equipo est listo para el siguiente

elemento pregunta al dueo del producto qu es lo ms importante yobtiene una respuesta. Si este escenario ideal persiste podemosdeshacernos de las dos colas "Pila" y "Seleccionado" y tener un tiempode entrega muy corto!

Cory Ladas lo cuenta muy bien: "El proceso ideal de planificacin deltrabajo siempre debe proporcionar al equipo de desarrollo lo msadecuado para continuar, ni ms ni menos".

Los lmites del trabajo en curso (WIP) estn ah para evitar problemasantes de que aparezcan. As, si las cosas estn fluyendo sin problemas,los lmites del trabajo en curso (WIP) no son realmente utilizados.

Un da en el pas de Kanban

Selecccionado Desarrollar

Terminado

A BG

D

Pila 22

Produccin!En curso

Implementar

CF

H I

1

SelecccionadoDesarrollar

Terminado

Pila 22

Produccin!En curso

Implementar1

A

BG CF D

H I


63/123


64/123


65/123


49

El tablero Kanban tiene que tener este aspecto?

No, el tablero anterior fue solo un ejemplo.

Lo nico que prescribe Kanban es que el flujo de trabajo debe ser visual,

y que el trabajo en curso debe estar limitado. El objetivo es crear unflujo suave a travs del sistema y minimizar el tiempo de entrega. Por lotanto, necesitas plantearte regularmente cuestiones tales como:

Qu columnas deberamos tener?

Cada columna representa un estado del flujo de trabajo, o una cola(buffer) entre dos estados del flujo de trabajo. Empieza de forma sencillay aade nuevas columnas cuando lo necesites.

Selecccionado

Desarrollar

TerminadoPila 22 Produccin!En curso

Implementar1

C

D

G

B

A

FH I

J

K

L1"

0""

$,,,/.##$"

!%#,

SelecccionadoDesarrollar

Terminado

Pila 22

Produccin!En curso

Implementar1

%#

...

MH

JL

R

C

DGB

A

F

I K

1'!0

12

(01-0

/++.

,/2!

.+/.,++/.10.0


66/123


67/123

51

16Resumen de Scrum vs KanbanParecidos

Ambos son Lean y giles. Ambos emplean sistemas de planificacin "pull".

Ambos establecen lmites WIP.

En ambos la visibilidad del proceso es la base de su mejora.

Ambos tienen como objetivo la entrega temprana y

frecuente de software.

Ambos trabajan con equipos auto-organizados.

Ambos necesitan la divisin del trabajo en partes.

Ambos revisan y mejoran de forma continua el plan del

producto en base a datos empricos (velocidad / tiempo de

entrega)

Diferencias

Scrum Kanban

Las iteraciones deben ser de

tiempo fijo.

El tiempo fijo en las iteraciones es

opcional. La cadencia puede variar

en funcin del plan del producto y la

mejora del proceso. Pueden estar

marcadas por la previsin de los

eventos en lugar de tener un tiempopre-fijado.


68/123


52

El equipo asume un compromiso de

trabajo por iteracin.El compromiso es opcional.

La mtrica por defecto para laplanificacin y la mejora del proceso

es la Velocidad.

La mtrica por defecto para la

planificacin y la mejora del procesoes el Lead Time (tiempo de entrega

o tiempo medio que tarda una

peticin en salir del ciclo)

Los equipos deben ser multi-

funcionales.

Los equipos pueden ser multi-

funcionales o especializados.

Las funcionalidades deben dividirse

en partes que puedan completarse

en un sprint.

No hay ninguna prescripcin en

cuanto al tamao de las divisiones.

Deben emplearse grficos

Burndown.

No se prescriben diagramas de

seguimiento concretos.

Se emplea una limitacin WIP

indirecta (por sprint).

Se emplea una limitacin WIP

directa (marcada por el estado del

trabajo).

Se deben realizar estimaciones. Las estimaciones son opcionales.

No se pueden aadir tareas enmedio de una iteracin.

Siempre que haya capacidad

disponible, se pueden aadirtareas.

La pila del sprint pertenece a un

equipo determinado.

Varios equipos o personas pueden

compartir la misma pizarra

Kanban.

Se prescriben 3 roles

(PP/SM/Equipo).No hay roles prescritos.

En cada sprint se limpia el tablero

de seguimiento. El tablero Kanban es persistente.

La pila del producto debe estar

priorizada.La priorizacin es opcional.

Ala. Esto es todo. Ahora ya conoces las diferencias.

Sin embargo, an no ha terminado, ahora es el momento de la mejor


69/123


53

parte!. Clzate las botas, porque es hora de ir a las trincheras conMattias para ver cmo se pone esto en prctica!


70/123


71/123

55

Parte II Caso de estudio

Kanban en la vida real

Esta es la historia de cmo hemos aprendido a mejorar usando Kanban.

Cuando empezamos no haba mucha informacin, y el Dr. Google nos

dej con las manos vacas. Hoy en da Kanban est evolucionando

satisfactoriamente y hay un cuerpo de conocimiento incipiente.

Recomiendo echar un vistazo al trabajo de David Anderson, por

ejemplo a "classes of service". As que aqu viene la primera (y ltima)

advertencia (lo prometo!). Independientemente de la solucin que

vayas a implementar, asegrate de tratar sus problemas especficos.

Una vez dicho, vamos con nuestra historia.

/Mattias Skarin

Ideas Mercado En desarrollo

Carrito

Cliente

Prueba Produccin

Historia

Login

Invitar Email

GUI*

Retroceder

Servicio

* Graphical User Interface: Interfaz Grfica de Usuario


72/123


73/123

57

17La naturaleza de las operacionestcnicasSi alguna vez has estado en un servicio de soporte 24/7, tendrs una ideaclara de la responsabilidad que se siente al gestionar un entorno deproduccin. Se espera que resuelvas la situacin en medio de la noche,

sin importar si el problema era por tu culpa o no. Nadie lo sabe, por esote llaman. Es un reto complicado porque t no eres el fabricante delhardware, los drivers, el sistema operativo ni el software del usuario. Amenudo tus opciones se limitan a acotar el problema o su impacto, y aregistrar la informacin necesaria para poder repetir el error, de maneraque la persona responsable pueda solucionar el problema del que tu hassido testigo.

La respuesta y la capacidad para resolver problemas son claves, siemprecon velocidad y precisin.


74/123


75/123


76/123


60

Adems, el progreso en los equipos de desarrollo significaba unaumento de las peticiones a los gerentes para echar una mano en elanlisis y la revisin de ideas. Esto significaba que tenan menos tiempo

para la priorizacin de tareas y resolucin de problemas en el da a da.El equipo de gerentes se dio cuenta de que necesitaban actuar antes deque la situacin se volviera inmanejable.


77/123

61

19Por dnde empezamos?Una buena forma de empezar era preguntar a los equipos de desarrollo,porque eran los clientes del grupo de Operaciones.El equipo de operaciones, visto por los

desarrolladoresLes pregunt; "qu tres cosas os vienen a la cabeza cuando pensis en'Operaciones'?". Las respuestas ms comunes fueron:

Conocimiento variable Su sistema de workflow

apesta

Muy competentes cuando se trata

de infraestructuraQu estn haciendo los

chicos?Ellos quieren ayudar, pero en

realidad es difcil obtener ayudaNecesito muchos correos

electrnicos para hacer cosas

simplesLos proyectos duran demasiado Difciles de contactar

En resumen, as era cmo los desarrolladores vean al equipo deOperacin. Comparmoslo con la visin de Desarrollo que tena elequipo de Operacin:

Desarrollo, visto desde el equipo de operaciones

61


78/123


62

Por qu no utilizis las ventajas que os ofrecen las plataformas?

Hagamos de la distribucin algo menos pesado!

Vuestra baja calidad nos afecta!

"Tienen que cambiar" - era el tema comn en las quejas de ambosequipos. Obviamente, debamos cambiar ese esquema mental siqueramos avanzar en la resolucin de los problemas comunes. Por lomenos, "muy competentes cuando se trata de infraestructura" indicabaconfianza en las capacidades y me haca pensar que esa mentalidad de"nosotros contra ellos"poda arreglarse si se creaban las condiciones detrabajo adecuadas. Una opcin viable poda ser eliminar el sobre-

esfuerzo y concentrarnos en la calidad.


79/123

63

20Iniciando la marchaAs que necesitbamos iniciar la marcha, pero por dnde empezamos?La nico cierto que sabamos es: el sitio donde empecemos no serdonde terminemos.

Mi experiencia es la de un desarrollador, as que seguramente saba muypoco sobre la naturaleza del trabajo de Operaciones. Y no era cuestinde entrar a lo loco y comenzar a cambiar cosas. Necesitaba un enfoquemenos frontal que an as nos enseara las cosas relevantes, descartaralas no relevantes y fuera fcil de aprender.

Los candidatos eran:

1. Scrum - estaba funcionando bien en equipos de desarrollo.2. Kanban - era nuevo y no estaba probado, aunque encaja bien con

los principios Lean que se echaban en falta.

En discusiones con los gerentes los principios de Kanban y Leanparecan encajar con los problemas que estbamos intentando resolver.Desde su punto de vista los sprints no se adaptaran muy bien ya quehacan repriorizacin de forma diaria.

Por lo tanto Kanban pareca el punto de partida ms lgico, inclusoaunque fuera algo nuevo para todos nosotros.


80/123


81/123

65

21Puesta en marcha de los equiposCmo poner en marcha los equipos? No haba ningn manual quedijera cmo hacerlo. Y hacerlo mal poda ser muy arriesgado. Aparte de perder las mejoras, tenamos que tratar con una plataforma deproduccin con personal altamente especializado y cualificado; difcilesde reemplazar. Dejarlos de lado era una idea muuuy mala.

Deberamos simplemente ponernos en marcha? Asumir lasconsecuencias segn vayan surgiendo? O bien, hacer primero un taller?

Era obvio para nosotros - Hacer el taller, verdad? Pero cmo?

Era un reto conseguir que todo el equipo de soporte participara en untaller (Quin contestar al telfono si alguien llama?). Al final

decidimos hacer un taller de medio da, y mantenerlo sencillo y basadoen ejercicios.

El taller

Uno de los beneficios del taller era que ayudara a poner de manifiestocuanto antes nuestros problemas. Pero adems proporcion un ambientede alta confianza donde las implicaciones podan ser discutidasdirectamente con los miembros del equipo. Porque, seamos sinceros, no

todo el mundo era demasiado entusiasta acerca de cambiar la actualforma de trabajo. Pero la mayora de los miembros del equipo estabanabiertos a intentarlo, as que se llev a cabo un taller de demostracin delos principios ms importantes y se hizo una simulacin a escala deKanban.


82/123


83/123

67

22Dirigindonos a los involucradosEra muy probable que otras partes interesadas (soporte, clientes, otrosequipos, ...) se vieran afectadas por la aplicacin de Kanban. Aunque loscambios seran para mejor, significara que el equipo comenzara a decir"no" al trabajo que no podan completar, a defender la calidad, y aeliminar tareas de baja prioridad de la pila del equipo.A pesar de ello, tener una discusin previa siempre es una buena idea.

Los interesados ms cercanos eran la primera lnea de soporte y losgerentes de departamento. Como haban participado en el taller, ya eranpartidarios de seguir adelante. Lo mismo para los equipos de desarrollo(que esperaban en mayor o menor medida las mejoras). Pero, para unequipo, el equipo de soporte, las cosas eran diferentes. Su problema msimportante era que estaban sobrecargados de trabajo. Adems, ellosgestionaban las solicitudes de los clientes y la empresa se haba

comprometido a responder a todas las solicitudes.

Ahora esto era muy probable que cambiara si aplicbamos Kanban y secomenzbamos a cumplir los lmites de WIP (trabajo en curso). As quehicimos una visita a los principales interesados para presentarlesnuestras intenciones, beneficios esperados, y posibles consecuencias.

Para mi alivio, nuestras ideas fueron muy bien acogidas, a veces con unaobservacin: "estupendo si finalmente podemos dejar estos asuntos en

paz".


84/123


85/123

69

23Construyendo el primer tableroUna buena manera de comenzar la construccin de un tablero deKanban es haciendo un mapa de la cadena de valor (value stream map).Se trata bsicamente de una visualizacin de la cadena de valor yproporciona la comprensin de los estados de los trabajos, el flujo y eltiempo a en el sistema (tiempo del ciclo).

Pero empezamos por algo mucho ms simple; un tablero de ejemploKanban dibujado en papel junto con el gerente. Revisado un par deveces y luego nos pusimos en marcha. Las cuestiones que surgieron enesta etapa incluyen:

Qu tipos de trabajo tenemos? Quin los maneja? Debemos compartir la responsabilidad entre los diferentes tiposde trabajo? Cmo podemos hacer frente a la responsabilidad compartidateniendo en cuenta que tenemos conocimientos especializados?

Dado que para los diferentes tipos de trabajo haba acuerdos de nivel deservicios diferentes, pareca natural permitir que cada equipo llevara elcontrol de su propio tablero. Ellos mismos hicieron las filas y columnas.


86/123


70

La siguiente gran decisin era si utilizar o no una responsabilidadcompartida entre los diferentes tipos de trabajo.

"Debemos dejar que una parte fija del equipo trate con las preguntas

directas (trabajo reactivo) y dejar que el resto del equipo se centre enlos proyectos (trabajo proactivo)?"

Decidimos en un primer momento probar la responsabilidad compartida.Una razn fundamental era que habamos identificado que la auto-organizacin y el crecimiento de los miembros del equipo eranesenciales para el crecimiento sostenido. El inconveniente de estadecisin eran las potenciales interrupciones para todo el mundo, peroesta era la mejor solucin que pensamos para comenzar.

Una pequea nota al margen: cuando realizamos el taller los equipos seorganizaron solos para solucionar este problema. Dejaron que unapersona a manejara las solicitudes inmediatas y el resto las cuestionesms extensas.

El primer modelo Kanban

A continuacin se muestra el modelo bsico que utilizamos paraKanban. Tenga en cuenta que el equipo decidi poner el flujo del producto hacia arriba (como burbujas en el agua) en lugar de usar elmodelo de flujo ms tpico de izquierda a derecha.

Figura 2. Este es el primer modelo de Kanban. Prioridades de

ejecucin de izquierda a derecha, flujo de ejecucin hacia arriba.

Trabajos en curso contados como el nmero total de tareas en la


87/123

CONSTRUYENDO EL PRIMER TABLN | 71

71

lnea de trabajo en curso (con crculo rojo). El modelo est

influenciado por las experiencias transmitidas por Linda Cook.

Figura 3. Primer tablero Kanban para el equipo de administracin

de sistemas.

Filas utilizadas:

Estado del flujo de trabajo (fila) Como lo definimosBacklog (Pila de producto) Historias que el gerente decide que

son necesarias.Listo para WIP Historias estimadas y divididas en

tareas con una duracin mxima de8 horas.

Trabajo en curso Fila que contena un lmite para eltrabajo en curso. Empezamos con unlmite de 2 X tamao del equipo -1(-1 para colaboracin). As, un

equipo de 4 personas tendra unlmite de 7.

Hecho Ejecutable por el usuario.


88/123


72

Columnas utilizadas:

Tipo de trabajo Como lo definimosRelease (liberacin) Ayudar a los equipos de desarrollo a

liberar software.Soporte Pequeas peticiones de otros

equipos.No planificado Trabajo imprevisto que es necesario

realizar pero que no tiene un propietario definido. Por ejemplo, pequeas mejoras en la

infraestructura.Proyecto A Proyectos grandes de soporte

tcnico, por ejemplo cambiar elhardware del entorno de pruebas.

Proyecto B Otro proyecto largo

No todos los tableros Kanban tenan la misma apariencia. Todoscomenzaron con un boceto simple y evolucionaron por el camino.


89/123

73

24Estableciendo el primer lmite de WIPNuestro primer lmite de WIP (trabajo en curso) era bastante generoso.Supusimos que mediante la visualizacin del flujo veramos yexperimentaramos lo que iba sucediendo y que era poco probable quefuramos capaces de adivinar el lmite ptimo desde el principio. Segn pasara el tiempo, ajustaramos los lmites de WIP cada vez queencontrramos una buena razn para ello (slo haca falta apuntarlo enel tablero).

El primer lmite WIP que usamos fue 2n-1 donde n era el nmero demiembros del equipo y -1 un modo de potenciar la cooperacin. Porqu decidimos este lmite? Simplemente, porque no tenamos una ideamejor J. Adems, pareca algo poco controvertido para empezar. Lafrmula proporcionaba una explicacin simple y lgica para cualquieraque intentara cargar ms trabajo al equipo: ...si cada miembro del

equipo slo puede trabajar en un mximo de dos cosas a la vez, unaactiva y otra en espera... cmo crees que pueden aceptar ms?".Mirando ahora hacia atrs, cualquier lmite generoso habra funcionado para un equipo novato. Monitorizando el tablero Kanban es sencillodescubrir los lmites correctos sobre la marcha.


90/123


74

Figura 4. Cmo aplicbamos el lmite de WIP para el equipo de

DBA y administracin de sistemas, con un lmite por cada tipo de

trabajo

Pronto descubrimos que no era til definir el lmite WIP en puntos dehistoria porque era difcil de controlar. El nico lmite suficientementesencillo de controlar era simplemente la cuenta del nmero de elementos

del panel, es decir, el nmero de tareas en paralelo.

Para el equipo de suporte establecimos un lmite WIP por columna, porque necesitbamos capacidad de reaccin rpida si el lmite sesobrepasaba.


91/123

75

25Respetando el lmite WIPAunque respetar el lmite WIP establecido suena fcil en teora, es unatarea difcil de conseguir en la prctica, porque siempre significa decirno en algn momento. Pusimos en prctica diferentes aproximacionespara conseguir esto.

Discutir frente al tablero

Cada vez que se descubra una violacin de los lmites WIP llevbamosa las partes interesadas ante el tablero Kanban y les preguntbamos qu pretendan conseguir. Al principio, la razn ms habitual para esasviolaciones era simple inexperiencia. En algunos casos nos encontramoscon perspectivas diferentes sobre la priorizacin, siendo tpicos los casos

de especialistas trabajando sobre su rea especfica. Estas fueron lasnicas ocasiones en que experimentamos alguna friccin, porque lamayora de las veces estas violaciones se solucionaban all mismodiscutindolo a la vista del tablero.

Creando una seccin de sobrecarga

Cuando decir no supona demasiada confrontacin, y eliminarelementos del tablero era complicado, movamos los elementos demenor prioridad a una seccin de sobrecarga en el tablero, all dondelos lmites WIP se haban sobrepasado. Dos reglas aplicaban a las tareasen sobrecarga:

1. No han sido olvidadas. En cuanto tengamos tiempo lastrataremos.

2. Si las abandonamos, sers informado.


92/123


76

Justo pasadas dos semanas se haca obvio que los elementos desobrecarga incluso ni se trataran nunca, de forma que con el apoyo deljefe de equipo finalmente se podran quitar.

Figura 5. Boceto del tablero Kanban para el equipo de soporte, con

la seccin de sobrecarga en la ltima columna.


93/123

77

26Qu tareas llevar al tablero?Pronto tomamos la decisin de no incluir todo el trabajo hecho por elequipo en el tablero. Monitorizar cosas como una llamada telefnica otomar un caf convertira el Kanban en un monstruo administrativo.

Estbamos aqu para resolver problemas, no para crearlos J. As quedecidimos slo poner en el tablero las tareas con tamao mayor de unahora. Todo lo menor de una hora se consideraba ruido blanco.

El lmite de 1h realmente funcion bastante bien, y fue de las pocascosas que permanecieron sin cambios a lo largo del tiempo (tuvimos querevisar nuestras previsiones acerca del impacto que el ruido de fondotena, pero hablaremos de eso ms tarde).

Figura 6. Comenzamos por sumir que la capacidad total era

principalmente ocupada en dos tipos de trabajo; grande

(proyectos) y pequeos (soporte). El seguimiento de la velocidad

en proyectos nos poda dar pistas acerca de la fecha de entrega si

era necesario. Siempre contbamos con que el ruido blanco

(pequeo soporte menor de 1h, reuniones, caf, ayudar a los

colegas) estara por ah de todos modos.


94/123


95/123

79

27Cmo estimar?Este es un tema siempre recurrente y realmente hay ms de unarespuesta correcta: Estimar regularmente.

Estimar cuando se necesita.

Usar estimaciones en das ideales o en puntos de historia.

Las estimaciones son inciertas, usa tallas de camiseta (S-

pequea, M-media, L-grande)

No estimes, o estima slo cuando exista un coste asociado alretraso que lo justifique.

Ligeramente influidos por Scrum

KanbanVsScrum Caste Llano FINAL-Printed

Documents

Transcript of KanbanVsScrum Caste Llano FINAL-Printed