TALLER DE

PREPARACIÓN PARA
EL EXAMEN DE
CERTIFICACIÓN PMP

• José Francisco Ojeda

MBA, Ingeniero y PMP
• Instructor Certificado por el PMI

1
Los materiales de este curso están basados en las siguientes
fuentes:

• PMI Authorized PMP Exam Prep – Course Edition VER 3.0, Project
Management Institute, Inc. 2023.

• 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.

• Project Management Institute, A Guide to the Project

Management Body of Knowledge, (PMBOK® Guide) - Séptima
Edición, Project Management Institute, Inc. 2017
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 Tercera Cuarta Edición Quinta

(1996) Edición Edición (2008) Edición
(2000) (2004) (2012)
 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

REQUISITOS:
• 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

CURSO DE PREPARACIÓN EN SÍ:

• Lección 1: Entorno de Negocio
• Lección 2: Iniciar el Proyecto
• Lección 3: Planificar el Proyecto
• Lección 4: Liderar al equipo
• Lección 5: Dar Soporte al Equipo del Proyecto
• Lección 6: Cerrar el Proyecto o Fase
REQUISITO 3:
ENFOQUE ÁGIL PARA LA DIRECCIÓN DE
PROYECTOS Y TEMAS CLAVE
6
 CONTENIDOS DEL REQUISITO 3

• Enfoque ágil en la dirección de proyectos

• Temas clave de enfoque ágil en la dirección de proyectos
 Fuentes: Las diapositivas siguientes están basadas en
el material autorizado por el PMI “Exam Prep –
Course Edition VER 3.0 2023”; y en el libro “Agile
Practice Guide”, creado por el PMI en asociación con
la Agile Alliance, 2017.

8
REQUISITO 3:
INTRODUCCIÓN AL ENFOQUE ÁGIL PARA LA
DIRECCIÓN DE PROYECTOS
9
 TRABAJO
DEFINIBLE VS.
TRABAJO DE ALTA • El trabajo de los proyectos varía desde el trabajo definible hasta el trabajo
INCERTIDUMBRE de alta incertidumbre.
(1/2) • 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 • Los proyectos de alta incertidumbre exhiben altas tasas de cambio,
INCERTIDUMBRE complejidad y riesgo.
(2/2) • 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
 ENTREGA
ORIENTADA AL
• La razón por la que se emprenden los proyectos es para generar valor
VALOR (1/3) comercial, ya sea para producir un beneficio o mejorar un servicio.
Incluso los proyectos de seguridad y cumplimiento normativo pueden
expresarse en términos de valor comercial al considerar el riesgo
comercial y el impacto de no emprenderlos.
• Entonces, si entregar valor es la razón para hacer proyectos, la entrega
impulsada por el valor debe ser nuestro enfoque a lo largo del proyecto.
• En la lección anterior se respondió a la pregunta "¿Por qué usar Agile?“ y
la contestamos desde el punto de vista del tipo de producto y el costo de
los cambios.
• Sin embargo, aquí esta pregunta será abordada desde el punto de vista
del valor que los métodos ágiles pueden ofrecer en comparación con los
métodos no ágiles. Esto se denomina "propuesta de valor ágil" y
generalmente se representa visualmente, como se muestra a
continuación

13
ENTREGA ORIENTADA AL VALOR (2/3)

PROPUESTA DE
VALOR EN
PROYECTOS
EJECUTADOS CON
ENFOQUES
ADAPTATIVOS O
ÁGILES
 ENTREGA
ORIENTADA AL • Maximizar el valor es un tema central para los equipos ágiles.
Cuando se enfrentan a una decisión, preguntan: "¿Qué opción
VALOR (3/3) agregará el mayor valor para el cliente?".

• El enfoque en la entrega de valor impulsa muchas de las

actividades y decisiones en un proyecto ágil y es el objetivo final de
muchas de las prácticas en el conjunto de herramientas ágiles.

• Este es uno de los temas ágiles más importantes, que une muchos
conceptos ágiles fundamentales, como la priorización, la entrega
incremental y el desarrollo basado en pruebas.

