TALLER DE PREPARACIÓN PARA EL

EXAMEN DE CERTIFICACIÓN PMP

Ing. José Francisco Ojeda

Romero| PMP®,
José MBA
Francisco Ojeda
MBA, Ingeniero y PMP
Instructor Certificado por el PMI

1
Los materiales de este curso están basados en las
siguientes fuentes:
• Project Management Institute, A Guide to the Project
Management Body of Knowledge, (PMBOK® Guide) -
Sexta Edición, Project Management Institute, Inc.
2017
• Guía Práctica Ágil publicada por el PMI en asociación
con la Agile Alliance, 2017.
• PMI Authorized PMP Exam Prep – Course Edition,
Project Management Institute, Inc. 2020

2
EL PROJECT MANAGEMENT INSTITUTE
(PMI)
Project Management Institute (PMI®), con sede en Estados Unidos:
Es una asociación sin fines de lucro, con cerca de 1 M de miembros en más de 190 países.
Está orientada a difundir la profesión de Dirección de Proyectos a través de estándares y
certificaciones reconocidas mundialmente.
En 1984, el PMI® creó la titulación PMP® (Project Management Professional), Profesional
de la Dirección de Proyectos. Las empresas que quieren asegurar el éxito en sus proyectos
críticos, asignan PMPs para que los dirijan.
El cuerpo de conocimientos básico que aplica a todos los proyectos está muy bien
estructurado en la Guía del PMBOK® (guía de los fundamentos para la dirección de
proyectos, estándar ANSI que está en su 6ª edición y es consistente con el estándar ISO
21500).

Primera Edición Segunda Edición Tercera Cuarta Edición Quinta Edición

(1996) (2000) Edición (2008) (2012)
(2004)
Sexta Edición (2017)

3
 ESTRUCTURA A SEGUIRSE EN EL
CURSO
• Se efectuará revisiones por áreas de conocimiento con ejemplos y casuística.
• Se tomará tests por áreas de conocimiento con preguntas similares a las del
examen de certificación, buscando reafirmar los conceptos presentados.
• Al final del curso se realizará un simulacro (de número variable) de
preguntas, de acuerdo al grado de avance de los alumnos, pero siempre
usando preguntas similares al del examen de certificación..

4
 CONTENIDOS DEL CURSO
• Requisito 1: Introducción a la dirección de proyectos
• Requisito 2: Fundamentos básicos de la dirección de proyectos
• Requisito 3: Enfoque ágil en la gestión de proyectos
• Lección 1: Creación de un equipo de alto desempeño
• Lección 2: Inicio de un proyecto
• Lección 3: Haciendo el trabajo
• Lección 4: Manteniendo al equipo encaminado
• Lección 5: Manteniendo el negocio en mente
• En todas las sesiones se dejará preguntas de revisión o “Mastery
Builders” (o Constructores de Maestría)
• Simulacros de 180 y 60 preguntas y revisión.

5
 REQUISITO 3
ENFOQUE ÁGIL PARA LA
DIRECCIÓN DE PROYECTOS Y
TEMAS CLAVE

6
 CONTENIDOS DEL REQUISITO 3
I. Enfoque ágil en la dirección de proyectos
II. Temas clave de enfoque ágil en la dirección de proyectos

7
• Fuente: Los materiales están basados en el
libro Agile Practice Guide, creado por el PMI
en asociación con la Agile Alliance, 2017.

8
 REQUISITO 3:
I) ENFOQUE ÁGIL EN LA
DIRECCIÓN DE PROYECTOS

9
1. INTRODUCCIÓN AL
ENFOQUE ÁGIL

10
TRABAJO DEFINIBLE VS. TRABAJO DE ALTA
INCERTIDUMBRE (1/2)
• El trabajo de los proyectos varía desde el trabajo definible hasta el trabajo
de alta incertidumbre.

• Los proyectos de trabajos definibles se caracterizan por procedimientos

claros que han tenido éxito en el pasado en proyectos similares.

• La producción de un automóvil, un electrodoméstico o una vivienda,

después de completar el diseño, son ejemplos de trabajos definibles.

• El dominio de la producción y los procesos involucrados son generalmente

bien entendidos, y normalmente existen bajos niveles de incertidumbre y
riesgo de ejecución.

11
TRABAJO DEFINIBLE VS. TRABAJO DE ALTA
INCERTIDUMBRE (2/2)
• Los proyectos de alta incertidumbre exhiben altas tasas de cambio,
complejidad y riesgo.

• Las anteriores características pueden presentar problemas para los enfoques

predictivos tradicionales que apuntan a determinar la mayor parte de los
requisitos al inicio, y a controlar los cambios a través de un proceso de solicitud
de cambio.

• En cambio, los enfoques ágiles fueron creados para explorar la viabilidad en

ciclos cortos, y adaptarse rápidamente en función de la evaluación y la
retroalimentación.

12
 LOS CUATRO VALORES DEL MANIFIESTO AGIL

1. Los Individuos e interacciones valen más que los

