Curso:
GESTIÓN ÁGIL DE PROYECTOS
Alineado con la certificación PMI-ACP
(Agile Certified Practitioner)
Página 2
Presentación:
En esta Primera Unidad, explicaremos los principales conceptos de
las Metodologías Ágiles, a través de sus prácticas, técnicas y
herramientas más difundidas y aceptadas.
Página 3
Unidad 1:
Introducción
Página 4
Objetivo:
Al terminar la Unidad los participantes:
 Se apropiarán de los principales conceptos, filosofías,
fundamentos, marcos de trabajo y herramientas de las
“metodologías ágiles”.
 Habrán conocido y asimilado los principios Lean.
 Conocerán las principales prácticas de las metodologías
ágiles.
Página 5
Temario:
1. Introducción a Metodologías Ágiles
2. Manifiesto Ágil y sus Principios
3. Introducción a Lean, Scrum, Kanban y XP
4. Radiadores de Información
5. Adopción de Metodologías Ágiles
Página 6
Temario Detallado
0
1
2
Introducción .......................................................................................................... 8
0.1
Contexto ......................................................................................................... 8
0.2
Temario .......................................................................................................... 9
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
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
3
Principios ...................................................................................................... 17
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
4
5
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
Radiadores de Información ................................................................................. 38
4.2
Tablero de Sprint .......................................................................................... 39
4.3
Diagrama de Burndown ................................................................................ 40
4.4
Tablero Kanban ............................................................................................. 42
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
6
XP (Extreme Programing) .............................................................................. 32
Nuevas Prácticas Ágiles ................................................................................. 54
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)®.
Antes que todo, veamos los objetivos principales que abordaremos
OBJETIVOS DEL CURSO
Que los participantes:
 Conozcan y estén en condiciones de aplicar las principales prácticas ágiles de
gestión de proyectos.
 Complementen su formación de gestión tradicional con metodologías ágiles.
 Conozcan la certificación propuesta por el PMI® (PMI-ACP®).
 Entiendan las restricciones, los beneficios y los contextos de aplicación de las
metodologías ágiles.
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
Unidad 02: Priorización, Planificación y Adaptación
 Priorización basada en valor
 Estimación ágil
 Planificación, monitoreo y adaptación
 Métricas
Unidad 03: Interacciones y Comunicación
 Gestión de compromisos e involucrados
 Contratos ágiles
 Comunicación ágil
 Consolidación de equipos ágiles
 Coaching ágil
Unidad 04: Calidad y Mejora Continua
 Calidad de producto
 Gestión de impedimentos y gestión de riesgos
 Retrospectivas
 Gestión de mejoras: de la persona, del equipo y de la organización
Unidad 05: Guía para la Certificación PMI-ACP
 La certificación PMI-ACP
 Conceptos generales
 Recomendaciones
 Planificación y otras consideraciones
Página 10
1 INTRODUCCIÓN A LAS METODOLOGÍAS
ÁGILES
Página 11
1.1 GESTIÓN DE PROYECTOS
“Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado único.” PMI.
Por “temporal” se refiere a que tiene un principio y un fin. El principio es cuando se
decide satisfacer a una necesidad y se inicia el proyecto. El final es cuando se cumplieron
los objetivos del proyecto, o cuando se cancela.
Otra definición interesante es la siguiente: “Secuencia única, compleja y conectada de
actividades teniendo un objetivo principal que debe ser completado en un tiempo
específico y dentro del presupuesto, y de acuerdo a una especificación” Robert K
Wysocki.
Muchos de los proyectos de desarrollo de software fracasaron, fracasan y fracasarán. En
1994 una investigación de referencia del Standish Group1 llamada Chaos Report
determinó que solo el 16% de los proyectos de TI relevados fueron exitosos (en términos
de alcance, tiempos y costos). Desde entonces a hoy, el Chaos Report presenta año a
año una importante mejora, llegando a un 30% de proyectos exitosos.
Sin embargo, esta proporción sigue resultando alarmante y motiva importantes
esfuerzos en gestión de proyectos con diversas metodologías para intentar lograr
mejorar los resultados esperados de cada proyecto. Uno de los más exitosos en este
contexto es el enfoque ágil.
1.2 DEFINICIÓN DE ENFOQUE ÁGIL
La gestión ágil tiene como meta entregar un producto o un resultado, con el mayor valor
posible para el cliente, en un tiempo dado (time-boxed).
Se emplea para ello un ciclo de desarrollo iterativo e incremental. Iterativo ya que se
sigue una secuencia de etapas cortas que terminan con la entrega de una primera
versión del producto terminada.
Se realizan entregas incrementales para reducir el riesgo y la incertidumbre. Es lo
contrario a terminar el producto y toda la funcionalidad por completo. La idea es
construir pequeñas unidades de funcionalidad y entregarlas para tener una validación
temprana.
Este ciclo se contrapone con el seguimiento de un plan pre-establecido para llegar a un
objetivo conocido, ya que permite ir descubriendo cuales son las funcionalidades que
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.
1.3 LA MENTALIDAD ÁGIL
Si bien las metodologías ágiles introducen actividades, procesos y técnicas, el enfoque
ágil requiere de un cambio de paradigma para adoptar esta nueva mentalidad ágil
además de seguir un mero proceso.
A modo de introducción a la mentalidad ágil, enumeramos algunas de las
recomendaciones más comunes al respecto:
-
Enfocar el esfuerzo en la creación de valor.
Sumar al cliente como parte del proceso.
Aceptar la incertidumbre a través de iteraciones y adaptación.
Maximizar la creatividad y la innovación invirtiendo en las personas y sus
interacciones.
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.
1.4 ENFOQUE DE GESTIÓN DE LAS METODOLOGÍAS ÁGILES
El enfoque de gestión ágil revisa fuertemente las premisas del enfoque predictivo,
adoptando otras premisas:
1. Los requerimientos de un producto o servicio cambian con el tiempo.
Durante la ejecución del proyecto pueden surgir cambios regulatorios, cambios en la
organización, la operatoria o el negocio. También suele ocurrir que a medida que se
desarrolla el producto se va entendiendo mejor la problemática y las necesidades de los
usuarios. Adicionalmente es común que durante el transcurso del proyecto los
interesados definan requerimientos que no habían sido identificadas en un principio.
Página 13
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.
3. No se construye el mejor producto en un solo intento.
En este sentido es fundamental que el equipo de trabajo tome el proyecto como un
camino de aprendizaje, donde es necesario poder tener feedback frecuente del usuario
para ir descubriendo con él cuál es la mejor forma de solucionar su problemática.
1.5 ¿CUÁNDO SI Y CUÁNDO NO?
Para describir los contextos en los cuales el enfoque ágil es más fuertemente
recomendado, se diferencian en el siguiente gráfico los tipos de proyectos
caracterizados según 2 ejes:
 Qué tanto acuerdo existe respecto a cuáles son los requerimientos a resolver
 Qué tanto dominio o certeza se tiene sobre a la tecnología a utilizar
