Este documento presenta los conceptos y principios de la gestión ágil de proyectos. Explica brevemente el método tradicional en cascada y contrasta con el enfoque ágil. Luego describe los principios del Manifiesto Ágil y los roles, artefactos y eventos clave de Scrum, una de las metodologías ágiles más populares. Finalmente, menciona otras metodologías ágiles y algunas malas prácticas a evitar.

1. PRESENTACION
1
GESTión ÁGIL
DE PROYECTOS

2. ¿QUÉ ES LA
AGILIDAD?

3. INCERTIDUMBRE
Y CULTURA

4. FACTIBILIDAD
REQUERIMIENTOS
DISEÑO
EN CASCADA
4
MÉTODO TRADICIONAL
CODIFICACIÓN
TEST
IMPLEMENTACIÓN
MANTENIMIENTO
Intervención del usuario
Usuario excluido
Intervención del usuario
Extensa fase de análisis
Comienza el mantenimiento

5. Just IN TIME

6. 6
Estamos descubriendo formas mejores de desarrollar software
tanto por nuestra experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha,
valoramos aún más los de la izquierda.

7. PRINCIPIOS
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de
software con valor.
7
MANIFIESTO ÁGIL
01

8. PRINCIPIOS
Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos
ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
8
MANIFIESTO ÁGIL
02

9. PRINCIPIOS
Entregamos software funcional frecuentemente,
entre dos semanas y dos meses, con preferencia
al periodo de tiempo más corto posible.
9
MANIFIESTO ÁGIL
03

10. PRINCIPIOS
Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante
todo el proyecto.
10
MANIFIESTO ÁGIL
04

11. PRINCIPIOS
Los proyectos se desarrollan en torno a
individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
11
MANIFIESTO ÁGIL
05

12. PRINCIPIOS
El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
12
MANIFIESTO ÁGIL
06

13. PRINCIPIOS
El software funcionando es la medida
principal de progreso.
13
MANIFIESTO ÁGIL
07

14. PRINCIPIOS
Los procesos ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y
usuarios debemos ser capaces de mantener un
ritmo constante de forma indefinida.
14
MANIFIESTO ÁGIL
08

15. PRINCIPIOS
La atención continua a la excelencia técnica y al
buen diseño mejora la agilidad.
15
MANIFIESTO ÁGIL
09

16. PRINCIPIOS
La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
16
MANIFIESTO ÁGIL
10

17. PRINCIPIOS
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
17
MANIFIESTO ÁGIL
11

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

19. METODOLOGÍAS ÁGILES
§ Feature Driven Development (FDD)
§ Dynamic System Development Methodology
§ Crystal
§ Agile Unified Process (AUP)
§ Scaled Agile Framework (SAFe)
§ Disciplined Agile Delivery (DAD)
§ Agile Modeling
§ Lean
§ Extreme Programming (XP)
§ Scrum
§ Kanban
§ Large Scale Scrum (LeSS)
§ Scrumban
§ 3x (Explore, Expand, Extract)
§ Essence
§ Modern Agile
19

20. 20

22. LIVIANO
FÁCIL DE APRENDER
DIFÍCIL DE DOMINAR
Un marco de trabajo por el cual las
personas pueden abordar problemas
complejos adaptativos, a la vez que
entregar productos del máximo valor
posible productiva y creativamente.
SCRUM
22

23. 23
CORAJE
para asumir desafíos
FOCO
sobre un acotado número de características
COMPROMISO
con el éxito del proyecto y del equipo
RESPETO
por la capacidad y el valor de los demás
APERTURA
para discutir los desafíos con transparencia

24. PILARES
24
SCRUM
TRANSPARENCIA
INSPECCIÓN
ADAPTACIÓN

25. 25
FRAMEWORK
SCRUM

26. La razón de que este marco funcione es
simple: se estudia cómo la gente trabaja en
realidad, no como dice que trabaja.

27. En Scrum un proyecto se ejecuta en
ciclos temporales cortos y de duración
fija llamado Sprint que normalmente
son de 1 semana hasta el límite
máximo de 4 semanas.
SPRINT
27
SCRUM
El objetivo de cada ciclo es crear un
producto potencialmente usable, es
decir, un incremento de producto final
que pueda ser utilizado por los
clientes.