procesos y las herramientas.
2. El Software que funciona vale más que una
documentación completa.
3. Vale más la colaboración con el cliente que la
negociación del contrato con él.
4. Responder al cambio vale más que seguir un plan.
(El Manifiesto Ágil dice que hay valor en los elementos
sin subrayar, pero valora más los elementos en
negrita y subrayados).

13
 LOS DOCE PRINCIPIOS DETRÁS DEL
MANIFIESTO AGIL (1/2)
1.La máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de
software con valor.
2.Los cambios a los requerimientos son bienvenidos, incluso en etapas avanzadas del
desarrollo. Los procesos ágiles aprovechan el cambio para lograr la ventaja competitiva del
cliente.
3.Entregar software funcional con frecuencia, desde un par de semanas a un par de meses,
con preferencia por la escala de tiempo más corta.

4.El negocio y los desarrolladores deben trabajar en conjunto todos los días durante
todo el proyecto.
5.Construir proyectos alrededor de individuos motivados. Darles el entorno y el apoyo
que necesiten, y confiar en ellos para hacer el trabajo.
6.El método más eficiente y eficaz de transmitir información a un equipo de desarrollo, y
dentro de él, es la conversación cara a cara.

14
 LOS DOCE PRINCIPIOS DETRÁS DEL
MANIFESTO AGIL (2/2)
7. El software que funciona es la medida principal del progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios deberían poder mantener un ritmo constante en forma
indefinida.
9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
10. La simplicidad es esencial.

11. Las mejores arquitecturas, requerimientos y diseños surgen de equipos auto-

organizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

15
LA RELACIÓN ENTRE LOS VALORES, PRINCIPIOS Y
PRÁCTICAS COMUNES DEL MANIFESTO AGIL

Mentalidad
ágil

4 12
Valores Principios
Prácticas

Ágil es una mentalidad definida por valores, guiada por principios y que se manifiesta
a través de muchas prácticas diferentes. Los profesionales practicantes de
ágil seleccionan prácticas basadas en sus necesidades.

16
PENSAMIENTO LEAN

Lean

Ágil

Kanban
ScrumBan

Crystal
AU
Scrum P
FD
X
D
P DSD
M

17
2. SELECCIÓN DEL CICLO DE VIDA
DEL PROYECTO

18
 SELECCIÓN DEL CICLO DE VIDA
DE UN PROYECTO
Esta guía práctica se refiere a cuatro tipos de ciclos de vida, definidos de la
siguiente manera:
• Ciclo de vida predictivo. Un enfoque más tradicional, en el que la
mayor parte de la planificación ocurre por adelantado, y luego se
ejecuta en una sola pasada; es un proceso secuencial.
• Ciclo de vida iterativo. Un enfoque que permite obtener
retroalimentación para el trabajo sin terminar, a fin de mejorar y
modificar ese trabajo.
• Ciclo de vida incremental. Un enfoque que proporciona entregables
terminados que el cliente puede utilizar de inmediato. Busca la
velocidad en las “entregas” (productos usables).
• Ciclo de vida ágil. Un enfoque que es tanto iterativo como incremental
a fin de refinar los elementos de trabajo y poder entregar con
frecuencia.

19
 CARACTERÍSTICAS DE LOS CICLOS
DE VIDA DE LOS PROYECTOS
Características

Enfoque
Requisitos Actividades Entrega Meta

Gestionar alcance
Predictivo Se trata de
Realizados una vez Entrega única tiempo y costos, junto
determinar todos al
a los riesgos y la
comienzo. para todo el proyecto
calidad
Iterativo Entrega única, luego
Dinámicos Repetidos hasta que de varias iteraciones Corrección de la
esté correcto que reciben solución
retroalimentación
Incremental
Dinámicos Realizados una vez para Entregas frecuentes
Velocidad
un incremento dado más pequeñas

Ágil Valor para el cliente

Dinámicos Repetidos hasta que Entregas pequeñas
mediante entregas
esté correcto frecuentes
frecuentes y
retroalimentación

20
EL CONTINUO DE LOS CICLOS
DE VIDA DE LOS PROYECTOS

Alt
o
Incremental Ágil
Frecuencia de Entrega

uo
tin
n
Co

Predictivo Iterativo
Baj
o

Baj Alt
o Grado de Cambio o

21
CICLO DE VIDA DE PROYECTO “ADECUADO” (1/2)

Ningún ciclo de vida puede resultar perfecto para todos los proyectos. Por el
contrario, cada proyecto encuentra un punto en el continuo que proporciona
un equilibrio óptimo de características para su contexto. Específicamente,

* Ciclos de vida predictivos. Aprovechan las cosas que son conocidas y

probadas. Esta reducción en incertidumbre y complejidad permite a los
equipos segmentar el trabajo en una secuencia de agrupaciones predecibles.
* Ciclos de vida iterativos. Permiten obtener retroalimentación sobre
trabajo parcialmente terminado o sin terminar, a fin de mejorarlo y
modificarlo.

22
CICLO DE VIDA DE PROYECTO “ADECUADO” (2/2)

* Ciclos de vida incrementales. Proporcionan entregables terminados que