Baja Complejidad Simple
Complejo
Baja Complejidad
Alto
Requerimientos
Nivel de acuerdo
Medio
Bajo
Anarquia/ Caos
Bajo
Medio
Alto
Tecnologia
Nivel de Certeza
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 MANIFIESTO ÁGIL Y SUS PRINCIPIOS
Página 15
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.
Desde entonces, el Manifiesto Ágil ha sido adoptado y firmado por miles de
profesionales de la industria del 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:
2.2.1 Individuos e Interacciones sobre Procesos y Herramientas
No se niega la necesidad de procesos y herramientas: los procesos ayudan al trabajo,
sirven de guía de operación. Y seguramente las herramientas mejoran la eficiencia y
soportan a los procesos. Los procesos y las herramientas deben ser una ayuda para guiar
el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al
revés. Sin personas con el conocimiento y una actitud adecuada, los procesos y las
herramientas no generan resultados.
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
2.2.2 Producto Funcionando sobre Documentación Extensiva
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).
2.2.3 Colaboración con el Cliente sobre Negociación Contractual
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.2.4 Respuesta ante el Cambio sobre Seguir un Plan
En entornos inestables, donde el cambio es continuo e imprevisible (como una gran
parte de los entornos para los que desarrollamos software), se requiere una capacidad
para la evolución rápida y continua. El seguimiento y aseguramiento de planes preestablecidos en muchos casos no permite enfrentar este desafío con éxito, y la gestión
de proyectos más predictiva y tradicional a través de planificación y control para evitar
desviaciones sobre el plan suele fracasar. La gestión ágil se enfoca en la anticipación y la
adaptación a través de mecanismos de feedback constantes, de incorporación del
cambio y de re-planificación continua.
Página 17
2.3 PRINCIPIOS
Tras los cuatro valores descritos previamente, el Manifiesto Ágil presenta los siguientes
principios del agilísimo:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y
continua de valor.
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.
3. Entregamos un producto funcionando frecuentemente, entre dos semanas y un
mes, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y el equipo de proyecto trabajamos juntos de forma
cotidiana durante todo el proyecto.
5. Los proyectos se realizan entorno a individuos motivados. Hay que darles el
entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de
proyecto y entre sus miembros es la conversación cara a cara.
7. El producto funcionando es la medida principal de progreso.
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.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores ideas, requisitos y diseños emergen de equipos auto-organizados.
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 INTRODUCCIÓN A LEAN, SCRUM, KANBAN Y
XP
Página 19
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.
Por ejemplo, en un proyecto donde hay un retraso, se puede optar sistemáticamente
por pedir al personal que realice horas extras para compensarlo. Pero si no sabe cuál fue
la causa del retraso, potencialmente se repita el problema y se requiera horas extras
durante mucho tiempo.

Valor para el negocio
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.
En la elaboración de un software se puede desarrollar funciones que reduzcan el tiempo
de operatoria más de lo perceptible por el usuario, o incluso se puede realizar
funcionalidades deseables, pero realmente no necesarias.
También se pueden automatizar procesos manuales muy pocos frecuentes o
cambiantes, los cuales conllevan un mayor costo en su desarrollo, que la sumatoria del
costo de toda la vida útil de la aplicación del proceso manual.
Página 20

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.
Se genera entonces el foco en reducir los costos, aumentar la productividad,
incrementar la satisfacción del usuario y mejorar las ventas, entre otros puntos.
Un buen ejemplo de mejora continua es Apple, qué persigue sin parar la simplificación
del uso de sus funcionalidades.

Optimización de la cadena de valor
Lean prioriza la cadena de valor en orden inverso al de la cadena de construcción.
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).
Por ejemplo, en el desarrollo de sistemas, se puede desarrollar funcionalidades en base
a demandas puntuales del momento, en vez de generar un amplio set de
funcionalidades, anticipando necesidades futuras que quizás nunca se concreten.

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 consiguiente, se basa en posponer la decisión hasta el último momento responsable,
para evitar tomar decisiones tempranas que pueden cambiar varias veces antes de
aplicarse debido al desconocimiento de situaciones futuras.
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 replanificaciones, 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