• Una de las formas clave en que los equipos ágiles intentan

maximizar el valor es entregando valor temprano. Esto significa que
su objetivo es entregar las partes de mayor valor del proyecto lo
antes posible.
 ENTREGAS INCREMENTALES
• En proyectos ágiles, el equipo se esfuerza por lograr valor
para el cliente lo más rápido posible.
• Para hacer esto, en lugar de intentar entregar el producto
final con todas las características, es más común trabajar
con distribuciones parciales más pequeñas. Estas suelen
ser:
⚬ Producto mínimo viable ó Producto Viable Mínimo
(MVP: Minimum Viable Product)

⚬ Características comercializables mínimas ó Mínimo

Incremento de Negocio (MMF: Minimum Marketable
Feature)
 • El MVP o Producto Mínimo Viable es una “versión preliminar”, no
EL MVP o PRODUCTO completamente terminada, que le permite al equipo:
MÍNIMO VIABLE (1/4)
• Obtener retroalimentación real del cliente y/o los usuarios (para saber si van bien, si
están creando el producto correcto).

• Brindar una solución lo suficiente viable para que sea utilizada por el cliente y/o
usuario. Este segundo punto también se puede entender como brindar una versión del
producto lo suficientemente usable para empezar a generar valor real para el negocio.

PRODUCTO MÍNIMO VIABLE

Algo tangible que los La base más rudimentaria Suficiente para los
clientes puedan tocar y y básica de la solución primeros usuarios
sentir posible
EL MVP o PRODUCTO • El MVP Se logra utilizando la menor cantidad de tiempo y dinero posible.
MÍNIMO VIABLE (2/4)
• Aprender de un MVP es más económico que desarrollar un producto
con más funciones (lo que aumentaría los costos y los riesgos si el
producto falla).

• Algunas veces, los desarrolladores lanzan MVP a un pequeño grupo de

clientes potenciales, como los "primeros usuarios", que son más
indulgentes, tienen más probabilidades de dar su opinión y pueden
capturar información sobre el producto a partir de un prototipo.

• En otras palabras, algunas veces no implementan el MVP para todos los

clientes.

• El MVP no solo puede basarse en la funcionalidad del producto, sino que

también debe incluir fiabilidad, usabilidad y diseño.
 EL MVP o PRODUCTO MÍNIMO VIABLE (3/4)

• Con un MVP Se busca reducir el tiempo total dedicado a iteraciones.

• Este proceso se repite hasta que se obtiene un producto apto para el mercado o hasta
que se concluye que el producto no es viable.
• El MVP a veces no es un producto práctico, sino un prototipo.
• Por ejemplo, la presentación en exposiciones internacionales de prototipos no
operativos, de automóviles construidos de acuerdo con las preferencias de los
consumidores potenciales.
EL MVP o PRODUCTO
El MVP incluye: El MVP no incluye:
MÍNIMO VIABLE (4/4)

• Probar nuevas ideas • Diseño para obtener

para aprender beneficios de manera
inmediata.
• Enfoque para • Diseño para
resolver un c
impresionar al
problema. usuario.

• Diseño para obtener • Producto final

una rápida
retroalimentación
con baja inversión

20
EL MÍNIMO INCREMENTO
DE NEGOCIO O LA
CARACTERÍSTICA • Otra forma de priorizar el alcance inicial de un proyecto es definir las
COMERCIALIZABLE Características Mínimas Comercializables (MMF: Minimum Marketable
MÍNIMA MMF(*) (1/2) Feature).

• Si bien los conceptos MVP y MMF se suelen utilizar como sinónimos, no

significan lo mismo.

• El MMF es la unidad funcional más pequeña que puede proporcionar un

valor tangible al cliente. A diferencia de MVP, que puede ser un prototipo
inicial, MMF sigue siendo un producto terminado.

• Desde el 2021, el PMI usa el termino “Mínimo Incremento de Negocio” ó “MBI”,

