1

Pontificia Universidad Católica de Valparaíso

Escuela de Ingeniería Civil
Formación Continua
Curso APM | Agile Project Management

Julio 2018
Valparaíso, Chile

AUTOR
Akira Bloise
Arquitecto especialista en Gerencia de
Proyectos, certificada como Project
Management Professional, Six Sigma Green
Belt, Scrum Master certificada y
Facilitadora de la Metodología LEGO®
SERIOUS PLAY™. Con vasta experiencia
ejecutando y liderando proyectos en los
sectores de ingeniería civil,
telecomunicaciones, tecnología de la
información y de la Banca. Actualmente
dedicada a la asesoría y capacitación en la
implementación de los procesos en
Dirección de Proyectos, creación de oficinas
de proyectos y aplicación de métodos ágiles
en empresas de diversos sectores de la
economía chilena. Negociadora y
comunicadora, capaz de evaluar
necesidades, resolver conflictos, con un alto
sentido de responsabilidad y compromiso
al logro de los objetivos planteados.
Frecuente relatora en eventos nacionales e
internacionales que fomentan la promoción
y divulgación de las mejores prácticas en
Dirección de Proyectos.

2
Contenido
PRÓLOGO .......................................................................................................................... 4
1. UNIDAD 1: FUNDAMENTOS DE LA GESTIÓN DE PROYECTOS
ÁGILES ............................................................................................................................... 5
1.1. Introducción a la filosofía ágil ........................................................... 5
1.2. Valores y principios ágiles................................................................... 7
1.3. Selección del ciclo de vida ................................................................. 10
1.4. Marcos de trabajo y prácticas ágiles: Scrum, Lean, Kanban,
XP, Crystal, TDD...................................................................................................... 15
2. UNIDAD 2: CONFORMACIÓN DE UN ENTORNO ÁGIL ..................... 21
2.1. Liderazgo servicial que empodera a los equipos .................... 21
2.2. ¿Qué hace el directos del proyecto en un entorno ágil? ....... 21
2.3. Composición de un equipo ágil ....................................................... 22
3. UNIDAD 3: PRÁCTICAS ÁGILES COMUNES .......................................... 26
3.1. Planificación de la iteración .............................................................. 26
3.2. Reunión diaria de pie........................................................................... 28
3.3. Ejecución de la iteración .................................................................... 29
3.4. Revisión o demostración de la iteración ..................................... 30
3.5. Retrospectivita de la iteración ........................................................ 30
3.6. Creación de la lista de requerimientos del producto (Product
Backlog) ..................................................................................................................... 30
3.7. Refinamiento de la lista de requerimientos (Product
Backlog) ..................................................................................................................... 33
4. UNIDAD 4: CONSIDERACIONES EN LA ADOPCIÓN .......................... 36
4.1. Cultura organizacional ........................................................................ 36
4.2. Métricas ..................................................................................................... 37
4.3. Contratos ................................................................................................... 40
5. REFERENCIAS .................................................................................................... 43

3
PRÓLOGO
En la actualidad los mercados son volátiles y dinámicos dado que
las necesidades de los clientes cambian constantemente,
producto del vertiginoso avance de la tecnología. Esto ha
provocado que las organizaciones estén demandando directores
de proyecto versátiles que cuenten no solo con el conocimiento
y la experiencia de las prácticas tradicionales de gestión de
proyectos sino también que sean capaces de aplicar prácticas
ágiles que les permita acelerar la entrega de productos con la
más alta calidad.
Es así como la gestión de proyectos ágiles es un nuevo enfoque
que todo director de proyectos debe conocer, basado en
satisfacer las necesidades del cliente, mediante la entrega
frecuente y continua de valor para su negocio. En el centro de la
agilidad se encuentran las personas y sus interacciones como
uno de los pilares básicos que asegura el cumplimiento de dichas
necesidades. Esto conlleva a exhibir: valores y comportamientos
centrales de transparencia, flexibilidad, adaptación, auto-
organización y colaboración, y en donde el rol del director de
proyecto como facilitador es clave.
Por lo tanto, el objetivo de este curso es que los estudiantes al
final de él sean capaces de aplicar herramientas ágiles en la
gestión de sus proyectos, además deberán ser capaces de
impulsar un ambiente y cultura de trabajo colaborativo
enmarcado en flujos de trabajo y roles definidos.

Prof. Rodrigo F. Herrera

Coordinador Formación Continua
Escuela de Ingeniería Civil
Pontificia Universidad Católica de Valparaíso

4
 1. UNIDAD 1: FUNDAMENTOS DE LA GESTIÓN DE
PROYECTOS ÁGILES
1.1. Introducción a la filosofía ágil
Trabajo definible vs Trabajo de alta incertidumbre
Los proyectos son únicos e irrepetibles por lo que no existe un
único enfoque para abordarlos.
El nivel de conocimiento y certeza que se tenga sobre el trabajo
realizar influye en la escogencia del enfoque.
Proyectos de tipo “industrial” o de producción en serie se apoyan
en enfoques predictivos.
Proyectos cuyo trabajo es incierto o desconocido requieren de
enfoques más adaptativos.
En la Tabla 1 se presenta una comparación de diversas
Tabla 1: Proyectos industriales vs proyectos de innovación.

Proyectos Industriales Proyectos de innovación

Visible/Tangible Invisible/Intangible
Mayormente estables Muchos cambios
Estructurados Entorno volátil
Respuestas correctas Menos estructura
Gestión por actividades Muchas preguntas
Comando y control Gestión por valor
Estándares Autonomía
Medidas de rendimiento Innovación
El trabajador representa un costo Enseñanza aprendizaje
Los trabajadores son un activo no
un costo

Procesos definidos:
- Procesos que son repetibles.
- Se hace el trabajo de la misma manera.
- Acciones claramente prescritas en base a comportamiento.

Procesos empíricos:
- Basados en la experiencia y observación.
- Formulación y comprobación de hipótesis.
- Acciones que son definidas en base a los resultados producto
de la experiencia.

5
Procesos definidos vs procesos empíricos

- El trabajo definible se sustenta es procesos repetibles