Todos participan de la mejora
La optimización de los procesos en Lean no es una tarea exclusiva de la gerencia. AL
contrario, todos deben tener una participación activa en mejorar la cadena de valor para
el negocio y entender cuál es el aporte que realizan.
En consecuencia, es necesario fomentar el respeto por cada empleado de la
organización y darle un espacio para la participación en este ciclo de mejora continua.
En muchas organizaciones se intenta tibiamente fomentar este principio, solo con
comentar vía email o algún otro medio que la gerencia apoya este tipo de participación.
Esto no es suficiente sin un espacio claro de participación, en el cual los problemas y las
propuestas de los empleados sean escuchados y atendidos.
También es fundamental contemplar la liberación de tiempo para que el empleado
pueda tratar estos temas, y establecer beneficios asociados a la mejora continua para el
empleado.
3.1.2 Los 7 Principios de Lean
Los siete principios Lean contemplados para el desarrollo de software se pueden resumir
de la siguiente forma:
1. Eliminar Desperdicios: Quitar todo lo que no añade valor: retrasos, burocracia,
funcionalidad innecesaria, entregables que no se consumen, comunicación
innecesaria.
2. Potenciar el equipo: evitar el micro-management, valorar el conocimiento
especializado del equipo y fomentar que tomen sus propias decisiones.
3. Entrega rápida: maximizar el retorno de inversión del proyecto (ROI), haciendo
entregas rápidas e iterativas que agreguen valor y permita obtener un
aprendizaje de estas.
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.
6. No adelantar decisiones: no tomar todas las decisiones de entrada o planear
todo al inicio. Retrasar las decisiones tanto como sea posible para evitar retrabajos al tomarlas por adelantado.
Página 22
7. Amplificar conocimientos: facilitar la comunicación temprana, frecuente y el
feedback tanto como se pueda.
*Libro sugerido: Lean – Agile Software development, Achiving Enterprise Agility, de Alan
Shalloway, Guy Beaver y James R. Trott.
3.1.3 Value Stream Maping
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.
Básicamente consta de dibujar todo el proceso de negocio de principio a fin y visualizar
su el flujo de información, las colas, los tiempos de cada proceso y los tiempos de espera.
Facilita la detección de desperdicios en flujo y permite la mejora de su eficiencia.
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
La técnica consta de los siguientes pasos:
1. Identificar el producto o servicio a analizar.
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.
3. Revisar la gráfica, el mapa, para detectar retrasos, desperdicios y restricciones.
4. Dibujar el mapa de valor deseado para futuro, reduciendo los retrasos,
desperdicios y restricciones.
5. Desarrollar un plan de acción para llegar al mapa futuro.
6. Realizar periódicamente una revisión del proceso para ajustarlo y optimizarlo.
Ejemplo de Análisis de Mapa de Flujo de Valor:
Para construir el ejemplo anterior se relevó el proceso de implementación de mejoras
desde la petición de la misma hasta la implementación.
Los pasos para la construcción de este Mapa de Flujo de Valor son los siguientes
1. El producto a analizar se identificó: “Mejora Aplicativa” (mejora de un sistema,
una aplicación de software, por ejemplo).
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.
3. Revisando el flujo se encontraron desperdicios en la espera para ser
desarrollada la mejora y en el tiempo de espera de ser validada por el usuario.
El tiempo de espera de 1 día para ser implementada es una restricción del
sistema que no puede ser quitada. En cambio, el tiempo que tarda el
desarrollador en tomar un tema puede ser reducido logrando que el
desarrollador no este asignado a la resolución de incidentes y con esto
reduciendo el tiempo de switch entre mejoras e incidentes. También se puede
reducir el tiempo de validación debido a lo difícil que es contactar al usuario
poniendo un tiempo fijo de 10 minutos todos los días donde el usuario se
encarga de validar.
4. Se generó el mapa de flujo de valor deseado
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.
6. Se planificó para dentro de 3 meses una nueva evaluación del flujo.
En este ejemplo se ve en forma aplicada como se utiliza el Value Stream Mapping y se
logra un aumento de la eficiencia del 15%, generando en esto una mejor repuesta para
el negocio en la implementación de mejoras aplicativas.
*Libro sugerido: Lean-Agile Software Development: Achieving Enterprise Agility – Alan
Shallaway, Guy Beaver, James r. Trott
Página 25
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.
3.2.1 Pilares y Valores
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.
Los 5 valores de Scrum que hace que de valor:
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
2.
3.
4.
5.
planificar una iteración, foco en sincronizarse diariamente, poco en obtener
feedback del producto desarrollado, y foco en mejorar continuamente.
Coraje: En tomar responsabilidades, y desafiarse a mejorar continuamente.
Apertura: en qué todos pueden expresar su opinión con el fin de mejorar y ser
más creativos.
Compromiso: de todos, de lograr el objetivo de cada sprint, y el éxito.
Respeto: Entender que todos somos limitados y merecedores de buen trato.
3.2.2 Marco de Trabajo Scrum
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.
A continuación, se presenta un diagrama y una explicación del ciclo de Scrum:
Producto


3
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.
Hirotaka Takeuchi e Ikujiro Nonaka (1986) - New New Product Development Game - Harvard Business
Review
Página 27





