Curso:

GESTIN GIL DE PROYECTOS

Alineado con la certificacin PMI-ACP
(Agile Certified Practitioner)
 Pgina 2

Presentacin:

En esta Primera Unidad, explicaremos los principales conceptos de

las Metodologas giles, a travs de sus prcticas, tcnicas y
herramientas ms difundidas y aceptadas.
 Pgina 3

Unidad 1:

Introduccin
 Pgina 4

Objetivo:

Al terminar la Unidad los participantes:

Se apropiarn de los principales conceptos, filosofas,

fundamentos, marcos de trabajo y herramientas de las
metodologas giles.

Habrn conocido y asimilado los principios Lean.

Conocern las principales prcticas de las metodologas

giles.
 Pgina 5

Temario:

1. Introduccin a Metodologas giles

2. Manifiesto gil y sus Principios

3. Introduccin a Lean, Scrum, Kanban y XP

4. Radiadores de Informacin

5. Adopcin de Metodologas giles

 Pgina 6

Temario Detallado
0 Introduccin ............................................................................................................. 8
0.1 Contexto............................................................................................................. 8
0.2 Temario .............................................................................................................. 9
1 Introduccin a las metodologas giles .................................................................. 10
1.1 Gestin de Proyectos ....................................................................................... 11
1.2 Definicin de Metodologas giles .................................................................. 11
1.3 La Mentalidad gil ........................................................................................... 12
1.4 Enfoque de Gestin de las Metodologas giles ............................................. 12
1.5 Cundo Si y Cundo 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 Documentacin Extensiva ........................ 16
2.2.3 Colaboracin con el Cliente sobre Negociacin Contractual ................... 16
2.2.4 Respuesta ante el Cambio sobre Seguir un Plan ...................................... 16
2.3 Principios .......................................................................................................... 17
3 Introduccin a Lean, Kanban, Scrum 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 El marco de trabajo .................................................................................. 26
3.2.3 Sprint ........................................................................................................ 27
3.2.4 Roles ......................................................................................................... 27
3.2.5 Artefactos ................................................................................................. 27
3.2.6 Ceremonias ............................................................................................... 28
3.2.7 Conclusiones ............................................................................................. 29
3.3 Kanban ............................................................................................................. 30
 Pgina 7

3.3.1 Orgenes .................................................................................................... 30

3.3.2 Las 3 Reglas de Kanban............................................................................. 31
3.3.3 Mtricas Kanban ....................................................................................... 33
3.4 XP (Extreme Programing)................................................................................. 34
3.4.1 Introduccin ............................................................................................. 34
3.4.2 Valores ...................................................................................................... 34
3.4.3 Resumen de las Prcticas de XP ............................................................... 35
3.4.4 Las prcticas de XP.................................................................................... 35
3.4.5 Ejemplo de un Proyecto XP Tpico ............................................................ 39
4 Radiadores de Informacin .................................................................................... 40
4.2 Tablero de Sprint.............................................................................................. 41
4.3 Diagrama de Burndown ................................................................................... 42
4.4 Tablero Kanban ................................................................................................ 44
4.5 Diagrama de Flujo Acumulado ......................................................................... 45
4.6 Control de Lmites ............................................................................................ 46
5 Adopcin de metodologas agiles........................................................................... 48
5.1 Globalizacin, Cultura y Diversidad de los equipos ......................................... 49
5.2 Modelos de Toma de Decisin Participativos .................................................. 49
5.3 Errores y Aprendizaje ....................................................................................... 50
5.3.1 Comportamientos Problemticos ............................................................ 50
5.3.2 Comportamientos a Adoptar .................................................................... 51
5.3.3 Estrategia a Seguir .................................................................................... 51
5.4 Cambios de Metodologa ................................................................................. 52
5.4.1 Anti-patrones de Adopcin ...................................................................... 52
5.4.2 Criterios de Adopcin ............................................................................... 53
5.5 Modelos Hbridos ............................................................................................. 53
5.5.1 Ejemplo de Modelo Hbrido: Scrum con Kanban (Scrumban) .................. 54
5.5.2 Ejemplo de Modelo Hbrido: enfoque predictivo y Scrum ....................... 54
5.6 Nuevas Prcticas giles.................................................................................... 54
6 Referencias ............................................................................................................. 56
Lo que vimos y lo que vendr ......................................................................................... 57
 Pgina 8

0 INTRODUCCIN
La capacidad de management de los individuos y la correcta ejecucin de las prcticas
de gestin son un diferencial clave en cualquier organizacin. Sin embargo, no existe un
modelo nico de gestin que asegure el xito de cualquier proyecto.

En este curso revisaremos los principios y prcticas que son comprendidas en la gestin
gil de proyectos, teniendo en cuenta tambin la certificacin PMI Agile Certified
Practitioner (ACP).

Antes que todo, veamos los objetivos principales que abordaremos

OBJETIVOS DEL CURSO

Que los participantes:
Conozcan y estn en condiciones de aplicar las principales prcticas giles de
gestin de proyecto.
Conozcan la certificacin propuesta por el PMI (PMI-ACP).
Entiendan las restricciones, los beneficios y los contextos de aplicacin de las
metodologas giles.

0.1 CONTEXTO
El enfoque gil tiene su auge en varias metodologas nacidas en los aos 90 (Extreme
Programming, Scrum, Lean) o ms recientemente (Kanban). Si bien las metodologas
giles se basan en varias buenas prcticas anteriores y tienen cada una sus
especificidades, todas se diferencian de la gestin tradicional (predictiva) por considerar
esquemas ms adaptativos.

Las metodologas giles son un conjunto de buenas prcticas con cada vez ms
aceptacin, siendo empleadas y aplicadas en todo tipo de organizaciones y dominios.
 Pgina 9

0.2 TEMARIO
Unidad 01: Introduccin
Introduccin a las metodologas giles
El manifiesto gil y sus principios
Introduccin a Scrum, XP, Kanban y Lean
Radiadores de Informacin
Adopcin de metodologas giles

Unidad 02: Priorizacin, Planificacin y Adaptacin

Priorizacin basada en valor
Estimacin gil
Planificacin, monitoreo y adaptacin
Mtricas

Unidad 03: Interacciones y Comunicacin

Gestin de compromisos e involucrados
Contratos giles
Mecanismos de comunicacin
Formacin y consolidacin de equipos giles
Coaching gil

Unidad 04: Calidad y Mejora Continua

Calidad de producto
Gestin de impedimentos y gestin de riesgos
Retrospectivas
Gestin de mejoras: de la persona, del equipo y de la organizacin

Unidad 05: Gua para la Certificacin PMI-ACP

La certificacin PMI-ACP
Conceptos generales
Recomendaciones
Planificacin y otras consideraciones
 Pgina 10

1 INTRODUCCIN A LAS METODOLOGAS

GILES
 Pgina 11

1.1 GESTIN 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 definicin interesante es la siguiente: Secuencia nica, compleja y conectada de

actividades teniendo un objetivo principal que debe ser completado en un tiempo
especfico y dentro del presupuesto y de acuerdo a una especificacin Robert K Wysocki

Muchos de los proyectos de desarrollo de software fracasaron, fracasan y fracasarn. En

1994 una investigacin de referencia del Standish Group1 llamada Chaos Report
determino que solo el 16% de los proyectos de TI relevados fueron exitosos (en termino
de alcance, tiempos y costos). Desde entonces a hoy el Chaos Report presenta ao a ao
una importante mejora, llegando a un 30% de proyectos exitosos.

