GESTIÓN DE PROYECTOS

Universidad del Salvador

Facultad de Ingeniería
Ingeniería Industrial
Prof. Mag. Marisa Gouget - PMP

Mag. Marisa Gouget - USAL - 2022 1

METODOLOGÍAS ÁGILES
En esta Clase
Agilidad en los proyectos

• Agilidad
• Bases de la agilidad: historia, manifiesto, principios
• Ser ágil - El corazón de la agilidad
• SCRUM
• Kanban
• Gestión híbrida de proyectos
Bases de la
agilidad

Historia, principios,
manifiesto
 Bases de la agilidad
Historia

Marzo de 2001

Kent Beck (fundador de Extreme

Programming) convoca a 17 profesionales
del software.

Se reunieron para discutir acerca de los

procesos.

Crearon el manifiesto ágil que se resume

en 4 postulados.
Bases de la agilidad
12 Principios
El corazón de
la agilidad

Ser ágil
El corazón de la agilidad
Ser ágil

Aplicar metodologías y marcos de trabajo de

gestión de proyectos ágiles como SCRUM,
KANBAN o LEAN está muy bien, muy alineado con
el convulso mundo al que la mayoría de las
compañías se enfrentan.
Ahora bien, no siempre estos proyectos alcanzan el
éxito esperado y esto es porque las personas no
tienen una actitud ágil. Desconocen los valores
principales de la agilidad o simplemente aunque los
conocen, no están alineados con su personalidad.
Son las personas las que marcan la diferencia entre
el éxito y el fracaso, cuando no son capaces de
asumir los valores ágiles de forma individual, es
difícil que el equipo en su conjunto sea capaz de
hacerlo.
El corazón de la agilidad
Ser ágil – Colabora

Por Juliana Betancur

El corazón de la agilidad
Ser ágil – Entrega

Por Juliana Betancur

El corazón de la agilidad
Ser ágil – Reflexiona

Por Juliana Betancur

El corazón de la agilidad
Ser ágil – Mejora

Por Juliana Betancur

Cómo ganar agilidad
Ser ágil

Evita percibir
Usa el las Intenta
enfoque de situaciones entender el Piensa
No te ates a liderazgo adversas contexto de positivo y
las ideas correcto para desde un dónde acepta el
cada punto de proviene el cambio
situación vista cambio
personal
SCRUM
Metodologías ágiles
SCRUM
Metodología

SCRUM
Se creó a principio de Método Dividido en
los 80. iterativo e ciclos o
Ikujiro Nonaka y incremental sprints
Hirotaka Takeuchi
Un artículo que se
llamó “El nuevo juego Cada ciclo
para el desarrollo de Lista
tiene como
resultado un
productos” requisitos
entregable
En 1995, Ken priorizadas
que aporta
Schwaber y Jeff valor
Sutherland
Inicio del proyecto
Inception – Product Vision Board
Inicio del proyecto
Inception – Otras herramientas
• ¿Para qué el proyecto?
• Personas involucradas
Impact • Impacto desde y hacia las personas
mapping
• ¿Qué hacer?

• Desglosar cada qué

• Priorizar
• Armar versiones

+ Fechas =
Release plan

Fuente: Ágil Es - Por Cris Rúa - Youtube

Fecha de fin del proyecto
Inception – Estimación por tallas de camisetas
1. Definir los tamaños de las
camisetas de XS a XL
2. Tomar las épicas del user story
map y clasificarlas por talle
3. Relacionar cada talle con una
cantidad de puntos de historia
(PH)
4. Multiplicar la cantidad de historia
de cada tamaño por sus PH y
sumar todas las categorías
5. Obtener los PH del proyecto
6. Considerar:
• Velocidad del equipo x
cantidad de sprints =
estimación inicial + desvío de Fuente: Ágil Es - Por Cris Rúa - Youtube
la estimación
(Considerar velocidad optimista y pesimista según
últimos 3 sprints del equipo para plantear escenarios)
SCRUM
Ciclo
SCRUM
Roles

• Product Owner
SCRUM • ScrumMaster
Roles • Equipo de
proyecto
SCRUM
Roles –Product Owner

Desarrolla y comunica el objetivo del producto

Representa a los stakeholders frente al developer team

Representa al developer team frente a los stakeholders

Gestiona y prioriza el backlog para maximizar el valor del producto

SCRUM
Roles –Scrum Master

Ayuda al Product • Revisar objetivos, alcance y dominio del

producto
Owner • Gestionar el backlog

Ayuda al • Entender la pila de productos y el valor aportado

Development • Organizar las reuniones y eventos necesarios ○
Resolver conflictos
Team