- El trabajo del conocimiento se basa en procesos de
experimentación.
- Un proceso definido establece una manera anticipada de
conseguir el objetivo.

Los procesos empíricos se caracterizan por ser:

- Interactivos
- Incrementales
- Con frecuentes cambios
- Adaptativos
- Con frecuentes periodos de revisión

Concepto de agilidad

Se asocia con una cualidad en cualquier objeto, persona u

organización que otorga flexibilidad, ligereza, fluidez, rapidez,
velocidad, dinamismo…etc.

A partir del Manifiesto Ágil (2001): “Agilidad es la capacidad de

crear y responder a los cambios con el fin de generar valor y
aprendizaje temprano en un entorno de negocios turbulento para
lograr resultados superiores a los esperados”[1]

6
 1.2. Valores y principios ágiles.
Los 4 Valores del Manifiesto Ágil (2001)
“Estamos descubriendo formas mejores de desarrollar software
tanto por nuestra propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:” [2]
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Los 12 principios del Manifiesto Ágil (2001)
A continuación, se presentan los 12 principios del Manifiesto Ágil
[2]
1. Nuestra más alta prioridad es satisfacer al cliente a través de
la entrega temprana y continua de software de valor.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos ágiles aprovechan el
cambio para generar ventaja competitiva para el cliente.
3. Entregar frecuentemente software funcionando, desde un
par de semanas, hasta un par de meses, con preferencia al
período de tiempo más corto posible.
4. La gente de negocios y los desarrolladores trabajamos en
conjunto, de forma cotidiana a lo largo del proyecto.
5. Los proyectos se desarrollan en torno 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 efectivo y eficiente de transmitir información
hacia y dentro del equipo de trabajo, es a través de la
conversación cara a cara.
7. Software funcionando es la principal medida de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deben ser
capaces de mantener un ritmo constante de trabajo de
manera indefinida.
9. La atención continua a la excelencia técnica y al buen diseño,
mejora la agilidad.
10. Simplicidad, el arte de maximizar la cantidad de trabajo que
no se hace, es esencial.
11. Las mejores arquitecturas, requerimientos y diseños
emergen de equipos auto-organizados.
12. A intervalos regulares, el equipo reflexiona respecto a cómo
ser más efectivo, para a continuación ajustar y perfeccionar
su comportamiento de acuerdo con ello.
Relación entre Valores, principios y prácticas
Como se muestra en la Figura 1, agilidad en una mentalidad
definida por valores, guiada por principios y que se manifiesta a
través de muchas prácticas diferentes. Los profesionales

7
practicantes de ágil seleccionan prácticas basadas en sus
necesidades.

Figura 1: Relación de mentalidad ágil [2]

Declaración de Interdependencia (DOI - 2005)

En 2005 , una comunidad de líderes de proyecto encabezados
por algunos de los firmantes iniciales del Manifiesto Ágil, (David
Anderson,Sanjiv Augustine, Christopher Avery, Alistair
Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim
Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent
McDonald, Pollyanna Pixton, Preston Smith y Robert Wysocki
) hicieron esta “declaración de principios” sobre lo que debería
de ser una Gestión de Proyectos “moderna”, constituyendo con
ello el conjunto de declaraciones que sirvieron de base para el
establecimiento de lo que se ha llamado un “Gestión Ágil de
Proyectos”.
“Somos una comunidad de líderes de proyecto con mucho éxito al
momento de entregar resultados. Para lograr estos resultados
nosotros:”
- Incrementamos el retorno sobre la inversión al hacer foco en
el flujo continuo de valor.
- Entregamos resultados fiables involucrando al cliente
frecuentemente y compartiendo la propiedad del proyecto.
- Esperamos incertidumbre y la gestionamos a través de
iteraciones, anticipación y adaptación.
- Desatamos creatividad e innovación al reconocer que los
individuos son la fuente última de valor, y al hacerlo creamos
un ambiente donde cada quien puede lograr la diferencia.
- Fomentamos el rendimiento a través de la responsabilidad
compartida en los resultados y en la efectividad del equipo.
- Mejoramos la efectividad y fiabilidad a través de estrategias,
procesos y prácticas, específicas para cada situación.
Agile Project Management
La gestión ágil de proyectos se refiere al conjunto de técnicas y
herramientas que son aplicadas a un proyecto que precisa
adaptabilidad y flexibilidad ante un entorno de alta
incertidumbre cuyo resultado es complejo de visualizar en un
horizonte de tiempo dado.

8
 Actividad: Trabajo en equipos
Asociar los principios ágiles a los valores señalados
anteriormente.
Compartan su reflexión

Cambio de Paradigma (Fecha fija, Costo Fijo, Alcance

variable)
En la Figura 2, se presenta el triángulo de hierro (forma
tradicional) y el triángulo ágil, donde se muestra que en el caso
tradicional el plan determina los estimados de tiempo y costo,
mientras que el caso ágil, la visión impulsa la priorización de
entregas en tiempo y costo.
Triángulo de hierro tradicional Triángulo ágil

Restricciones Alcance Costo Tiempo

Guiados
por la
visión de
Guiados negocio
por un
plan

Estimados Costo Tiempo Alcance

El plan determina los La visión impulsa la
Figura 2: Paradigma tradicional vs paradigma ágil
estimados de tiempo y costo priorización de entregas
en tiempo y costo

En la Figura 3, se presenta el modelo de incertidumbre

complejidad, donde se muestra que los métodos tradicionales
aplican cuando los requerimientos tienen alto nivel de acuerdo y
no existen dudas en la tecnología a utilizar, y las prácticas
emergentes vienen a apoyar cuando se sale de esa zona simple.

Figura 3: Modelo incertidumbre complejidad

Fuente: Ralph Stacy. University of Hertfordshire.

9
 1.3. Selección del ciclo de vida
Existen 4 categorías de ciclos de vida, los cuales se presentan en
la Tabla 2.
Tabla 2: Ciclos de vida