El equipo tiene un tiempo limitado, un Sprint (1 a 4 semanas), para terminar su
trabajo, pero se reúne cada día para constatar su progreso en la Reunión Diaria
(15 minutos).
En este camino, el Scrum Master mantiene el equipo enfocado hacía su objetivo.
Al final del sprint, el trabajo debería ser Potencialmente Entregable, o sea estar
listo para enviar a un cliente, empaquetar para su distribución o presentar a un
sponsor.
El sprint termina con una Revisión de Sprint y una Retrospectiva.
Cuando se inicia el próximo sprint, el equipo selecciona otra pequeña porción
del backlog de producto y empieza a trabajar de nuevo.
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.
3.2.5 Dueño de Producto
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.
Sus principales responsabilidades:
• Canalizar las necesidades del negocio
• Maximizar el valor para el negocio
• Inspeccionar y adaptar el producto
3.2.6 Scrum Master
Página 28
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.
Sus principales responsabilidades:
• Asegurar la correcta aplicación de Scrum.
• Eliminar los impedimentos que frenan el trabajo del equipo.
3.2.7 Equipo
El equipo es un grupo auto-organizado, multidisciplinario y con autonomía, que
desarrolla el producto. Su única responsabilidad es de transformar el Backlog de
Producto en incrementos de funcionalidad potencialmente entregable en cada sprint.
Se caracteriza también el equipo por su auto-gestión.
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.
3.2.8.1 Backlog de Producto
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.8.2 Backlog de Sprint
El Backlog de Sprint es un conjunto reducido negociado de ítems del Backlog de
Producto que el equipo se compromete a completar durante el tiempo alocado al Sprint.
Cada ítem incluido en el sprint es dividido en tareas detalladas que el equipo va a
completar, con una estimación de duración que no supere un día de esfuerzo. El Backlog
de Sprint es actualizado diariamente por el equipo, y muestra en cada momento las
tareas pendientes, en curso y terminadas para completar los ítems del sprint, así como
una estimación del esfuerzo pendiente de cada tarea no terminada y a quién está
asignada la tarea. Se suele utilizar un Tablero de Sprint como forma de visualizar el
Backlog de Sprint, o algún otro soporte herramental que permite darle visibilidad.
Página 29
3.2.8.3 Incremento de Funcionalidad Potencialmente Entregable
Al final de cada sprint el equipo debería entregar un incremento de funcionalidades del
producto con una calidad productiva. El incremento del producto debe funcionar y si
quedan tareas pendientes para su entrega, deberían requerir un esfuerzo mínimo.
3.2.9 Ceremonias
Scrum identifica cuatro ceremonias o prácticas a ejecutar en cada sprint: la Planificación,
la Reunión Diaria, la Revisión y la Retrospectiva.
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.
3.2.9.2
Reunión Diaria
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:



Escuchar distintos puntos de vista dentro del equipo sobre lo ocurrido en el
Sprint.
Identificar colaborativamente las causas de los principales problemas del equipo
durante el Sprint.
Idear, consensuar y seleccionar acciones de mejora concretas que pueda
ejecutar el equipo en el próximo Sprint.
Página 30
3.2.10 Valores Fundacionales de Scrum
En las secciones anteriores se ha presentado el marco de trabajo de Scrum, con sus
distintos roles, artefactos y ceremonias.
Es importante destacar unos mecanismos subyacentes de Scrum que se encuentran en
la mayoría de sus roles, artefactos y ceremonias y que potencian fuertemente esta
metodología:
3.2.10.1 Time-Boxing
El Time-Boxing (limitación de la duración) es muy presente en Scrum. Primero el sprint
tiene una duración fija pre-establecida a respetar, y esta duración es la que da el ritmo
al equipo. Con el paso de los sprints el equipo empieza a conocerse mejor y a saber
exactamente lo que pueden comprometer y entregar en un sprint.
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.
El time-boxing es un mecanismo que permite a su vez garantizar el foco en lo importante
y la orientación al resultado concreto.
3.2.10.2 Empirismo y Auto-Organización
En ambientes cambiantes con proyectos inestables y a veces caóticos, las metodologías
ágiles se basan en el empirismo y la auto-gestión de un equipo para encontrar y madurar
la mejor forma de trabajar e interactuar para resolver una problemática. El mecanismo
de prueba y error es entonces la base del ciclo de vida iterativo, permitiendo probar en
cada iteración si es necesario nuevas formas de trabajar e interactuar para ir refinando
un proceso de trabajo en equipo de a poco.
Scrum se basa en la auto-gestión eliminando roles de liderazgo enfocados a la asignación
y el control del equipo, simplemente porque se demuestra que las personas mejor
calificada para estimar, comprometer, definir tareas son las que las ejecutan. Es una
forma de reforzar el compromiso de los equipos y hacerlos crecer como tal.
Página 31
3.2.10.3 Mejora Continua y Retrospección
Scrum plantea varios mecanismos para recolectar feedback (a través de Revisión y
Retrospectivas), tanto sobre los productos construidos como sobre el proceso de trabajo
y sus interacciones. De esta forma, a través de un ciclo iterativo e incremental se puede
aplicar acciones concretas de mejoras al proceso y al producto.
La retrospección es el mecanismo fundamental de aprendizaje en Scrum, y se concreta
principalmente con la ceremonia de Retrospectiva. Es la ceremonia que permite
identificar acciones de mejoras, probarlas en la iteración siguiente y luego definir si
fueron exitosas o si se necesita buscar otras soluciones. Es también el mecanismo que
permite a un equipo (mientras esté abierto a la auto-crítica constructiva y tenga cierto
interés en la mejora) crecer y de poco transformarse en híper-productivo.
3.2.11 Conclusiones
Si bien Scrum fue diseñado en el contexto de proyectos de desarrollo de software, sus
prácticas son fácilmente extrapolables a otros contextos, principalmente por referirse a
la gestión de proyectos sin hacer un foco importante en prácticas más técnicas del
desarrollo. Se ha aplicado en otros tipos de proyectos como por ejemplo Mantenimiento
de Aplicación, Soporte de TI, Testing Funcional, Mejora de Procesos de TI, y también
fuera del ambiente de TI, como por ejemplo en empresas del dominio artístico o médico,
ONGs, etc.
Página 32
3.3 XP (EXTREME PROGRAMING)
En esta parte vamos a presentar la metodología ágil Extreme Programming
(Programación Extrema o XP), que aporta un enfoque más técnico en el desarrollo de
software.
3.3.1 Introducción
Extreme Programming (o XP) define un conjunto de valores, principios y prácticas para
el desarrollo rápido de software de alta calidad. XP busca maximizar el valor creado al
cliente en un plazo lo más corto posible.
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.
XP enfatiza también el trabajo colaborativo, permitiendo al equipo su auto-organización
para resolver de la mejora forma los problemas que ocurren.
3.3.2 Valores
XP está diseñado sobre la base de los siguientes valores fundacionales:

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.