el cliente puede utilizar de inmediato.
* Ciclos de vida ágiles. Aprovechan tanto los aspectos de las
características iterativas como los de las incrementales. Cuando los
equipos usan enfoques ágiles, iteran sobre el producto a fin de crear
entregables terminados. El equipo obtiene retroalimentación temprana y
proporciona al cliente visibilidad, confianza y control sobre el producto.
Puesto que el equipo puede liberar más temprano, el proyecto puede
lograr un retorno sobre la inversión anticipado, ya que el equipo entrega el
trabajo de mayor valor en primer lugar.

23
 3. IMPLEMENTACIÓN DE ÁGIL:
CREACIÓN DE UN ENTORNO ÁGIL

24
COMENZAR CON UNA MENTALIDAD ÁGIL
• La gestión de un proyecto utilizando un enfoque ágil requiere que el
equipo del proyecto adopte una mentalidad ágil.
• Las respuestas a las siguientes preguntas ayudarán a desarrollar una
estrategia de implementación
• ¿Cómo puede el equipo del proyecto actuar de manera ágil?
• ¿Qué puede el equipo entregar rápidamente y obtener
retroalimentación temprana a fin de beneficiar al siguiente ciclo de
entrega?
• ¿Cómo puede el equipo del proyecto actuar de manera transparente?
• ¿Qué tipo de trabajo se puede evitar para concentrarse en elementos
de alta prioridad?
• ¿Cómo puede un enfoque de liderazgo de servicio beneficiar al logro
de los objetivos del equipo?

25
 EL LIDERAZGO DE SERVICIO

• Los enfoques ágiles enfatizan el liderazgo de servicio como una forma

de empoderar a los equipos.
• El liderazgo de servicio es la práctica de liderar a través del servicio al
equipo, centrándose en la comprensión y abordando las necesidades y
el desarrollo de los miembros del mismo con el fin de permitir el
máximo desempeño posible del equipo.

26
 RESPONSABILIDADES DEL LÍDER DE
SERVICIO (1/2)
• Los líderes de servicio manejan las relaciones para crear comunicación y
coordinación dentro del equipo y en toda la organización. Estas relaciones
ayudan a los líderes a navegar por la organización a fin de prestar soporte
al equipo.

• Este tipo de soporte ayuda a eliminar los impedimentos y orienta al equipo

para simplificar sus procesos.

• Debido a que los líderes de servicio entienden la agilidad y practican un

enfoque específico para ágil, pueden ayudar a satisfacer las necesidades del
equipo.

27
 RESPONSABILIDADES DEL LÍDER DE
SERVICIO (1/2)
Rol de un Líder de Servicio en un entorno Ágil

Facilita
Eliminan impedimentos

Allanan el camino

28
ROL DE UN DIRECTOR DE PROYECTO EN UN
ENTORNO ÁGIL

• En un entorno ágil, los directores de proyecto son líderes de servicio,

cambian 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.
• Como líderes de servicio, los directores de proyecto fomentan la
distribución de la responsabilidad al equipo: hacia aquellas personas que
tienen los conocimientos necesarios para realizar el trabajo.

29
 ROLES DE LOS EQUIPOS ÁGILES
Rol Descripción

Miembro de equipo Los equipos multidisciplinarios constan de miembros del equipo con todas las habilidades necesarias para producir
un producto funcional. En el desarrollo de software, los equipos multidisciplinarios suelen estar compuestos por
multidisciplinario diseñadores, desarrolladores, especialistas en pruebas y demás roles requeridos. Los equipos multidisciplinarios de
desarrollo están formados por profesionales que ofrecen productos potencialmente entregables, con una cadencia
periódica. Los equipos multidisciplinarios resultan críticos porque pueden entregar trabajos terminados en el
menor tiempo posible, con mayor calidad, sin dependencias externas

Dueño del producto El dueño del producto es el encargado de guiar la orientación del mismo.
Los dueños del producto clasifican el trabajo en función de su valor comercial. Los dueños del producto
trabajan con sus equipos diariamente, proporcionando retroalimentación del producto y estableciendo la
dirección para la próxima pieza de funcionalidad que será desarrollada/entregada. Eso significa que el
trabajo es reducido, a menudo lo suficientemente pequeño para ser descrito en una tarjeta.
El dueño del producto trabaja con los interesados, los clientes y los equipos a fin de definir la dirección
del producto. Típicamente, los dueños del producto tienen un trasfondo empresarial y aportan a las
decisiones una profunda experiencia sobre el tema. A veces, el dueño del producto solicita ayuda de
personas con profunda experiencia en los dominios, tales como los arquitectos, o experiencia profunda
con los clientes, tales como los gerentes de productos Los dueños del producto necesitan capacitación
sobre cómo organizar y manejar el flujo de trabajo a través del equipo.
En el método ágil, los dueños del producto crean la lista de trabajo pendiente para y con el equipo. La
lista de trabajo pendiente ayuda a los equipos a ver cómo entregar el valor más alto sin crear
desperdicios.

Facilitador del equipo El tercer rol típicamente visto en los equipos ágiles es de un facilitador de equipo, un líder
de servicio. Este rol puede ser denominado un director de proyecto, Scrum Master, líder
de equipo de proyecto, coach de equipo o facilitador de equipo.
Todos los equipos ágiles necesitan liderazgo de servicio sobre el equipo. La gente necesita
tiempo para desarrollar sus habilidades de liderazgo de servicio de facilitación, coaching y
eliminación de impedimentos.