Características
Enfoque Requisitos Actividades Entrega Meta
Realizados
una vez para Entrega Gestión
Predictivo Fijos
todo el única costos
proyecto
Repetidos Corrección
Entrega
Iterativo Dinámicos hasta que de la
única
esté correcto solución
Realizados
Entregas
una vez para
recuentes
Incremental Dinámicos un Velocidad
más
incremento
pequeñas
dado
Valor para el
cliente
Repetidos Entregas mediante
Ágil Dinámicos hasta que frecuentes entregas
esté correcto pequeñas frecuentes y
retroaliment
ación

Ciclo de vida tipo “Cascada o predictivo”

- La forma lógica en que el trabajo se realiza.
- Equipara el desarrollo de software con líneas de producción.
- Las gráficas de Gantt son usadas para mapear el detalle de
tareas y dependencias, algunas veces con años de antelación.
A continuación, en la Figura 4 se presenta un ejemplo del ciclo de
vida predictivo.

Figura 4: Ejemplo ciclo de vida predictivo [3].

10
Entrega de Valor: Enfoque Tradicional
En la Figura 5 se muestra como es la entrega de valor en el
enfoque tradicional.

Figura 5: Entrega de valor

Ciclo de vida iterativo

- Introducidos a principios de 1990s.
- El enfoque de fases secuenciales es reemplazado con técnicas
iterativas.
- Más parecido al desarrollo de un nuevo producto que al
proceso de fabricación en serie.
En la Figura 6 se presenta un ejemplo del ciclo de vida iterativo.

Figura 6: Ejemplo ciclo de vida iterativo

Ciclo de vida Incremental

Corresponden a entregables terminados que el cliente puede
usar, en la Figura 7 se muestra un ejemplo de estos, se asocia a
procesos.

11
 Figura 7: Ciclo de vida incremental de tamaño variable [3]

Desarrollo Ágil: Iterativo-incremental

El ciclo de vida ágil combina las bondades del ciclo de vida
iterativo e incremental
- Promueve el desarrollo a través de iteraciones.
- Fomenta la colaboración abierta y la adaptabilidad de
procesos.
- Planificación “JIT” de bloques de trabajo estrictamente
definidos.
- Énfasis en el involucramiento de los interesados.
La Figura 8 muestra cómo se desarrolla el enfoque ágil.

Figura 8: Ejemplo de desarrollo ciclo de vida ágil [2]

Entrega de Valor: Desarrollo iterativo incremental

- Cada iteración produce una versión ejecutable, un
incremento adicional al sistema.
- Priorizar funcionalidad de mayor valor y mitigar riesgos
(tecnológicos y de entendimiento de requerimientos).
- Promover un ritmo sostenible de trabajo.
En la Figura 9 se muestra como el desarrollo ágil acelera la
entrega de valor en comparación al enfoque tradicional

12
 Figura 9: Entrega de valor, enfoque ágil

Aplicación de ciclos de vida ágiles

Funcionan bien para proyectos que involucran:
• Investigación y desarrollo
• Presentan altas tasas de cambio
• Requisitos inestables
• Persiguen un objetivo final poco claro de describir.
¿Cómo escoger el ciclo de vida para tu proyecto?
A continuación se enlistan las preguntas a realizar para escoger
el ciclo de vida adecuado para su proyecto [4]:
- ¿Qué tan estables son los requerimientos?
- ¿Quiénes son los usuarios del producto?
- ¿Qué tan agresivo o conservador es el cronograma?
- ¿Qué dimensiones tamaño / esfuerzo tienen el producto /
proyecto?
- ¿Dónde están ubicados los miembros del equipo?
- ¿Cuáles son los recursos críticos y su disponibilidad?
Tradicional Vs. Ágil
Tabla 3: Comparación de enfoques

Enfoque Agile Tradicional

Énfasis Personas Procesos
Dominio Impredecible/Exploratoria Predecible
Documentación Mínima, solo la requerida Comprehensiva
Aseguramiento Centrada en el
Centrada en el Cliente
Calidad Proceso
Estilo de proceso Iterativo Lineal
Planificación
Baja Alta
Inicial

13
 Enfoque Agile Tradicional
Actitud ante el
Adaptabilidad Rigidez
cambio
Priorización
Basada en valor de negocio Fija en el plan
requerimientos
Estilo de Gestión Descentralizada Autocrítico
Comando y
Liderazgo Colaborativo, Líder servicial
control
Medición de Cumplimiento
Valor para el negocio
desempeño del plan
Retorno sobre la Quick Wins (a lo largo del Al final del
inversión proyecto) proyecto

Actividad: Para discutir

¿Para cuál de los siguientes proyectos usaría enfoque ágil y
para cual tradicional? Justifique su respuesta.
1. Construir una nueva línea de metro
2. Hacer una modificación a un software para atender un
nuevo requerimiento normativo
3. Desarrollar una aplicación móvil que permita lanzar un
nuevo negocio
4. Hacer cambios en una organización con el propósito de
mejorar su desempeño

Métodos y Prácticas Ágiles

Los enfoques ágiles se originan del pensamiento Lean y nacen
mucho antes del manifiesto ágil. Ágil es un término genérico que
incluye varios enfoques, como se aprecia en la Figura 10 [2].

Figura 10: Relación de Lean, Ágil y Kanban [2]

14
 1.4. Marcos de trabajo y prácticas ágiles: Scrum, Lean,
Kanban, XP, Crystal, TDD.
Scrum
Enfoque holístico o Rugby [5]
- Trabajo en entornos cambiantes
- Equipos auto-organizados
- Desarrollo iterativo
- Aprendizaje continuo
- Control sutil
- Transferencia de conocimiento organizacional
Definición de Scrum
Jeff Sutherland y Ken Schwaber presentaron Scrum en OOPSLA
(Object-Oriented Programming, Systems, Languages &
Applications), 1995, definiéndolo como: “Un marco de trabajo
dentro del cual las personas pueden abordar problemas complejos
con adaptación a entornos cambiantes, mientras productivamente
y creativamente entregan productos del más alto valor posible”.
Se fundamente en tres pilares, los cuales se ven en la Figura 11.

Figura 11: Fundamentos del Scrum

Característica de Scrum:
- Desarrollo a través de SPRINTS de una duración pre
determinada.
- Priorizar de acuerdo al valor para el negocio.
- Reducir riesgos lo antes posible.
- Equipos auto-gestionados.
- Aprendizaje continuo.