Simplicidad: Se hace lo necesario y lo pedido, pero nada más. Esto permite
maximizar el valor creado para la inversión realizada hasta el momento. Se busca
hacer pequeños pasos simples hacía el objetivo final y mitigar las fallas a medida que
ocurren. Se produce un resultado que genera el orgullo del equipo y que se puede
mantener a largo plazo con costos aceptables.

Feedback: El equipo busca y consigue feedback de su producción testeando su
software desde el primer día. El equipo entrega el software al cliente lo antes posible
e implementa los cambios sugeridos.

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.
3.3.3 Resumen de las Prácticas de XP
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.
En el siguiente diagrama se pueden ver las prácticas de XP y las principales relaciones
que tienen entre sí:
3.3.4 Las prácticas de XP
1. On-site Customer (Cliente In-Situ)
Se necesita disponibilidad del cliente, no solo para ayudar el equipo de proyecto, sino
también como parte del equipo.
Todas las fases de un proyecto XP requieren comunicación e interacción con el cliente,
y preferentemente cara a cara en el mismo sitio.
2. 40 Hour Week (Semana de 40 Horas)
Página 34
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.
En XP se busca identificar una metáfora (o varias) que permita al equipo sintetizar el
diseño esencial del software en un concepto que entiendan todos. Es una herramienta
que permite eliminar los problemas de comunicación que suelen aparecer por las
diferencias de perspectivas o de background de cada uno.
4. Simple Design (Diseño Simple)
Con esta práctica, XP propone utilizar el diseño lo más simple posible que permita
cumplir con la necesidad.
Es probable que los requerimientos cambien en el futuro, con lo cual se propone hacer
únicamente lo necesario para cumplir con los requerimientos actuales, sin anticiparse a
los posibles requerimientos futuros. De esta forma el equipo se puede enfocar en
proveer valor para el negocio.
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.”.
6. Pair Programming (Programación de a Pares)
El objetivo es que todo el código fuente productivo haya sido escrito por dos
desarrolladores sentados en la misma computadora. La programación de a pares
permite que todo el código sea revisado a medida que se vaya escribiendo.
Página 35
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.
7. Short Releases (Entregas Cortas)
El objetivo de esta práctica es poder hacer entregas tempranas y frecuentes, agregando
unas pocas funcionalidades cada vez. La práctica apunta a un ciclo de vida iterativo corto
e incremental. Esto hace foco en lograr un feedback temprano.
8. Testing (Pruebas)
XP define dos tipos de pruebas: las Pruebas de Unidad (o Pruebas Unitarias) y las
Pruebas de Aceptación.
 Pruebas de Unidad (Unit Tests)
Las pruebas de unidad permiten testear la funcionalidad de pequeñas porciones de
código (por ejemplo, una clase o un método). Con XP, se usa un enfoque de TDD (Test
Driven Development = Desarrollo Dirigido por las Pruebas), donde las pruebas unitarias
son diseñadas y codificadas en un framework especifico4 antes de escribir el código
correspondiente. Este mecanismo permite motivar al desarrollador en pensar primero
en las condiciones en las cuales su futuro código podría fallar. También permite pensar
primero en la definición de la interfaz del código y del objetivo del código a construir
antes de pensar en su implementación detallada.
 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.