Ayuda a la • Entender los principios agile

Organización
SCRUM
Roles - Equipo

Equipo multidisciplinar

El objetivo es entregar valor lo antes posible

Su objetivo es el objetivo del sprint

Ej. Programadores, DevOps, UX...

SCRUM
Ceremonias

• Sprint planning
SCRUM • Daily stand up
Ceremonias
• Review
• Retrospectiva
SCRUM
Ceremonias –Sprint planning

Reunión para planificar el sprint que está comenzando

Participan todos los miembros del equipo Scrum

Puede participar algún stakeholder

Debe establecerse un time-box

OBJETIVO
• Presentar las historias de usuario al equipo
• Incluir las tareas necesarias (deuda técnica, tareas técnicas...)
• Crear el Sprint Backlog
• Si se necesita hay que hacer un refinamiento previo de items
SCRUM
Ceremonias –Daily meeting

Reunión de 15 minutos aprox.

Asiste el equipo de desarrollo, opcionalmente SM y PO

Planificación del trabajo del día

¿DE QUÉ SE HABLA?

• Que se ha hecho desde la última reunión
• Que se va a hacer durante el día de hoy
• Comentar problemas que se han encontrado
SCRUM
Ceremonias – Sprint Review

Evento de scrum para comentar el estado del producto

Asisten todos los miembros del equipo y stakeholders

El objetivo es aprender y tomar decisiones

No es un evento formal
• Explicar los elementos del Product Backlog terminados y los que quedan
• El Dev Team habla de los problemas que se encontraron
• El Dev Team presenta los elementos terminados
• Comentar el futuro y actualizar Backlog de Producto
• Analizar mercado
• Feedback
SCRUM
Ceremonias - Retrospectiva
• “Una reunión especial donde el equipo participa después de completar un
incremento de trabajo para inspeccionar y adaptar sus métodos y trabajo en
equipo. Las retrospectivas permiten el aprendizaje de todo el equipo, actúan
catalizadores para el cambio y generan acción” Agile Retrospectives, Making
Good Teams Great (2006)
• En Scrum la retrospectiva tiene lugar al final del Sprint, después de la Revisión de
Sprint y antes de la siguiente Planificación de Sprint.
• La duración de la retrospectiva es, como máximo, de tres horas para Sprints de un
mes. En la práctica si trabajamos con Sprints de 2 semanas, la duración será a lo
sumo de 1 hora y media.
• El propósito de la retrospectiva es planificar formas de aumentar la calidad y la
efectividad. El equipo Scrum inspecciona cómo fue el último Sprint con respecto a
las personas, las interacciones, los procesos, las herramientas y su Definición de
Terminado.
• Participa el equipo Scrum completo: desarrolladores, Scrum Master y Product
Owner.
SCRUM
Ceremonias - Retrospectiva

Objetivo de la Información Entendimient Items más Repaso de lo

reunión y significativa o del por qué prioritarios y que fue la
cómo está del Sprint y de cada en base a retrospectiva,
cada persona se comparte evento eso definir revisión de El rol del Scrum
para entre todos. significativo accionables accionables y Master es clave
comenzar sucedido en que se aprendizajes, en la
con la el Sprint. puedan cómo mejorar retrospectiva,
retrospectiva. ejecutar en el próximas como facilitador
próximo retrospectivas y como coach
Sprint. .
SCRUM
Artefactos
SCRUM
Requerimientos: Épica – Features - Historias de usuarios

Formato de
historia

Épica Features Historias Tareas

SCRUM
Épica – Features - Historias de usuarios

Lo «épico» es la parte integral del producto, Feature (característica) agrupa las historias de
suficiente para tener valor comercial, o, por usuario y expresa la función del producto,
decirlo suavemente, la «gran historia de relacionada con requisitos funcionales y no
usuario», que expone las macro necesidades funcionales.
de la organización y representa la entrega
total del producto. Lo épico está formado por La responsabilidad de la gestión de funciones
características. también recae en el Product Owner

En este ítem, el Product Owner es Story, o la historia del usuario, muestra la

responsable, con pleno poder sobre las necesidad o el requisito de un usuario .
decisiones, en algunos casos; en otros,
dependiendo de la estrategia, la El Product Owner es el único responsable de
responsabilidad recae en el Product Manager, administrar, priorizar y actualizar el backlog, pero
Business Owner o algún otro profesional el modelo está abierto para que todos hagan
equivalente. sugerencias.
SCRUM
Planificación - Planning póker

• Es un método de estimación que ayuda al equipo ágil a calcular la