15
Principios de Scrum
1.- Control empírico del proceso: Pone de manifiesto la filosofía
central de scrum en base a Transparencia, inspección y
adaptación.
2.- La auto-organización: Este principio se centra en los valores
de los empleados de hoy que entregan mayo valor cuando son
auto-organizados.
3.- La colaboración: Este principio se centra en las 3 dimensiones
básica del trabajo colaborativo que son conciencia, articulación
y apropiación. También aboga por una gerencia de proyectos
como un proceso de valor compartido.
4.- La priorización basada en valor: Consiste en ofrecer el
máximo valor al negocio de inicio a fin durante todo el proceso.
5.- Time-boxing: Se refiere a como el tiempo se considera una
limitante en Scrum y de qué manera esta técnica ayuda a
aumentar la efectividad en la planificación y ejecución. Los
elementos del time box son los sprints, Reunión diaria de scrum,
planificación del sprint, reunión de revisión del sprint.
6.- Desarrollo iterativo: Enfatiza como manejar los cambios y
crear productos que satisfagan las necesidades del cliente,
también delinea las responsabilidades del product owner y de la
organización durante el desarrollo iterativo.
En la Figura 12 se presenta la visión general de Scrum.

Figura 12: Visión general de Scrum

La mejor utilidad de Scrum se logra en proyectos que involucran

lo siguiente:
- Desarrollo de productos tecnológicos innovadores.
- Equipos de proyecto Cross funcionales dedicados y
altamente calificados.
- Desarrollo de productos en ambientes hipercompetitivos.
- Requerimientos de cambio frecuentes e inesperados.
- Una necesidad regular de retroalimentación debido a
requerimientos complejos.

16
 Actividad por equipos
Arma el ciclo de Scrum: Identifica los eventos, artefactos y
roles que participan.
Comparte con el grupo.

Kanban: “Tarjeta” o “Tablero”

Un sistema de información que controla de modo armónico la
fabricación de los productos necesarios en la cantidad y tiempo
necesarios en cada uno de los procesos que tienen lugar en una
fábrica
Se basa en 5 principios, los cuales son:
1. Visualizar el flujo de trabajo
2. Limitar el Trabajo en Progreso (WIP)
3. Administrar el flujo
4. Hacer las políticas de proceso explícitas
5. Mejorar colaborativamente
Se enfoca en:
- No utilizar PUSH (se estimaba la demanda y en base a ello
se producía)
- Nuevo enfoque: PULL (cuando tengo disponibilidad voy
a buscar trabajo)
- Minimizar el Trabajo-en-progreso (WIP)
- Visualizar y compartir el estado del proyecto en una pared
dentro de la sala de proyectos
Beneficios de limitar el WIP:
- Mantener el foco
- Evitamos desperdicios de tiempo
- Evitemos perder información importante
- Mejoramos la calidad de nuestro trabajo
- Reaccionamos antes a problemas y bloqueos
- Conseguimos una frecuencia de entrega predecible
- Quedan de manifiestos los cuellos de botella
En la Figura 13 se presenta un ejemplo de Kanban

17
 Figura 13: Ejemplo de Kanban

Actividad: Trabajo de equipo

Desarrolla el Kanban de tu proyecto.
- Define el flujo.
- Determina la capacidad en cada etapa.
- Acuerda con tu equipo los momentos de revisión y reglas
de colaboración.

Principios LEAN
- Eliminar todos los desperdicios: Sobreproducción, Tiempo
de espera, Transporte, exceso de procedimientos, Inventario,
Movimientos y defectos.
- Buscar la perfección de manera continua
- Origen en sector industrial (Toyota)
- Incentiva que los trabajadores identifiquen mejores
LEAN aplicado al Software: Principios [6]:
- Eliminar Desperdicios
- Funcionalidades innecesarias
- Burocracia
- Comunicación interna lenta
- Ampliar aprendizaje
- Probar tempranamente
- Realimentación del cliente
- Decidir lo más tarde posible
- Entregar tan rápido como sea posible
- Potenciar el equipo
- Crear la integridad
- Véase todo el conjunto
En la Tabla 4 se muestran los cinco valores de la “XP:
Programación extrema”

18
 Tabla 4: Valores de la programación extrema

Valores Vinculación
Con clientes
Comunicación Dentro del equipo
Lo más directa posible
Simplicidad Lo que realmente se necesita ahora
Del sistema (Test automatizados)
Realimentación Del cliente
Del equipo
Enfrentar problemas dentro del equipo
Coraje
Asumir errores
El código es de todos: debo escribir para que otros
Respeto entiendan
Solucionar problemas lo antes posible

En la Figura 14, se muestra un ejemplo de la aplicación de estos

valores, lo que genera buenas prácticas en el desarrollo del
trabajo.

Figura 14: XP Buenas practicas

Crystal
Las metodologías cristal son una familia de metodologías agiles,
donde cada una de ellas esta adecuada para un tipo de proyectos
- Eficiencia.
- Habitabilidad. (El equipo se siente cómodo usándolo)
- Foco en las personas y no en los procesos.
- Entrega frecuente de código usable.
- Mejora reflexiva.
- Comunicación osmótica.
FDD: Feature Driven Development
Es una metodología ágil diseñada para el desarrollo de software,
basada en la calidad y el monitoreo constante del proyecto, la
cual consta de 5 pasos los cuales se muestran en la Figura 15.

19
Figura 15: Feature Driven Development