9. Coding Standards (Estándares de Código)
XP recomienda que cada miembro del equipo codifique con los mismos estándares.
Idealmente, no se debería poder identificar quien del equipo ha escrito una porción
específica del código solo leyéndolo (cohesión de estándar de código).
4
Por ejemplo, JUnit, NUnit, etc.
Página 36
10. Collective Ownership (Propiedad Colectiva)
El objetivo es evitar que una sola persona sea “dueña” de un módulo de la aplicación.
Se espera de todos los desarrolladores que puedan trabajar sobre cualquier porción del
código en cualquier momento.
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.
11. Continuous Integración (Integración Continua)
El objetivo es lograr que todos los cambios al código fuente sean integrados en una base
común de código por lo menos diariamente, y que sean ejecutados todos los tests
automáticos existentes antes y después de la integración.
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.
12. Planning Game (Juego de Planificación)
El objetico del Juego de Planificación es que el equipo de proyecto y el cliente cooperen
para producir el máximo valor para el negocio de la forma más rápida posible.
Suele ocurrir en una reunión al inicio de la iteración a la cual participa el equipo de
proyecto y el cliente. La dinámica es la siguiente:
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.
2. El equipo de proyecto estima cuanto esfuerzo de desarrollo es necesario para cada
Historia de Usuario. También se define el esfuerzo total que el equipo puede
producir durante la iteración. El equipo divide cada Historia de Usuario en tareas
técnicas asignables a una sola persona, que luego son estimadas por el mismo
equipo de proyecto.
3. El cliente decide que Historias de Usuario implementar y en qué orden, para
maximizar el valor creado para el negocio en función del esfuerzo disponible del
equipo de proyecto.
Página 37
3.3.5 Ejemplo de un Proyecto XP Típico
En esta sección, y a modo de repaso, describimos como se desarrolla un proyecto XP
típico:
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.
Durante el resto de la iteración, el equipo va a implementar las funcionalidades
comprometidas, trabajando de a pares sobre todo el código producido. Para toda
porción de código, los desarrolladores primero crean tests unitarios antes de escribir el
código y se integra todo el código producido una vez por día, en general al finalizar la
jornada laboral. El cliente provee tests de aceptación para validar las funcionalidades
que el equipo está desarrollando.
Al final de la iteración (usualmente un viernes), los desarrolladores entregan un software
funcionando al cliente. El software puede no estar completo, pero toda la funcionalidad
entregada funciona completamente, sin defectos. El cliente acepta la entrega, y el
equipo se va temprano a casa.
El lunes siguiente se reúnen nuevamente para planificar la iteración siguiente, y el ciclo
se repite.
* Libro sugerido: The Art of Agile Development, de Shame Shore -
Página 38
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.
4.2 TABLERO DE SPRINT
Una práctica común en Scrum, cuando todo el equipo de proyecto está colocado, es de
materializar el Backlog de Sprint a través de un tablero físico (por ejemplo, con
rotafolios, panel de corcho, pizarrón, etc.), expuesto en la sala donde trabaja el equipo.
De esta forma se logra una visibilidad importante sobre el avance del sprint para todas
las personas que están ubicados en este lugar o que pasan por la sala.
En un Tablero de Sprint, se presenta el Backlog de Sprint visualmente, usualmente con
post-its o tarjetas de cartón o papel para representar ítems y tareas del sprint, en las
cuales se registra información básica de los ítems (como por ejemplo título, estimación
de esfuerzo, prioridad, criterios de aceptación) y de las tareas (como por ejemplo tarea,
esfuerzo restante estimado, responsable). Se suele dividir el tablero en tres columnas,
con los tres estados de tareas: Pendiente, En Curso, Terminado, en las cuales se ubican
las tareas según el avance.
Finalmente se suele complementar la información del tablero con un Diagrama de
Burndown (descrito más adelante), que muestra gráficamente el esfuerzo restante del
sprint.
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.
Se puede combinar el Tablero de Sprint con un soporte herramental para el Backlog de
Sprint en caso de querer registrar alguna información adicional, tener backups, tener
parte del equipo distribuido, contar con información histórica, integrar la información
de Backlog de Sprint con otras herramientas, sacar métricas e indicadores de forma más
automáticas, etc.
A continuación, se presenta un ejemplo de Tablero de Sprint:
Página 40
4.3 DIAGRAMA DE BURNDOWN
El Diagrama de Burndown es una forma gráfica de resumir el avance de un sprint. Se
trata de registrar diariamente el esfuerzo restante para completar todos los ítems
comprometidos para el sprint en curso. Para eso, cada día se suma el esfuerzo restante
de todas las tareas en estado Pendiente y En Curso, una vez que el equipo haya
actualizado todos los esfuerzos restantes. Esta suma es la cantidad de horas necesarias
de parte del equipo para que se pueda completar el sprint.
El Diagrama de Burndown muestra en el eje X el tiempo, con un rango que representa
todos los días hasta terminar el sprint actual (por ejemplo, diez días hábiles si es un
sprint de dos semanas de duración). El eje Y representa el esfuerzo restante del equipo
para completar todos los ítems comprometidos, con una graduación en horas de
esfuerzo restante.
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.
A continuación, se muestra un ejemplo de Diagrama de Burndow:
En este ejemplo vemos un sprint de 20 días de duración, con un esfuerzo restante
estimado inicial de 190 horas. En gris se ve la línea de progreso teórico y en rojo el
registro diario del esfuerzo restante actualizado.
Un Diagrama de Burndown permite visualizar distintas situaciones:

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.

Si la pendiente es horizontal de un día al otro, quiere decir que el esfuerzo restante
no cambio de un día al otro, o sea que los eventuales avances fueron compensados
por incrementos en esfuerzos restantes estimados (nuevas tareas, complicaciones
en tareas existentes, etc.).

Si la pendiente pasa por arriba de la línea de progreso teórico, se puede interpretar
como que el equipo se esté atrasando y que no se pueda cumplir con los objetivos
del sprint siguiendo este ritmo.