28. ROLES
28
SCRUM
DT DEV
TEAM

29. ROLES
29
SCRUM
Mantener y priorizar el
Product Backlog
Asegurar que se trabajen los
items de mayor valor
Entender y priorizar las
necesidades de los SH
Responder las consultas del
equipo de desarrollo
Es una única persona
RESPONSABILIDADES
Y CARACTERÍSTICAS:

30. ROLES
30
SCRUM
RESPONSABILIDADES
Y CARACTERÍSTICAS:
Asegurar la correcta
implementación de Scrum
Eliminar los impedimentos
que bloquean al equipo
No es una autoridad jerárquica
Es una única persona
Es el facilitador de los
eventos de Scrum

31. ROLES
31
SCRUM
DEV TEAM
DT
RESPONSABILIDADES
Y CARACTERÍSTICAS:
Encargados de construir el
producto
Autoorganizado y
autodirigido
Multidisciplinario
No tienen títulos
No existen sub-equipos

32. ROLES
32
SCRUM

33. ROLES
CERDOS COMPROMETIDOS
PRODUCT OWNER
Quién maximiza el valor del producto
resultante del trabajo del Equipo.
SCRUM MASTER
Quién asegura la correcta aplicación de Scrum
y elimina los impedimientos
DEV TEAM
Quienes realizan el trabajo de entregar un
incremento de producto en cada Sprint.
33
SCRUM
GALLINAS INVOLUCRADOS
USUARIOS
Quienes utilizan el producto
CLIENTES
Quienes compran el producto
MARKETING Y VENTAS
Quienes comercializarán el producto
DUEÑOS, MANAGERS Y OTROS
STAKEHOLDERS
Quienes permiten que el proyecto exista

34. El Scrum Master y el Dev Team están a cargo de lo rápido
que avanzan y la mayor calidad que pueden alcanzar.
El Product Manager lo está de traducir
esa productividad en valor.

35. Las historias de usuario, son pequeñas descripciones
de los requerimientos de un cliente.
Una historia de usuario suele ser una funcionalidad,
algo visible para los usuarios finales.
Debe venir acompañada de los criterios de
aceptación.
La historias de usuario deben cumplir el criterio
INVEST
35
HISTORIAS DE USUARIO

36. HISTORIAS DE USUARIO
36
I N V E S T
INDEPENDENT
INDEPENDIENTE
NEGOTIABLE
NEGOCIABLE
VALUABLE
VALIOSA
ESTIMABLE
ESTIMABLE
SMALL
PEQUEÑA
TESTEABLE
TESTEABLE

37. Una tarea es una unidad de trabajo necesaria para
terminar una historia.
Puede ser realizada por un solo miembro del
equipo, mientras que producir una historia es
responsabilidad de todo el equipo.
Lo recomendable es que una tarea no dure más de
un día de trabajo, o en caso contrario,
descomponerla en dos o más tareas.
La tareas deben cumplir el criterio SMART
37
TAREAS

38. TAREAS
38
S M A R T
SPECIFIC
ESPECIFICA
MEASURABLE
ESTIMABLE
ACHIEVABLE
REALIZABLE
RELEVANT
RELEVANTE
TIME-BOXED
LIMITADA

39. Una épica es una historia de
usuario que no puede ser
entregada tal y como se ha
definido dentro de una sola
iteración, o que es
suficientemente grande
como para ser partida en
historias de usuario más
pequeñas.
39
ÉPICAS

40. 40
ARTEFACTOS
SCRUM

41. 41
PRODUCT BACKLOG
SCRUM ARTEFACTOS
Es el conjunto de requisitos o funcionalidades que
debe tener un proyecto de forma actualizado y
priorizado por los elementos que más valor aportan
a nivel de negocio.
• Nunca está completo, evoluciona junto con el
producto y el entorno.
• Es dinámico, cambia constantemente para
identificar lo que el producto necesita.
• Es responsabilidad del Product Owner