20
2. UNIDAD 2: CONFORMACIÓN DE UN ENTORNO ÁGIL
2.1. Liderazgo servicial que empodera a los equipos
El liderazgo servicial es la práctica de estar al servicio del equipo,
al centrarse en atender sus necesidades para permitir que logre
el más alto desempeño.
Características del liderazgo servicial:
- Promover la autoconciencia
- Escucha
- Sirviendo al equipo (Removiendo obstáculos)
- Ayudando a las personas a crecer
- Coaching vs control
- Promoviendo seguridad, respecto y confianza
- Promoviendo la energía e inteligencia de otros
Responsabilidades del líder servicial:
- Gestionar las relaciones entre los miembros del equipo
- Educar a los involucrados sobre el por qué y cómo ser ágiles
- Apoyar al equipo siendo mentor y estimulando la mejora
continua
- Celebrar con el equipo y reconocer sus logros
- Ayuda al equipo en las actividades de gestión dentro del
proyecto
Los líderes serviciales son facilitadores
Los jefes de proyecto que actúan en un proyecto ágil como
líderes serviciales, el énfasis en su rol se mueve de una gestión y
coordinación a facilitación y colaboración.
Tareas del liderazgo servicial:
- Dar transparencia a través de la visualización.
- Crear un ambiente seguro para la experimentación.
- Experimentar con nuevas técnicas y procesos.
- Compartir conocimiento a través de la colaboración.
2.2. ¿Qué hace el directos del proyecto en un entorno
ágil?
“Es la persona asignada por la organización ejecutora para
liderar al equipo responsable de alcanzar los objetivos del
proyecto”.
Es un líder de servicio, cambia el énfasis hacia el coaching de las
personas que quieren ayuda, promoviendo una mayor
colaboración en el equipo y alineando las necesidades de los
interesados.
Fomenta la distribución de la responsabilidad al equipo [2].

21
 2.3. Composición de un equipo ágil
Existen tres miembros que componen un equipo ágil, estos son:
miembros de un equipo multifuncionales, facilitador del equipo
y dueño del producto
Miembros de equipo multifuncionales:
- Tienen todas las habilidades para realizar el trabajo que les
permitirá crear el producto (Multifuncionaales).
- Se comprometen a hacer entregas frecuentes del producto.
- Los equipos multifuncionales son críticos porque:
- Son capaces de entregar un incremento de producto
en un periodo corto de tiempo,
- Con alta calidad y,
- Sin dependencias externas.
Deben ser “Generalistas - Especialistas”
Generalistas: Conocimientos generales en varios campos.
Expertos al menos en uno.
Auto-organizados: Todos están involucrados en las decisiones
sobre cómo hacer el trabajo.
Multi-funcionales: Todos las habilidades y conocimientos
necesarios están disponibles, sin depender de alguien externo.
Equipos 100% dedicados: Miembros entre 3 y 9 personas,
deben estar co-ubicados en un mismo espacio físico.
Al definir el equipo, se deben identificar backups para cada uno.
Funciones:
- Deben entender las historias de usuario y el Product Backlog
priorizado.
- Realizan la estimación de las historias de usuario.
- Asumen el compromiso de que historias de usuario
desarrollar en un Sprint.
- Identifican la lista de tareas para desarrollar cada historia de
usuario, las estiman y las asignan dentro del equipo.
- Participan en reuniones de trabajo.
- Ejecutan las tareas y crean el incremento del producto.

Actividad por equipos

Lea los escenarios entregados.
Discutir cómo podrían responder a cada situación si fueran un
equipo ágil.

22
Dueño del producto (Product Owner):
Su principal responsabilidad es maximizar el valor del producto
administrando la lista de requerimientos en orden de prioridad
para el negocio. Además, debe ser:
- La voz del cliente.
- Maximiza el valor del producto.
- Representa a los interesados y es responsable de asegurar
que el equipo genere valor.
- Responsable de asegurar una clara comunicación de las
funcionalidades del producto al equipo.
- Establece una visión compartida del producto.
- Se asegura de que el equipo trabaje desde la perspectiva del
negocio.
- Escoge qué y cuándo debe ser liberado (Realese)
Funciones:
- Define la Visión del Producto.
- Crea la lista de requerimientos iniciales identificados.
- Ayuda a crear el presupuesto del producto.
- Identifica interesados y ayuda a conformar el equipo Scrum.
- Define el Criterio de Terminado.
- Participa en el Sprint Planning y en la revisión del sprint.
- Mantiene el Product Backlog Priorizado.

Actividad para discutir

¿Cree usted qué es conveniente que el Product Owner sea el
Cliente o uno de sus representantes? Ventajas y desventajas

Facilitador del equipo

El facilitador de un equipo ágil es un líder servicial que puede ser
nombrado de diferentes maneras.
Su función principal es la de potenciar las habilidades del equipo
para que sea capaz de entregar valor en un periodo corto de
tiempo.
Funciones:
- Completa responsabilidad a través de la confianza.
- Entrena al equipo y al Product Owner en Scrum.
- Implementa los valores del Manifestó Ágil.
- Facilita las reuniones o eventos.
- Se asegura de que el trabajo y los impedimentos sean
visibles.

23
- Mantiene los radiadores de información sobre del progreso
del equipo.
- Alienta la apertura y la transparencia.
- Identifica y se asegura de que los impedimentos sean
resueltos.

Actividad para discutir

¿Cuáles crees que son las principales diferencias entre el rol
de facilitador en un equipo ágil y el rol del jefe de proyectos
en un enfoque tradicional?

Espacio de trabajo de un equipo ágil

Un espacio de trabajo de un equipo ágil debe permitir la que
estén interconectados, promover la creatividad y comunicación
y ofrecer la comodidad adecuada. A continuación, se presentan
diversos ejemplos de espacios agiles.

24
 Actividad: Discusión en equipos
Identifica cuáles son las principales dificultades que existen
en las organizaciones para crear entornos colaborativos.
Piensa en una acción que permita dar solución a esas barreras
identificadas.

25
3. UNIDAD 3: PRÁCTICAS ÁGILES COMUNES
En esta unidad se abordarán los siguientes contenidos:
Planificación:
- Planeación del trabajo contenido en el Product Blacklog.
- Permite establecer el objetivo de la iteración y definición de
la porción del trabajo a ejecutar.
Reunión diaria:
- Se informa el progreso del trabajo.
- Permite la actualización del plan diario del equipo.
Reunión de revisión:
- Reunión para la inspección del trabajo completado
(Incremento).
- Permite actualizar el product backlog.
Retrospectiva:
- Reunión para reflexionar sobre los resultados obtenidos.
- Permite identificar la mejora continua necesaria a
incorporar en la próxima iteración.
Iteración:
- Momento en el que se crea el incremento del producto con
una duración de 30 días o menos.
3.1. Planificación de la iteración
En la reunión de planificación se abordan 2 temas centrales,
¿Qué haremos? Y ¿Cómo lo haremos?
- Los equipos estiman las dimensiones del trabajo y el
esfuerzo del trabajo a realizar.
- Los equipos evalúan sus capacidades para tomar decisiones
sobre la porción del trabajo a comprometer.
- Los miembros del equipo trabajan en conjunto con el
Product Owner para garantizar la entrega del máximo valor
para el negocio.
En la Figura 16 podemos ver los datos de entrada de la reunión,
quienes participan de la reunión y que se obtiene finalmente de
está.

