TALLER
SCRUM
Conceptos y aplicación de SCRUM
02 mayo 2018
1
Taller- SCRUM
Índice
➢ ÁGIL
✓ Dinámica 1
✓ ¿Que es Ágil?
✓ Enfoque Tradicional Vs Ágil.
✓ Manifiesto Ágil.
✓ 12 Principios Agiles.
➢ MARCO DE TRABAJO
✓ SCRUM/XP/KAMBAN.
➢ SCRUM
✓ Que es SCRUM ?
✓ Principios de SCRUM.
✓ Elementos de SCRUM(Roles, Eventos y Artefactos)
✓ Dinámica 2
➢ Ciclo SCRUM
✓ Ciclo
✓ Ejemplo Practico
✓ Dinámica 3
ÁGIL
¿Que es Ágil?
• Serie de técnicas para la gestión de Ecosistema de Incertidumbre
proyectos que se originaron en
contraposición a los métodos
clásicos.
• ‘Agile’ es un conjunto de metodologías
para el desarrollo de proyectos que
precisan de rapidez y flexibilidad para
adaptarse a condiciones cambiantes del
sector o mercado.
• Proyectos que se “trocea” en pequeñas
partes que tienen que completarse y
entregarse en pocas semanas.
3
“Entregar valor en el menor tiempo posible”
ÁGIL
Enfoque Tradicional Vs Ágil
Enfoque Tradicional
Es la construcción de software que usan empresas de todos los tamaños es el ciclo de
vida secuencial “en cascada”. ( “Waterfall“ )
Características:
a. Correlación entre actividades y fases de tiempo.
b. Actividades secuenciales.
c. “…Con el ciclo de vida en cascada una gran idea tardía no es una bendición, es una
amenaza.”.
d. Detección de errores en forma tardía.
Análisis
Diseño
Construcción
Construcción
Pruebas
4
ÁGIL
Enfoque Tradicional Vs Ágil
Enfoque ÁGIL
Crean productos funciones desde el principio
✓ Desarrollo iterativo. ✓ Equipos que priman la colaboración.
✓ Equipos que se auto-organizan. ✓ Procesos adaptables con capacidad de
respuesta al cambio.
5
ÁGIL
Enfoque Tradicional Vs Ágil
ÁGIL
Manifesto Ágil
Todos los sistemas de trabajo de procesos Agiles se basan en cuatro
valores del Manifiesto Ágil, sobre los que añaden unos ejercicios
específicos para ponerlos en práctica.
8
ÁGIL
12 Principios Agiles. (1/3)
Principio 1: Nuestra mayor prioridad es satisfacer al Principio 2: Aceptamos que los requisitos
cliente mediante la entrega temprana y continuada de cambien, incluso en etapas tardías del
software con valor desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva
al cliente.
Principio 3: Entregamos software funcional
frecuentemente, entre dos semanas y un mes, con Principio 4: Los responsables de negocio y
preferencia por periodos de tiempo lo más corto los desarrolladores trabajamos juntos de
posibles. forma cotidiana durante todo el proyecto
9
ÁGIL
12 Principios Agiles. (2/3)
Principio 5: Los proyectos se desarrollan en torno a Principio 6: El método más eficiente y efectivo de
individuos motivados. Hay que darles el entorno y el comunicar información al equipo de desarrollo y
apoyo que necesitan, y confiarles la ejecución del entre sus miembros es la conversación cara a cara
trabajo.
Principio 8: Los procesos Ágiles promueven el
Principio 7: El software funcionando es la principal
desarrollo sostenible. Los promotores,
medida progreso
desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
Trabajar no es el objetivo; alcanzar el producto es el
objetivo.
10
ÁGIL
12 Principios Agiles. (3/3)
Principio 9: La atención continua a la excelencia Principio 10: La simplicidad, o el arte de maximizar
técnica y al buen diseño mejora la Agilidad la cantidad de trabajo no realizado, es esencial.
Principio 11: Las mejores arquitecturas, requisitos Principio 12: A intervalos regulares el equipo
y diseños emergen de equipos auto-organizados. reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su
comportamiento en consecuencia.
11
MARCO DE TRABAJO
METODOLOGÍAS ÁGILES
Actualmente existen diversas metodologías de gestión Ágil, siendo la más popular para la
gestión de proyectos Scrum.
SCRUM:
Scrum es el más común entre equipos ágiles. Se centra en la
colaboración y los incrementos de trabajo, y en ese sentido es
similar a Kanban. Scrum difiere en cómo se divide el trabajo
en períodos de tiempo o cuadros de tiempo.
Extreme Programming (XP):
Es una metodología de desarrollo que pertenece a las
conocidas como metodologías ágiles, cuyo objetivo es el
desarrollo y gestión de proyectos con eficacia, flexibilidad y
control. XP programming es una metodología basada en la
comunicación, la reutilización del código desarrollado y la
realimentación.
KAMBAN:
Es una palabra japonesa que significa “tarjetas visuales” (kan
significa visual, y ban tarjeta). Esta técnica se creó en Toyota,
y se utiliza para controlar el avance del trabajo, en el
contexto de una línea de producción. Actualmente está
siendo aplicado en la gestión de proyectos software.
12
SCRUM
Que es SCRUM ?
Scrum es un marco de trabajo ( framework ) iterativo e incremental
para el desarrollo de proyectos, productos y aplicaciones, que se
engloba dentro de las metodologías ágiles (“Agile”).
SCRUM…
✓ Está basado en la teoría de control de procesos empíricos
✓ Es iterativo e incremental
✓ Optimiza la predictibilidad y control de riesgos
13
SCRUM
Principios SCRUM
Se basa en 3 principios:
➢ Transparencia: Todos los aspectos que influencian el resultado deben
de ser visibles al cliente.
➢ Inspección: Todos los aspectos del proceso deben de ser
inspeccionados frecuentemente para detectar variaciones inaceptables
en el mismo o en el producto resultante.
➢ Adaptación: Si se detectan variaciones inaceptables, se deben tomar
medidas para adaptar dichos procesos o dicho resultado.
SCRUM
Elementos de SCRUM
SCRUM
Roles : SCRUM MASTER
➢ El SCRUM Master es responsable de asegurar que el equipo se adhiere a
los valores de SCRUM, a sus practicas y a sus reglas.
➢ Ayuda no sólo al equipo, sino a la organización en general a adoptar
SCRUM.
➢ Guía al equipo de SCRUM , conduciéndolo a ser más productivo y a
crear productos de más alta calidad.
➢ Enseña al equipo a ser más autosuficiente.
➢ Guía las reuniones ( Daily Planning, Sprint Planning, etc ).
➢ Impide interrupciones externas al equipo.
➢ El SCRUM Master no es el jefe de proyecto a la manera tradicional,
dictando las tareas explícitamente: El equipo se organiza por sí mismo
en gran parte
SCRUM
Roles : PRODUCT OWNER
➢ El Product Owner es el único responsable del Product Backlog y de
asegurar el valor comercial del trabajo que el equipo realiza. (
Responsable por la visión del producto )
➢ Mantiene el Product Backlog y asegura que sea visible a todo el
mundo.
➢ Gracias a él, todo el mundo sabe que tareas tienen la máxima prioridad,
con lo que todos las personas implicadas pueden saber en qué se está
trabajando.
➢ Redefine prioridades entre Sprints
➢ Acepta o rechaza características del producto luego de cada iteración
➢ Es una sola persona (no un comité).
SCRUM
Roles : EL EQUIPO
➢ Responsable por el desarrollo del producto.
➢ Se compromete en cada Sprint Planning a convertir una cierta cantidad
del Product Backlog en Producto Potencialmente Entregable.
➢ Los miembros del equipo deben de tener las habilidades necesarias para
crear dicho incremento.
➢ Provee estimaciones para cada requerimiento ( user story )
➢ Con Funciones Cruzadas.
➢ Los equipos se auto-organizan: Nadie (ni tan sólo el SCRUM Master) le
dice al equipo cómo transformar el Product Backlog en un incremento
del producto final que esta potencialmente listo para una Release; el
equipo lo decide por sí solo..
➢ El tamaño ideal para un equipo es de siete personas (más – menos dos).
Cuando hay menos de cinco, no hay mucha interacción y la productividad
se resiente. Cuando el equipo es más grande, es muy complicado de
manejar bajo el framework SCRUM.
SCRUM
Eventos: Sprint Planning
También llamada “reunión de kick-off” para el Sprint, es en esta reunión
que se planea la iteración. Se limita a 4 horas por Sprint, dividida en dos
partes de 2 horas:
✓ Durante la primera parte (el “Qué”) se decide que puntos del
Product Backlog se van a trabajar en el Sprint.
El Product Owner presenta el Product Backlog priorizado.
El Equipo estima uno por uno las User Stories ( U.S )
Se discuten U.S. y se agregan al Backlog como un acuerdo
entre El Equipo y el P.O.
✓ Durante la segunda (el “Cómo”), el equipo decide cómo se van a
desarrollar dichos puntos.
• Que Tareas se necesitarán para desarrollar lo
comprometido. Se dividen las U.S en tareas.
• Solo el equipo participa de esta parte de la reunión.
SCRUM
Eventos: Daily Scrum
➢ La reunión diaria de SCRUM mejora las comunicaciones entre el
equipo, eliminando la necesidad de muchos otras reuniones. Sirve
para identificar y eliminar obstáculos que impiden el avance en el
desarrollo, hace patente la necesidad de tomar decisiones rápidas y
homogeniza el nivel de conocimiento sobre el estado del proyecto
entre todos los miembros del equipo.
➢ Reunión diaria de 15 minutos, que tiene lugar en el mismo sitio y a la
misma hora cada día. Durante la reunión (se aconseja que los
miembros estén de pie, y por eso a veces se le llama “stand up
meeting”), se cada miembro del equipo responde a las tres preguntas
siguientes, fundamentales en SCRUM:
▪ En qué ha estado trabajando desde el último SCRUM diario.
▪ En qué va a trabajar hasta el próximo SCRUM diario.
▪ Qué obstáculos (si los hay) tiene para realizar dicho trabajo.
SCRUM
Eventos: Sprint Review
➢ El Sprint Review tiene lugar al final del Sprint
➢ El Product Owner verifica la realización del Backlog acordado.
➢ El Product Owner acepta o rechaza la funcionalidad
➢ El equipo muestra el producto potencialmente entregable que
construyeron recientemente en el ultimo sprint.
➢ Cualquier feedback, entregado por el Product Owner, se debe
incorporar al Product Backlog para ser nuevamente priorizado.
SCRUM
Eventos: Retrospectiva
➢ Tiene lugar después del Sprint Review y antes del próximo Sprint Planning, estimado
en 3 horas.
➢ En él, el SCRUM Master alienta al equipo a revisar, dentro el framework SCRUM, los
procesos de desarrollo y las prácticas actuales, para hacer que el próximo Sprint sea
más productivo y más efectivo para todos.
➢ El principal propósito de la reunión Retrospective es ver cómo fue el último Sprint en
relación a los miembros del equipo, sus relaciones y interacciones, los procesos y
las herramientas usadas
SCRUM
Artefactos: Product Backlog
➢El Product Backlog contiene los requerimientos para el producto que el
equipo va a desarrollar. ( Pila de requerimientos priorizados )
➢El Product Backlog es responsabilidad única y exclusivamente del
Product Owner. Se encarga no sólo de su contenido, sino de su
disponibilidad, visibilidad y priorización.
➢El Product Backlog nunca está completo; evoluciona a medida que el
producto y el entorno donde dicho producto se enmarca evolucionan. Es
dinámico, y siempre debe asegurar que el producto desarrollado sea
apropiado, competitivo y útil.
➢Mientras el producto exista, el Product Backlog existe.
➢Los items pueden ser :
➢ Epics – Requerimientos de alto nivel
➢ Features – Requerimientos intermedios
➢ User Stories – Requerimientos de Bajo nivel
▪ Como ( Actor ) ….
▪ Necesito ( Actividad ) ….
▪ Con el objetivo de ( objetivo buscado ) ….
➢ Cuanto mas prioridad tiene un item, más pronto será procesado por
el equipo de desarrollo.
SCRUM
Artefactos: Sprint Backlog
➢Consiste en las tareas que el equipo realiza durante 1 Sprint para
transformar los requerimientos del Product Backlog en un incremento
acabado.
➢Las tareas deben de ser simples.
➢El equipo es el encargado de actualizar el Sprint Backlog . Puesto que
las tareas son unidades pequeñas (tareas simples), es posible que
acaben apareciendo tareas nuevas o algunas desaparezcan durante el
Sprint.
➢El Sprint Backlog es una imagen a tiempo real del trabajo que el equipo
planea acabar durante un Sprint, y es propiedad exclusiva de éste
equipo.
SCRUM
Artefactos: Burndown Charts
➢ El gráfico Sprint Backlog Burndown muestra la cantidad de trabajo aún
por realizar.
➢ Se crea sumando las estimaciones del tiempo del Sprint Backlog aún
por hacer, cada día.
➢ Es un gráfico de línea, con el que el equipo mide la evolución para
completar un Sprint. Sólo se consideran dos variables:
▪ Trabajo aún por realizar
▪ Fecha
CICLO SCRUM
Ciclo SCRUM
CICLO SCRUM
➢ Técnicas de Estimación
Planning Poker
Conocido también como Estimation Poker. Esta técnica de
estimación implementa el consenso para estimar los tamaños
relativos de las historias de usuario o el trabajo necesario para
desarrollarlos.
CICLO SCRUM
➢ Técnicas de Estimación
Planning Poker – U.S.
• ¿Cuántas historias puedo desarrollar?
(Según la velocidad del equipo)
• Aprendizaje del producto.
• Conocimiento homologado.
• Descubrimiento de nuevas historias de usuario o que agregan valor
28
29
CICLO SCRUM
➢ Técnicas de Estimación
Estimación del Equipo - Tareas
• ¿Cuánto trabajo puedo aceptar?
(Esfuerzo estimado < Esfuerzo ideal)
• Análisis técnico detallado.
• Identificación de problemas y riegos.
• Desglose de actividades.
30
CICLO SCRUM
¿Que es una User Story ?
➢Breve descripción de la funcionalidad, contada
desde la perspectiva del usuario.
✓ Como ( Actor ) ….
✓ Quiero ( Actividad ) ….
✓ Para ( objetivo buscado ) ….
➢Contenido:
✓ Que debería hacer el sistema en
términos del negocio
✓ Sin tecnicismos
➢Redacción:
✓ por el cliente y PO
✓ el PO y el Equipo
CICLO SCRUM
Ejemplo Practico
32
CICLO SCRUM
Ejemplo Practico
Footer Text 33
CICLO SCRUM
Ejemplo Practico
34
CICLO SCRUM
Ejemplos Practico
35
CICLO SCRUM
Ejemplos Practico
36
CICLO SCRUM
Ejemplos Practico
37
CICLO SCRUM
Ejemplos Practico
38
CICLO SCRUM
Ejemplos Practico
39
CICLO SCRUM
Ejemplos Practico
40
CICLO SCRUM
Ejemplos Practico
41
CICLO SCRUM
Ejemplos Practico
42
CICLO SCRUM
Ejemplos Practico
43
CICLO SCRUM
Ejemplos Practico
44
CICLO SCRUM
Ejemplos Practico
45
CICLO SCRUM
Ejemplos Practico
46
CICLO SCRUM
Ejemplos Practico
Footer Text 47
CICLO SCRUM
Ejemplos Practico
48
CICLO SCRUM
Taller
CREACIÓN DE HISTORIAS DE USUARIO
49
Georgina Suarez
[email protected]
50