42. 42
SPRINT BACKLOG
SCRUM ARTEFACTOS
Es el conjunto de elementos del Product Backlog
seleccionados para el Sprint, más un plan para entregar
el Incremento de producto.
• Estimada por el Dev Team
• Priorizada
• Hace visible todo el trabajo que se está realizando
• Suficientemente detallada
• Compone el Objetivo del Sprint

43. 43
INCREMENTO
SCRUM ARTEFACTOS
Es la suma de todos los elementos del Sprint
Backlog completados durante un Sprint y el valor
de los incrementos de todos los Sprints anteriores.
• Inspeccionable
• Respalda el empirismo del Sprint
• En condiciones de utilizarse aún si en Product
Owner no lo libera.
• Es un paso hacia la visión o meta final.

44. Cuando un elemento del Product Backlog o un Incremento se describe
como “Terminado”, todo el mundo debe entender lo que significa
“Terminado”.
Los miembros del Equipo deben tener un entendimiento compartido de
lo que significa que el trabajo esté completado para asegurar la
transparencia.
El propósito de cada Sprint es entregar Incrementos de funcionalidad
que potencialmente se puedan poner en producción y que se ajustan a
la Definición de “Terminado” actual del Equipo Scrum.
44
TERMINADO DEFINITION OF DONE

45. Un Spike sirve para incluir en un Sprint tareas que no implican
desarrollar una historia de usuario y por tanto no aportan directamente
un Incremento al producto que se está desarrollando.
Se utilizan para:
• Investigación y pruebas
• Documentación
• Formación interna
Un Spike no debe durar más que un Sprint
45
SPIKE

46. 46
EVENTOS
SCRUM

47. Es el evento dónde se planifica el trabajo que se va a
realizar durante el Sprint.
• Intervienen todos los miembros del Equipo Scrum
• Se seleccionan y estiman los ítems para el Sprint
• Se aclaran dudas sobre los ítems seleccionados
• Se define el Objetivo del Sprint
• Duración máxima: 2 horas por cada semana de Sprint
47
SPRINT PLANNING
SCRUM EVENTOS

48. Es una reunión diaria con un bloque de tiempo de 15 minutos para el
Equipo de Desarrollo, donde se planea el trabajo para las próximas 24
horas.
• Interviene Equipo de Desarrollo y el Scrum Master
• El Product Owner puede asistir
• No es una reunión de reporte
• Duración: 15 minutos
Es usual que luego del Daily Scrum los miembros del equipo se vuelvan
a reunir para tener discusiones detalladas sobre temas puntuales.
48
DAILY SCRUM
SCRUM EVENTOS

49. 49
DAILY SCRUM
SCRUM EVENTOS

50. Se lleva a cabo al finalizar el Sprint para inspeccionar el Incremento y
adaptar el Product Backlog si fuese necesario.
La presentación del Incremento tiene como objetivo facilitar la
retroalimentación de información y fomentar la colaboración.
• Intervienen todos los miembros del Equipo de Scrum
• El Product Owner muestra o explica el avance
• Pueden asistir Stakeholders y hacer preguntas
• Se revisan tiempos, presupuestos, etc.
• Duración máxima: 1 hora por cada semana de Sprint
50
SPRINT REVIEW
SCRUM EVENTOS

51. Es una oportunidad para el Equipo Scrum de
inspeccionarse a sí mismo y de crear un plan de
mejoras que sean abordadas durante el siguiente
Sprint. Debe ser positiva y productiva.
Se inspecciona cómo fue el último Sprint en cuanto
a personas, relaciones, procesos y herramientas.
Duración máxima: 45 min por cada semana de
Sprint.
51
RETROSPECTIVA
SCRUM EVENTOS

52. No es un evento oficial de Scrum, pero el propio creador
reconoce su importancia.
• Asiste todo el Equipo Scrum
• Se revisa cada elemento del Product Backlog y se
asegura de que tanto su descripción como los criterios
de aceptación del mismo sean precisos y reflejen las
necesidades exactas del momento actual del proyecto.
• Duración máxima: 2 horas por cada semana de Sprint
52
REFINAMIENTO GROOMING
SCRUM EVENTOS