26
 Figura 16: Ejemplo reunión de planificación

Definición de “Terminado” (DoD)

Es un entendimiento compartido sobre lo que se considera
completado en el sprint.
Es una lista de verificación de actividades que tienen que ser
universalmente entendidas y acordadas por el equipo para
brindar transparencia.
Se considera el común denominador de calidad del producto.
Todas las historias de usuario dentro del product backlog deben
cumplir con ello para considerarse terminadas.
Ejemplo:
- Manual de usuario
- Código escrito
- Pruebas unitarias
- Pruebas de integración

Actividad
Enliste las actividades y responsabilidades de cada uno de los
roles durante el Sprint Planning.
Product Owner Equipo de desarrollo Scrum Master

27
 3.2. Reunión diaria de pie
La reunión diaria es para que el Equipo sincronice sus
actividades y cree un plan para las siguientes 24 horas, esta
reunión promueve la colaboración entre los distintos miembros
que integran el equipo, se deben realizar a la misma hora y lugar
todos los días, se busca que participen todos los miembros, pero,
aunque falten, es imposible de cancelar.
Reunión diaria de pie para una iteración
Cada miembro debe responder:
- ¿Qué hice ayer?
- ¿Qué haré hoy para ayudar al Equipo a lograr el Objetivo de
la iteración?
- ¿Estoy enfrentando algún obstáculo o impedimento?
Es importante considerar que:
- Debe ser una reunión “cara a cara”.
- Es una reunión de transmisión de información.
- Cualquier discusión o resolución de problemas se debe hacer
después.
- El facilitador recolecta información sobre los problemas e
impedimentos y, posteriormente, se ocupa de su resolución.
- Se ocupa para:
- Mejorar la comunicación.
- Identificar impedimentos.
- Mejorar el nivel de conocimiento de todo el equipo.
- Ayudar a incrementar la probabilidad de que el
equipo cumpla con los objetivos fijados.
- Promueven la toma de decisiones rápida.
Reunión diaria de pie para una práctica basada en el flujo
Se centra en el rendimiento del equipo, evaluando el tablero de
derecha a izquierda:
- ¿Qué necesitamos para hacer avanzar este trabajo?
- ¿Hay alguien trabajando sobre algo que no esté en el
tablero?
- ¿Qué necesitamos trabajar como equipo?
- ¿Existe algún cuello de botella o algún obstáculo en el
flujo de trabajo?
La Figura 17 presenta un ejemplo del tablero utilizado y la Figura
18 un ejemplo de la reunión.

28
 Figura 17: Ejemplo de tablero

Figura 18: Ejemplo de reunión

3.3. Ejecución de la iteración

Su foco es el desarrollo de las actividades para producir el
incremento del producto.
El equipo en conjunto con el facilitador monitorean el trabajo
que ha sido realizado.
El equipo hace foco en la calidad de la entrega, incorporando
prácticas que les permitan integrar resultados y detectar
posibles defectos.
Duración de entre 2 y 4 semanas para recibir retroalimentación
de manera regular.
El esfuerzo principal recae en los miembros del equipo, quienes
se auto-organizan para tomar decisiones en relación la forma de
desarrollar los entregables.

29
El Product Owner actúa como un puente entre el equipo Scrum y
los interesados, proveyéndolos de información relevante para el
desarrollo del incremento del producto.
El Facilitador es el responsable de asegurar que durante el
desarrollo de la iteración no existan impedimentos para los
miembros del equipo.
3.4. Revisión o demostración de la iteración
El Equipo presenta los resultados obtenidos de la iteración al
Product Owner, y otros interesados, quien valida el
cumplimiento de los requerimientos según los criterios de
aceptación definidos.
El equipo demuestra todos los elementos que han sido
completados.
En esta reunión se pretende que el equipo muestre un producto
funcional que refleje el compromiso adquirido.
Como resultado de la reunión se aprueba o rechaza los
requerimientos presentados.
3.5. Retrospectivita de la iteración
La retrospectiva de la iteración es una oportunidad para que el
equipo reflexione, se inspeccione a sí mismo y elabore un plan de
mejoras que sean abordadas durante la siguiente iteración. Con
esta reunión se pretende:
- Inspeccionar cómo fue la última iteración.
- Identificar y ordenar las posibles mejoras.
- Crear un plan para implementar las mejoras a la forma en la
que el Equipo Scrum desempeña su trabajo.
3.6. Creación de la lista de requerimientos del producto
(Product Backlog)
Es un inventario del trabajo del equipo desarrollo.
Product Backlog Items (PBI): Épicas o Historias de Usuario
Es una lista priorizada de las características del producto.
Mantenida por el Product Owner.
Es dinámica:
- Se pueden añadir funcionalidades
- Se pueden eliminar funcionalidades
- Reorganización cada vez que se incluye o elimina una
funcionalidad
Es pública, visible y transparente.

30
Product Backlog Items / Historias de usuario
Es una característica o funcionalidad que puede ser desarrollada
dentro de una iteración.
Idealmente, pueden ser desarrollados de forma independiente,
es decir, no existen dependencias entre ellos.
Pueden ser expresados a través de historias de usuario.
Se estiman en función de la capacidad y características del
equipo.
En la Figura 19 se presenta un ejemplo de Product Backlog,
considerando todos los elementos que debe contener.

Figura 19: Product Blacklog

Estimación Puntos de historia