indicando que este es el que ofrece suficientes aspectos de alto valor de la solución para
comenzar a usarlo y obtener beneficios de él.
 EL MÍNIMO INCREMENTO DE NEGOCIO O LA
CARACTERÍSTICA COMERCIALIZABLE MÍNIMA MMF(*) (2/2)

MVP MMF

• El MMF aborda una necesidad específica, resuelve un problema específico, es de alta calidad y fácil
de usar. Es una característica que se puede intercambiar, vender y enviar.
• Un ejemplo de MMF es lanzar un celular con un software que incluye funciones básicas, luego
agregar gradualmente funciones adicionales a medida que el software se actualiza; En lugar de
crear un producto con muchas características a la vez, que los clientes no aprecian.
• El MMF prioriza las características de alto valor y el tiempo de comercialización más rápido para
llevar su producto al mercado más rápido y aumentar el retorno de la inversión.
 LOS CUATRO VALORES DEL MANIFIESTO AGIL
1. Los Individuos e interacciones valen
más que los procesos y las
herramientas.
3. Vale más la colaboración con el
cliente que la negociación del
contrato con él.
2. El Software que funciona vale más
que una documentación
completa.
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).
LOS DOCE PRINCIPIOS
DETRÁS DEL • La máxima prioridad es satisfacer al cliente mediante la entrega
MANIFIESTO AGIL (1/2) temprana y continua de software con valor.
• 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.
• 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.
• El (personal de) negocio y los desarrolladores deben trabajar en conjunto
todos los días durante todo el proyecto.
• Construir proyectos alrededor de individuos motivados. Darles el entorno y el
apoyo que necesiten, y confiar en ellos para hacer el trabajo.
• 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.
LOS DOCE PRINCIPIOS
DETRÁS DEL
• El software que funciona es la medida principal del progreso.
MANIFESTO AGIL (2/2)
• Los procesos ágiles promueven el desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deberían poder
mantener un ritmo constante en forma indefinida.
• La atención continua a la excelencia técnica y el buen diseño
mejora la agilidad.
• La simplicidad es esencial.
• Las mejores arquitecturas, requerimientos y diseños surgen
de equipos auto-organizados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser
más efectivo, para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.
 LA RELACIÓN ENTRE
LOS VALORES,
PRINCIPIOS Y PRÁCTICAS
COMUNES DEL
MANIFESTO AGIL

Mentalidad 4 12
ágil 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.
PENSAMIENTO
LEAN
Lean
Ágil

Kanban
ScrumBa
n
Cryst
al AU
Scru P
m
FD
X
D
P DSD
M
SELECCIÓN DEL CICLO DE
VIDA DEL PROYECTO
27
SELECCIÓN DEL
CICLO DE VIDA Esta guía práctica se refiere a cuatro tipos de ciclos de vida, definidos de la
DE UN PROYECTO 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, HASTA
LOGRAR EL PRODUCTO CORRECTO.

• 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.

29
CARACTERÍSTICAS DE
LOS CICLOS Características
DE VIDADE LOS
PROYECTOS Enfoque Requisitos Actividades Entrega Meta

Gestionar alcance
Predictivo Se trata de Realizados una vez Entrega
tiempo y costos, junto
determinar todos al
para todo el única a los riesgos y la
comienzo.
calidad
proyecto
Iterativo Entrega única, luego
Dinámico Repetidos hasta que Corrección de la
de varias iteraciones
s esté correcto que reciben solución
retroalimentación
Dinámicos, pero
Incremental Realizados una vez Entregas
buscando el valor Velocidad
esencial lo antes para un incremento frecuentes más
posible
dado pequeñas Valor para el cliente
Ágil Dinámico Repetidos hasta que Entregas
mediante entregas
s esté correcto pequeñas
frecuentes y
frecuentes
retroalimentación
EL CONTINUO DE
LOS CICLOS
DE VIDADE LOS Alt
PROYECTOS o
Incremental Ágil

Frecuencia de
Entrega
(de producto o uo
ntin
valor)
Co

Predictivo Iterativo
Bajo
Baj Alt
o Grado de Cambio o