53. 53
BURNDOWN CHART
Sirve para saber el tiempo que falta para completar las tareas comprometidas en un Sprint.
Por debajo de la línea quiere decir que llegamos a tiempo,
si vamos por encima de la línea puede querer decir varias
cosas: que hemos estimado mal, que ha habido algún
problema bloqueante, alguna baja, que el Equipo no
funcionando bien, cambios en los requisitos, etc.
Al final del Sprint, se tiene una referencia de la velocidad
real del Equipo.
SCRUM

54. Es una técnica para calcular una estimación basada en el consenso, en su
mayoría utilizada para estimar el esfuerzo relativo de las tareas
• Cada integrante del Equipo tiene un mazo con barajas numeradas
• Se propone la tarea a estimar, dando lugar a debate o preguntas
• Cada integrante muestra la carta cuyo valor representa
el esfuerzo que considera requerirá esa tarea.
• Si dos o más integrantes muestran cartas con más de
tres grados de diferencia, se piden explicaciones y
se vuelve a debatir.
• Se repite la operación hasta llegar a un consenso.
54
PLANNING POKER
SCRUM

55. ¿Cuánto toma ESCRIBIR
UN NOMBRE?

56. La gente no hace multitarea porque es buena para eso,
sino por ser muy distraída.
Se le dificulta inhibir el impulso de hacer otra cosa.
David Sanbonmatsu - autor de Who multitask and why?

57. 57
TÉCNICA DEL POMODORO
PRODUCTIVIDAD

59. MALAS
Prácticas

60. PRIORIZACIÓN POR PROXY
Un stakeholder prioriza el Product Backlog
basado en requerimientos de su oficina o de un
cliente.
60
MALAS PRÁCTICAS PRODUCT OWNER
01

61. 100% DE CObertura
El Equipo de Scrum crea un Product Backlog
cubriendo la totalidad de un proyecto porque
entiende que su alcance es limitado.
61
02
MALAS PRÁCTICAS PRODUCT OWNER

62. SIN / DEMASIADOS CRITERIOS DE ACEPTACIÓN
El Product Backlog contiene historias de usuario
que no incluyen los criterios de aceptación o
incluyen demasiados.
62
03
MALAS PRÁCTICAS PRODUCT OWNER

63. NO HAY ÉPICAS / NO HAY SPIKES
El Product Backlog no contiene épicas ni spikes.
63
04
MALAS PRÁCTICAS PRODUCT OWNER

64. REPOSITORIO DE IDEAS
El Product Owner usa el Product Backlog como
un repositorio de ideas y requerimientos.
64
05
MALAS PRÁCTICAS PRODUCT OWNER

65. PO PART-TIME / COPYPASTE
El Product Owner no trabaja en el Product
Backlog diariamente.
65
06
MALAS PRÁCTICAS PRODUCT OWNER

66. PO DOMINANTE
El Product Owner crea historias de usuario
agregando el “cómo” hacerlo.
66
07
MALAS PRÁCTICAS PRODUCT OWNER

67. SAbELOTODO
El Product Owner no involucra a los stakeholders
o expertos para representar su visión.
67
07
MALAS PRÁCTICAS PRODUCT OWNER

68. TRABAJO ADICIONAL
El Product Owner agrega tareas al Sprint Backlog
por considerarlas de suma urgencia.
68
07
MALAS PRÁCTICAS PRODUCT OWNER

69. CASI TERMINADO
El Product Owner muestra en el Sprint Review
historias que no están “Terminadas” como si lo
estuvieran.
69
08
MALAS PRÁCTICAS PRODUCT OWNER

70. DT SUMISO
El Dev Team cumple con las demandas del PO sin
discusión.
70
01
MALAS PRÁCTICAS DEV TEAM

71. CERO DEUDA tÉCNICA
El Dev Team no reclama tiempo o recursos para
atacar bugs o mejorar el producto.
71
02
MALAS PRÁCTICAS DEV TEAM

72. TIEMPO DE REFINAMIENTO
El Dev Team no dedica tiempo suficiente para
refinar el Backlog (o le dedica demasiado)
72
03
MALAS PRÁCTICAS DEV TEAM

73. DAILY PLANNING
El Dev Team utiliza la Daily para discutir
requerimientos, refinar historias y hacer una
suerte de mini Sprint Planning.
73
04
MALAS PRÁCTICAS DEV TEAM