Un punto de historia es un número que representa la apreciación
del equipo en cuanto al “tamaño relativo” de una historia
(Complejidad-Conocimiento-Incertidumbre). Los puntos de
historia son relativos y no están relacionados con una medida
específica. Se utiliza como herramienta comparativa entre
historias o PBIs.
Técnica de Estimación: Planning Poker.
Es una técnica en la cual todo el equipo participa y se utiliza el
juicio experto y la analogía de forma combinada. En la Figura 20
se presenta un ejemplo.

31
 Figura 20: Planning Poker

Actividad
Use la técnica de “Planning Poker”
para estimar el tamaño relativo de
los animales.
Nombre un Product Owner.
Como equipo escojan el más
pequeño.
Estimen comparativamente con el
resto de los animales usando la escala
acordada.

Calidad Historias de Usuario – Técnica “INVEST”

Es una técnica para asegurar la calidad en la escritura de
historias de usuario, priorizando el cumplimiento de las
siguientes características:
I - Independent (independiente)
N - Negotiable (negociable)
V Valuable (valiosa)
E - Estimable (estimable)
S - Small (pequeña)
T - Testable (certificable)
Product Backlog Items / Priorización
Los elementos del product backlog se priorizan considerando:
- Valor para el negocio: los componentes de mayor valor
se colocan de primeros (ROI Estimado).
- Riesgo: los componentes asociados a un alto riesgo con
alta prioridad.

32
El product Owner es el responsable de ordenar el product
backlog de acuerdo a las prioridades del negocio.
Técnicas de priorización:
Esquema de Priorización MoSCoW (ver Figura 21). Se analizan
los requerimientos considerando los siguientes criterios “Must
have (Debe tener)”, “Should have (Debería tener)”, “Could have
(Podría tener)” y “Will not have (No tendrá)” (Won’t have now
but Would be later).

Figura 21: Esquema MoSCoW

Método de los 100 Puntos: Se trata de darle al customer 100

puntos que pueden usar para votar por los requisitos que son
más importantes. El objetivo es dar más peso a los que son de
mayor prioridad en comparación con otros. Cada miembro del
grupo asigna puntos a las diversas características, dando más
puntos a los que se sienten son más importantes. Al finalizar el
proceso de votación, la priorización se determina calculando el
total de puntos asignados a cada uno.
3.7. Refinamiento de la lista de requerimientos (Product
Backlog)
El Product Owner en conjunto con el equipo trabajan en la
construcción de las historias de usuario que serán abordadas en
la próxima iteración.
Dedican al menos 1 hora semanal dentro de la iteración para
revisar los requerimientos.
El propósito de esta reunión es que el equipo entienda el trabajo
a realizar y pueda entender sus dimensiones y relación con las
demás historias.
Plan de trabajo de la iteración
El plan de trabajo para la iteración muestra una lista de
características seleccionadas del Product Backlog para
desarrollar durante la ejecución.
El equipo es el propietario y administrador de este plan de
trabajo.
Representa el compromiso del equipo durante la iteración.

33
Es actualizado cada vez que emerja o pierda vigencia el trabajo
necesario para cumplir con el objetivo y alcance fijado.
Plan de trabajo de la iteración: tableros visuales de
información
Los tableros tipo Kanban son comúnmente utilizado para dar
visibilidad y transparencia al trabajo de la iteración (ver Figura
22). Solamente se muestra el trabajo del sprint en curso.

Figura 22: Ejemplo

Incremento de producto
Es la suma de todos los requisitos del producto completados
durante el sprint (PBI o Historias de Usuario).
El producto es la suma de todos los incrementos.
Es usable y funciona.
Es potencialmente liberable.
Tiene que estar “Terminado”
- De acuerdo a los estándares de calidad establecidos por
el equipo.
- Sin trabajo pendiente (Deuda Técnica).
Plan de lanzamiento del producto (Release Planning)
- Definir el plan de lanzamiento de producto implica
establecer compromisos de entrega de sus características a
través del tiempo.
- El product owner es el responsable de crear este plan en
conjunto con el equipo.
- El plan da visibilidad al momento en el tiempo en que cada
característica es liberada al mercado en un tiempo
determinado.

34
 Actividad
Ejercicio La fábrica de aviones
En cada equipo estarán presentes los 3 roles centrales de un
equipo ágil.
Cada equipo deberá fabricar tantos aviones como sea posible.
Criterios de aceptación de los aviones:
- Deben volar 5 metros
- Deben tener escrito el nombre del equipo constructor
- Deben tener escrito el código del avión
- Deben tener 2 puertas y 3 ventanas de cada lado

35
4. UNIDAD 4: CONSIDERACIONES EN LA ADOPCIÓN
En esta unidad se abordarán las consideraciones y desafíos en la
adopción de métodos ágiles:
- Cultura organizacional
- Métricas
- Contratos

Actividad en equipo
1. ¿Qué prácticas ágiles se pueden implementar desde ya en
su organización?
2. ¿Cuáles son los factores que facilitan la adopción de
agilidad en su organización?
3. ¿Cuáles son los factores que dificultan la implementación
de la agilidad en su organización?

4.1. Cultura organizacional

¿Está mi organización lista para adoptar métodos agiles?
¿La empresa trabaja en equipo, delega, promueve la creatividad
y mejora continua?
¿Cuál es el nivel de involucramiento de nuestros clientes en los
proyectos?
¿La dirección de la empresa cree en el valor de la gente,
fomentando la colaboración, la auto gestión y la conformación de
equipos multidisciplinares?
¿Somos capaces de comprometernos con otros y de colaborar
para alcanzar un objetivo común?
¿Estamos dispuestos a flexibilizar los cambios y aceptarlos de
manera natural?
Desafíos
Cambio Paradigma: De alcance fijo a Tiempo fijo
Gobernabilidad: Nivel Portafolio y adecuar métricas
Tipos de Contrato:
- No Precio Fijo
- Opciones:
- Time and Material (muy riesgosa)
- Costo reembolsable más incentivos (compartir riesgo)
- Por unidad
Niveles de gobernabilidad
Se definen tres niveles de gobernabilidad, los cuales se pueden
ver en la Figura 23.

36
 Figura 23: Nivel de gobernabilidad

¿Qué cambia en un modelo ágil?