Sin embargo, esta proporcin sigue resultando alarmante y motiva importantes

esfuerzos en gestin de proyectos con diversas metodologas para intentar lograr mejor
los resultados esperados de cada proyecto. Unas de las ms exitosas en este contexto
son las metodologas giles.

1.2 DEFINICIN DE METODOLOGAS GILES

La gestin 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 vida iterativo e incremental. Iterativo ya que se sigue
una secuencia de etapas cortas que terminan con la entrega de una porcin del producto
terminada o un resultado parcial alcanzado.

Se realizan entregas incrementales para reducir el riesgo y la incertidumbre. Es lo

contrario a terminar el producto y toda la funcionalidad antes de validarla por completo
con el cliente o con los responsables. La idea es definir pequeas unidades de
funcionalidad y entregarlas para tener una validacin 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
aportan ms valor al cliente a medida que se entregan las porciones del producto en

1
http://www.standishgroup.com/
 Pgina 12

cada iteracin. Tambin permite incorporar cambios provenientes del feedback del
cliente sobre el uso real del producto (o servicio).

La gestin gil es tambin conocida por otros calificativos, como por ejemplo gestin
liviana o adaptativa.

1.3 LA MENTALIDAD GIL

Si bien las metodologas giles introducen actividades, procesos y tcnicas, el enfoque
gil requiere de un cambio de paradigma para adoptar esta nueva mentalidad gil
adems de seguir un mero proceso.

A modo de introduccin a la mentalidad gil, enumeramos algunas de las

recomendaciones ms comunes al respecto:

- Enfocar el esfuerzo en la creacin de valor.

- Sumar al cliente como parte del proceso.
- Aceptar la incertidumbre a travs de iteraciones y adaptacin.
- Maximizar la creatividad y la innovacin 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 prcticas giles, es vital entender para qu se hace
cada prctica, 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 GESTIN DE LAS METODOLOGAS GILES

El enfoque de gestin gil revisita fuertemente las premisas del enfoque predictivo,
adoptando otras premisas:

1. Los requerimientos de un producto o servicio cambian con el tiempo.

Durante la ejecucin del proyecto pueden surgir cambios regulatorios, cambios en la

organizacin, la operatoria o el negocio. Tambin suele ocurrir que a medida que se
desarrolla el producto se va entendiendo mejor la problemtica y la necesidad de la
organizacin. Adicionalmente es comn que los interesados definan mejoras que no
haban identificadas de antemano.
 Pgina 13

2. El objetivo de un proyecto debe ser el valor del producto para el negocio o sus
interesados ms que el cumplimiento del plan.

En algunos casos puede ser ms importante para el negocio que el producto se adapte
a un cambio reciente o que se agreguen algunas funcionalidades importantes que se
propusieron en el medio del proyecto, en lugar de terminar en fecha y con el
presupuesto acordado.

3. No se construye el mejor producto con 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, cual es la mejor forma de solucionar su problemtica.

1.5 CUNDO SI Y CUNDO NO?

Alto Baja Complejidad Simple

Requerimientos Medio Complejo Baja Complejidad
Nivel de acuerdo Bajo Anarquia/ Caos
Bajo Medio Alto
Tecnologia
Nivel de Certeza

El enfoque gil suele tener los mejores resultados en la zona naranja de los proyectos
complejos. Se puede utilizar tambin en proyectos de baja complejidad o simples (zona
verde), pero puede ser ms conveniente seguir un enfoque tradicional. En proyectos
donde no hay acuerdos fijados y se desconoce la tecnologa (zona roja), no hay garanta
de resultados con el enfoque gil.
 Pgina 14

2 MANIFIESTO GIL Y SUS PRINCIPIOS

 Pgina 15

2.1 CONTEXTO
Los principales pensadores de esta nueva corriente idearon un encuentro para explorar
juntos las similitudes en sus distintos trabajos y definir valores comunes que queran
promulgar.

Este encuentro se celebr el 12 de febrero del 2001, en Snowbird, Utah, EEUU, en el

cual se juntaron 17 personas, y decidieron asociar el adjetivo gil a sus metodologas,
para asociarles una nocin de resultados rpidos y liviandad. Tambin crearon y
firmaron el conocido Manifiesto gil2, declaracin de valores para el desarrollo de
software.

Dicho Manifiesto gil fue adoptado y firmado formalmente por miles de profesionales
de la industria del software.

2.2 VALORES
En el Manifiesto gil se presentan los 4 pilares fundamentales del agilsimo, 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 gua de operacin. 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 organizacin, a los equipos y a las personas; y no al
revs. Sin personas con el conocimiento y una actitud adecuada, los procesos y las
herramientas no generan resultados.

En general la mayora de las tareas tcnicas de trabajo deben gran parte de su valor al
conocimiento y al talento de las personas que las realizan. Considerar que con procesos
se pueden conseguir resultados extraordinarios con personas mediocres puede llevar a
problemas importantes cuando los trabajos necesitan de creatividad constante como en
el desarrollo moderno de software.

2
Manifiesto gil: http://agilemanifesto.org/ - Traduccin: http://agilemanifesto.org/iso/es/
 Pgina 16

2.2.2 Producto Funcionando sobre Documentacin Extensiva

La perspectiva subyacente al Manifiesto gil establece el xito desde el punto de vista

de la entrega de valor para el negocio. Conceptualmente la documentacin que se
suele elaborar en los proyectos no aporta valor directo al negocio. El valor para el
negocio se habilita nicamente cuando se entrega un producto funcionando en un
ambiente operativo.

Es probable que se requiera alguna documentacin para poder llegar a este objetivo,
pero el Manifiesto gil reconoce que al fin y al cabo la nica medida real de avance de
un proyecto es la entrega de un producto funcionando, y por esta razn tiene que ser
el objetivo permanente de cualquier equipo de proyecto.

Adicionalmente ver un software funcionando facilita fuertemente el feedback del

cliente o futuro cliente en comparacin con la lectura de un documento de
especificacin de requerimientos, por ejemplo.

2.2.3 Colaboracin con el Cliente sobre Negociacin Contractual

Las prcticas giles cobran particular relevancia para el desarrollo de productos difciles
de definir con detalle en el principio, o cuando los requisitos suelen ser muy voltiles
por los cambios en el entorno de negocio. En tales casos suelen fracasar las gestiones
basadas en modelos contractuales cerrados con procedimientos de gestin de cambios
muy definidos 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 ms 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 relacin 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, se requiere una

capacidad para la evolucin rpida y continua. El seguimiento y aseguramiento de
planes pre-establecidos en muchos casos no permite enfrentar este desafo con xito, y
la gestin de proyectos ms predictiva y tradicional a travs de planificacin y control
para evitar desviaciones sobre el plan suele fracasar. La gestin gil se enfoca en la
anticipacin y la adaptacin a travs de mecanismos de feedback constantes, de
incorporacin del cambio y de re-planificacin continua.
 Pgina 17

2.3 PRINCIPIOS
Tras los cuatro valores descritos previamente, el Manifiesto gil presenta los siguientes
principios del agilsimo:

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 tardas 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 ms 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 ejecucin del trabajo.

6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de