Si la pendiente pasa por debajo de la línea de progreso teórico, se puede
interpretar que el equipo está avanzado más rápido que lo previsto (puede ser que
se eliminaron algunas tareas, que algunas tareas se terminaron en menos tiempo
que lo previsto, etc.).
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
4.4 TABLERO KANBAN
El término “Kanban” proviene del japonés: 看 板
▪ 看 (Kan) que se puede traducir como “visual”
▪ 板 (Ban) que se puede traducir como “insignia” o “sello”
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.
Uno de los elementos claves de KanBan es el enfoque de Push vs Pull.
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
Se logra esta limitación con dos mecanismos básicos:
1. Se utiliza un número fijo y limitado de tarjetas Kanban.
2. El proceso posterior solamente retira partes terminadas del proceso anterior
cuando las necesita.
Finalmente, para cerrar esta breve introducción, se puede mencionar las reglas que
propone respecto a Kanban:
1. El cliente (proceso posterior) retira partes en la cantidad exacta definida por el
Kanban
2. El proveedor (proceso anterior) produce partes en la cantidad exacta y secuencia
especificada por el Kanban
3. Ninguna parte es creada o movida sin un Kanban
4. Un Kanban debe acompañar cada ítem en todo momento
5. Nunca se mandan defectos o cantidades incorrectas al próximo proceso
posterior
6. La cantidad de Kanbans es reducida con precaución para limitar inventarios y
revelar problemas de flujo.
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
Limitar el WIP permite reducir el multi-tasking (trabajar en varias tareas a la vez), lo
cual tiene efectos importantes:
Página 44
▪
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)
▪
Ejecutar tareas secuencialmente genera resultados más rápido. Como lo muestra
el diagrama siguiente, haciendo multi-tasking sobre A, B y C (arriba) se entrega
A más tarde y C un poco más tarde que en forma secuencial (abajo)
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.
● ¿Qué son los límites de WIP?
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.
● Explicitar los límites de 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.
● ¿Qué límites de WIP elegir?
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.
● Limitar la cola de entradas
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.
Tablero KanBan con 3 estados (Pendiente, en Progreso, Terminado) :
Los PostIts representan ítems de trabajo
Página 47
Página 48
5 ADOPCIÓN DE METODOLOGÍAS AGILES
Página 49
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.
5.1 GLOBALIZACIÓN, CULTURA Y DIVERSIDAD DE LOS EQUIPOS
Hoy en día los equipos suelen tener integrantes de varios países. Y aunque estos hablen
el mismo idioma suele haber muchas diferencias culturales. Adicionalmente puede
haber grandes diferencias entre integrantes de una misma zona geográfica, ya que cada
uno tiene su propia formación, experiencia, cultura e historia.
Estas diferencias tienen un impacto fuerte en el equipo, ya que impactan directamente
la fluidez de sus comunicaciones.
Varias personas reconocidas de la comunidad ágil recomiendan, entre otros, buscar la
forma de trabajar cara a cara en las primeras iteraciones de un proyecto (por ejemplo,
durante 2 o 3 iteraciones). Dicho mecanismo permite lograr una experiencia
compartida, un conocimiento mutuo y una toma de conciencia de las diferencias que
seguramente será muy beneficioso a lo largo de todo el proyecto.
5.2 MODELOS DE TOMA DE DECISIÓN PARTICIPATIVOS
Es un hecho comprobado que el compromiso que tengan los participantes afecta
directamente al cumplimiento del proyecto. También está demostrado que una forma
de lograr mayor compromiso de los participantes es que sean partes de la toma de
decisión.
En el enfoque ágil de gestión de proyectos, se busca la auto-organización de los equipos,
y especialmente para la toma de decisión. En particular se suelen utilizar algunas de las
siguientes técnicas para permitir a un equipo lograr decisiones por consenso:
 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.
 Técnica del Pulgar
Adicionalmente a la técnica de votación, en esta técnica los participantes expresan su
opinión respecto a una alternativa en particular usando la posición de su pulgar:
o Pulgar por arriba: de acuerdo con la alternativa
Página 50
o Pulgar por abajo: rechazo
o Pulgar horizontal: puedo vivir con esta alternativa
Se puede tomar la decisión final por mayoría de pulgar por arriba o si no hay ningún
pulgar por abajo.
 Espectro de decisión de Jim Highsmith
En esta técnica, el foco está específicamente sobre el “pero” o las reservas que puede
tener un participante. Se busca expresar estos “peros” y valorarlos.
o A favor, sin reserva
o OK, pero con reservas
o Sentimientos mezclados: no estoy a favor, tengo reservas, pero puedo
acompañar la decisión
o En contra, con reservas fuertes que generan rechazo
 Votación por dedos
Se vota una alternativa usando de 0 a 5 dedos por cada participante (desde 0: muy en
contra a 5: muy a favor). Se cuenta el total de dedos y se toma la decisión en función de
este total.
5.3 ERRORES Y APRENDIZAJE
Un cambio de paradigma importante en el enfoque ágil tiene que ver con la relación al
error. Se trata de ver el error como una inversión que nos permite aprender y mejorar
la próxima vez. Es una premisa clave para sostener la creatividad y la innovación.
5.3.1 Comportamientos Problemáticos
Alistar Cockburn, en su libro Agile Software Development: The Cooperative Game, 2nd
Edition, identifica los principales comportamientos que atentan a este principio:
 No aceptar que los errores ocurren
Se recomienda reconocer el hecho que el error es inevitable, para estar preparado para
recuperarse lo más rápido posible y aprender de él.
 Elegir fallar conservativamente
Se basa en que es mejor malo conocido que bueno por conocer. Solemos tener
tendencia a elegir las opciones conocidas, aunque tengan problemas que explorar
nuevas opciones que potencialmente puedan generar problemas desconocidos.
Página 51
 Inventar antes que investigar
Muchas veces se tiende a reinventar la rueda en vez de investigar si ya hay algo existente
que soluciona el problema.
 Ser criaturas de hábito
Solemos quedarnos en nuestras zonas de confort, en particular cuando logramos ciertas
rutinas basadas en hábitos. A veces, al no cuestionarnos, nos perdemos la oportunidad
de mejora o la necesidad de hacer un cambio.
 Ser inconsecuentes
Cuando usamos buenas prácticas, es bastante común que perdamos la regularidad y que
las empecemos a dejar de seguir.
5.3.2 Comportamientos a Adoptar
Alistar Cockburn recomienda adoptar conscientemente los siguientes comportamientos
para remediar a estos problemas:
 Ser bueno mirando alrededor
Ser observador para poder notar cuando las cosas no caminan como es esperado.
 Ser capaz de aprender
Aprender de los errores
 Ser adaptable