NO cambia el nivel estratégico ni táctico
SI cambia a nivel de proyecto:
- Criterios de éxito
- Estructura
- Modelo de toma de decisiones
- Métricas relevantes
4.2. Métricas
Comparación de paradigmas
En la Tabla 5 se presenta la comparación del paradigma
tradicional y el paradigma ágil.
Tabla 5: Paradigma tradicional vs Paradigma ágil

Paradigma tradicional Paradigma ágil

- Desviación de Plazos y - Valor generado (Basado en las
Costo User Story Terminadas/ROI)
- Aseguramiento Calidad - Productividad (User Story
(Adherencia al proceso) Points/Sprint)
- Alcance (Control de - Control de Calidad (Defectos en
cambios) funcionalidad ya liberada)
- Control Calidad - Riesgo (Perfil de Riesgo del
(Defectos), Proyecto)
- Riesgos (perfil de riesgo - Bloqueos (Incidentes por
del proyecto) resolver)
- Bloqueos (Incidentes por
resolver)

Métricas de agilidad
Las métricas en agilidad son empíricas.
La agilidad mide lo que el equipo entrega, no lo que predice que
entregará.

37
La agilidad se basa en entregar productos funcionales de valor
para el cliente.
Velocidad: Valor relativo del trabajo que es completado por el
equipo en un período de tiempo fijo expresado en puntos de
historia.
Los equipos ágiles basados en flujos miden: tiempo de entrega,
tiempo de ciclo y tiempo de respuesta.
Burndown Chart (Gráfico del trabajo restante o pendiente)
Un gráfico de trabajo pendiente a lo largo del tiempo muestra la
velocidad a la que se está completando los objetivos/requisitos.
Permite extrapolar si el Equipo podrá completar el trabajo en el
tiempo estimado. Un ejemplo de esto se muestra en la Figura 24

Figura 24: Burndown Chart

Los gráficos de burn up tienen más sentido cuando se enfocan en

el trabajo entre iteraciones (ver Figura 25)

Figura 25: Burnup Chart

38
Los cambios de alcance son evidentes de inmediato en Burn Up
Charts. Cuando se agregue nuevo trabajo, la línea de trabajo total
(que generalmente es plana y constante) mostrará claramente el
aumento en el alcance y el trabajo total.
Los equipos que trabajan basados en un flujo utilizan diferentes
medidas: tiempo de entrega, tiempo de ciclo y tiempo de
respuesta.

Figura 26: Tablero Kanban

La gráfica del flujo de valor acumulado es una herramienta que

permite evidenciar los cuellos de botella.
En esta gráfica la acumulación del trabajo se puede ver a simple
vista en la Figura 27.

Figura 27: Métricas de agilidad

39
 4.3. Contratos
Money for nothing
El cliente puede finalizar el proyecto antes de la fecha estimada
inicialmente si así lo considera oportuno, ver Figura 28.

Figura 28: Money for nothing

Change for free

El cliente puede introducir tantos cambios de alcance al proyecto
como estime conveniente, ver Figura 29.

Figura 29: Change for free

Tiempo y materiales graduados

- Es un enfoque de riesgo financiero compartido.
- El proveedor puede ser recompensado con una tarifa horaria
más alta si la entrega se produce antes del plazo contratado.
- El proveedor recibe una tarifa reducida si por el contrario se
retrasa en la entrega.
- Ejemplo: Precio por hora de 50 dólares para un proyecto de
1 año, si el proveedor lo entrega entre 1 día y 2 meses antes

40
 se le paga una tarifa de 60 dólares, si por el contrario se
retrasa entre 1 día y 2 mes la tarifa a recibir será de 44
dólares por hora.
Sin exceder tiempo y materiales
- Se limita el presupuesto global a un monto fijo.
- Esto permite al cliente incorporar nuevas ideas o
innovaciones que no fueron previstas originalmente.
- El trabajo debe ser monitoreado de cerca para no exceder las
horas fijadas.
Precio fijo por paquetes de trabajo (Historias de Usuario)
Establece acuerdos entre el cliente y el proveedor a través de
paquetes de trabajo con alcance concreto.
¿Cómo implementar?
- Seleccionar equipo de adopción
- Motivar
- Capacitar
- Acompañar
- Evaluar
- Convencer
- Capacitarse
- Pedir Ayuda
- Evaluar
- Compartir
- Comunicar, Comunicar, Comunicar
Resistencia al cambio
Especialmente de quienes pierden poder o autoridad.
El rol del Jefe de Proyecto se divide en los tres roles centrales
Pueden no entender su nuevo rol y como contribuir al éxito del
equipo.
La gente que ha invertido en las metodologías tradicionales
también puede resistir.
Manteniendo el compromiso de los Stakeholders
Informe adecuadamente a todos los cambios en la forma de
trabajo.
Establezca un acuerdo de trabajo de colaboración.
Comunique los progresos del equipo y el desarrollo de
capacidades, de manera de generar expectativas realistas acerca
de alcance, tiempo y costo.
Soporte Ejecutivo
Comuníquese regularmente con quienes financian el proyecto de
implementación.
Es importante que conozcan:

41
- Los beneficios que otorga a la organización.
- Los costos y fechas de la implementación.
- Cuáles son los riesgos y su estrategia de abordaje.
Manténgalos conscientes del nivel de avance y resultados
obtenidos
Infórmelos de cualquier problema, especialmente los que
pueden afectar los resultados de los proyectos con los que inicia
la implementación.

42
5. REFERENCIAS
[1] J. Highsmith, “Manifiesto por el Desarrollo Ágil de
Software,” 2002. [Online]. Available:
http://agilemanifesto.org/iso/es/manifesto.html.
[2] PMI, Agile Practice Guide. 2017.
[3] PMI, Project Management Body of Knowledge (PMBoK) 6o
Edición. 2017.
[4] “Which Life Cycle Is Best For Your Project.” [Online].
Available: http://www.pmhut.com/which-life-cycle-is-
best-for-your-project%0A.
[5] Takeuchi and Nonaka, “The New New Product
Development Game,” Harv. Bus. Rev., 1986.
[6] J. Hismith and K. Schwaber, Lean Software Development:
An Agile Toolkit. .

43