proyecto y entre sus miembros es la conversacin 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 atencin continua a la excelencia tcnica y al buen diseo 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 diseos emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a
continuacin ajustar y perfeccionar su comportamiento en consecuencia.
 Pgina 18

3 INTRODUCCIN A LEAN, KANBAN, SCRUM Y

XP
 Pgina 19

3.1 LEAN
Lean o Lean Manufacturing (manufactura esbelta) fue generado por Toyota para la
construccin de automviles. Lean es una metodologa que consta de una serie de
principios que puede aplicarse en varios mbitos y en mltiples niveles de las
organizaciones: no solo para proyectos, sino tambin para contabilidad, ventas,
administracin gerencial, logstica, etc.

3.1.1 Conceptos

Bsqueda 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 sistemticamente

por pedir al personal que realice horas extras para compensarlo. Pero si no sabe cul 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 generacin 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 generacin de ms 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 elaboracin de un software se puede desarrollar funciones que reduzcan el tiempo

de operatoria ms de lo perceptible por el usuario, o incluso se puede realizar
funcionalidades deseables, pero realmente no necesarias.

Tambin 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 aplicacin del proceso manual.
 Pgina 20

Mejora continua

Lean toma la calidad como una meta mvil, ya que se sube el nivel a medida que se vaya
alcanzando. En consecuencia, la organizacin debe estar mejorando continuamente.

Se genera entonces el foco en reducir los costos, aumentar la productividad,

incrementar la satisfaccin del usuario y mejorar las ventas, entre otros puntos.

Un buen ejemplo de mejora continua es Apple, qu persigue sin parar la simplificacin

del uso de sus funcionalidades.

Optimizacin de la cadena de valor

Lean prioriza la cadena de valor en orden inverso al de la cadena de construccin.

Para simplificar, la generacin 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 revs. 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 quizs 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 podran realizarse
ms adelante.

Por consiguiente, se basa en posponer la decisin 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 planificacin muy detallada a largo plazo en un
proyecto de alta incertidumbre, difcilmente se puede evitar caer en mltiples 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 podra evitar postergando la
planificacin a detalle hasta que el nivel de incertidumbre haya disminuido.
 Pgina 21

Todos participan de la mejora

La optimizacin de los procesos en Lean no es una tarea exclusiva de la gerencia. AL

contrario, todos deben tener una participacin activa en mejorar la cadena de valor para
el negocio y entender cul es el aporte que realizan.

En consecuencia, es necesario fomentar el respeto por cada empleado de la

organizacin y darle un espacio para la participacin en este ciclo de mejora continua.
En muchas organizaciones se intenta tibiamente fomentar este principio, solo con
comentar va email o algn otro medio que la gerencia apoya este tipo de participacin.
Esto no es suficiente sin un espacio claro de participacin, en el cual los problemas y las
propuestas de los empleados sean escuchados y atendidos.

Tambin es fundamental contemplar la liberacin 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 aade valor: retrasos, burocracia,

funcionalidad innecesaria, entregables que no se consumen, comunicacin
innecesaria.

2. Potenciar el equipo: evitar el micro-management, valorar el conocimiento

especializado del equipo y fomentar que tomen sus propias decisiones.

3. Entrega rpida: maximizar el retorno de inversin del proyecto (ROI), haciendo

entregas rpidas e iterativas que agreguen valor y permita obtener un
aprendizaje de estas.

4. Optimizar el todo: ver el sistema como ms que la suma de sus partes. Ver como
se alinea con la organizacin y mejorar la interrelacin 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 re-
trabajos al tomarlas por adelantado.
 Pgina 22

7. Amplificar conocimientos: facilitar la comunicacin 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 tcnica de Lean que es
comnmente utilizada en las organizaciones giles. Est orientada a sostener el principio
de optimizar todo el proceso para generar mayor valor al negocio.

Bsicamente consta de dibujar todo el proceso de negocio de principio a fin y visualizar

su el flujo de informacin, las colas, los tiempos de cada proceso y los tiempos de espera.
Facilita la deteccin de desperdicios en flujo y permite la mejora de su eficiencia.

En el siguiente grfico, se muestra un Value Stream Map, desde una etapa temprana
de recepcin de mercadera de un proveedor hasta la entrega de un producto a un
cliente:
 Pgina 23

La tcnica 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
informacin. Esto es el Mapa de Flujo de Valor actual.

3. Revisar la grfica, 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 accin para llegar al mapa futuro.

6. Realizar peridicamente una revisin del proceso para ajustarlo y optimizarlo.

Ejemplo de Anlisis de Mapa de Flujo de Valor:

Para construir el ejemplo anterior se relev el proceso de implementacin de mejoras

desde la peticin de la misma hasta la implementacin.

Los pasos para la construccin de este Mapa de Flujo de Valor son los siguientes

1. El producto a analizar se identific: Mejora Aplicativa (mejora de un sistema,

una aplicacin de software, por ejemplo).

2. Se determin cada uno de los procesos del flujo, y sus tiempos promedios.
Tambin 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 das. Cuando ya estn desarrolladas es difcil
 Pgina 24

contactar con el usuario para que valide la mejora. Por esta razn se tarda
aproximadamente 5 das. Las implementaciones se realizan siempre a final de
da.

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 da para ser implementada es una restriccin 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 resolucin de incidentes y con esto
reduciendo el tiempo de switch entre mejoras e incidentes. Tambin se puede
reducir el tiempo de validacin debido a lo difcil que es contactar al usuario
poniendo un tiempo fijo de 10 minutos todos los das 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 capacitacin de un grupo de desarrolladores
exclusivamente para incidentes y otro para mejoras aplicativas.

6. Se planific para dentro de 3 meses una nueva evaluacin 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 implementacin de mejoras aplicativas.

*Libro sugerido: Lean-Agile Software Development: Achieving Enterprise Agility Alan

Shallaway, Guy Beaver, James r. Trott
 Pgina 25

3.2 SCRUM
Scrum utiliza un proceso iterativo e incremental donde se ejecutan iteraciones de
duracin corta, manteniendo a un ritmo parejo en el paso por la planificacin, la
ejecucin y la reflexin sobre lo ocurrido.

3.2.1 Pilares y Valores

Scrum se basa en tres pilares: transparencia, inspeccin, y adaptacin:

Transparencia: dar visibilidad de todos los aspectos importantes del trabajo a

todos los involucrados.

Inspeccin: revisar constantemente cmo el proyecto est progresando de

acuerdo a los objetivos.

Adaptacin: ajustar el proceso de elaboracin en funcin de los resultados y el

feedback de la inspeccin para lograr los mejores resultados.

Los valores de Scrum son:

Foco: Los equipos Scrum se enfocan en un conjunto acotado

de caractersticas por vez. Esto permite que al final de cada iteracin se entregue
un producto de alta calidad y adicional mente se reduce el time-to-market.

Coraje: Debido a que los equipos Scrum trabajan como verdaderos equipos nos
apoyamos entre compaeros para as asumir compromisos desafiantes.

Apertura: Nos permite una discusin abierta de los problemas que tenemos al
realizar el proyecto, la informacin est disponible para todos.

Compromiso: Cada integrante del equipo debe tener un compromiso para lograr
el xito del grupo.

Respeto: Ya que el grupo trabaja en forma conjunta compartiendo xitos y

fracasos se fomenta el respeto mutuo.
 Pgina 26

3.2.2 El marco de trabajo