30
DEDICACIÓN DE LOS MIEMBROS DEL
EQUIPO
• ¿Qué sucede cuando el tiempo de los miembros no está en un 100%
dedicado al equipo? Si bien esta condición no es ideal,
lamentablemente a veces no se puede evitar.
• El problema central de tener a alguien que invierte solo el 25% o 50%
de su capacidad en el equipo es que realizará varias tareas a la vez y
deberá cambiar de tarea.
• La multitarea reduce el rendimiento del trabajo del equipo e impacta
la capacidad del equipo para pronosticar la entrega de manera
consistente.

31
 CÓMO APLICA PMI EL AGILISMO
Área del PMBOK Aplicación en un trabajo con Ágil
Integración Los miembros del equipo van integrando planes y componentes, el PM debe establecer un entorno
colaborativo.
Alcance El alcance al principio no se detalla todo y se va perfeccionando en la medida que se profundiza.

Cronograma Se utiliza programación iterativa, predictiva o híbrida según el tamaño y el enfoque del proyecto.
Calendario de liberaciones.
Costos Se utilizan métodos de estimación ligera para pronosticar los costos del proyecto que se van
ajustando.
Calidad Dada por la cercanía equipo – cliente. También por los criterios de aceptación y la “Definición de
Listo o Hecho”. Se usa la retrospectiva para buscar la causa-raíz de los incidentes y se generan
nuevos enfoques para validar la calidad en las entregas.

Recursos Equipos auto-organizados con especialistas generalizados maximizan el enfoque

Comunicaciones En productos cambiantes se requiere comunicación ágil.

Riesgos Lo riesgos se identifican en las iteraciones
Adquisiciones Modelo de contratación de riesgo compartido
Interesados Participación activa especialmente en proyecto de alto grado de cambio.

31
4. EJECUCIÓN DE UN PROYECTO ÁGIL:
CEREMONIAS Y/O PRÁCTICAS AGILES

33
 REUNIÓN CON LOS INICIO
INTERESADOS CREACION DE LA VISION
DEL PROYECTO

IDENTIFICACION DEL
Justificación LÍDER DEL PROYECTO
(USUALMENTE UN
Negocio FACILITADOR SENIOR O
¿Porque es “SCRUM MASTER”) E
necesario? INTERESADOS

FORMACION DEL EQUIPO

Costo de ÁGIL
Negocio
- Beneficio
Dueño de Producto
- Riesgo ó “Product Owner”
- Tiempo
Interesado o
Stakeholder
Declaración visión
proyecto
Necesidades y
objetivos
establecer

34
 INICIO DEL PROYECTO
“Las épicas son una gran historia de usuario que
INICIO
EPICA no puede completarse en una iteración. Por lo
tanto, las épicas se dividen en historias de
usuario más pequeñas las cuales podrán ser DESARROLLO DE
entregadas en distintas iteraciones” EPICAS
PRODUCT BACKLOG
Priorización con PRIORIZADO
“MOSCOW” (por
ejemplo) PLANIFICACION ÁGIL DE
1 Debe LAS LIBERACIONES
2 Podrá
3 Podría PLANIFICAR Y ESTIMAR
4 No tendrá CREAR USER STORY

Productos básicos RES

PO
NS
AB
LE
USER STORY
TITULO DESCRIPCION CRITERIOS “DEFINITION
Como…Quien… OF READY”
Beneficio DE
COLABORADOR
Prioridad Estimación ACEPTACION
INDEPENDENCIA
NEGOCIABLE as
tic
“Las historias de usuario son una breve descripción escrita VALORADAS e rís
t
ESTIMADAS arac
que representa un requisito o funcionalidad del proyecto PEQUEÑA C
Dueño de Equipo Ágil ó Scrum Team
utilizando el lenguaje común del usuario.” Producto ó
Product Owner
“Todas las historias de usuario forman parte del trabajo
pendiente asociado al producto (product backlog). Las
historias de usuario seleccionadas para desarrollar durante
las iteraciones definen el alcance del proyecto”

35
 REUNIÓN DE PLANEAMIENTO DE
PLANIFICAR Y ESTIMAR
LA ITERACIÓN O SPRINT APROBAR, ESTIMAR Y
8 horas COMPROMETERSE CON LAS
1 Sprint 1 Mes USER STORY

DOR CREAR TAREAS

LITA
FACI
ESTIMAR TAREAS
OBJETIVO DURACION
SPRINT SPRINT
SE CREA EL “SPRINT
BACKLOG”
“listado de
RESU
LTAD
O 1,1 tareas”
1,2
EN
IEN

1,3
ERV

O
AD
ENT
INT

R ES
REP
TODO D TES DONE ZOOM del
OI TIN
1,4
N
G
G
Product backlog
Equipo Ágil ó Scrum Team SCRUM BOARD

Objetivo Sprint
SPRINT BACKLOG
TO D D
Dueño de Producto o D O O
Como se va a realizar
Product O NE NE
Owner Cuanto va a durar

KAMBAN