31
 CICLO DE VIDADE Ningún ciclo de vida puede resultar perfecto para todos los proyectos. Por
PROYECTO “ADECUADO” el contrario, cada proyecto encuentra un punto en el continuo que
(1/2)
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.
CICLO DE VIDADE
PROYECTO * Ciclos de vida incrementales. Proporcionan entregables terminados
“ADECUADO” (2/2) 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.
IMPLEMENTACIÓN DEL AGILISMO:
CREACIÓN DE UN ENTORNO ÁGIL
33
 COMENZAR CON
UNA MENTALIDAD
• La gestión de un proyecto utilizando un enfoque ágil requiere que el equipo del
ÁGIL
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?
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
de las necesidades y el desarrollo de los miembros
del mismo, con el fin de permitir el máximo
desempeño posible del equipo.
 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.
RESPONSABILIDADES
DEL LÍDER DE
Rol de un Líder de Servicio
SERVICIO (1/2) en un entorno Ágil

Facilita

Eliminan impedimentos

Allanan el camino
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 la facilitación 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.
 ROLES DE LOS Rol Descripción

EQUIPOS ÁGILES Miembro de equipo

multidisciplinario
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 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.
Dueño del producto El dueño del producto es el encargado de guiar el desarrollo 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..
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, y en las relaciones con los clientes, tales como los gerentes
de productos
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.
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.
 Área del PMBOK Aplicación en un trabajo con Ágil
CÓMO APLICA
PMI EL Integración
Los miembros del equipo, capacitados y empoderados, van integrando planes y componentes. El Director
de Proyecto debe aplicar el Liderazgo de Servicio y establecer un entorno colaborativo.
AGILISMO El alcance, al principio, no se detalla del todo y se va perfeccionando en la medida que se avanza en el proyecto y se
Alcance
profundiza en el detalle.

Se utiliza programación iterativa, predictiva o híbrida según el tamaño y el enfoque del proyecto. El artefacto
Cronograma
usado es el “Calendario de Liberaciones” en lugar de un cronograma.

Costos Se utilizan métodos de estimación ligera para pronosticar los costos del proyecto que se van ajustando.

Dada por la cercanía del equipo con el cliente. También por los criterios de aceptación y la “Definición de Listo o Hecho”. Se
Calidad
usa la retrospectiva para buscar la causa-raíz de los incidentes y se aplican acciones de mejora continua.

A diferencia de Scrum, el PMI si contempla la figura de un director de proyectos, que encuentra su lugar en el proyecto a
través del Liderazgo de Servicio.
Recursos Equipos capacitados continuamente, con conocimiento de su responsabilidad, son auto-organizados. Los equipos buscan tener
especialistas “T-Shaped”, con un fuerte conocimiento en su especialidad pero con al menos conocimiento general en las otras
especialidades del proyecto

Comunicaciones Similar a la predictiva pero muy probablemente hecha de manera mucho mas frecuente.

La gestión es continua y se identifican los riesgos y sus respuestas en la planificación de las iteraciones. Se busca tratar los
Riesgos
riesgos lo antes posible.

Adquisiciones Usualmente se usa un modelo de contratación de riesgo compartido

Interesados Participación activa y continuaespecialmente en proyectos de posible alto grado de cambio.

EJECUCIÓN DE UN PROYECTO ÁGIL: CEREMONIAS Y/O
PRÁCTICAS ÁGILES
42
¿CUÁNDO ES “ÁGIL” Cuando aplica correctamente:
UN EQUIPO DE • La capacitación y empoderamiento de los miembros
PROYECTO? del equipo.
• Los roles definidos para un equipo ágil
• Las “Ceremonias” o prácticas ágiles de gestión
• El desarrollo y uso de “artefactos” ágiles

Y además, un equipo puede aplicar practicas ágiles con

mayor fluidez cuando la organización también muestra
“agilismo”

43
 REUNIONES INICIALES
INICIO
CREACION DE LA VISION
DEL PROYECTO