cantidad de esfuerzo que se necesita para completar una historia
de usuario en un backlog del producto.
• El término “póker” del nombre hace referencia a las cartas que
cada miembro del equipo usa durante el proceso.
• Es un proceso de estimación basado en el consenso.
• Por lo general se realiza justo antes del proceso de planificación del
sprint, de modo que el gerente de producto o Scrum master pueda
tener una idea precisa del trabajo que se debe realizar antes de
programar un sprint.
SCRUM
Planificación - Planning póker

1. Crear cartas de 3. Llegar a un

planning poker consenso

2. Votar en cada 4. Planificar el

historia de usuario sprint
SCRUM
Planificación - Planning póker
1. Crear cartas de planning poker
• Todos los integrantes de tu equipo Scrum o ágil tienen un mazo de cartas
con diferentes valores. Cada carta tendrá uno de estos valores: 0, 1, 2, 3, 5, 8,
13, 20, 40 y 100. Estos números pueden parecer aleatorios, pero en realidad
son variaciones redondeadas de la secuencia de Fibonacci. Por lo general,
estos valores representan puntos de historia. Sin embargo, algunos equipos
pueden usarlos como una estimación basada en el tiempo para saber
cuánto tiempo se necesita para finalizar una historia de usuario. La
estimación más común basada en el tiempo se mide en horas.

• El propietario del producto (product owner) o el Scrum master actuará como

moderador y leerá una historia de usuario específica del backlog del sprint o
del producto. Luego, los miembros del equipo tendrán la oportunidad de
hacer preguntas y aclarar lo que sea necesario para que todo el equipo
pueda tener una idea exacta de las tareas que deben completarse para
ese elemento específico del backlog.
SCRUM
Planificación - Planning póker
2. Votar en cada historia de usuario
• Una vez que el equipo termina de analizar una historia de usuario, cada
estimador elige una carta que corresponde a la cantidad de esfuerzo o
puntos de historia que considera que se correlaciona con ese elemento del
backlog. Luego, todos revelan la carta al mismo tiempo. Si todos eligieron la
misma estimación, esa se convierte en la estimación oficial para ese
elemento del backlog. El objetivo es que todos tengan la misma estimación.

3. Llegar a un consenso
• Si los miembros del equipo tienen opiniones diferentes sobre sus estimaciones
iniciales, el miembro del equipo con la mayor estimación y el miembro del
equipo con la menor estimación deben tomarse un tiempo para debatir por
qué eligieron ese número específico. Una vez que se termina el debate,
todos vuelven a seleccionar sus cartas. Este proceso se repite hasta que el
equipo llegue a un consenso.
SCRUM
Planificación - Planning póker
4. Planificar el sprint
• Una vez que se tienen las estimaciones de todos los elementos del backlog,
es mucho más fácil planificar con precisión un sprint. Dado que todo el
equipo ha llegado a un consenso con respecto a cuánto tiempo
demandará realizar cada tarea, es mucho más probable que se pueda
destinar la cantidad adecuada de trabajo en los sprints.
SCRUM
Ejecución – Tablero Kanban x cada sprint

El trabajo se muestra en en
forma de tablero organizado
por columnas.
Tradicionalmente, cada
columna representa una
etapa del trabajo. El tablero
Kanban más básico puede
presentar columnas como
Trabajo pendiente, En
progreso y Terminado. Las
tareas individuales —
representadas por tarjetas
visuales en el tablero—
avanzan a través de las
diferentes columnas hasta
que estén finalizadas.
SCRUM
Seguimiento

Un gráfico burndown
o de trabajo
pendiente, es un
diagrama que
muestra el trabajo que
queda por hacer con
respecto al tiempo
necesario para
completarlo.
Corresponde al Scrum
Master actualizar el
burndown chart al
final de cada sprint.
SCRUM
Seguimiento

Sprint Release Product

burndown burndown burndown
chart chart chart
Kanban
Kanban
Mucho más que un tablero Principios
Kanban es un método
para gestionar el trabajo
que surgió en Toyota
Production System (TPS),
a finales de los años 40.
Representa un sistema de
arrastre. Esto significa que
la producción se basa en
la demanda de los
clientes y no en la
práctica tradicional
“pull” de fabricar
productos e intentar
venderlos en el mercado.
Kanban
Tablero Toyota Real – Servicio de mantenimiento
Poniendo
agilidad en el
gerenciamiento
de proyectos
Resumiendo
Agilidad en el Gerenciamiento de Proyectos

Para aplicar/hacer agilidad, antes hay que ser ágil

Gestión híbrida
de proyectos