36
 EL SPRINT 15
minutos
diarios DESARROLLAR/IMPLEMENTAR
CREAR LOS ENTREGABLES
DAILY
SE CREA REALIZAR REUNIONES DIARIAS

ADAPTACION
INCREMENTO DEL DE A PIE (DAILY STANDUPS)
PRODUCTO
TRANSPARENCIA INSPECC
ION
REFINAMIENTO DE LA
¿Qué termine ayer?
PRIORIDAD DEL PRODUCT
¿Qué voy a terminar hoy?
BACKLOG (si es necesario)
¿Qué impedimentos
Estoy enfrentando?

8%
Del Sprint
REFINAMIENTO

Equipo Ágil ó Scrum Team

1 1 1
2 3 3
RESPONSABLE 3 4 4
4 2 5
SEGUIR ESTANDARES 5 5 2
CUMPLIR CON EL “DONE”

37
 REUNIONES DE REVISIÓN
REUNIONES DE REVISIÓN Y RETROSPECTIVA
DEL SPRINT CONVOCAR REUNIÓN
4 horas
Por un Sprint
De un mes
DEMOSTRACIÓN Y VALIDACIÓN
SPRINT
RESTROSPECTIVA DEL SPRINT
ENTREGA

INCREMENTO LANZAMIENTO
ENTREGA DE BIENES Y SERVICIOS

RETROSPECTIVA DEL PROYECTO

REUNIÓN DE
RETROSPECTIVA DEL
Product CUMPLIMIENTO SPRINT
Equipo Ágil
Owner CRITERIOS DE LECCIONES
ACEPTACION APRENDIDAS

Equipo Ágil

Product
Owner
Interesado Interesado

38
5. PRÁCTICAS ÁGILES
COMUNES EN DETALLE

39
 1. PREPARACIÓN DE LA LISTA DE
TRABAJO PENDIENTE (BACKLOG) (1/2)
• La lista de trabajo pendiente está ordenada y contiene todo el
trabajo para un equipo, presentada en forma de historia (story).
• No es necesario crear todas las historias para todo el proyecto
antes de que se inicie el trabajo, solo lo suficiente para
comprender la primera versión en pinceladas amplias y, a
continuación, los elementos suficientes para la siguiente iteración.

40
 1. PREPARACIÓN DE LA LISTA DE
TRABAJO PENDIENTE (BACKLOG) (2/2)
• Los dueños del producto (o un equipo responsable del valor, que
incluya al gerente del producto y a todos los dueños de producto
relevantes para esa área) podrían elaborar una hoja de ruta de los
productos a fin de mostrar la secuencia anticipada de entregas a lo
largo del tiempo.
• El dueño del producto re planifica la hoja de ruta con base en lo que
el equipo produce.

41
2. PLANIFICACIÓN DE ÁGIL BASADA EN
ITERACIONES
• La capacidad de cada equipo es diferente.
• El tamaño de la historia típica de cada dueño del producto es
diferente.
• Los equipos toman en cuenta el tamaño de su historia (story) para
evitar comprometerse con más historias de las que el equipo puede
completar dentro de una iteración.
• Los equipos ágiles no planifican todo en un solo paso. Por el
contrario, los equipos ágiles planifican un poco, entregan, aprenden
y luego vuelven a planificar un poco más, en un ciclo continuo.
• El número de iteraciones o sprints se determina durante la
Planificación Ágil de Liberaciones

42
 3. REUNIONES DIARIAS DE PIE
(DAILY STANDUPS) (1/2)
• Los equipos usan reuniones de pie para comunicarse entre sí, descubrir
problemas y garantizar que el trabajo fluye sin problemas a través del
equipo.
• La reunión de pie se lleva a cabo en un período de tiempo
preestablecido de no más de 15 minutos.
• El equipo “recorre” el tablero Kanban o el tablero de tareas de alguna
manera, y cualquier persona del equipo puede facilitar la reunión de pie.

43
 3. REUNIONES DIARIAS DE PIE
(DAILY STANDUPS) (2/2)
En ágil basado en la iteración, todo el mundo responde a las siguientes
preguntas por turno:

* ¿Qué he completado desde la última reunión de pie?

* ¿Qué estoy planeando completar entre ahora y la siguiente reunión

de pie?

* ¿Cuáles son mis impedimentos (o riesgos o problemas)?

44
 4. RETROSPECTIVAS (1/2)
• La práctica más importante es la retrospectiva, ya que permite al
equipo aprender, mejorar y adaptar su proceso.
• Las retrospectivas ayudan al equipo a aprender de su trabajo
previo sobre el producto y su proceso.
• Uno de los principios que respaldan el Manifiesto de Ágil es: “A
intervalos regulares, el equipo reflexiona sobre cómo ser más
efectivo, para a continuación ajustar y perfeccionar su
comportamiento en consecuencia”.
• El equipo suele hacer una retrospectiva cuando completa una
liberación o envía algo. No necesita ser un incremento
monumental. Puede ser cualquier liberación, no importa que tan
pequeña.

45
 4. RETROSPECTIVAS (2/2)