Cuando Jeff Sutherland creo el marco de Scrum en 1993, utilizo el trmino scrum por
una analoga presentada en un estudio de 1986, por Takeuchi y Nonaka3. En este estudio
se compara equipos de alto rendimiento y multidisciplinario a la formacin del scrum
de los equipos de rugby.

A continuacin, se presenta un diagrama y una explicacin resumidos del ciclo de Scrum:

24
horas

Incremento de
1a4 Funcionalidad
Backlog de Backlog semanas Potencialmente
Producto de Entregable
Sprint

Ciclo Iterativo e Incremental de Scrum

Cascada

Un Dueo del Producto crea una lista priorizada de requisitos llamada Backlog
de Producto.
Durante la Planificacin del Sprint4, el Equipo selecciona una pequea porcin
de esta lista, un Backlog de Sprint, y decide cmo implementar estos requisitos.
El equipo tiene un tiempo limitado, un Sprint (1 a 4 semanas), para terminar su
trabajo, pero se rene cada da para constatar su progreso (Reunin Diaria de
15 minutos).
En este camino, el Scrum Master mantiene el equipo enfocado haca su objetivo.
Al final del sprint, el trabajo debera ser Potencialmente Entregable, o sea estar
listo para enviar a un cliente, empaquetar para su distribucin o presentar a un
sponsor.
El sprint termina con una Revisin de Sprint y una Retrospectiva.
Cuando se inicia el prximo sprint, el equipo selecciona otra pequea porcin
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 deadline haya llegado, segn la especificidad de
cada proyecto. No importa lo que genera el fin del trabajo, Scrum asegura que se haya
terminado el proyecto de mayor valor al final del proyecto.

3
Hirotaka Takeuchi e Ikujiro Nonaka (1986) - New Product Development Game - Harvard Business Review
4
La iteracin en Scrum se denomina Sprint
 Pgina 27

3.2.3 Sprint

Sprint es el nombre de la iteracin en Scrum. Se acuerda una duracin fija para todos
los sprints, en general entre una y cuatro semanas. Los sprints se ejecutan uno tras el
otro respetando est duracin, 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 Dueo de Proyecto, el Scrum Master y el Equipo.

Dueo de Producto
Es la voz del cliente, el que establece una visin slida del producto a desarrollar y
prioriza continuamente los requisitos para alcanzar dicha visin.

Sus responsabilidades:
canalizar las necesidades del negocio
maximizar el valor para el negocio
inspeccionar y adaptar el producto

Scrum Master
El Scrum Master es un lder servicial para el equipo, pero tambin un facilitador y agente
de cambio para la aplicacin adecuada de Scrum en el equipo y la organizacin.

Sus responsabilidades:
asegurar la correcta aplicacin de Scrum.
eliminar los impedimentos que frenan el trabajo del equipo.

Equipo
El equipo es un grupo auto-organizados, multidisciplinario y con autonoma, 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 tambin el equipo por su auto-gestin.

3.2.5 Artefactos

Scrum identifica tres artefactos o productos de trabajo: el Backlog de Producto, el

Backlog de Sprint, y el Incremento de Funcionalidad Potencialmente Entregable.
 Pgina 28

Backlog de Producto
El Backlog de Producto es una lista nica, pblica y dinmica que recopila una secuencia
priorizada de requerimientos para el producto. Algunos de estos requerimientos tienen
una estimacin 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 Cmo.

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 estimacin de duracin que no supere un da 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 estimacin del esfuerzo pendiente de cada tarea no terminada y a quin est
asignada la tarea. Se suele utilizar un Tablero de Sprint como forma de visualizar el
Backlog de Sprint, o algn otro soporte herramental que permite darle visibilidad.

Incremento de Funcionalidad de Producto Potencialmente Entregable

Al final de cada sprint el equipo debera haber entregado un incremento de
funcionalidades del producto al sistema con una calidad productiva. El incremento del
producto debe lograrse funcionando y debera poder entregarse con un esfuerzo
mnimo si fuera necesario.

3.2.6 Ceremonias

Scrum identifica cuatro ceremonias o prcticas a ejecutar en cada sprint: la Planificacin,

la Reunin Diaria, la Revisin y la Retrospectiva.

Planificacin
Objetivos:
Que el Equipo entienda los tems ms prioritarios del Backlog de
Producto
Que el Equipo y el Dueo de Producto acuerdan el conjunto de tems del
Backlog de Producto que se van a desarrollar durante el prximo sprint
Que el Equipo de defina las tareas requeridas para construir las
funcionalidades acordadas durante el prximo sprint

Reunin Diaria (de sincronizacin)

Objetivos: Que los miembros del Equipo sincronicen sus tareas, pidan ayuda al equipo
y/o al Scrum Master si tienen dificultades o impedimentos para avanzar.
 Pgina 29

Revisin
La Reunin de Revisin tiene los siguientes objetivos:
Que los interesados en el producto puedan visualizar y/o experimentar
las funcionalidades construidas durante el sprint.
Que el Dueo de Producto pueda aceptar o rechazar dichas
funcionalidades.
Que los interesados en el producto puedan elaborar eventuales mejoras
al producto en base a lo visto.

Retrospectiva
Objetivos: Inspeccionar los procesos de trabajo y las interacciones que ocurrieron en el
ltimo sprint para detectar fortalezas del equipo y oportunidades de mejora. Se busca
acordar unas pocas acciones concretas de mejora a implementar en el prximo sprint
para hacerlo ms productivo.

3.2.7 Conclusiones

Es importante destacar unos mecanismos subyacentes de Scrum que se encuentran en

la mayora de sus roles, artefactos y ceremonias y que potencian fuertemente esta
metodologa:

El time-boxing (limitacin en el tiempo) de las actividades para controlar y limitar

el tiempo invertido en cada actividad y buscar una mayor eficiencia a medida
que el equipo va madurando en su forma de ejecutar las distintas ceremonias.
El empirismo y la auto-gestin como principios de definicin de las formas de
trabajo del equipo ms que tener un proceso estndar impuesto al equipo por
una organizacin.
La mejora continua de los procesos y de las capacidades de los individuos a
travs de espacios frecuentes para poder reflexionar y definir mejoras a probar
en prximas iteraciones.

Si bien Scrum fue diseado en el contexto de proyectos de desarrollo de software, sus

prcticas son fcilmente extrapolables a otros contextos, principalmente por referirse a
la gestin de proyectos sin hacer un foco en prcticas ms tcnicas del desarrollo. Se ha
aplicado en otros tipos de proyectos por ejemplo en empresas del dominio artstico o
mdico.

* Libros sugeridos: Scrum y XP desde las trincheras - Henrik Kniberg

 Pgina 30

3.3 KANBAN
Es la primera metodologa gil de segunda generacin, ya que aparece luego que las
principales otras metodologas giles hayan sido aplicadas durante por lo menos una
dcada. Aporta un enfoque centrado en la mejora continua del proceso basado en un
flujo continuo de trabajo que lleva a una gestin de proyectos muy distinta a lo que se
present hasta ahora en el curso.

3.3.1 Orgenes

Kanban es un trmino japons:

(Kan) que se puede traducir como visual

(Ban) que se puede traducir como insignia o sello