Elegir el enfoque y
adaptar
Usando ciclos de vida híbridos para proyectos
Adaptar al contexto del proyecto
No es necesario utilizar un solo enfoque para todo un proyecto.
Muchos proyectos pueden beneficiarse de la combinación de ciclos de vida,
aprovechando un enfoque más rígido y predictivo para cumplir con ciertos
requisitos y un enfoque ágil para las fases que requieren una mayor flexibilidad.
Este enfoque de combinación para la planificación de proyectos se denomina
ciclo de vida híbrido.
El uso de un enfoque híbrido permite que una organización adopte partes y
piezas de otro ciclo de vida sin dejar de cumplir con sus métodos tradicionales
conocidos.
Existen múltiples formas de combinar enfoques de proyectos en un ciclo de vida
híbrido. En un proyecto de TI, por ejemplo, “el hardware se puede hacer en
cascada y el software se puede hacer utilizando un enfoque incremental para
entregar un producto al mercado más rápido, con funciones clave primero”

Tener un equipo que esté dispuesto a probar nuevos enfoques y atender las
necesidades específicas de un proyecto ayudará a que una organización sea
más eficiente y eficaz a largo plazo.
Preguntas de práctica de comprensión
 Preguntas de práctica de comprensión
1. ¿Cuál de los siguientes no surge del manifiesto ágil?
a) Las mejores arquitecturas, requisitos y diseños surgen de equipos
auto-organizados
b) La reflexión como herramienta de mejora
c) El cambio como ventaja competitiva
d) La persuasión como forma de liderar

Mag. Marisa Gouget - USAL - 2022 49

 Preguntas de práctica de comprensión
2. ¿Qué no está incluido en los principios del manifiesto?
a) Satisfacer al cliente
b) Desarrollar más rápido
c) Valor continuo
d) Entrega temprana

Mag. Marisa Gouget - USAL - 2022 50

 Preguntas de práctica de comprensión
3. Cuando la prioridad de una organización está en la documentación de
los procesos, ¿qué no se está teniendo en cuenta?
a) Las personas y las interacciones
b) La reflexión
c) La adaptación
d) La transparencia

Mag. Marisa Gouget - USAL - 2022 51

 Preguntas de práctica de comprensión
4. Cuál de las siguientes no es una técnica o herramienta para la etapa
de inception del proyecto:
a) Product vision
b) Sprint review
c) Impact mapping
d) User story mapping

Mag. Marisa Gouget - USAL - 2022 52

 Preguntas de práctica de comprensión
5. Todos los siguientes son roles de SCRUM, excepto:
a) Product Owner
b) Project Manager
c) ScrumMaster
d) Equipo de proyecto

Mag. Marisa Gouget - USAL - 2022 53

 Preguntas de práctica de comprensión
6. ¿En cuál de las siguientes reuniones se explican los elementos del
Product Backlog terminados y los que quedan?:
a) Sprint planning
b) Daily stand up
c) Review
d) Retrospectiva

Mag. Marisa Gouget - USAL - 2022 54

 Preguntas de práctica de comprensión
7. ¿Qué rol es el responsable por Gestionar el backlog?
a) Product Owner
b) Project Manager
c) ScrumMaster
d) Equipo de proyecto

Mag. Marisa Gouget - USAL - 2022 55

 Preguntas de práctica de comprensión
8. ¿En qué momento generalmente el equipo utiliza el método de
estimación por planning póker?
a) Justo antes del proceso de planificación del sprint
b) En el medio del sprint
c) En la review del sprint
d) En la retrospectiva del sprint

Mag. Marisa Gouget - USAL - 2022 56

 Preguntas de práctica de comprensión
9. ¿Cuál de los siguientes no es un principio de Kanban?
a) Limitar el trabajo en curso
b) Visualizar el trabajo
c) Hacer explíticas las políticas
d) Práctica pull

Mag. Marisa Gouget - USAL - 2022 57

 Preguntas de práctica de comprensión
10. ¿Cuál de las siguientes afirmaciones es correcta?
a) En un proyecto solo se puede adoptar un ciclo de vida o enfoque
b) No es necesario utilizar un solo enfoque para todo un proyecto
c) Se puede usar más de un enfoque en un proyecto, pero no es
aconsejable
d) Tener un equipo que esté dispuesto a probar nuevos enfoques no
genera eficiencia

Mag. Marisa Gouget - USAL - 2022 58

 Preguntas de práctica de comprensión – Respuestas

1. D
2. B
3. A
4. B
5. B
6. C
7. A
8. A
9. D
10. B

Mag. Marisa Gouget - USAL - 2022 59

Fin del tema