• La retrospectiva no es acerca de culpar; la retrospectiva es un
momento para que el equipo aprenda de trabajos previos y haga
pequeñas mejoras.
• En la retrospectiva se trata de observar los datos cualitativos
(sentimientos de la gente) y cuantitativos (métricas), y luego usar
esos datos para encontrar causas raíz, diseñar respuestas y
desarrollar planes de acción.
• El equipo del proyecto podría acabar con muchas posibles acciones
a fin de remover los impedimentos.
• LA RETROSPECTIVA DEBE GENERAR ACCIONES DE MEJORA

46
 5. DEMOSTRACIONES/REVISIONES
• A medida que el equipo completa las características, normalmente en la
forma de historias de usuario, el equipo demuestra periódicamente el
producto funcional.
• El dueño del producto ve la demostración y acepta o rechaza las historias.
• En ágil basado en iteración, el equipo demuestra todos los elementos de
trabajo completados al final de la iteración.

47
6. PRÁCTICAS DE EJECUCIÓN QUE AYUDAN
A LOS EQUIPOS A ENTREGAR VALOR (*)
• Integración continua.

• Prueba a todos los niveles

• ATDD Desarrollo guiado por pruebas de aceptación (usualmente con el

usuario).
• TDD Desarrollo guiado por pruebas (incluye al refactoring) (usualmente
con áreas de calidad, pruebas asociadas a la conformidad técnica)
• Spikes (de investigación, de experimentación o de riesgos)
(*) Página 56 de la Guía Práctica Ágil

48
7. TEMAS SENSIBLES EN ÁGIL Y ALTERNATIVAS DE SOLUCIÓN DE PROBLEMAS
(1/2)
Tema Sensible Alternativas de Solución de Problemas
Propósito o misión poco clara para el equipo Constitución ágil para el propósito—visión, misión y pruebas de misión.

Acuerdos de trabajo poco claros para el equipo Constitución ágil para la alineación—valores, principios y acuerdos de trabajo.

El contexto del equipo no es claro Constitución ágil para el contexto—límites, activos comprometidos y análisis prospectivo.

Requisitos poco claros Ayudar a patrocinadores e interesados a elaborar la visión del producto. Considerar la
construcción de una hoja de ruta de productos usando especificaciones mediante ejemplo,
mapeo de historias de usuario y mapeo de impacto. Reunir al equipo y al dueño del producto
para aclarar las expectativas y el valor de un requisito. Descomponer progresivamente la hoja
de ruta en requisitos de trabajo pendiente concretos y más pequeños.
Mala experiencia del usuario Las prácticas de diseño de experiencia de usuario incluidas en el equipo de desarrollo involucran a
los usuarios al principio y a menudo.
Estimación imprecisa Reducir el tamaño de la historia dividiendo las historias. Utilizar la estimación relativa con todo
el equipo para estimar. Considerar la posibilidad de modelado ágil o Spikes para entender la
historia.
Asignaciones de trabajo o progreso del trabajo poco claros Ayudar al equipo a darse cuenta de que auto-gestionan su trabajo. Tomar en consideración los
tableros kanban para ver el lujo de trabajo. Tomar en consideración una reunión diaria de pie
(daily standup) para recorrer el tablero y ver dónde está cada trabajo.
El equipo lucha contra los obstáculos Un líder de servicio puede ayudar a eliminar estos obstáculos. Si el equipo no conoce las
opciones que tiene, considere involucrar a un facilitador. A veces, el equipo necesita escalar
las historias que equipo o el líder de servicio no ha podido eliminar.
Retrasos de trabajo/sobrecostos debido a la falta de Historias combinadas del dueño del producto y del taller del equipo. Crear una definición de
perfeccionamientos de algunos elementos de la lista de trabajo “listo” para las historias. Pensar en dividir historias para usar historias más pequeñas.
pendiente del producto.
Tomar en consideración las prácticas técnicas que funcionan para el entorno. Algunas
Defectos posibilidades son: trabajo en pares, responsabilidad colectiva del producto, pruebas de mayor
cobertura (enfoque guiado por pruebas y de pruebas automatizadas) y una definición robusta
de “terminado”.
El trabajo no está completo El equipo establece la definición de “terminado” para las historias, incluyendo los criterios de
aceptación. También agregar los criterios de liberación para los proyectos.
Deuda técnica (calidad del código degradada) Refactorización, modelado ágil, pruebas de mayor cobertura, análisis automatizado de la
calidad del código fuente, definición de “terminado”.