Al final de la primera mitad del siglo veinte, la empresa automotriz japonesa Toyota
investig como mejorar su gestin de la demanda automotriz y de su stock de materiales
y autos. Taiichi Ohno tuvo la primera idea de Kanban visitando un supermercado de
EEUU donde el cliente se dirige directamente al depsito correspondiente para buscar
el producto que necesita (siguiendo seales visuales o Kanban que lo guan haca el
depsito) en lugar de pedirlo al personal del negocio.

Generalizando este mecanismo, Toyota ve un proceso de produccin como el cliente de

depsitos de los procesos previos. Toyota utiliza en consecuencia el ritmo de la demanda
para controlar el ritmo de produccin, replicando el mecanismo a partir de la demanda
de los clientes finales en toda la cadena de sub-procesos cliente/depsito. Se conoce
este enfoque como sistema Pull5, donde el ritmo de la demanda actual determina el
ritmo de todos los sub-procesos necesarios a la produccin, a diferencia de sistemas
Push6, donde se trabaja sobre el ritmo de produccin y el nivel de stock a partir de la
prediccin de las ventas posibles.

En el 2004, David Anderson introdujo por primera vez los principios de Kanban en el
equipo de mantenimiento continuo para la Unidad de Negocio XIT en Microsoft, cuya
situacin y rendimiento era al principio bastante por debajo de otros equipos parecidos
y lejos de cumplir con las distintas expectativas involucradas.

5
Pull = Tirar
6
Push = Empujar
 Pgina 31

3.3.2 Las 3 Reglas de Kanban

David Anderson da la siguiente definicin de un Sistema Kanban:

Un sistema Kanban es un sistema o proceso diseado para disparar trabajo cuando hay
capacidad para procesarlo. El disparador se representa con una tarjeta. Se pone a
disposicin una cantidad de tarjetas correspondiente a la capacidad del sistema. Una
tarjeta se adjunta a cada tem de trabajo. La tarjeta sirve como mecanismo visual. Un
nuevo tem de trabajo puede iniciarse nicamente cuando se dispone de una tarjeta libre.
Esta tarjeta libre se adjunta al tem de trabajo para que pueda avanzar a travs del
sistema. Cuando no hay ms tarjetas libres, no se pueden iniciar nuevos trabajos. Cuando
el trabajo se termina, la tarjeta es separada del tem y reutilizada. Este mecanismo 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 funcin de la demanda.

1. Mostrar el proceso
2. Limitar el trabajo en curso
3. Optimizar el flujo

1. Mostrar el Proceso
Con esta regla se busca visualizar los tems de trabajo y el proceso de trabajo en un
tablero fsico o herramienta digital equivalente.

Definicin del proceso a controlar: Se debe definir qu parte del proceso se va

a controlar.

Definicin de Tipos de tems de Trabajo: Pueden ser Requerimientos,

Funcionalidades, Historias de Usuarios, Casos de Uso, Pedidos de Cambio,
Sugerencia de Mejora.

Diseo de Tarjetas de tems de Trabajo: Por cada tem de trabajo se suele

registrar la informacin siguiente: ttulo, nmero identificador, fecha de entrada
al sistema Kanban, tipo de tem, persona asignada, prioridad, fecha deadline, etc.

Identificacin de la Secuencia de Actividades: En Kanban se busca definir el

proceso de creacin de valor en funcin de las actividades y no de los roles
involucrados. Estas actividades se enmarcan entre los puntos de entradas y de
salidas definidos.
 Pgina 32

Luego puede ser til agregar unos estados de En Curso y Terminado para estas
actividades para poder identificar con detalle el estado de avance de los tems de
trabajo. Por ejemplo: Prueba en Curso y Prueba Terminada.

Finalmente se suelen agregar estados de buffer o cola en esta secuencia, como por
ejemplo un estado de espera entre Desarrollo e Integracin.

2. Limitar el Trabajo en Curso

Con esta regla se busca acordar entre los involucrados lmites sobre la cantidad de tems
de trabajo que pueden encararse a la vez. En el resto del documento utilizaremos el
trmino WIP (Work in Progress) en lugar de trabajo en curso.

Limitar el WIP permite reducir el multi-tasking (trabajar en varias tareas a la vez), lo cual
tiene efectos importantes: reduce el tiempo por cambio de contexto, suele mostrar los
cuellos de botella.

Un lmite de WIP provoca una restriccin sobre cuntos tems de trabajo pueden estar
en el mismo paso del proceso de creacin 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 problemtico. Este
mecanismo suele provocar colaboracin y motivacin de todo el equipo para remover
rpidamente el bloqueo antes de empezar con nuevos tems de trabajo.

Definir los lmites de WIP es una tarea compleja que depende de cada equipo, estos
lmites suelen calibrarse mejor a medida que el equipo encuentra su ritmo ptimo.

3. Optimizar el Flujo

Con esta regla se busca monitorear y seguir el avance de los tems de trabajo, para
determinar si el progreso sigue un ritmo regular, estable y ptimo.

Lograr un flujo de desarrollo estable, previsible y adecuado a las necesidades del

negocio. El foco principal para habilitar compromiso y confianza con un sistema Kanban.

El flujo es la progresin visible de los tems de trabajo a travs del sistema Kanban. El
flujo debera seguir un ritmo consistente.
Si un tem de trabajo parece estar frenado, el equipo debera debatir para resolver como
se puede rehabilitar el flujo de nuevo.
 Pgina 33

Si todos los tems de trabajo de un paso en particular parecen estar frenados, puede
haber un cuello de botella en el sistema, y el equipo deber tambin debatir
(eventualmente incluyendo roles de management) para cambiar el proceso de creacin
de valor y solucionar el problema.

3.3.3 Mtricas Kanban

Se suelen utilizar las siguientes mtricas en Kanban:

Cycle Time: mide la duracin entre el momento en el cul el equipo empieza a

trabajar sobre un tem y se termina cuando este tem est listo para la entrega.

Throughput: mide la cantidad de salidas de un proceso en un periodo de tiempo

dado. Representa la cantidad de tems que un equipo puede terminar en un
periodo dado, por ejemplo 4 tems por semana.

Las mejoras que se buscan en general son:

Minimizar el Cycle Time.

Maximizar el Throughput.
Lograr menos variabilidad del Cycle Time y del Throughput.

* Libro Sugerido: Kanban: Succesfull Evolutionary Change for Your Technology Business
David J. Anderson
 Pgina 34

3.4 XP (EXTREME PROGRAMING)

En esta parte vamos a presentar la metodologa gil Extreme Programming
(Programacin Extrema o XP), que aporta un enfoque ms tcnico en el desarrollo de
software.

3.4.1 Introduccin

Extreme Programming (o XP) define un conjunto de valores, principios y prcticas para

el desarrollo rpido de software de alta calidad. XP busca maximizar el valor creado al
cliente en un plazo lo ms corto posible.

El primer proyecto XP fue iniciado en 1996, y luego XP demostr ser exitoso en mltiples
organizaciones de distintos tamaos y distintas industrias en el mundo entero. Los
fundadores de XP son Kent Beck, Ward Cunningham y Ron Jeffries.

XP enfatiza tambin el trabajo colaborativo, permitiendo al equipo su auto-organizacin

para resolver de la mejora forma los problemas que ocurren.

3.4.2 Valores

XP est diseado sobre la base de los siguientes valores fundacionales:

Comunicacin: 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
cdigo. Se crea la mejor solucin posible a los problemas en conjunto.