DESIGNACIÓN DEL
LÍDER DEL PROYECTO
Justificación (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

45 44
 INICIO DEL PROYECTO
“Las épicas son una gran historia de usuario que no
puede completarse en una iteración. Por lo tanto, las
INICIO
EPICA épicas se dividen en historias de usuario más
pequeñas las cuales podrán ser entregadas en
DESARROLLO Y/O
DOCUMENTACIÓN DE
S distintas iteraciones” EPICAS
Priorización con DESARROLLO DEL
“MOSCOW” (por PRODUCT BACKLOG
ejemplo) PRIORIZADO
PLANIFICACION ÁGIL DE
1 LAS LIBERACIONES
Debe
Las épicas se
desglosan en
2 Podrá
historias de
usuario
3 Podría PLANIFICAR Y
4 No tendrá ESTIMAR
DOCUMENTAR LAS
Productos básicos HISTORIAS DE USUARIO
USER RE
SPO
NS
AB
STORY LE PLANIFICAR EL SPRINT

TITULO DESCRIPCION CRITERIOS “DEFINITION

Como…Quien… DE OF READY”
Beneficio
Prioridad Estimación ACEPTACION
INDEPENDENCIA
NEGOCIABLE s
VALORADAS stica
rí COLABORADOR
“Las historias de usuario son una breve descripción ESTIMADAS acte
r
PEQUEÑA Ca
escrita que representa un requisito o funcionalidad
del proyecto utilizando el lenguaje común del
usuario.”
Dueño de Producto ó Equipo Ágil que incluye al
“Todas las historias de usuario forman parte del Product Owner Director de Proyecto
trabajo pendiente asociado al producto (product
backlog). Las historias de usuario seleccionadas para
desarrollar durante las iteraciones definen el
alcance del proyecto” 45
PLANIFICACIÓN DE LA ITERACIÓN O EL SPRINT

PLANIFICAR Y ESTIMAR
APROBAR, ESTIMAR Y COMPROMETER LO QUE SE
8 horas
1 Sprint 1 Mes ENTREGARÁ AL COMPLETAR LAS TAREAS
REQUERIDAS ARA DAR RESPUESTA A LAS
HISTORIAS DE USUARIO
ILIT
A DEFINIR LAS TAREAS NECESARIAS PARA DAR
FAC
DOR RESPUESTA A LAS HISTORIAS DE USUARIO
ESTIMAR LOS PUNTOS DE ESFUERZO
OBJETIVO DURACION
SPRINT SPRINT NECESARIOS PARA COMPLETAR LAS
TAREAS Y LAS HISTORIAS
SE CREA EL BACKLOG DE LA ITERACIÓN
O “SPRINT BACKLOG”
RESU
LTAD
O
1,
1
1, “Listado de
EN

DO
TA
IEN

N 2
ESE
tareas”
ERV

PR
RE
1,
INT

TODO DOING TESTING DONE

3
1,
4
Equipo Ágil ó Scrum Team SCRUM
BOARD SPRINT
Objetivo Sprint

Dueño de Producto o Como se va a realizar TODO DONE DONE

BACKLOG
Product
Cuanto va a durar
Owner

KAMBAN

46
 LA ITERACIÓN O SPRINT
DESARROLLAR/IMPLEMENTAR
REUNIÓN SE CREAN LOS ENTREGABLES
15
SE DESARROLLA EL DIARIA DE minutos
INCREMENTO DEL A PIE diarios SE REALIZAN REUNIONES

ADAPTACIO
PRODUCTO DIARIAS DE A PIE (DAILY

N
STANDUPS)
REFINAMIENTO DE LAS
ION ¿Qué termine ayer?
TRANSPARENCIA INSPECC PRIORIDADES EN EL PRODUCT
¿Qué voy a terminar hoy?
BACKLOG (si es necesario) Y TOMA
¿Qué impedimentos
Estoy enfrentando? DE NOTA PARA POSIBLES
INCLUSIONES EN LA SIGUIENTE
ITERACIÓN

REFINAMIENTO

Equipo Ágil ó Scrum Team

1 1 1
2 3 3
RESPONSABLE 3 4 4
4 2 5
SEGUIR 5 5 2
ESTANDARES
CUMPLIR CON LAS
DEFINICIONES DE HECHO
Y LOS CRITERIOS DE
ACEPTACION
47
REUNIONES DE REVISIÓN DEL SPRINT
(O DEMOSTRACIONES) REUNIONES DE REVISIÓN Y
RETROSPECTIVAS
CONVOCAR REUNIÓN
4 horas
Por un Sprint
De un mes
DEMOSTRACIÓN Y VALIDACIÓN
DE LO COMPLTEADO EN LA
ITERACIÓN O SPRINT
ENTREGA RESTROSPECTIVA DE LA
ITERACIÓN O SPRINT
INCREMENTO
LANZAMIENTO
ENTREGA DEL PRODUCTO,
SERVICIO O RESULTADO
REUNIÓN DE RETROSPECTIVA DEL
RETROSPECTIVA DEL PROYECTO
Equipo Ágil Product CUMPLIMIENTO SPRINT
Owner CRITERIOS DE
ACEPTACION
LECCIONES
APRENDIDAS
Equipo Ágil

Product
Owner
Interesado

Interesado

48
PRÁCTICAS ÁGILES COMUNES EN
MAYOR DETALLE
49
1. PREPARACIÓN DE • La lista de trabajo pendiente está ordenada y contiene todo el trabajo para un equipo,
LA LISTA DE TRABAJO presentada en forma de historias de usuario (user stories).
PENDIENTE • No es necesario crear todas las historias para todo el proyecto antes de que se inicie el
(BACKLOG) (1/2) 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.

• Ejemplo, Product Backlog de mi proyecto “Lapicero”:

⚬ 1.Carga con tinta y carcaza provisional que permita escribir (Valor esencial del producto)

⚬ 2.Carcaza de plástico definitiva, pero sin acabado

⚬ 3.Tapa del lapicero

⚬ 4.Paquete de trabajo de pintado y acabado decorativo del lapicero

50
1. PREPARACIÓN DE
LA LISTA DE
TRABAJO • Los dueños del producto (o un equipo responsable del valor, que
PENDIENTE incluya al gerente del producto y a todos los dueños de producto
(BACKLOG) (2/2) 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.

52 51
2. PLANIFICACIÓN DE
ÁGIL BASADA EN • La capacidad de cada equipo es diferente.
ITERACIONES O
SPRINTS • 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

52
3. REUNIONES
DIARIAS DE PIE
• Los equipos usan reuniones de pie para comunicarse entre sí, descubrir
(DAILY STANDUPS)
(1/2) 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.

53
3. REUNIONES
DIARIAS DE PIE
(DAILY STANDUPS) En ágil basado en la iteración, todo el mundo responde a las
(2/2)
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)?

54
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.

55
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 CONDUCENTES

A LA MEJORA

56
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.

57
6. PRÁCTICAS DE
EJECUCIÓN QUE • Integración continua.
AYUDAN A LOS • Prueba a todos los niveles
EQUIPOS A • ATDD Desarrollo guiado por pruebas de aceptación (usualmente con el
ENTREGAR VALOR (*) usuario).
• TDD Desarrollo guiado por pruebas (incluye al refactoring)
(usualmente con áreas de calidad, pruebas asociadas a la conformidad
técnica) (seguir el ciclo “Escribir una prueba automatizada fallida (que
seguramente fallará) -> Ejecutar la prueba fallida -> desarrollar código
para hacer pasar la prueba -> ejecutar prueba -> repetir”)
• Spikes (de investigación, de experimentación o de riesgos)
• (*) Página 56 de la Guía Práctica Ágil

59 58
7. TEMAS SENSIBLES EN ÁGIL Y ALTERNATIVAS DE SOLUCIÓN DE PROBLEMAS (1/2)
Tema Sensible
Propósito o misión poco clara para el equipo
Acuerdos de trabajo poco claros para el equipo
El contexto del equipo no es claro
Requisitos poco claros
Mala experiencia del usuario
Estimación imprecisa
Asignaciones de trabajo o progreso del trabajo
poco claros
El equipo lucha contra los obstáculos
Retrasos de trabajo/sobrecostos debido a la falta de
perfeccionamientos de algunos elementos de la lista
de trabajo pendiente del producto.
Defectos
El trabajo no está completo
Deuda técnica (calidad del código degradada)
Alternativas de Solución de Problemas
Constitución ágil para el propósito—visión, misión y pruebas de misión.
Constitución ágil para la alineación—valores, principios y acuerdos de trabajo.
Constitución ágil para el contexto—límites, activos comprometidos y análisis prospectivo.
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.
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.
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.
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.
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.
Historias combinadas del dueño del producto y del taller del equipo. Crear una definición
de “listo” para las historias. Pensar en dividir historias para usar historias más pequeñas.
Tomar en consideración las prácticas técnicas que funcionan para el entorno. Algunas
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 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.
Refactorización, modelado ágil, pruebas de mayor cobertura, análisis automatizado de la
calidad del código fuente, definición de “terminado”.
59
7. TEMAS SENSIBLES EN ÁGIL YALTERNATIVAS 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.
61 60
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”.

61
8. MEDICIONES EN
PROYECTOS Algunos proyectos
Puntos de Historia Restantes
ÁGILES (2/5) basados en iteraciones
usan gráficas de trabajo
pendiente (burndown) 35

para ver dónde va el

30
proyecto en el tiempo.
El gráfico muestra un 25
LEYENDA

ejemplo de una gráfica

20
de trabajo pendiente en Puntos
de Historia
la que el equipo 15 Restantes
planeaba entregar 37
puntos de historia. 10

Muchos equipos ágiles 5

usan puntos de historia
para evaluar el esfuerzo. 0
Día Día Día Día Día Día Día Día Día Día
La línea punteada de 1 2 3 4 5 6 7 8 9 10
trabajo pendiente es el
plan.
Gráfica de Trabajo Pendiente para los Puntos de Historia

Restantes
62
8. MEDICIONES EN
PROYECTOS Puntos de Historia Realizadas
ÁGILES (3/5) 35
Algunos equipos
de proyecto 30

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

una gráfica de 0
trabajo realizado. 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

63
8. MEDICIONES EN
PROYECTOS ÁGILES • Los equipos ágiles basados en flujo utilizan diferentes medidas:
(4/5) 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

64
8. MEDICIONES EN
Tablero Kanban
PROYECTOS ÁGILES
Desarrollo y Prueba de
(5/5) Listo Pruebas Unitarias Desarrollado Sistema Completado

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.

65
REQUISITO 3:
TEMAS CLAVE DEL ENFOQUE ÁGIL
66
 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).