49
7. TEMAS SENSIBLES EN ÁGIL Y ALTERNATIVAS DE SOLUCIÓN DE PROBLEMAS
(2/2)
Tema Sensible
Demasiada complejidad del producto
Lenta o ninguna mejora en el proceso de trabajo en
equipo
Demasiado trabajo inicial que conduce al retrabajo
Inicios en falso, desperdicio de esfuerzos
Esquema de ordenamiento ineficiente de los elementos
de la lista de trabajo pendiente del producto
Flujo de trabajo desigual con
apuros/esperas
Demandas imposibles por parte de los
interesados
Retrasos inesperados o imprevistos
Equipos en silos, en lugar de equipos
multidisciplinarios
Alternativas de Solución de Problemas
Alentar al equipo a estar pensando siempre “¿cuál es la cosa más sencilla que podría funcionar?”,
y aplicar el principio ágil de “Simplicidad —el arte de maximizar la cantidad de trabajo no
realizado” —aplica para software y no software. Esto ayuda a reducir la complejidad.
Capturar no más de tres elementos a mejorar en cada retrospectiva. Pedir al líder de servicio
que ayude al equipo a aprender a integrar esos elementos.
En lugar de realizar mucho trabajo inicial, considerar los Spikes para el equipo, a fin de aprender.
Además, medir el trabajo en proceso (WIP, por sus siglas en inglés) durante el inicio del proyecto
y ver cuáles son las opciones del equipo para entregar valor en lugar de diseños. Acortar las
iteraciones y crear una definición robusta de “terminado”.
Pedir al dueño del producto que se convierta en una parte integral del equipo.
Clasificar de acuerdo al valor, incluyendo el costo del retraso dividido por la duración (CD3: cost of
delay divided by duration) y otros modelos de valor.
Planificar según la capacidad del equipo y no más. Pedir a las personas que dejen de realizar tareas
múltiples y se dediquen a un equipo. Pedir al equipo que trabaje en pares, o aplique swarming o
mobbing para equilibrar las capacidades de todo el equipo.
Aplicar liderazgo de servicio con este interesado (y posiblemente dueño del producto).
Pedir al equipo que se comunique más a menudo, use tableros kanban para ver el flujo de trabajo y
los límites de trabajo en progreso para entender el impacto de las demandas sobre el equipo o
producto. También hacer un seguimiento a los impedimentos y la eliminación de los mismos en un
tablero de impedimentos.
Pedir a las personas que forman parte de los proyectos que se auto-organicen como equipos
multidisciplinarios. Utilizar las habilidades de liderazgo de servicio para ayudar a los gerentes a
entender por qué los equipos ágiles necesitan ser multidisciplinarios.
50
8. MEDICIONES EN PROYECTOS ÁGILES (1/5)

• Ágil favorece métricas empíricas y basadas en valores en lugar de

métricas predictivas.
• Ágil mide lo que el equipo entrega, no lo que el equipo predice que
entregará.
• “Un equipo que esté acostumbrado a tener líneas de base del proyecto
y estimaciones del valor ganado y RSI (Retorno Sobre la Inversión),
puede no comprender como se trabaja en un proyecto ágil sin
manejarse de acuerdo con una línea base”.

51
8. MEDICIONES EN PROYECTOS ÁGILES (2/5)
Puntos de Historia Restantes
Algunos proyectos
basados en iteraciones
35
usan gráficas de
trabajo pendiente 30
(burndown) para ver
dónde va el proyecto 25
en el tiempo. El LEYENDA

gráfico muestra un 20
Puntos
ejemplo de una gráfica de
Historia
de trabajo pendiente 15 Restantes

en la que el equipo
10
planeaba entregar 37
puntos de historia. 5
Muchos equipos ágiles
usan puntos de historia 0
para evaluar el Día Día Día Día Día Día Día Día Día Día
1 2 3 4 5 6 7 8 9 10
esfuerzo. La línea
punteada de trabajo
pendiente es el plan. Gráfica de Trabajo Pendiente para los Puntos de Historia Restantes

52
8. MEDICIONES EN PROYECTOS ÁGILES (3/5)

Puntos de Historia Realizadas

35
Algunos equipos de
proyecto prefieren 30

gráficas de trabajo 25
realizado (burnup).
Los mismos datos 20
Puntos
utilizados en el de Historia
15 Realizadas
primer gráfico se
muestran en el 10
segundo gráfico, en
una gráfica de 5

trabajo realizado. 0
Día Día Día Día Día Día Día Día Día Día
1 2 3 4 5 6 7 8 9 10

Gráfica de Trabajo Realizado Mostrado Puntos de Historia Completados

53
8. MEDICIONES EN PROYECTOS ÁGILES (4/5)

• Los equipos ágiles basados en flujo utilizan diferentes medidas: tiempo de entrega (el tiempo total
que se tarda en entregar un elemento, medido desde el momento en que se agrega al tablero hasta el
momento en que se completa), tiempo de ciclo (el tiempo requerido para procesar un elemento), y el
tiempo de respuesta (el tiempo que un elemento espera hasta que empieza el trabajo).
• Los equipos miden el tiempo del ciclo para visualizar cuellos de botella y retrasos, no necesariamente
dentro del equipo.
• Los equipos pueden descubrir que lograr una velocidad estable puede tomar de cuatro a
ocho iteraciones

54
8. MEDICIONES EN PROYECTOS ÁGILES (5/5)
Tablero Kanban

Desarrollo y Prueba de
Listo Pruebas Desarrollado Sistema Completado
Unitarias

Tiempo de ciclo:
8 3 2 desde el momento
en que inicia una
tarea hasta que se
completa.

Entrega al cliente

Plazo de entrega: desde el

momento en que ingresa al
tablero hasta que se entrega.
Debido a que puede cambiar el
orden de los elementos en la
columna “Listo”, éste puede ser
impredecible.

Hay un límite sobre