Simplicidad: Se hace lo necesario y lo pedido, pero nada ms. Esto permite

maximizar el valor creado para la inversin realizada hasta el momento. Se busca
hacer pequeos pasos simples haca 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 produccin testeando su

software desde el primer da. 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
recprocamente.
 Pgina 35

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 tecnologas cuando ocurren.

3.4.3 Resumen de las Prcticas de XP

Las prcticas propuestas por XP son pocas y son simples de entender. Sin embargo, estas
doce prcticas 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 prcticas de XP y las principales relaciones

que tienen entre s:

3.4.4 Las prcticas de XP

1. On-site Customer (Cliente In-Situ)

Se necesita disponibilidad del cliente, no solo para ayudar el equipo de proyecto, sino
tambin como parte del equipo.
Todas las fases de un proyecto XP requieren comunicacin e interaccin con el cliente,
y preferentemente cara a cara en el mismo sitio.

2. 40 Hour Week (Semana de 40 Horas)

 Pgina 36

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 seales 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 dueo de sus propias estimaciones, suele tener ms confianza para

terminar el trabajo en el tiempo comprometido.

3. Metaphor (Metfora)
El objetivo de una metfora es de crear un puente de entendimiento: una persona que
trata de explicar un concepto a otra intenta encontrar una referencia comn a los dos
que permita representar el concepto en una forma entendible por ambos. Luego es
posible explicar el concepto usando esta referencia comn como marco.

En XP se busca identificar una metfora (o varias) que permita al equipo sintetizar el

diseo esencial del software en un concepto que entiendan todos. Es una herramienta
que permite eliminar los problemas de comunicacin que suelen aparecer por las
diferencias de perspectivas o de background de cada uno.

4. Simple Design (Diseo Simple)

Con esta prctica, XP propone utilizar el diseo lo ms 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 prctica tambin se conoce como KISS, Keep It Simple Silly, y es una de las ms
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 cdigo pero que si permita mejorar
su estructura interna..

6. Pair Programming (Programacin de a Pares)

El objetivo es que todo el cdigo fuente productivo haya sido escrito por dos
desarrolladores sentados en la misma computadora. La programacin de a pares
permite que todo el cdigo sea revisado a medida que se vaya escribiendo.
 Pgina 37

Eso significa que todo el cdigo 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 codificacin.
El otro desarrollador se enfoca en un nivel ms abstracto y revisa continuamente el
cdigo que escribe el primer desarrollador. Los desarrolladores intercambian roles
peridicamente.

7. Short Releases (Entregas Cortas)

El objetivo de esta prctica es poder hacer entregas tempranas y frecuentes, agregando
unas pocas funcionalidades cada vez. La prctica 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 Aceptacin.

Pruebas de Unidad (Unit Tests)

Las pruebas de unidad permiten testear la funcionalidad de pequeas porciones de
cdigo (por ejemplo, una clase o un mtodo). Con XP, se usa un enfoque de TDD (Test
Driven Development = Desarrollo Dirigido por las Pruebas), donde las pruebas unitarias
son diseadas y codificadas en un framework especifico7 antes de escribir el cdigo
correspondiente. Este mecanismo permite motivar al desarrollador en pensar primero
en las condiciones en las cuales su futuro cdigo podra fallar. Tambin permite pensar
primero en la definicin de la interfaz del cdigo y del objetivo del cdigo a construir
antes de pensar en su implementacin detallada.

Pruebas de Aceptacin
XP indica que unas pruebas de aceptacin deben ser definidas por el cliente para
asegurar que la aplicacin funciona correctamente. En general las pruebas de
aceptacin son pruebas de alto nivel de la aplicacin, ms orientadas a la operacin real
del negocio. Una funcionalidad es considerada terminada cuando todos los tests de
aceptacin correspondientes fueron ejecutados con xito.

9. Coding Standards (Estndares de Cdigo)

XP recomienda que cada miembro del equipo codifique con los mismos estndares.
Idealmente, no se debera poder identificar quien del equipo ha escrito una porcin
especfica del cdigo solo leyndolo (cohesin de estndar de cdigo).

7
Por ejemplo, JUnit, NUnit, etc.
 Pgina 38

10. Collective Ownership (Propiedad Colectiva)

El objetivo es evitar que una sola persona sea duea de un mdulo de la aplicacin.
Se espera de todos los desarrolladores que puedan trabajar sobre cualquier porcin del
cdigo en cualquier momento.

La propiedad colectiva del cdigo implica que cada uno es responsable de todo el cdigo,
y tambin que cada uno tiene el permiso de modificar cualquier porcin del cdigo.

11. Continuous Integracin (Integracin Continua)

El objetivo es lograr que todos los cambios al cdigo fuente sean integrados en una base
comn de cdigo por lo menos diariamente, y que sean ejecutados todos los tests
automticos existentes antes y despus de la integracin.

Con XP se integra toda la aplicacin cada vez que se sube cdigo al repositorio
compartido de cdigo fuente. De esta forma se descubren los potenciales problemas de
integracin tempranamente y se resuelven en forma gradual ni bien aparecen.

12. Planning Game (Juego de Planificacin)

El objetico del Juego de Planificacin es que el equipo de proyecto y el cliente cooperen
para producir el mximo valor para el negocio de la forma ms rpida posible.

Suele ocurrir en una reunin al inicio de la iteracin a la cual participa el equipo de

proyecto y el cliente. La dinmica 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. Tambin se define el esfuerzo total que el equipo puede
producir durante la iteracin. El equipo divide cada Historia de Usuario en tareas
tcnicas 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 funcin del esfuerzo disponible del
equipo de proyecto.
 Pgina 39

3.4.5 Ejemplo de un Proyecto XP Tpico

En esta seccin, y a modo de repaso, describimos como se desarrolla un proyecto XP

tpico:

El primer punto de inters a mencionar es que todos los desarrolladores estn ubicados
fsicamente en una misma habitacin, 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 iteracin
tpicamente dura entre una y cuatro semanas segn el equipo, pero la duracin es
siempre la misma.

Al inicio de cada iteracin, el equipo se rene con el cliente para una reunin de
planificacin. En esta reunin, repasan las funcionalidades que el cliente quiere
terminadas en esta iteracin, dividiendo cada funcionalidad en tareas tcnicas de una
persona. Luego cada desarrollador se asigna tareas especficas y las estima. Ningn
desarrollador puede asignarse ms trabajo en esta iteracin que lo que termin en la
iteracin anterior.

Durante el resto de la iteracin, el equipo va a implementar las funcionalidades

comprometidas, trabajando de a pares sobre todo el cdigo producido. Para toda
porcin de cdigo, los desarrolladores primero crean tests unitarios antes de escribir el
cdigo y se integra todo el cdigo producido una vez por da, en general al finalizar la
jornada laboral. El cliente provee tests de aceptacin para validar las funcionalidades
que el equipo est desarrollando.