Mantenerse capaz de cambiar y probar nuevas ideas.
 Enorgullecerse de que el trabajo se logre
Ser capaz de buscar lo correcto más allá que esto esté fuera de nuestro rol
5.3.3 Estrategia a Seguir
Finalmente, Alistair Cockburn propone la siguiente estrategia para cambiar los
comportamientos problemáticos:
1. Tener disciplina y tolerancia
2. Empezar corrigiendo problemas concretos y tangibles
3. Copiar y ajustar, antes que crear de cero
Página 52
4. Observar y escuchar para aprender de los otros, ya que todos tienen algo del que
podemos aprender
5. Tener concentración y comunicación, y a veces es necesario una interrupción
breve para estar bien comunicado
6. Hacer que los involucrados concuerdan con la labor a realizar
7. Elegir y conservar los talentosos
8. Dar premios que preservan la alegría, basados en la motivación de la autoestima,
el orgullo de la labor lograda, y valorando los esfuerzos extras
9. Combinar premios, para lograr un sistema de recompensas que combine lo
laboral con los intereses personales
10. Dar y recibir feedback constantemente
*Libro recomendado: Alistar Cockburn - Agile Software Development: The Cooperative
Game, 2nd Edition.
5.4 CAMBIOS DE METODOLOGÍA
5.4.1 Anti-patrones de Adopción
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.
2. Intolerancia. Si la metodología es demasiado estricta como para poder seguirla,
no va a funcionar.
3. Pesada. Si se requiere mucho más esfuerzo en el uso de la metodología que en
el trabajo en sí, es probable que tampoco funcione.
4. Embellecida. Cuando se agregan a la metodología algunos “debería” y “podría”
sobre tareas adicionales o segundarias a realizar, probablemente sean costosos
en valor y/o tiempo, si aportar demasiado.
Página 53
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.
5.4.2 Criterios de Adopción
En el diseño o la adaptación de una metodología a adoptar, se recomiendo considerar
los siguientes criterios:
1. El canal más rápido de comunicación para intercambiar información es cara a
cara.
2. El exceso de metodología tiene un impacto negativo.
3. A grandes equipos, grandes metodologías: se debe documentar más cuando hay
mayor cantidad de temas y se corren riesgos al no ser comunicados a todos.
4. A proyectos críticos, mejores prácticas: se requiere ejecutar la metodología con
más rigurosidad en estos proyectos en los cuales un fallo puede ser catastrófico.
5. Incrementar el feedback y la comunicación reduce la necesidad de entregables
intermedios.
6. El conocimiento es intangible: no se puede tocar ni ver. La documentación se
puede ver, pero que haya documentación no implica que haya conocimiento.
7. Los cargos formales y las habilidades no necesariamente están relacionados unos
con los otros.
8. La eficiencia puede ser secundaria en actividades que no sean cuello de botella.
Conviene enfocarse en la eficiencia de las actividades más críticas.
*Libro recomendado: Alistar Cockburn - Agile Software Development: The Cooperative
Game, 2nd Edition.
5.5 MODELOS HÍBRIDOS
Página 54
Han emergidos múltiples modelos híbridos en cuanto al uso de metodologías ágiles. Un
modelo híbrido combina varias prácticas provenientes de distintas metodologías, que
pueden ser ágiles o no.
Es importante tener un nivel de conocimiento y experiencia con las metodologías a
combinar para lograr el éxito manteniendo la simplicidad y efectividad de las prácticas
elegidas.
5.5.1 Ejemplo de Modelo Híbrido: Scrum con Kanban (Scrumban)
Este modelo híbrido ha sido ampliamente probado en la comunidad ágil.
Una vez implementado Scrum se puede migrar parcialmente a Kanban, básicamente
transformando el tablero para que represente el flujo de trabajo, agregando el límite de
Trabajo en Progreso y luego optimizando el flujo. El otro agregado para lograr esto es
implementar los indicadores de Kanban.
5.5.2 Ejemplo de Modelo Híbrido: enfoque predictivo y Scrum
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:
 Reuniones Diarias de Sincronización
Pese a no tener iteraciones y a tener un plan ya fijado para todo el proyecto, suele ser
de valor tener una reunión diaria de sincronización (Scrum) donde todos los miembros
del equipo sincronizan sus tareas, y piden ayuda si tienen dificultades o impedimentos
para avanzar.
 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.
5.6 NUEVAS PRÁCTICAS ÁGILES
El ritmo con el cuál un equipo o una organización puede incorporar nuevas prácticas es
limitado, como la cantidad de agua que puede absorber una planta. La recomendación
en estos casos es simple: no reinventar la rueda... si no se necesita.
Página 55
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.
El compromiso de PMI para la certificación PMI-ACP es actualizar anualmente el alcance
del examen con nuevas prácticas que han sido ampliamente reconocidas.
Las metodologías ágiles actuales incluidas en la certificación PMI-ACP son:
 Scrum
 Extreme Programming (XP)
 Feature-Driven Development (FDD)
 Dynamic Systems Development Method (DSDM)
 Cristal Family
 Lean
 Kanban
Actualmente se está analizando incorporar:
 Behavior driven development
Es una extensión de Test Driven Development que incorpora los intereses del negocio
con una visión técnica, con distintas herramientas automatizadas de soporte. Libro
sugerido: The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and
Friends.
 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
LO QUE VIMOS Y LO QUE VENDRÁ
En esta unidad introducimos los principales principios,
prácticas, técnicas que se suelen usar en las metodologías
ágiles.
En las próximas unidades nos enfocaremos en priorizar,
estimar, planificar, monitorear y adaptar un proyecto de
desarrollo.