esta columna.
Puede intercambiar
algo existente por
algo distinto en
cualquier momento.

55
 REQUISITO 3:
II) TEMAS CLAVE DE ENFOQUE
ÁGIL

56
 ENFOQUE ÁGIL
TEMAS CLAVE (1/4)
1.Leer el manifiesto ágil y la mentalidad ágil (Pag. 8 de la Guía Práctica Ágil)
2.Saber cuándo elegir el tipo de enfoque ágil que requiere mi proyecto y tener clara
la diferencias entre estos enfoques: (Pag. 17 a la 27 de la Guía Práctica Ágil).
A. Enfoque Incremental: Añado funcionalidad nueva en cada iteración gracias a la retroalimentación
del usuario y es más rápido (y el producto se puede usar desde la primera iteración o primer
grupo de iteraciones)
B. Enfoque Iterativo: Descubro mejoras requeridas y las aplico en cada iteración.
C. Enfoque Ágil en sí: Es una mezcla de los anteriores.

3.Beneficios de los tableros Kanban (Pag. 31 de la Guía Práctica Ágil)

4.Conocer el concepto de Liderazgo de Servicio o Liderazgo Servidor (Pags. 33 a la
37 de la Guía Práctica Ágil).
5.El líder de un proyecto ágil se enfoca principalmente en su equipo (Manifiesto Ágil.
Pag. 8 de la Guía Práctica Ágil)

57
 ENFOQUE ÁGIL
TEMAS CLAVE (2/4)
6.Rol del gerente de proyecto en un entorno ágil: Servir al equipo y a la gerencia. Es
el que asume el liderazgo servidor, y empodera. Aunque no precisamente, podría
decirse que es un coordinador de “facilitadores” y el facilitador numero uno. NO ES
EL DUEÑO DEL PRODUCTO, NI EL JEFE DEL EQUIPO. (Pags. 37 y 38 de la Guía Práctica
Ágil)
7.Roles en un equipo ágil de proyecto: (Pags. 40 y 41 de la Guía Práctica Ágil):
A. Dueño de producto: el que “delimita” el Alcance y responsable de mantenerlo.
B. Facilitador: (no es un Gerente de Proyecto o Jefe de equipo) sino el que hace posible que el
equipo trabaje sin problemas de acuerdo a lo que determinó el propio equipo.
C. Equipo multidisciplinario: especialistas en recopilar requisitos en el formato de historias de
usuario, programadores, especialistas en calidad, etc.

8.Equipos multitarea vs equipos dedicados. (Pag. 44 de la Guía Práctica Ágil).

9.Definiciones básicas de Ágil (Pags. 49 a 55 de la Guía Práctica Ágil)
A. Historias de usuario: Breves descripciones textuales de la funcionalidad requerida. Las historias
de usuarios describen el rol del interesado que se beneficia con la característica (rol), aquello que
el interesado necesita lograr (objetivo), el beneficio para el interesado (motivación) y los criterios
de aceptación (incluso, los “definition of ready”).

58
 ENFOQUE ÁGIL
TEMAS CLAVE (3/4)
9.Definiciones básicas de Ágil (continua:)
B. Product backlog: Lista de trabajo pendiente. Consiste en historias y épicas.
C. Sprints: Grupos de actividades para completar historias y épicas. Por defecto toman dos semanas.
D. Reuniones diarias de a pie: dan informes breves de avance y posiblemente alguna dificultad. Aquí no se
resuelven esas dificultades.
E. Retrospectivas: usualmente cada 15 días, cada finalización de un Sprint o en cada entrega significativa.

10. Se debe tener clara la particularidad de la gestión del Alcance en proyectos con
enfoque ágil (“circuito” Requisito >>> Entregable, sin definiciones elaboradas previas a
la construcción, desarrollo o implementación)).
11. La Planificación Ágil de Liberaciones determina la cantidad de iteraciones o sprints de la
liberación, y permite al responsable del producto y al equipo decidir cuánto es
necesario desarrollar y cuánto tiempo insumirá tener un producto liberable sobre la
base de las metas, dependencias e impedimentos del negocio.
12. La Calidad en entornos ágiles: El involucramiento de los interesados con el equipo
garantiza que la satisfacción del cliente se mantenga durante todo el proyecto
13. Revisar las prácticas de ejecución que ayudan a los equipos a entregar valor (Pag 56
de la Guía Práctica Ágil)
14. Revisar las sección (tabla) “Temas Sensibles en Ágil y Alternativas de Solución de
Problemas”(Pags 58 y 59)
59
 ENFOQUE ÁGIL
TEMAS CLAVE (4/4)
15. El PMI afirma: Los equipos Auto-organizados. Equipo que funciona con ausencia de
control centralizado. En los proyectos que tienen equipos auto-organizados, el rol de
director del proyecto (que no es propiamente un director del proyecto) proporciona al
equipo el entorno y el apoyo necesarios e impulsa al equipo para hacer el trabajo.
16. El PMI afirma: Los equipos auto-organizados exitosos por lo general consisten en
especialistas en temas generales en lugar de expertos en la materia, quienes
continuamente se adaptan a los cambios del entorno y aprecian la retroalimentación
constructiva.

60