1. 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)
2. Enfoque Iterativo: Descubro mejoras requeridas y las aplico en cada iteración.
3. 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)

67
 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):

6. Dueño de producto: el que “delimita” el Alcance y responsable de mantenerlo.
7. 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.
8. 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)

6. 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”).

68
 ENFOQUE ÁGIL
TEMAS CLAVE (3/4)
10. Definiciones básicas de Ágil (continua:)
10. Product backlog: Lista de trabajo pendiente. Consiste en historias y épicas.
11. Sprints: Grupos de actividades para completar historias y épicas. Por defecto toman dos semanas.
12. Reuniones diarias de a pie: dan informes breves de avance y posiblemente alguna dificultad. Aquí no se resuelven esas dificultades.
13. Retrospectivas: usualmente cada 15 días, cada finalización de un Sprint o en cada entrega significativa.
11. 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)).
12. 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.
13. 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
14. Revisar las prácticas de ejecución que ayudan a los equipos a entregar valor (Pag 56 de la Guía Práctica Ágil)
15. Revisar las sección (tabla) “Temas Sensibles en Ágil y Alternativas de Solución de Problemas”(Pags 58 y 59)

69
 ENFOQUE ÁGIL
TEMAS CLAVE (4/4)
16.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.
17.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.

70
Fin de la Lección