Documente Academic
Documente Profesional
Documente Cultură
Agilidad en
los proyectos
“SCRUM es el arte de balancear limites
con libertad, para poder ser creativos y
productivos a la vez”
Alan Cymet
Scrum
360
Presentación – Personal Maps
https://management30.com/practice/personal-maps/
5
Introducción
Triple Restricción
Calidad Restricciones
Alcance Intrínseca Costo, Tiempo, alcance
Tipos de Proyectos
A partir del caos todo es posible, queremos crear, pero debemos ser productivos.
REF: http://www.agilemanifesto.org/iso/es/
12
Los 6 valores
Los rápidos cambios en la tecnología, las demandas y expectativas del mercado han creado
grandes desafíos en relación a los productos y servicios en desarrollo que usan los modelos
tradicionales de gestión de proyectos.
Anexo A00o1
24
25
Barreras de la Agilidad
26
Beneficios de Scrum
Top 5 Técnicas
Herramientas de Gestión
29
¿Que es Scrum?
Scrum es:
• Ligero.
• Fácil de Entender.
• Extremadamente difícil de llegar a
dominar.
¿Qué es Scrum?
Scrum es una de las metodología agiles más populares, “es una metodología de
adaptación, iterativa e incremental, rápida, flexible y eficaz, diseñada para ofrecer un
valor significativo de forma rápida en todo el proyecto”.
1 2 3
1 2 3
Al final de cada Sprint o Iteración se consigue una versión mas estable del producto,
con calidad y añadiendo además mas funcionalidades con respecto a las versiones
anteriores.
Los Sprint se pueden conocer como mini proyectos, en todas los sprint se repite un
“proceso” de trabajo similar (planeación, construcción, sincronización, entrega y
retrospectiva), con el objetivo de proporcionar un resultado completo para el
producto final pero siempre teniendo encuenta que el Stakeholder debe obtener
beneficios del proyecto de forma incremental.
En cada Sprint el equipo evoluciona el producto a partir de los resultados
completados en las iteraciones anteriores, añadiendo nuevos objetivos, requisitos o
mejorando los que ya fueron completados.
Mínimo producto viables (MVP)
Los aspectos significativos del proyecto deben ser visibles para aquellos que
son responsables del resultado.
La transparencia requiere que dichos aspectos sean definidos por un estándar
común, de tal modo que los observadores compartan un entendimiento común
de lo que se está viendo.
Donde vemos reflejada la transparencia:
• En la declaración de la visión del proyecto que puede ser visto por todos los
Stakeholders y el Scrum Team
• El Product Backlog que pueden ser visto por todos, tanto dentro como fuera del
Scrum Team
• Clara visibilidad sobre el progreso del equipo a través del uso de un Scrumboard,
Burndown Chart y otros radiadores de información
• Durante el Daily Scrum en el que todos los Development Team informan lo que
han hecho el día anterior, lo que van a hacer hoy, y cualquier problema que les
impida completar sus tareas en el Sprint actual
• Sprint Review en el que el Development Team le muestra los entregables al
Product Owner y a los Stakeholders
Inspección
• En Daily Scrum, los miembros del Development Team discuten abiertamente los
impedimentos para completar sus tareas y buscar la ayuda de otros miembros del
equipo. Los miembros con más experiencia en el Development Team sirven como
mentores a aquellos quienes tienen relativamente menos experiencia y
conocimiento del proyecto o de tecnología.
• La identificación de los riesgos se lleva a cabo y se reitera a lo largo del proyecto.
• En la Retrospect, los participantes documentan las lecciones aprendidas y realizan
revisiones en busca de oportunidades para mejorar los procesos y abordar las
ineficiencias.
43
Valores de Scrum
Para trabajar con Scrum se necesita una base firme de valores que sirven como
“lineamentos” para el trabajo en equipo
Foco: Porque nos enfocamos en solo una cosa a la vez, trabajamos bien juntos y
producimos un resultado excelente. De este modo logramos entregar ítems valiosos
Coraje: porque no estamos solos, nos sentimos apoyados y tenemos más recursos a
nuestra disposición, esto nos da el coraje para enfrentar desafíos más grandes.
Apertura: durante el trabajo en conjunto expresamos cotidianamente como nos va y
que problema encontramos. Aprendemos que es bueno manifestar las
preocupaciones, para que estas puedan ser tomadas en cuenta.
Compromiso: porque tenemos gran control sobre nuestro destino, ¡¡nos
comprometemos con nuestro destino¡¡.
Respecto: a medida que trabajamos juntos compartiendo éxitos y fracasos, llegamos
a respetarnos los unos a los otros y a ayudamos mutuamente al convertirnos en
merecedores de respeto.
Beneficios de SCRUM
Beneficios de Scrum
CRONOLOGÍA Historia
A mediados de la década de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron una
estrategia de desarrollo de producto flexible e incluyente en la que el equipo de
desarrollo trabaja como una unidad para alcanzar un objetivo común. Estos
describieron un enfoque innovador para el desarrollo de productos que ellos llaman
un enfoque holístico o "rugby", "donde un equipo intenta llegar hasta el final como
una unidad, pasando el balón hacia atrás y adelante. Takeuchi y Nonaka propusieron
que el desarrollo de productos no debe ser como una carrera de relevos secuencial,
sino que debería ser análogo al del juego de rugby en el que el equipo trabaja en
conjunto, pasando el balón hacia atrás y hacia adelante a medida que se mueve como
una unidad por el campo.
✓ Scrum Team
Entender los roles y responsabilidades ✓ Scrum Core Roles
definidos en un proyecto de Scrum es muy ✓ Comprometidos
importante para asegurar la exitosa
implementación de Scrum. ✓ Stakeholder
✓ Implicado
50
Roles
Juntos se conocen como el equipo central o principal de Scrum (Scrum Core Team), es
importante tener en cuenta que, de estos tres roles, ningún papel tiene autoridad
sobre los otros.
51
Product Owner
El Product Owner siempre debe mantener una visión dual él debe entender y apoyar las
necesidades e intereses de todos los Stakeholders, mientras que comprende las necesidades
y el funcionamiento del Development Team.
Scrum Master
El Scrum Master es el Servant Learder quien modera y facilita las interacciones del equipo
como entrenador del equipo y motivador.
Es un facilitador que asegura que el Scrum Team esté dotado de un ambiente propicio para
completar el proyecto con éxito. este guía, facilita y les enseña las prácticas de Scrum a todos
los involucrados en el proyecto; elimina los “impedimentos” que encuentra el Development
Team; y asegura que se estén siguiendo los procesos de Scrum.
Tenga en cuenta que el papel del Scrum Master es muy diferente a la función desempeñada
por el director de proyectos en un modelo de cascada tradicional de gestión de proyectos. El
Scrum Master sólo funciona como un facilitador y el esta en el mismo nivel jerárquico que
cualquier otra persona en el Scrum Team, cualquier persona del Scrum Team que aprenda a
facilitar proyectos de Scrum puede convertirse en el Scrum Master de un proyecto o Sprint.
57
58
59
60
Development Team
Una desventaja importante es que los equipos más pequeños se ven afectados más
significativamente por la pérdida de un miembro del equipo en comparación a los
equipos más grandes, así esta pérdida sea por un corto tiempo.
62
63
65
Stakeholders
Cliente: Es el que adquiere el producto del proyecto, servicio o cualquier otro resultado.
Usuarios: Son aquellos que utilizan directamente el producto del proyecto, servicio o
cualquier otro resultado. También en algunas industrias se conocen como clientes o usuarios
pero en realialidad pueden ser lo mismo.
Épicas: Es una historia de usuario que es demasiado grande para construir en un sprint, a menudo
este término se utiliza para describir una gran historia de usuario que tendrá que ser dividido en
historias más pequeñas.
User Stories: Es una representación de un requisito del usuario en forma escrita de una o dos
frases, utilizando el lenguaje común del usuario.
Task: Es una representación de el requisito que esta en lenguaje del usuario, pero de una forma
técnica donde esta definido como se va a trabajar y quien van a participar.
69
Como esta conformada una User Storie
Una historia de usuario debe estar conformada por las 3C: Características:
Modelo INVEST.
Unidad de trabajo gestionada por los Development. Una tarea tiene asignada
una persona para su realización, y es recomendable que el esfuerzo estimado
para llevarla a cabo sea como máximo el equivalente a una jornada de trabajo.
“Una tarea es creada en lenguaje técnico, mientras las User Stories son creadas
en lenguaje de usuario”
Como esta conformado una Task
ID:
Responsable:
Descripción:
Estimación:
Artefactos
Los artefactos en Scrum son herramientas que propone Scrum para mantener organizado un
proyecto, estos son 4:
Product Backlog
Es uno de los artefactos más esenciales de Scrum, es una lista ordenada de las ideas
para el producto, todo el trabajo que realiza el Development Team proviene del Product
Backlog.
El Product Owner es el responsable Product Backlog, incluyendo el contenido,
disponibilidad y ordenación, aunque puede y debería recibir ayuda para construirlo y
mantenerlo actualizado.
Es uno de los artefactos más esenciales de Scrum, es una lista ordenada de los
requerimientos, ideas para el producto, es la única fuente de requerimiento para
cualquier cambio a realizar, Se trata de una lista de todas las características,
funciones, tecnologías, mejoras y correcciones de errores que constituyen los
cambios que se harán al producto para futuras versiones. Todo el trabajo que realiza
el Scrum Team proviene del Product Backlog.
Ejemplos
78
Definición de DoD
Definición de Terminado
Son los acuerdos del Product Owner con los Stakeholders que contiene todas las condiciones que
deben de cumplir los ítems del Product Backlog para considerar un Sprint completo o finalizado.
Definición de Done
Imaginemos una pareja que acaba de volver del trabajo. El marido decide cocinar
fideos, mientras la mujer ordena la ropa. La mujer pregunta desde la habitación si la
comida está lista el marido responde que no, que en cinco minutos al cabo de un rato
la mujer insiste y el marido orgulloso responde que sí, que la cena está lista.
La mujer se dirige rápidamente a la mesa y encuentra, papeles desordenados y un
vaso medio vacío le pregunta al esposo qué pasa, ni si quiera está hecha la mesa !El
marido ,sorprendido, le contesta que los fideos están listos, lo que significa que la
cena está lista. Ahora resta servirlos en platos, limpiar la mesa ,etc., etc. ¿Quién Tiene
razón? ¡Ambos! ¿Cuál es el problema? Que ambos tienen distintos criterios de hecho.
¿La consecuencia? No solamente el enojo de ambos, si no que las decisiones se
tomaron según el propio criterio de hecho.
Refinamiento Product Backlog
El Sprint Backlog es una lista de tareas que el Equipo realiza para convertir el
elemento seleccionado del Product Backlog en incremento. El Development Team
modifica el Sprint Backlog a lo largo de todo el Sprint. A medida que se va trabajando
o se terminan tareas, se actualizan las horas de trabajo estimado restante para cada
tarea. Sólo el Development Team puede cambiar su Sprint Backlog durante un Sprint.
81
Ejemplo
Burn-Down Chart (Product, Sprint)
Un diagrama Burn-Down o diagrama de quemados, es una representación gráfica del trabajo por
hacer en un proyecto o muestra el esfuerzo restante durante un periodo determinado de tiempo.
A este radicado de información se le puede dar dos usos:
Grafico Ideal
Este diagrama indica un gran compromiso del equipo para organizarse
y trabajar en equipo. El Scrum master ayuda al Development Team en
los bloqueos del sprint, el Development Team no está demasiado
saturado en tareas y ha terminado sus labores a tiempo, en este caso,
no es necesario ninguna acción correctiva.
Gran equipo
EL grafico muestra el progreso de equipos experimentos. El equipo
cumplió con la meta en el tiempo estipulado, y tienen la posibilidad de
completar algún trabajo adicional.
Buen equipo
El grafico indica que el equipo fue capaz de completar su compromiso
a tiempo. Adaptaron el alcance o trabajaron más duro para completar
el sprint. El equipo debe discutir un cambio de plan, ya que se
evidencia que el progreso ha ido disminuyendo desde el comienzo del
sprint.
.
Es muy tarde
Este diagrama muestra que no se ha completado el
compromiso. El equipo no adapto el alcance al nivel
apropiado, en tal situación la capacidad del próximo sprint
debería ser reducida.
Demasiado temprano
El grafico muestra que el equipo termino el trabajo antes
de lo esperado. Las historias fueron posiblemente
sobreestimadas, tampoco se estimó correctamente la
velocidad del equipo. El scrum master debe ser más
proactivo en conseguir que el equipo fije la estimación
correcta o asegurarse de que las historias adicionales
estén listas para ser agregadas.
Durante este tiempo, el Development Team trabaja para convertir las necesidades del
Prioritized Product Backlog en funcionalidades de productos fáciles de enviar.
88
Cancelación de Sprint
Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Solo
el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo
bajo la influencia de los interesados, del Development Team o del Scrum Master.
Cuando se cancela un Sprint, se revisan todos los PBI del Product Backlog que se
hayan completado y “Terminado”. Si una parte del trabajo es potencialmente
entregable, el Dueño de Producto normalmente lo acepta. Todos los PBI no
completados se vuelven a estimar y se vuelven a introducir en el Product Backlog.
Esta pregunta nos ayuda para que el Scrum Team trabaje para proyectar la funcionalidad que se
desarrollara durante el Sprint, donde se define objetivo del Sprint (Sprint Goal).
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del
Development Team.
El objetivo es la primera parte, o las primeras 4 horas, El Scrum Team trabaja para
proyectar la funcionalidad que se desarrollará durante el Sprint, el Development
Team selecciona aquellos elementos del Product Backlog (PBI) que cree que puede
comprometerse a transformar en un incremento potencialmente entregable, el
número de elementos seleccionados del Product Backlog para el Sprint depende
únicamente del Development Team. Durante esta parte de la reunión, no es raro que
el equipo hable y aclare ciertos aspectos con el Product Owner, haciendo preguntas
para alejar la ambigüedad
Sprint Goal
Meta del Sprint
Como regla general, cada sprint debe tener un objetivo común. Esto asegura que
todo los involucrados se mueve en la misma dirección. Una vez que el objetivo ha
sido seleccionado, el Development Team lo implementara.
✓ Facilita la estimación
✓ Genera enfoque y facilita el trabajo en equipo
✓ Ayuda a obtener una retroalimentación relevante
✓ Hace mas fácil analizar las observaciones
✓ Soporte la comunicación con los Stakeholder
¿Cómo se conseguirá completar el trabajo
seleccionado?
Una vez que se ha establecido el Sprint Goal y seleccionado los elementos del
Product Backlog para el Sprint, el Development Team decide cómo construirá esta
funcionalidad para formar un Incremento de producto.
Esta es una de la técnicas mas reconocida en Scrum, ya que es muy sencilla, divertida y eficaz, donde
los Development estima como grupo el esfuerzo a realizar en el Sprint.
Para esta situación de planificación se utiliza mucho la famosa escala Fibonacci (0, 1,
2, 3, 5, 8, ect.) o también se utiliza la actividad de tamaño de camisetas (XS, S, M, L,
XL), entre más grande es la historia a estimar, menos certeza y precisión tenemos en
la misma, el valor 0 indica que una historia de usuario es muy simple y que puede ser
realizado con un esfuerzo mínimo, el signo de infinito indica que la historia es tan
compleja que no hay manera de saber cuánto se puede tardar en realizar, el signo de
interrogación indica que no es nada clara lo que se va a estimar y por último se
encuentra un signo de un Café que lo que hace referencia es hay que darse un
momento para “respirar”.
Actividad
Planning
Póker
Antes de empezar con el Planning póker, hay que definir qué unidad se va a utilizar
para medir, esta puede ser horas, días ideales, puntos funcionales, esfuerzo o
cualquier otra métrica, para nuestro ejemplo utilizaremos una métrica llamada
puntos de historia.
Esto es una reunión diaria de corta duración, Time-boxed a 15 minutos. Los miembros del
equipo se reúnen para informar sobre cómo marcha el proyecto.
respondiendo a las siguientes tres preguntas:
Al centrarse en lo que cada persona llevo a cabo ayer y cumplirá hoy, le permite al equipo
obtener una excelente comprensión de que trabajo se ha hecho, y el trabajo que queda por
realizar. La reunión de Scrum diario no es una reunión de actualización de estado en el que
un jefe está recogiendo información sobre quién está detrás de lo programado. Más bien, se
trata de un encuentro en que los miembros del equipo se comprometen entre sí.
¿Qué pasa con los • En esta ceremonia no se soluciona impedimentos, los Development
impedimentos se vuelven a reunir inmediatamente del Daily para tener discusiones
hallados? detalladas para adaptar, o replanificar el resto del trabajo.
97
El Sprint Review se evalúan los entregables en contra del objetivo del Sprint
determinado durante la reunión del Sprint Planning Meeting, se inspecciona el
Incremento y adapta el Product Backlog si fuera necesario.
Cabe aclarar que trata de una reunión informal, no una reunión de seguimiento y la
presentación del Incremento tiene como objetivo facilitar la retroalimentación de
información y fomentar la colaboración.
Una de las reglas de Scrum es pasar no más de una hora en una reunión de revisión
del sprint para cada semana del Sprint.
Reflexionar
Aquí es donde comienzan a aparecer las ideas, los posibles caminos a recorrer.
Durante la reflexión el equipo analiza los hechos y busca responderse dos preguntas
básicas:
• ¿por qué pasó lo que pasó?
• ¿cómo mejorar?
El equipo empieza a tener ideas sobre cómo poder seguir avanzando, no perdiendo
de vista las consecuencias que cree generarán los cambios.
Es aquí donde se empieza a comprender cómo los eventos, comportamientos y
circunstancias afectan al trabajo del equipo Development.
Decidir qué Hacer
Siempre hay que fomentar que el equipo busque acciones para solucionar sus
problemas.
Este es un momento crucial en la retrospectiva, y representa el compromiso del
equipo para actuar a futuro. El equipo deberá armar un plan de acción para concretar
alguno de los experimentos planteados en la reflexión.
Las acciones que el equipo decida tomar deben poder llevarse adelante por ellos
mismos: esperar que otras personas actúen por el equipo es un camino seguro a la
frustración.
Es importante evitar las retrospectivas de "hacer nada", porque pierden justamente
el sentido de la reunión: uno de los grandes impedimentos para mejora es que
pensemos que todo es perfecto o en su defecto que no tiene solución, pero también
es perder la iniciativa por aprender cosas mejores.
Cerrar la retrospectiva
Durante la retrospectiva el equipo trabajó mucho, realizó varias actividades y genera
un compromiso y plan de acción para el próximo sprint. Debemos guardar todo el
trabajo hecho durante la retrospectiva. Por ejemplo:
• registrar lo expuesto y sus soluciones
• sacar fotos de las actividades
•sacar fotos al pizarrón
Lo esencial del cierre es que todos los miembros del equipo se retiren con acciones
concretas y experimentos para aplicar durante la próxima iteración.
Técnica del Barco
Técnicas para
Retrospectiva
Técnicas para
Retrospectiva