Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Presentación:
Unidad 1:
Introducción
Página 4
Objetivo:
Temario:
4. Radiadores de Información
Temario Detallado
0 Introducción .......................................................................................................... 8
0.1 Contexto ......................................................................................................... 8
0.2 Temario .......................................................................................................... 9
1 Introducción a las metodologías ágiles ................................................................ 10
1.1 Gestión de Proyectos .................................................................................... 11
1.2 Definición de enfoque ágil ............................................................................ 11
1.3 La Mentalidad Ágil ........................................................................................ 12
1.4 Enfoque de Gestión de las Metodologías Ágiles ............................................ 12
1.5 ¿Cuándo Si y Cuándo No? ............................................................................. 13
2 Manifiesto Ágil y sus principios............................................................................ 14
2.1 Contexto ....................................................................................................... 15
2.2 Valores.......................................................................................................... 15
2.2.1 Individuos e Interacciones sobre Procesos y Herramientas .................... 15
2.2.2 Producto Funcionando sobre Documentación Extensiva ........................ 16
2.2.3 Colaboración con el Cliente sobre Negociación Contractual ................... 16
2.2.4 Respuesta ante el Cambio sobre Seguir un Plan ..................................... 16
2.3 Principios ...................................................................................................... 17
3 Introducción a Lean, Scrum, Kanban y XP ............................................................ 18
3.1 Lean .............................................................................................................. 19
3.1.1 Conceptos .............................................................................................. 19
3.1.2 Los 7 Principios de Lean ......................................................................... 21
3.1.3 Value Stream Maping ............................................................................ 22
3.2 Scrum ........................................................................................................... 25
3.2.1 Pilares y Valores..................................................................................... 25
3.2.2 Marco de Trabajo Scrum ........................................................................ 26
3.2.3 Sprint ..................................................................................................... 27
3.2.4 Roles ...................................................................................................... 27
3.2.5 Dueño de Producto ................................................................................ 27
3.2.6 Scrum Master ........................................................................................ 27
3.2.7 Equipo ................................................................................................... 28
3.2.8 Artefactos .............................................................................................. 28
Página 7
3.2.9 Ceremonias............................................................................................ 29
3.2.10 Valores Fundacionales de Scrum ............................................................ 30
3.2.11 Conclusiones.......................................................................................... 31
3.3 XP (Extreme Programing) .............................................................................. 32
3.3.1 Introducción .......................................................................................... 32
3.3.2 Valores .................................................................................................. 32
3.3.3 Resumen de las Prácticas de XP ............................................................. 33
3.3.4 Las prácticas de XP ................................................................................. 33
3.3.5 Ejemplo de un Proyecto XP Típico .......................................................... 37
4 Radiadores de Información ................................................................................. 38
4.2 Tablero de Sprint .......................................................................................... 39
4.3 Diagrama de Burndown ................................................................................ 40
4.4 Tablero Kanban ............................................................................................. 42
5 Adopción de metodologías agiles ........................................................................ 48
5.1 Globalización, Cultura y Diversidad de los equipos ........................................ 49
5.2 Modelos de Toma de Decisión Participativos ................................................ 49
5.3 Errores y Aprendizaje .................................................................................... 50
5.3.1 Comportamientos Problemáticos .......................................................... 50
5.3.2 Comportamientos a Adoptar ................................................................. 51
5.3.3 Estrategia a Seguir ................................................................................. 51
5.4 Cambios de Metodología .............................................................................. 52
5.4.1 Anti-patrones de Adopción .................................................................... 52
5.4.2 Criterios de Adopción ............................................................................ 53
5.5 Modelos Híbridos.......................................................................................... 53
5.5.1 Ejemplo de Modelo Híbrido: Scrum con Kanban (Scrumban) ................. 54
5.5.2 Ejemplo de Modelo Híbrido: enfoque predictivo y Scrum ...................... 54
5.6 Nuevas Prácticas Ágiles ................................................................................. 54
6 Referencias ......................................................................................................... 56
Lo que vimos y lo que vendrá ...................................................................................... 57
Página 8
0 INTRODUCCIÓN
La capacidad de management de los individuos y la correcta ejecución de las prácticas
de gestión son un diferencial clave en cualquier organización. Sin embargo, no existe un
modelo único de gestión que asegure el éxito de cualquier proyecto.
En este curso revisaremos los principios y prácticas que son comprendidas en la gestión
ágil de proyectos, teniendo en cuenta también la certificación PMI® Agile Certified
Practitioner (ACP)®.
0.1 CONTEXTO
El enfoque ágil tiene su auge en varias metodologías nacidas en los años 90 (Extreme
Programming, Scrum, Lean) y más recientemente (Kanban). Si bien las metodologías
ágiles se basan en varias buenas prácticas anteriores y tienen cada una sus
especificidades, todas se diferencian de la gestión tradicional (predictiva) por considerar
esquemas más adaptativos.
El enfoque ágil incluye un conjunto de valores, principios y buenas prácticas con cada
vez más aceptación, aplicadas en todo tipo de organizaciones y dominios.
Página 9
0.2 TEMARIO
Unidad 01: Introducción
Introducción a las metodologías ágiles
El manifiesto ágil y sus principios
Introducción a Scrum, XP, Kanban y Lean
Radiadores de Información
Adopción de metodologías ágiles
1
http://www.standishgroup.com/
Página 12
aportan más valor al cliente a medida que se entregan las versiones del producto en
cada iteración. También permite incorporar cambios provenientes del feedback del
cliente sobre el uso real del producto (o servicio).
La gestión ágil es también conocida por otros calificativos, como por ejemplo gestión
liviana o adaptativa.
Esta mentalidad ágil se refleja en el manifiesto ágil, los principios Lean, los valores de
XP, y los pilares de Scrum, entre otros.
Para que sea exitoso el uso de las prácticas ágiles, es vital entender para qué se hace
cada práctica, sin esto es como solo tener la costra del tronco de un árbol, sin tener el
interior… Es probable que no se pueda usar con éxito en forma sostenible.
2. El objetivo de un proyecto debe ser el valor del producto para el negocio o sus
interesados más que el cumplimiento del plan.
En algunos casos puede ser más importante para el negocio que el producto se adapte
a un cambio reciente, o que contemple funcionalidades surgidas luego del inicio, antes
que terminar en fecha y/o con el presupuesto acordado.
El enfoque ágil suele tener los mejores resultados en los proyectos clasificados como
Complejos (el área naranja en el gráfico). Se puede también aplicar en proyectos de Baja
Complejidad o Simples (área verde), pero en esos casos dado el bajo nivel de riesgo e
incertidumbre, el enfoque tradicional de gestión también suele resultar efectivo. En
proyectos donde no hay acuerdos fijados y se desconoce la tecnología (área roja), no
hay tampoco una fuerte recomendación para aplicar el enfoque ágil.
Página 14
2.1 CONTEXTO
Hacia fines de los años 90, los principales impulsores de esta nueva corriente
(provenientes del mundo del desarrollo del software) idearon un encuentro para
explorar juntos las similitudes en sus distintos trabajos e identificar qué valores comunes
que querían promulgar.
Este encuentro se celebró el 12 de febrero del 2001, en Snowbird, Utah, EEUU. Allí se
juntaron 17 personas, y decidieron denominar ágil a sus propuestas, para asociarles una
noción de resultados tempranos y liviandad. En ese encuentro redactaron y firmaron el
conocido Manifiesto Ágil2, que es una declaración de valores y llamados a la acción para
el desarrollo de software.
2.2 VALORES
En el Manifiesto Ágil se presentan los 4 pilares fundamentales del agilisimo, como un
conjunto de aspectos a valorar por sobre otros:
En general la mayoría de las tareas técnicas de trabajo deben gran parte de su valor al
conocimiento y al talento de las personas que las realizan. Considerar que sólo con
procesos se pueden conseguir resultados extraordinarios sin importar las personas que
los lleven a cabo, puede llevar a problemas importantes cuando se necesita de la
creatividad constante, como ocurre en el desarrollo de software.
2
Manifiesto Ágil: http://agilemanifesto.org/ - Traducción: http://agilemanifesto.org/iso/es/
Página 16
Este valor del Manifiesto Ágil resalta la importancia de la entrega de valor para el
negocio. Muchas veces la documentación que se elaborar como parte del trabajo en
los proyectos no aporta un valor directo al negocio. El valor para el negocio se habilita
concretamente cuando se entrega un producto funcionando en un ambiente
operativo.
Es probable que se requiera generar algún tipo de documentación para lograr ese
objetivo, pero se reconoce la entrega de un producto funcionando como medida real
de avance de un proyecto. Por esta razón es fundamental mantenerlo como foco
permanente dentro del equipo de proyecto.
Adicionalmente, contar con (una porción de) software funcionando habilita a obtener
de parte de los usuarios un feedback mucho más concreto y válido, que si tuvieran que
leer alguna documentación sobre ese mismo producto (ejemplo: un documento de
especificación de requerimientos).
Las prácticas ágiles cobran particular relevancia para el desarrollo de productos difíciles
de definir con detalle desde el inicio, o cuando los requisitos son muy volátiles, por
ejemplo debido a cambios en el negocio. En tales casos suelen fracasar los esquemas de
trabajo basados en modelos contractuales cerrados, con procedimientos de gestión de
cambios muy estrictos, que en general terminan en identificar si la “culpa” de los
retrasos la tiene el proveedor o el cliente.
En el desarrollo ágil, se busca sumar al cliente como un miembro más del equipo, que
se integra y colabora diariamente en el grupo de trabajo. Se trabaja en general con un
marco contractual de alto nivel sobre el cual se construye una relación de confianza
basada en los resultados logrados.
2.3 PRINCIPIOS
Tras los cuatro valores descritos previamente, el Manifiesto Ágil presenta los siguientes
principios del agilísimo:
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del proyecto.
Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva
al cliente.
8. Los procesos ágiles promueven el desarrollo sostenible. Los sponsors, equipo del
proyecto e interesados debemos ser capaces de mantener un ritmo constante
de forma indefinida.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
Página 18
3.1 LEAN
Lean o Lean Manufacturing (manufactura esbelta) fue generado por Toyota para la
construcción de automóviles. Lean es una metodología que consta de una serie de
principios que puede aplicarse en varios ámbitos y en múltiples niveles de las
organizaciones: no solo para proyectos, sino también para contabilidad, ventas,
administración gerencial, logística, etc.
3.1.1 Conceptos
Búsqueda de calidad
Lean busca enaltecer la calidad, reduciendo los defectos en su origen, atacando los
problemas de una manera permanente. Se opone a buscar soluciones provisorias o
work-around temporales, que solo ocasionan un alivio temporal.
Cuando no se tratan las causas originarias del problema o aun peor cuando se las
desconoce, se deja lugar a eventuales problemas mayores a futuro.
Lean se basa en la generación de valor para el negocio. Existen tareas que se realizan
que aparentemente son de valor, pero no de valor para el negocio. Probablemente
generan un valor intermedio, pero que no llega a impactar en el valor final.
Por ejemplo, en la manufactura la generación de más de 4 puertas por auto para un auto
de cuatro puertas no genera un valor extra, sino que genera stock y por consiguiente
costo de almacenamiento.
Mejora continua
Lean toma la calidad como una meta móvil, ya que se sube el nivel a medida que se vaya
alcanzando. En consecuencia, la organización debe estar mejorando continuamente.
Un buen ejemplo de mejora continua es Apple, qué persigue sin parar la simplificación
del uso de sus funcionalidades.
Para simplificar, la generación de un producto suele empezar por proveer las materias
primas, contratar el personal, conseguir la maquinaria, producir el producto final y
venderlo en el mercado (sistema Push).
Lean plantea no optimizar el proceso en este orden sino al revés. Se toma en cuenta
primero la solicitud del cliente, para mirar que se requiere generar en la etapa anterior,
y así sucesivamente con cada etapa (sistema Pull).
Retrasar decisiones
Para lograr flexibilidad, se debe realizar lo necesario para poder adaptarnos a un futuro,
pero sin adelantarnos a hacer suposiciones y desarrollos, los cuales podrían realizarse
más adelante.
Por ejemplo, cuando se realiza una planificación muy detallada a largo plazo en un
proyecto de alta incertidumbre, difícilmente se puede evitar caer en múltiples re-
planificaciones, debido al alto nivel de detalle de esta y a la dificultad de poder saber
con certeza como se desarrollará el proyecto. Se podría evitar postergando la
planificación a detalle hasta que el nivel de incertidumbre haya disminuido.
Página 21
Los siete principios Lean contemplados para el desarrollo de software se pueden resumir
de la siguiente forma:
4. Optimizar el todo: ver el sistema como más que la suma de sus partes. Ver como
se alinea con la organización y mejorar la interrelación entre los equipos.
5. Construir con Calidad: incluir calidad en cada parte del proceso y no solo medir
al final con un test. Asegurar la calidad en forma continua en el proyecto.
*Libro sugerido: Lean – Agile Software development, Achiving Enterprise Agility, de Alan
Shalloway, Guy Beaver y James R. Trott.
El Value Stream Maping (Mapa de Flujo de Valor) es una técnica de Lean que es
comúnmente utilizada en las organizaciones ágiles. Está orientada a sostener el principio
de optimizar todo el proceso para generar mayor valor al negocio.
En el siguiente gráfico, se muestra un Value Stream Map, desde una etapa temprana
de recepción de mercadería de un proveedor hasta la entrega de un producto a un
cliente:
Página 23
2. Dibujar todos los pasos del proceso, con sus duraciones y sus flujos de
información. Esto es el Mapa de Flujo de Valor actual.
Los pasos para la construcción de este Mapa de Flujo de Valor son los siguientes
2. Se determinó cada uno de los procesos del flujo, y sus tiempos promedios.
También se detectaron las colas existentes en el flujo: hay una antes de
ingresar las solicitudes al proceso de desarrollo, donde quedan encoladas
esperando respuesta por 3 días. Cuando ya están desarrolladas es difícil
Página 24
contactar con el usuario para que valide la mejora. Por esta razón se tarda
aproximadamente 5 días. Las implementaciones se realizan siempre a final de
día.
5. Se desarrolló un cronograma, plan, para hacer efectivo que las decisiones del
punto 4. Se planificó la capacitación de un grupo de desarrolladores
exclusivamente para incidentes y otro para mejoras aplicativas.
3.2 SCRUM
Es el marco de trabajo más popular y utilizado en ágiles… no siempre tan bien utilizado,
no siempre logrando agilidad.
Este marco de trabajo a nuestro criterio logró gran popularidad por cubrir con las
siguientes necesidades:
1. Definir como registrar la idea que se tiene del producto a desarrollar (Backlog de
Producto)
2. Cumplir con el principio de iteraciones pequeñas de valor del manifiesto ágil
(Sprints)
3. Cubrir la necesidad de mejora continua (Retrospectivas)
4. Tratar la necesidad de adaptación diaria del equipo (Daily Meeting)
5. Ser más específico y simple qué otros marcos de trabajo. (Artefactos,
Eventos/Ceremonias, Roles, Iteraciones)
6. Definir roles haciendo un gran cambio en la forma de trabajo anterior y con esto
obligar una gran transformación. (Nuevos: Scrum Master y Product Owner
Modificado: Desarrollador tiene más responsabilidad)
7. Cubre la necesidad de indicar cómo trabajar en equipos pequeños de desarrollo
con reglas simples. (Pero que son desafiantes llevarlas a la práctica)
8. Su foco son equipos que quieren trabajar en ágiles por 1ª vez.
9. No ser pensado solo para software y con esto poder aplicar para otras industrias.
10. Y por supuesto, bien utilizado logra más valor que su antecesor (Gestión de
Proyectos Predictiva) en entornos complejos.
Se basa en 3 Pilares
1. Transparencia: todo el trabajo que se realiza y los objetivos están visibles para
todos los participantes con el fin de que puedan tener una visión completa y esto
facilitar su forma de trabajo.
2. Inspección: mirar para atrás, tomar y analizar los datos con el fin de entender
cuáles son las fortalezas y las oportunidades de mejora.
3. Adaptación: ir mejorando y mejorando de acuerdo con las necesidades y
oportunidades emergentes, tomando en cuenta cada una de las experiencias
vividas, en periodos cortos.
1. Foco: Si hubiera que resumir Scrum en una sola palabra sería foco. Foco en
clarificar el producto backlog, foco definir el objetivo de la iteración, foco en
Página 26
Cuando Jeff Sutherland creó el proceso de Scrum en el 1993, utilizó el término “scrum”
de una analogía presentada en un estudio de 1986, por Takeuchi y Nonaka3. En este
estudio se comparan equipos de alto rendimiento y multidisciplinario a la formación del
“scrum” de los equipos de rugby.
Producto
El Dueño del Producto crea una lista priorizada de requisitos llamada Backlog de
Producto.
Durante la Planificación (2-4hs), el Equipo selecciona una pequeña porción de
esta lista, un Backlog de Sprint, y decide cómo implementar estos requisitos.
3
Hirotaka Takeuchi e Ikujiro Nonaka (1986) - New New Product Development Game - Harvard Business
Review
Página 27
Este ciclo se repite hasta que el backlog de producto se haya completado, que el
presupuesto se haya gastado o que un hito definitivo haya llegado, según la
especificidad de cada proyecto.
3.2.3 Sprint
Sprint es el nombre de la iteración en Scrum. Se acuerda una duración fija para todos
los sprints, en general entre una y cuatro semanas. Los sprints se ejecutan uno tras el
otro respetando está duración, sin tiempo muerto entre el sprint que termina y el sprint
que empieza. El objetivo del sprint es de transformar un conjunto acordado de ítems del
Backlog de Producto en un Incremento de Funcionalidad de Producto Potencialmente
Entregable.
3.2.4 Roles
Scrum formaliza tres roles: el Dueño de Producto, el Scrum Master y el Equipo.
Es la voz del cliente, el que establece una visión sólida del producto a desarrollar y
prioriza continuamente los requisitos para alcanzar dicha visión.
El Scrum Master es un líder servicial para el equipo, pero también un facilitador y agente
de cambio para la aplicación adecuada de Scrum en el equipo y la organización.
3.2.7 Equipo
3.2.8 Artefactos
Scrum identifica tres artefactos o productos de trabajo: el Backlog de Producto, el
Backlog de Sprint, y el Incremento de Funcionalidad Potencialmente Entregable.
El Backlog de Producto es una lista única, pública y dinámica que recopila una secuencia
priorizada de requerimientos para el producto. Algunos de estos requerimientos tienen
una estimación de alto nivel de esfuerzo o complejidad. Se suele decir que el Backlog de
Producto representa el “Qué” esperado del producto, sin preocuparse por el “Cómo”.
3.2.9 Ceremonias
3.2.9.1 Planificación
Objetivos:
Entender y determinar el trabajo que el Equipo se compromete a terminar en el
Sprint.
Definir cómo se va a realizar este trabajo.
Objetivos:
Compartir en el equipo el avance del trabajo comprometido para el Sprint.
Coordinar las actividades del equipo para terminar el trabajo comprometido
para el Sprint.
3.2.9.3 Revisión
Objetivos:
Demostrar concretamente y claramente el progreso del equipo.
Recibir retroalimentación (feedback) periódica de los usuarios/clientes sobre los
productos/resultados generados.
3.2.9.4 Retrospectiva
Objetivos:
3.2.10.1 Time-Boxing
Por otro lado, las ceremonias del Sprint son también limitadas en el tiempo, como clara
definición de cuánto tiempo se quiere invertir en actividades de gestión en cada sprint,
aunque el resultado sea imperfecto y mejorable. Es típico que para un sprint de 2
semanas se haga una Planificación de 2h, unas Reuniones Diarias de 15 minutos, una
Revisión de 1-2h y una Retrospectiva de 1h30.
3.2.11 Conclusiones
3.3.1 Introducción
El primer proyecto XP fue iniciado en 1996, y luego XP demostró ser exitoso en múltiples
organizaciones de distintos tamaños y distintas industrias en el mundo entero. Los
fundadores de XP son Kent Beck, Ward Cunningham y Ron Jeffries.
3.3.2 Valores
Comunicación: Todos los involucrados son parte del equipo y se comunican cara a
cara diariamente. Se trabaja en conjunto en todo, desde los requerimientos hasta el
código. Se crea la mejor solución posible a los problemas en conjunto.
Respeto: Cada uno da y siente el respeto merecido por su aporte de valor como
miembro del equipo. Los desarrolladores respetan la idoneidad del cliente y
recíprocamente.
Página 33
Coraje: El equipo dice la verdad sobre el avance y las estimaciones del proyecto. No
se documentan excusas sobre las fallas porque se planifica el éxito. No hay miedos
porque se trabaja en conjunto. El equipo se adapta a los cambios de requerimientos
y de tecnologías cuando ocurren.
Las prácticas propuestas por XP son pocas y son simples de entender. Sin embargo, estas
doce prácticas tienen un muy fuerte acoplamiento entre sí y logran el mayor efecto
cuando son aplicadas en conjunto y no en forma aislada.
Evitar un equipo agotado y menos productivo, lo cual genera una fuerte baja en la
calidad del software producido, ya sea en el corto, mediano o largo plazo.
Horas extras y esfuerzos heroicos son señales de problemas mayores, como por ejemplo
compromisos por encima de las posibilidades, estimaciones pobres, falta de recursos, y
otros. Varias organizaciones aceptan convivir con este problema continuamente.
El equipo es dueño de sus propias estimaciones, suele tener más confianza para
terminar el trabajo en el tiempo comprometido.
3. Metaphor (Metáfora)
El objetivo de una metáfora es de crear un puente de entendimiento: una persona que
trata de explicar un concepto a otra intenta encontrar una referencia común a los dos
que permita representar el concepto en una forma entendible por ambos. Luego es
posible explicar el concepto usando esta referencia común como marco.
Esta práctica también se conoce como KISS, Keep It Simple Silly, y es una de las más
antiguas del desarrollo de software.
5. Refactoring
Martin Fowler define el refactoring como “el proceso de cambiar un software de tal
forma que no afecte el comportamiento externo del código pero que si permita mejorar
su estructura interna.”.
Eso significa que todo el código es producido por parejas de personas que programan
una tarea en conjunto en una sola computadora. Uno de los desarrolladores tiene el
control sobre la computadora y piensa principalmente en los detalles de la codificación.
El otro desarrollador se enfoca en un nivel más abstracto y revisa continuamente el
código que escribe el primer desarrollador. Los desarrolladores intercambian roles
periódicamente.
8. Testing (Pruebas)
XP define dos tipos de pruebas: las Pruebas de Unidad (o Pruebas Unitarias) y las
Pruebas de Aceptación.
Pruebas de Aceptación
XP indica que unas pruebas de aceptación deben ser definidas por el cliente para
asegurar que la aplicación funciona correctamente. En general las pruebas de
aceptación son pruebas de alto nivel de la aplicación, más orientadas a la operación real
del negocio. Una funcionalidad es considerada terminada cuando todos los tests de
aceptación correspondientes fueron ejecutados con éxito.
4
Por ejemplo, JUnit, NUnit, etc.
Página 36
La propiedad colectiva del código implica que cada uno es responsable de todo el código,
y también que cada uno tiene el permiso de modificar cualquier porción del código.
Con XP se integra toda la aplicación cada vez que se sube código al repositorio
compartido de código fuente. De esta forma se descubren los potenciales problemas de
integración tempranamente y se resuelven en forma gradual ni bien aparecen.
1. El cliente presenta una lista de las funcionalidades deseadas para el sistema. Cada
funcionalidad es escrita en formato de Historia de Usuario, que da un nombre a la
funcionalidad y describe brevemente el comportamiento requerido.
El primer punto de interés a mencionar es que todos los desarrolladores están ubicados
físicamente en una misma habitación, usualmente sentados alrededor de una larga
mesa en el medio de la misma.
Los equipos XP trabajan en una serie de ciclos con iteraciones fijas. Una iteración
típicamente dura entre una y cuatro semanas según el equipo, pero la duración es
siempre la misma.
Al inicio de cada iteración, el equipo se reúne con el cliente para una reunión de
planificación. En esta reunión, repasan las funcionalidades que el cliente quiere
terminadas en esta iteración, dividiendo cada funcionalidad en tareas técnicas de una
persona. Luego cada desarrollador se asigna tareas específicas y las estima. Ningún
desarrollador puede asignarse más trabajo en esta iteración que lo que terminó en la
iteración anterior.
4 RADIADORES DE INFORMACIÓN
Página 39
Esta unidad centraliza los principales indicadores visuales de las metodologías ágiles,
llamado Radiadores Visuales por la metáfora de irradiar información para todos los
involucrados.
El Tablero de Sprint suele ser el lugar elegido para los equipos para hacer la Reunión
Diaria, y permite que todo el mundo pueda hacerle cambios visibles por todo el equipo,
lo que puede ser más complicado con una aplicación digital.
Existe una línea de progreso teórico que une el esfuerzo restante al principio del sprint
con el valor de esfuerzo restante cero al final del sprint. Es el progreso teórico que un
equipo debería seguir para tener un ritmo constante y continúo para llegar a cumplir
con el sprint si las estimaciones fueran perfectas y todas las tareas identificadas.
Página 41
Cada día el Scrum Master irá marcando, para el día correspondiente, el esfuerzo
restante actualizado. El objetivo es llegar a un esfuerzo nulo antes del final del Sprint.
Si la pendiente sube, se puede ver que el esfuerzo restante está creciendo. Puede
pasar cuando se están agregando tareas no previstas, o que surgen problemas que
hacen que las tareas duran más de lo estimado.
Tener esta suma actualizada diariamente permite tener una visión muy clara del avance
del equipo, así como una forma gráfica de monitorear el ritmo del equipo y detectar
tempranamente eventuales problemas de ritmo.
Página 42
Este término suele describir una insignia trabajada de metal o de madera usada como
marca o sello. En el siglo 17 se multiplicaron estas insignias Kanban como fuertes
símbolos de identidad de las tiendas japonesas. En aquella época, se combinaban formas
complicadas, caligrafías y dibujos muy visuales para representar distintos comercios y
marcas.
Se conoce este enfoque como sistema Pull (Tirar), donde el ritmo de la demanda actual
determina el ritmo de todos los sub-procesos necesarios a la producción, a diferencia
de sistemas Push (Empujar), donde se trabaja sobre el ritmo de producción y el nivel de
stock a partir de la predicción de las ventas posibles.
Es conocido como sistema “Pull”, porque un nuevo trabajo es introducido en el sistema
(“Pulled”) únicamente cuando hay disponibilidad para procesarlo, en lugar de ser
introducido (“Pushed”) en el sistema en función de la demanda estimada.
En un sistema Kanban, se busca limitar el trabajo en curso (WIP) para asegurar un flujo
de producción continuo y optimizado, sin espera o sobreproducción que lleven a trabajo
de inventario o sobre-stock.
Página 43
Finalmente, para cerrar esta breve introducción, se puede mencionar las reglas que
propone respecto a Kanban:
Con esta regla se busca acordar entre los involucrados límites sobre la cantidad de ítems
de trabajo que pueden encararse a la vez. En el resto del documento utilizaremos el
término WIP (Work in Progress) en lugar de trabajo en curso.
● Objetivos
▪ 20% del tiempo se pierde en el cambio de contexto por tarea, con lo cual tener
menos tareas a la vez reduce esta pérdida de tiempo (según Gerald Weinberg –
Quality Software Management: Systems Thinking)
Por otro lado, el WIP limitado suele relevar cuellos de botellas en el flujo de trabajo, lo
que permite una reflexión profunda para remover o desplazar estos problemas.
Finalmente genera colaboración entre los miembros del equipo para avanzar con ítems
de trabajos problemáticos que impiden encarar nuevos ítems.
En forma general el WIP limitado genera debates sobre la forma de trabajo que lleva a
mejoras importantes.
Un límite de WIP provoca una restricción sobre cuántos ítems de trabajo pueden estar
en el mismo paso del proceso de creación de valor (en cada columna del tablero).
Únicamente cuando un ítem de trabajo progresa en el proceso, se abre un espacio para
que un nuevo ítem de trabajo pueda entrar en el paso correspondiente.
Un resultado importante de estas restricciones es que un ítem de trabajo bloqueado
detiene toda la cadena de trabajo, y puede ocurrir que no se pueda encarar un nuevo
ítem de trabajo hasta que no se haya desbloqueado este ítem problemático. Este
mecanismo suele provocar colaboración y motivación de todo el equipo para remover
rápidamente el bloqueo antes de empezar con nuevos ítems de trabajo.
Cabe aclarar que no todos los pasos del proceso de creación de valor tienen que tener
un WIP limitado, y que a veces se usa un límite de WIP para varios pasos (o columnas)
en conjunto.
Página 45
En el ejemplo siguiente de tablero Kanban, se puede observar en rojo los límites de WIP
para los distintos pasos del proceso. Por ejemplo no puede haber más de 2 ítems de
trabajo a la vez en el paso de “Test”.
Se puede consultar el Anexo One Day in Kanban Land de Henrik Knibberg para un
ejemplo animado de cómo funciona el WIP.
Antes que todo, es fundamental que todos los límites de WIP que se apliquen en el
sistema Kanban implementado sean conocidos y acordados entre todos los
involucrados. En particular es necesario que el negocio, el cliente, los usuarios, el
management, los responsables de los procesos anteriores y posteriores y todo el equipo
de desarrollo estén de acuerdo con los límites elegidos y que sepan las consecuencias y
los mecanismos que eso implica.
Definir los límites de WIP es una tarea compleja que depende de cada equipo,
organización, tipo de trabajo, etc. También, estos límites suelen calibrarse mejor a
medida que el equipo encuentra su ritmo óptimo de trabajo a través de distintas
mejoras y prueba distintos límites hasta encontrar unos convenientes. En consecuencia,
no es necesario dar demasiada importancia a la definición inicial de estos límites, sino
que, como sugerencia, puede ser mejor elegir rápidamente unos límites de WIP que
Página 46
parezcan lógicos y poner el foco en revisar periódicamente si estos límites se tienen que
ajustar (por arriba o por abajo).
Se suele utilizar un promedio de ítems en curso por cada paso del proceso de creación
con un valor de entre uno a tres por persona.
Acordar un límite de tamaño sobre la cola de entradas al sistema Kanban (la primera
columna del tablero) permite hacer foco sobre los próximos ítems de trabajo a encarar
por el equipo y en particular, genera un proceso de priorización basado en el valor para
el negocio de cada ítem. Si la cola de entrada es por ejemplo limitada a sólo dos ítems
de trabajo a la vez, el negocio/cliente/usuario va a tener que priorizar periódicamente
los dos próximos ítems que quiere ver implementados en el software. Suele simplificar
la priorización tener un límite de cola de entrada bajo, y en general provoca que el
esfuerzo periódico de priorización de los ítems sea bajo.
En esta sección repasamos algunos aspectos que suelen ser claves en la adopción de
metodologías ágiles, y que el PMI incluye en su certificación PMI-ACP.
Votación
Luego de una conversación del equipo sobre las distintas alternativas, pedir a cada
integrante que vote su preferencia entre estas. Se puede acordar la decisión por mayoría
o por pasar cierto umbral de votos. La votación puede ser anónima o no.
Alistar Cockburn, en su libro Agile Software Development: The Cooperative Game, 2nd
Edition, identifica los principales comportamientos que atentan a este principio:
Ser inconsecuentes
Cuando usamos buenas prácticas, es bastante común que perdamos la regularidad y que
las empecemos a dejar de seguir.
Ser adaptable
Mantenerse capaz de cambiar y probar nuevas ideas.
4. Observar y escuchar para aprender de los otros, ya que todos tienen algo del que
podemos aprender
Alistair Cockburn, en el libro Agile Software Development: The Cooperative Game (2nd
Edition), proporciona reflexiones muy acertadas sobre anti-patrones a evitar en el
diseño o elección de una nueva metodología:
1. Bala de Plata. Tener una sola metodología para todos los tipos de proyectos no
es factible.
5. Sin Probar. Una metodología completa creada de cero, tiene un alto riesgo de
no estar adaptada a las necesidades y de ser difícil de cumplir.
6. Usada una vez. Una metodología probada poco tiempo o en un solo caso y que
no haya funcionada muy bien, se suele abandonar sin buscar adaptarla o
entender bien sus beneficios.
Sin implementar todas las prácticas de Scrum en un entorno con un enfoque predictivo,
se puede empezar sumando algunas prácticas, como por ejemplo en aspectos de
sincronización y de mejora continua:
Retrospectivas
Si bien no hay un proceso iterativo punta a punta que pase por todas las etapas de
elaboración, puede ser de valor aprender en forma continua y tratar de mejorar. Es
típico implementar reuniones periódicas de retrospectivas, con todo el equipo para
analizar lo ocurrido por ejemplo en el último mes, y pesar juntos experimentos de
mejora a probar a corto plazo.
Si ya existe una práctica (ágil) para tratar un problema, mejora usarla, ya que esta ha
sido testeada y se sabe para qué usarla, y para qué no.
Utilizar una práctica nueva tiene similitud con la habilitación de un nuevo medicamento.
Se debe hacer pruebas en un grupo reducido durante un tiempo, analizando si
realmente es solución para lo necesitado y evaluar los eventuales efectos secundarios.
Luego de estas pruebas se podrá decidir el uso a mayor escala.
La base para seguir aplicando prácticas nuevas es realizar un ciclo de inspección,
reflexión y adaptación. Si la práctica funciona se seguirá utilizando, sino no.
Lean start-up
La idea innovadora, además de las ideas ya conocidas de Lean, es utilizar una corrección
estructurada del curso de diseño para probar una nueva hipótesis fundamental sobre el
producto, la estrategia y el motor de crecimiento del negocio. Libro sugerido: The Lean
Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically
Successful Businesses.
Real Options
Es una técnica de cálculo para la valoración de decisiones. Libro sugerido: Real Options
Analysis: Tools and Techniques for Valuing Strategic Investment and Decisions, 2nd
Edition (Wiley Finance).
Página 56
6 REFERENCIAS
Agile Software Development: The Cooperative Game – 2nd Edition – Alistair Cockburn
ISBN #0321482751
The Art of Agile Development – James Shore ISBN #0596537675
Agile Project Mangement with Scrum – Ken Schwaber ISBN #073561993X
Lean-Agile Software Development: Achieving Enterprise Agility – Alan Shallaway,
Guy Beaver, James r. Trott ISBN #0321532899
Kanban and Scrum - making the most of both – Henrik Kniberg y Mattias Skarin –
Lulu.com – 2010
Kanban: Succesfull Evolutionary Change for Your Technology Business – David J.
Anderson – Blue Hole Press – 2010
Extreme Programming Explained: Embrace Change (2nd Edition) – Kent Beck -
Addison-Wesley Professional – 2004
Página 57