Al final de la iteracin (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 renen nuevamente para planificar la iteracin siguiente, y el ciclo

se repite.

* Libro sugerido: The Art of Agile Development, de Shame Shore -

 Pgina 40

4 RADIADORES DE INFORMACIN
 Pgina 41

Esta unidad centraliza los principales indicadores visuales de las metodologas giles,
llamado Radiadores Visuales por la metfora de irradiar informacin para todos los
involucrados.

4.2 TABLERO DE SPRINT

Una prctica comn en Scrum, cuando todo el equipo de proyecto est colocado, es de
materializar el Backlog de Sprint a travs de un tablero fsico (por ejemplo, con
rotafolios, panel de corcho, pizarrn, 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 estn 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 cartn o papel para representar tems y tareas del sprint, en las
cuales se registra informacin bsica de los tems (como por ejemplo ttulo, estimacin
de esfuerzo, prioridad, criterios de aceptacin) 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 segn el avance.

Finalmente se suele complementar la informacin del tablero con un Diagrama de

Burndown (descrito ms adelante), que muestra grficamente el esfuerzo restante del
sprint.

El Tablero de Sprint suele ser el lugar elegido para los equipos para hacer la Reunin
Diaria, y permite que todo el mundo pueda hacerle cambios visibles por todo el equipo,
lo que puede ser ms complicado con una aplicacin digital.

Se puede combinar el Tablero de Sprint con un soporte herramental para el Backlog de

Sprint en caso de querer registrar alguna informacin adicional, tener backups, tener
parte del equipo distribuido, contar con informacin histrica, integrar la informacin
de Backlog de Sprint con otras herramientas, sacar mtricas e indicadores de forma ms
automticas, etc.

A continuacin, se presenta un ejemplo de Tablero de Sprint:

 Pgina 42

4.3 DIAGRAMA DE BURNDOWN

El Diagrama de Burndown es una forma grfica 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 da 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 das hasta terminar el sprint actual (por ejemplo, diez das hbiles si es un
sprint de dos semanas de duracin). El eje Y representa el esfuerzo restante del equipo
para completar todos los tems comprometidos, con una graduacin en horas de
esfuerzo restante.

Existe una lnea de progreso terico que une el esfuerzo restante al principio del sprint
con el valor de esfuerzo restante cero al final del sprint. Es el progreso terico que un
equipo debera seguir para tener un ritmo constante y contino para llegar a cumplir
con el sprint si las estimaciones fueran perfectas y todas las tareas identificadas.
 Pgina 43

Cada da el Scrum Master ir marcando, para el da correspondiente, el esfuerzo

restante actualizado. El objetivo es llegar a un esfuerzo nulo antes del final del Sprint.

A continuacin, se muestra un ejemplo de Diagrama de Burndow:

En este ejemplo vemos un sprint de 20 das de duracin, con un esfuerzo restante

estimado inicial de 190 horas. En gris se ve la lnea de progreso terico 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 estn agregando tareas no previstas, o que surgen problemas que
hacen que las tareas duran ms de lo estimado.

Si la pendiente es horizontal de un da al otro, quiere decir que el esfuerzo restante

no cambio de un da 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 lnea de progreso terico, 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 lnea de progreso terico, se puede

interpretar que el equipo est avanzado ms rpido 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 visin muy clara del avance
del equipo, as como una forma grfica de monitorear el ritmo del equipo y detectar
tempranamente eventuales problemas de ritmo.
 Pgina 44

4.4 TABLERO KANBAN

En Kanban, la regla Mostrar el Proceso suele implicar la creacin de un tablero. Se
puede utilizar un tablero fsico en la pared (por ejemplo, con rotafolios, panel de corcho,
pizarrn, etc.) expuesto en la sala donde trabaja el equipo.

Se suele representar el flujo del proceso de creacin de valor de izquierda a derecha,

dibujando columnas para cada actividad de la secuencia definida. Tambin para cada
actividad definida se pueden dibujar dos sub-columnas para distinguir trabajo en curso
y trabajo terminado. Se agregan columnas correspondientes al punto de entrada y de
salida del sistema Kanban. Finalmente se agregan las columnas correspondientes de
buffer o cola entre actividades.

Luego se estila ubicar en estas columnas las tarjetas de los tems de trabajo en curso, en
forma de post-its o papel, con la informacin que mencionamos para cada tem, como
en el ejemplo a continuacin:
 Pgina 45

De esta forma logramos visualizar la secuencia de actividades del proceso de creacin

de valor, el estado de avance de los distintos tems de trabajo en curso, quien est
asignado a cada tem y otra informacin de gestin de mucha utilidad.

4.5 DIAGRAMA DE FLUJO ACUMULADO

Un Diagrama de Flujo Acumulado (CFD) provee visibilidad sobre como el trabajo fluye a
travs del sistema y releva cuellos de botellas. A continuacin, se presenta un ejemplo
de CFD:

En este ejemplo los pasos del proceso de creacin de valor representados son:
Inventory = En cola, para los prximos tems de trabajo priorizados.
Started = Iniciado, para los tems sobre los cuales el equipo empez a trabajar.
Designed = Diseado, para los tems cuyo diseo ha sido terminado.
Coded = Codificado, para los tems cuya codificacin ha sido terminada.
Complete = Completado, para los tems que fueron terminados

El eje Y representa la cantidad de tems en cada paso del sistema Kanban. El eje X
representa el tiempo y en particular en este ejemplo muestra fechas concretas
secuenciales. Tambin se puede ver como leer el Lead Time y el WIP en el grfico.

El CFD es una herramienta que permite evidenciar cuellos de botella. Por ejemplo, en el
diagrama siguiente se puede observar como el rea verde correspondiente al paso
Analysis se va ensanchando, mientras el rea beige correspondiente al paso DB
 Pgina 46

Procs sigue una progresin ms constante, lo cual suele representar un cuello de

botella en el paso Analysis.

4.6 CONTROL DE LMITES

Este tipo de diagrama permite registrar la evolucin de una variable en el tiempo. En el

eje X se sigue el tiempo (por ejemplo, los das, semanas o meses). En el eje Y, el valor de
la variable. Por ejemplo, podramos seguir mes a mes el promedio por da los pedidos
de soporte de los usuarios de un sistema. Adicionalmente, se establecen dos lmites de
 Pgina 47

control: el Lmite Inferior de Control (LIC), y el Lmite Superior de Control (LSC). Con la
definicin de estos lmites, podemos detectar claramente cuando la variable analizada
pasa los umbrales normales de valor, y nos provee una informacin clara para su
posterior anlisis y eventual resolucin.

El Control de Lmites es una herramienta grafica que puede ser utiliza en los enfoques
giles para mltiples propsitos, y es bastante comn aplicarla a variables como:

WIP (tems de trabajo en curso simultneamente)

Cantidad de tems terminados por iteracin
Cantidad de defectos detectados
Cantidad de pedidos o reclamos
 Pgina 48

5 ADOPCIN DE METODOLOGAS AGILES

 Pgina 49

En esta seccin repasamos algunos aspectos que suelen ser claves en la adopcin de
metodologas giles, y que el PMI incluye en su certificacin PMI-ACP.

5.1 GLOBALIZACIN, CULTURA Y DIVERSIDAD DE LOS EQUIPOS

Hoy en da los equipos suelen tener integrantes de varios pases. Y aunque estos hablen
el mismo idioma suele haber muchas diferencias culturales. Adicionalmente puede
haber grandes diferencias entre integrantes de una misma zona geogrfica, ya que cada
uno tiene su propia formacin, 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 DECISIN PARTICIPATIVOS

Es un hecho comprobado que el compromiso que tengan los participantes afecta
directamente al cumplimiento del proyecto. Tambin est demostrado que una forma
de lograr mayor compromiso de los participantes es que sean partes de la toma de
decisin.

En el enfoque gil de gestin de proyectos, se busca la auto-organizacin de los equipos,

y especialmente para la toma de decisin. En particular se suelen utilizar algunas de las
siguientes tcnicas para permitir a un equipo lograr decisiones por consenso:

Votacin
Luego de una conversacin del equipo sobre las distintas alternativas, pedir a cada
integrante que vote su preferencia entre estas. Se puede acordar la decisin por mayora
o por pasar cierto umbral de votos. La votacin puede ser annima o no.

Tcnica del Pulgar

Adicionalmente a la tcnica de votacin, en esta tcnica los participantes expresan su
opinin respecto a una alternativa en particular usando la posicin de su pulgar:
o Pulgar por arriba: de acuerdo con la alternativa
 Pgina 50

o Pulgar por abajo: rechazo

o Pulgar horizontal: puedo vivir con esta alternativa
Se puede tomar la decisin final por mayora de pulgar por arriba o si no hay ningn
pulgar por abajo.

Espectro de decisin de Jim Highsmith

En esta tcnica, el foco est especficamente 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
acompaar la decisin
o En contra, con reservas fuertes que generan rechazo

Votacin 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 decisin en funcin de
este total.

5.3 ERRORES Y APRENDIZAJE

Un cambio de paradigma importante en el enfoque gil tiene que ver con la relacin al
error. Se trata de ver el error como una inversin que nos permite aprender y mejorar
la prxima vez. Es una premisa clave para sostener la creatividad y la innovacin.

5.3.1 Comportamientos Problemticos

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 ms rpido 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.
 Pgina 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 hbito

Solemos quedarnos en nuestras zonas de confort, en particular cuando logramos ciertas
rutinas basadas en hbitos. A veces, al no cuestionarnos, nos perdemos la oportunidad
de mejora o la necesidad de hacer un cambio.

Ser inconsecuentes
Cuando usamos buenas prcticas, es bastante comn 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 ms 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 problemticos:

1. Tener disciplina y tolerancia

2. Empezar corrigiendo problemas concretos y tangibles

3. Copiar y ajustar, antes que crear de cero

 Pgina 52

4. Observar y escuchar para aprender de los otros, ya que todos tienen algo del que
podemos aprender

5. Tener concentracin y comunicacin, y a veces es necesario una interrupcin

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 alegra, basados en la motivacin 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 METODOLOGA

5.4.1 Anti-patrones de Adopcin

Alistair Cockburn, en el libro Agile Software Development: The Cooperative Game (2nd
Edition), proporciona reflexiones muy acertadas sobre anti-patrones a evitar en el
diseo o eleccin de una nueva metodologa:

1. Bala de Plata. Tener una sola metodologa para todos los tipos de proyectos no
es factible.

2. Intolerancia. Si la metodologa es demasiado estricta como para poder seguirla,

no va a funcionar.

3. Pesada. Si se requiere mucho ms esfuerzo en el uso de la metodologa que en

el trabajo en s, es probable que tampoco funcione.

4. Embellecida. Cuando se agregan a la metodologa algunos debera y podra

sobre tareas adicionales o segundarias a realizar, probablemente sean costosos
en valor y/o tiempo, si aportar demasiado.
 Pgina 53

5. Sin Probar. Una metodologa completa creada de cero, tiene un alto riesgo de
no estar adaptada a las necesidades y de ser difcil de cumplir.

6. Usada una vez. Una metodologa 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 Adopcin

En el diseo o la adaptacin de una metodologa a adoptar, se recomiendo considerar

los siguientes criterios:

1. El canal ms rpido de comunicacin para intercambiar informacin es cara a

cara.

2. El exceso de metodologa tiene un impacto negativo.

3. A grandes equipos, grandes metodologas: se debe documentar ms cuando hay

mayor cantidad de temas y se corren riesgos al no ser comunicados a todos.

4. A proyectos crticos, mejores prcticas: se requiere ejecutar la metodologa con

ms rigurosidad en estos proyectos en los cuales un fallo puede ser catastrfico.

5. Incrementar el feedback y la comunicacin reduce la necesidad de entregables

intermedios.

6. El conocimiento es intangible: no se puede tocar ni ver. La documentacin se

puede ver, pero que haya documentacin no implica que haya conocimiento.

7. Los cargos formales y las habilidades no necesariamente estn 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 ms crticas.

*Libro recomendado: Alistar Cockburn - Agile Software Development: The Cooperative

Game, 2nd Edition.

5.5 MODELOS HBRIDOS

 Pgina 54

Han emergidos mltiples modelos hbridos en cuanto al uso de metodologas giles. Un

modelo hbrido combina varias prcticas provenientes de distintas metodologas, que
pueden ser giles o no.

Es importante tener un nivel de conocimiento y experiencia con las metodologas a

combinar para lograr el xito manteniendo la simplicidad y efectividad de las prcticas
elegidas.

5.5.1 Ejemplo de Modelo Hbrido: Scrum con Kanban (Scrumban)

Este modelo hbrido ha sido ampliamente probado en la comunidad gil.

Una vez implementado Scrum se puede migrar parcialmente a Kanban, bsicamente

transformando el tablero para que represente el flujo de trabajo, agregando el lmite 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 Hbrido: enfoque predictivo y Scrum

Sin implementar todas las prcticas de Scrum en un entorno con un enfoque predictivo,
se puede empezar sumando algunas prcticas, como por ejemplo en aspectos de
sincronizacin y de mejora continua:

Reuniones Diarias de Sincronizacin

Pese a no tener iteraciones y a tener un plan ya fijado para todo el proyecto, suele ser
de valor tener una reunin diaria de sincronizacin (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
elaboracin, puede ser de valor aprender en forma continua y tratar de mejorar. Es
tpico implementar reuniones peridicas 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 PRCTICAS GILES

El ritmo con el cul un equipo o una organizacin puede incorporar nuevas prcticas es
limitado, como la cantidad de agua que puede absorber una planta. La recomendacin
en estos casos es simple: no reinventar la rueda... si no se necesita.
 Pgina 55

Si ya existe una prctica (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 prctica nueva tiene similitud con la habilitacin de un nuevo medicamento.
Se debe hacer pruebas en un grupo reducido durante un tiempo, analizando si
realmente es solucin 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 prcticas nuevas es realizar un ciclo de inspeccin,
reflexin y adaptacin. Si la prctica funciona se seguir utilizando, sino no.

El compromiso de PMI para la certificacin PMI-ACP es actualizar anualmente el alcance

del examen con nuevas prcticas que han sido ampliamente reconocidas.

Las metodologas giles actuales incluidas en la certificacin 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 extensin de Test Driven Development que incorpora los intereses del negocio
con una visin tcnica, 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, adems de las ideas ya conocidas de Lean, es utilizar una correccin
estructurada del curso de diseo para probar una nueva hiptesis 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 tcnica de clculo para la valoracin de decisiones. Libro sugerido: Real Options
Analysis: Tools and Techniques for Valuing Strategic Investment and Decisions, 2nd
Edition (Wiley Finance).
 Pgina 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
 Pgina 57

LO QUE VIMOS Y LO QUE VENDR

En esta unidad introducimos los principales principios,

prcticas, tcnicas que se suelen usar en las metodologas
giles.

En las prximas unidades nos enfocaremos en priorizar,

estimar, planificar, monitorear y adaptar un proyecto de
desarrollo.