74. MONÓLOGOS
No se respeta la regla del Time-Boxed
comenzando monólogos.
74
05
MALAS PRÁCTICAS DEV TEAM

75. TINO Y GARGAMUZA
Faltas de repeto, burlas, comentarios sarcásticos
sobre otro miembro del equipo o sus opiniones.
75
06
MALAS PRÁCTICAS DEV TEAM

76. FALTA DE PREPARACIÓN
No recordar en lo que se estuvo trabajando, o
considerarlo poco importante.
76
07
MALAS PRÁCTICAS DEV TEAM

77. SIDE PROJECTS
El Dev Team trabaja en otras tareas por fuera del
Objetivo del Sprint y el Product Owner se entera
en el Sprint Review.
77
08
MALAS PRÁCTICAS DEV TEAM

78. SIN RUTINA
El Daily Scrum no se produce a la misma hora
todos los días.
78
01
MALAS PRÁCTICAS SCRUM MASTER

79. Asignaciones
El Scrum Master asigna las tareas de cada
miembro del Dev Team
79
02
MALAS PRÁCTICAS SCRUM MASTER

80. TE QUITO UN MINUTO, PUEDER SER?
Managers esperan el final de la Daily para hablar
con algún miembro del equipo individualmente y
solicitarle un reporte más detallado.
80
03
MALAS PRÁCTICAS SCRUM MASTER

81. SPRINTS IRREGULARES
Los Sprints tienen duraciones irregulares, por
ejemplo, cuando no se completan todas las
tareas y se extienden a conveniencia.
81
04
MALAS PRÁCTICAS SCRUM MASTER

82. MICROMANAGEMENT
El Scrum Master impone su forma de
organización al Dev Team
82
05
MALAS PRÁCTICAS SCRUM MASTER

83. SUPER CODER HERO
El Scrum Master permite que regularmente
aparezca un “héroe” que resuelve cosas para
salvar el Sprint.
83
06
MALAS PRÁCTICAS SCRUM MASTER

84. SPRINTS DE MEJORA
Se organiza un Sprint de mejoras sin aportar valor
real al Incremento.
84
07
MALAS PRÁCTICAS SCRUM MASTER

85. EL CAMINO
A SCRUM

86. EL EQUIPO
Comunicar a toda la empresa que se va a trabajar
en un nuevo proyecto utilizando Scrum en su
totalidad.
86
01
EL CAMINO A SCRUM

87. EL EQUIPO
Proponer que los interesados se autopostulen
para ser parte del Scrum Team #1
87
02
EL CAMINO A SCRUM

88. EL EQUIPO
Reunir a todos los postulantes en una sala,
(opcionalmente) repasar los conceptos principales
de Scrum y proponer que entre ellos se elijan los
que finalmente van a participar del ST#1
Keywords: valores de Scrum, autoorganizados, multidisciplinario
88
03
EL CAMINO A SCRUM

89. EL PROYECTO
Seleccionar un proyecto para ser desarrollado en su
totalidad por el ST#1.
Idealmente debería ser un proyecto nuevo, en el
cuál se comunique al cliente la modalidad.
En caso que sea imposible, seleccionar el mejor
prospects entre los proyectos en marcha.
89
04
EL CAMINO A SCRUM

90. EL VIAJE
Elegidos el ST#1 y el PS#1, comenzar por el setup de
los artefactos y la agenda de eventos.
Es importante la transparencia y la comunicación
constante al resto de la compañía.
90
05
EL CAMINO A SCRUM

91. EL MAPA NO ES EL CAMINO
Finalmente, ser pacientes y colaborativos con uno
mismo y con el resto del equipo. Eso aplica tanto
para los cerdos como para las gallinas.
Los resultados no se van a ver en el primer ni en el
segundo Sprint, tomará al menos tres o cuatro
antes de comenzar a ver mejoras en el proceso.
91
06
EL CAMINO A SCRUM

92. Scrum es algo que sólo puedes
aprender con la práctica.

93. ¿Preguntas?

94. MUCHAS GRACIAS
MAX KRASZEWSKI / NADINA MAZZITELLI
minimalart.co minimalartminimalart