Seminario Scrum CLEFormacion

Scrum y Métodos Ágiles
Orador principal: Fernando Silvano Gil
Twitter: @GilSilvano
23/10/2015
CLEFORMACIÓN

Scrum y Métodos Ágiles 2
Contenidos
1. ¿Por qué los Métodos Ágiles?
2. ¿Qué son Métodos Ágiles?
3. Prácticas Ágiles
4. Scrum
5. Métricas y Medidas
6. Claves del Éxito

1. ¿Por qué Métodos Ágiles?

 Los Proyectos fallan
 No se entregan a tiempo
 No cumplen con los objetivos
 Cuestan más de lo estimado
 ¿De quién es la culpa?
 Hay demasiada documentación
 Hay muchos cambios
 La tecnología no es adecuada
 Los desarrolladores no son expertos
 La metodología falla (carrera de relevos)
 …

 Modelo de desarrollo tradicional (en cascada)
 Realizar de manera exhaustiva: Análisis, Diseño,
Implementación, Pruebas, Despliegue, Mantenimiento
 ¿Qué valor aportan estos proyectos?
 ¿En qué coste incurren?
 Al 90% del proyecto el valor aportado puede ser casi nulo

 Modelo de desarrollo incremental
 Realizar entregas periódicas que aportan valor
 Aportan valor desde la primera iteración
 Y siguen aportándolo de manera periódica
 Pero esto no es ágil…

 Modelo de desarrollo ágil
 No solo realizar entregas periódicas
 Sino priorizar las que aportan más valor
 El valor aportado al principio es mayor
 El valor aportado al final es menor

 Modelo de desarrollo ágil
 Pero esto nos da la oportunidad de añadir más valor en
subsiguientes iteraciones
 Y así poder continuar con el proyecto

 En resumen
 Los métodos ágiles buscan aportar el mayor valor lo antes
posible
 Dejando abierta la posibilidad de aumentar el valor
 Como efecto colateral permiten adaptarse a los cambios
 Y responder al feedback del cliente
 La cancelación del proyecto sigue aportando valor
 Es especialmente útil en proyectos con una duración y/o
un coste fijos que buscan aportar el máximo valor
 No funcionan tan bien cuando se quiere seguir un plan

1. ¿Qué son Métodos Ágiles?

Manifiesto Ágil
 2001, Kent Beck et. Al.
“Estamos poniendo al descubierto mejores métodos para
desarrollar software, haciéndolo y ayudando a otros a que lo
hagan ”
 Valorar más:
 Individuos y su interacción
 Software que funciona
 Colaborar con el cliente
 Respuesta al cambio
 Aunque lo de la derecha es importante valoramos
más lo de la izquierda
 Por encima de:
 Procesos y herramientas
 Documentación
 Ceñirse a contratos
 Seguir un plan

Manifiesto Ágil
 Individuos y su interacción
 Los procesos ayudan al trabajo
 Las herramientas mejoran la eficiencia
 Pero sin personas con conocimientos y actitud adecuados
no se consiguen resultados
 Software que funciona
 Es difícil tener un documento con todos los requisitos al
inicio del proyecto
 Los prototipos generan un feedback enriquecedor
 El exceso de documentación genera mucho trabajo que
no aporta valor directo al producto

Manifiesto Ágil
 Colaborar con el Cliente
 Las necesidades del cliente cambian
 Un contrato no aporta valor al producto
 El cliente debe ser un miembro más del equipo que
colabora en el equipo de trabajo
 Respuesta al Cambio
 Los proyectos tienen cambios
 Asegurar un plan es difícil
 Anticipación y adaptación al cambio

Principios del Agilismo
 Satisfacer al cliente mediante entregas tempranas y continuas
de software de valor
 Doblegarse a los requisitos cambiantes
 Trabajo conjunto de personas de negocio y desarrolladores
 Mantener la motivación de los individuos
 Aportarles los entornos y apoyo que necesiten
 Confiar en su capacidad
 Comunicar la información cara a cara
 Utilizar el software que funciona como medida de progreso
 Mantener un ritmo constante de trabajo
 Simplicidad y excelencia técnica
 Equipos auto-organizados
 Auto-reflexión periódica del equipo para ser más efectivos

Actividades y Fases de Proyecto
 Todo proyecto incurre en una serie de actividades
 Toma de requisitos
 Diseño Arquitectónico
 Construcción
 Pruebas de Integración (internas)
 Pruebas de Sistema (externas)
 Estas actividades se realizan (o no) en fases
 Modelo de Ciclo de Vida
 Cómo se secuencian y particionan estas actividades
 Es determinante para que una metodología funcione

¿Por qué ese interés?
 ¿Qué es mejor?
 Modelo puramente secuencial (Cascada)
 Implica realizar todas las pruebas al final
 Y éstas derivan en cambios y agujeros en los requisitos
 Además, seguramente impliquen cambios de diseño
 Modelo puramente iterativo (XP)
 XP Implica centrarse en la construcción
 Se pierden de vista los requisitos y el diseño
 Al final se acumulan los requisitos cambiantes
100% Requisitos 100% Diseño 100% Construcción 100% Test

¿Por qué ese interés?
 Las prácticas ágiles sólo son efectivas si el modelo
de ciclo de vida es adecuado
 El modelo de ciclo de vida es el atributo definitorio
de un Método Ágil
 Indica si un método es o no es Ágil
 Se pueden hacer mucha o pocas iteraciones
 Con mucha o poca dedicación a cada actividad

Historias de Usuario
 Representación de una característica escrita en una o dos
frases utilizando el lenguaje común del usuario
 Como {rol} quiero {algo} para obtener {valor de negocio}
 Forma rápida de administrar los requisitos sin elaborar gran
cantidad de documentos formales
 Debe ser limitada, escribible sobre un post-it
 De duración estimada entre 10 horas y 2 semanas
 Tiene asociada una prioridad
 Tiene asociadas unas pruebas de validación
 No es una especificación rigurosa sino un comienzo
 No es una tarea

 Cada historia es, en principio, independiente
 Las historias SON negociables
 Las historias son valiosas
 Las historias son estimables
 Días ideales
 Puntos de historia
 Triangulación
 Las historias deben ser pequeñas y fáciles de entender
 Las historias debe poder probarse para asegurar que han
finalizado
 Pruebas unitarias
 Criterio de aceptación
 Prototipos

 Beneficios
 Representan requisitos que pueden implementarse
rápidamente (días o semanas)
 Necesitan poco mantenimiento
 Mantienen una relación cercana con el cliente
 Permite dividir los proyectos en pequeñas entregas
 Permite estimar fácilmente el esfuerzo de desarrollo
 Ideal para proyectos con requerimientos no muy claros

 Limitaciones
 Sin pruebas de validación pueden quedar abiertas a
distintas interpretaciones haciendo difícil utilizarlas como
base para un contrato
 Se requiere un contacto permanente con el cliente
durante el proyecto lo cual puede ser difícil o costoso
 Podría resultar difícil escalar a proyectos grandes
 Requiere desarrolladores muy competentes
 Requieren saber cuando se puede considerar hecha

Planning Poker
 Estimación de tareas por consenso
 Utilizando cartas con valores:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?,
 No tiene unidades, el objetivo no es dar un valor
 Se explica la característica a estimar y todos votan
excepto un moderador
 Los votos más extremos deben explicarse
 Se repite la votación hasta el consenso
 Evita el poder de alguien influyente
 Incluye el punto de vista del cliente

Planning Poker

Programación por Pares
 Todo el código es escrito por parejas de programadores
 una sola máquina con un teclado (piloto) y un mouse
 No es un programador trabajando y el otro mirando
 No es una sesión de aprendizaje para un programador junior
 El que no está escribiendo
 piensa más estratégicamente
 revisa el código en tiempo real
 Los roles se pueden cambiar varias veces durante el día
 Fundamentos:
 dos programadores trabajando juntos son más efectivos
 el conocimiento grupal crece más rápido
 trabajar es más divertido

Propiedad colectiva del código
 Cualquier integrante del grupo tiene autoridad para
cambiar cualquier parte del código fuente
 Todos son dueños del código
 Siempre se utilizan estándares
 Los tests siempre deben funcionar al 100%
 Se integra con todo el sistema permanentemente
 Manejo de configuración

Refactorización
 Si el código se está volviendo complicado
 Modificar el diseño, volver a uno más simple
 Refactoring: modificar la forma del código sin
cambiar su funcionamiento
 Ejemplos: extraer método, renombrar (clase, método,
variable, etc.), reemplazar
 Hay herramientas
 C#Refactory (Xtreme Simplicity)
 Eclipse
 …

Pruebas
 Test Driven Development
 Diseño e implementación de las pruebas antes de
programar la funcionalidad
 El programador crea sus propios tests de unidad
 Integración continua
 Integración diaria
 Disponer de una máquina para integración
 Tests funcionales
 Cliente

Semana de 40 horas
 El desarrollo de software es un ejercicio creativo
 hay que estar fresco y descansado
 Sin “héroes”
 Se reduce la rotación de personal
 Mejora la calidad del producto
 Se permiten excepciones, con cuidado
 más de una semana de horas extra: problema

Descansos entre Proyectos
 En una empresa hay múltiples proyectos activos
 Se tiende a asignar gente disponible a esos proyectos
 Esto garantiza que cada individuo esté siempre ocupado
 Pero estando cada vez en un proyecto
 El punto crítico está en la persona/equipo sobrecargada
P1 P2 P3P1 P2 P3
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 2
Proyecto 2
Proyecto 1
Proyecto 2
Proyecto 2
Proyecto 2
Proyecto 3
Proyecto 3
Proyecto 3
Proyecto 1
Proyecto 2
Proyecto 2
Proyecto 1
Proyecto 2
Proyecto 3
Proyecto 3
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 2 Proyecto 2
Proyecto 1
Proyecto 2
Proyecto 3Proyecto 3
Proyecto 1
Proyecto 1
Proyecto 2
Proyecto 3

Descansos entre Proyectos
 Esto hace que cada proyecto se extienda en el tiempo
 Y puede ocasionar que un proyecto se cancele por demora
 Merece la pena liberarle de carga y cerrar los proyectos
 El tiempo entre proyectos se dedica a otras tareas
 Refactorización, formación, Google labs,…
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 2
Proyecto 2
Proyecto 2
Proyecto 3
Proyecto 3
Proyecto 3
7 meses
8 meses
9 meses
Proyecto 1
Proyecto 1
Proyecto 1
Proyecto 2
Proyecto 2
Proyecto 2
Proyecto 3
Proyecto 3
Proyecto 3
3 meses
6 meses
9 meses

Scrum
“El factor más importante en el desarrollo de software no son las
técnicas y las herramientas que emplean los programadores,
sino la calidad de los propios programadores”
Robert L. Glass
“Estimo que el 75% de las organizaciones que utilizan Scrum no
van a obtener los beneficios que esperan”
Ken Schwaber
Scrum y XP desde las Trincheras
Henrik Kniberg

Scrum
 No es método independiente, sino complemento de
otras metodologías (XP, MSF, RUP)
 Enfatiza valores y prácticas de gestión, no
cuestiones técnicas de desarrollo
 Equipos auto-dirigidos y auto-organizados
 No hay manager que decida, solo “miembros del equipo”
o “cerdos”
 Excepción: el Scrum Master que debe ser 50%
programador y que resuelve problemas, pero no manda
 Los observadores externos se llaman “gallinas”; pueden
observar, pero no interferir ni opinar

Categorías en Scrum
 Primero un chiste:
Una gallina y un cerdo pasean por la carretera cuando la gallina le dice al
cerdo: “¿Qué te parece si abrimos un restaurante?”, a lo que el cerdo
le pregunta: “¿y cómo se llamaría?”
La gallina le contesta: “Huevos con jamón” y el cerdo le replica: “No estoy
de acuerdo porque en este negocio, Yo estaría comprometido,
mientras que tu sólo estarías implicada”
 Quienes tienen la responsabilidad también tienen la autoridad
necesaria para poder lograr el éxito del proceso
 Para que quienes no la tienen no puedan producir
interferencias innecesarias

Roles en Scrum (Cerdos)
 Dueño del Producto (Product Owner)
 Determina qué es importante para el proyecto
 Determina la dirección en que evoluciona el producto
 Scrum Master
 Debe asegurar que el proyecto progresa con suavidad
 Y que el equipo tiene lo que necesita para tener éxito
 Establece reuniones
 Resuelve problemas
 Monitoriza el progreso del proyecto
 Equipo Scrum (Analista, Desarrollador, Tester,…)
 Proactivos, multifuncionales, autoorganizados, <10 por equipo

Roles en Scrum (Gallinas)
 Usuarios finales
 Marketing
 Áreas comerciales
 Áreas contables
 Administradores
 Etc

Ciclo de Scrum

Sprint
 Iteraciones de treinta días; se admite que sean más
frecuentes (recomendado 3 semanas)
 Demostración a participantes externos al final de
cada iteración en una fecha indicada
 Al principio de cada iteración, planeamiento de una
Meta expresada en términos de negocio
 Planificación del Sprint entre todos con una agenda
acotada (no alargar reuniones!!)
 Se selecciona una Pila de Sprint
 Historias que se van a incluir en el Sprint

Pila de Producto (Product Backlog)
 Lista priorizada de requisitos/historias
 Nombre, importancia, estimación inicial, cómo probarlo,…
 Puntos de historia: días/persona ideales para completar la
historia

Pila de Sprint (Sprint Backlog)
 Historias ordenadas
por importancia de la
pila de producto que se
van a implementar
 Tener en cuenta la
velocidad del equipo

Cambios durante el Sprint
 Durante un Sprint no se puede modificar el
contenidos de la pila
 El cliente puede cambiar una historia en las
reuniones mensuales (cambiando el alcance y/o
prioridad de una historia, o dividiéndola)
 Sólo el Scrum Master puede abortarlo
 Si la tecnología seleccionada no funciona
 Si las circunstancias del negocio han cambiado
 Si el equipo ha tenido interferencias

División de las historias
 Al equipo le interesan tareas pequeñas
 Una historia se descompone en tareas
 No son entregables, el cliente no se preocupa
 Pizarra y post-its

Scrum Diario

Alarmas
 Tareas terminadas de baja prioridad
 Exceso de tareas no planificadas

Al final de un Sprint…
 Hacer una demo para:
 Obtener reconocimiento para el equipo
 Que todos sepan lo que se está haciendo
 Obtener un feedback de los interesados
 Permite interactuar con otros equipos
 Fuerza a que realmente se terminen las cosas
 Auque haya poco y el resultado sea malo que enseñar se
motiva al equipo para que la próxima demo sea mejor

Al final de un Sprint…
 En la demo, centrarse en:
 Presentar claramente el objetivo del Sprint
 No hacer florituras (PPT, detalles de implementación,…)
 Mantener un ritmo rápido
 Mantenerse a nivel de negocio, sin detalles técnicos
 Hacer una retrospectiva para ver
 Cosas bien hechas
 Cosas mejorables
 Ideas de mejora para el futuro

¿Cómo funciona el equipo?
 Las métricas y medidas proporcionan una
indicación de dónde se puede mejorar
 Hay medidas informativas y motivacionales
 Las informativas pueden ayudar a mejorar los
procesos y a ser más efectivo y coordinado
 En los Métodos Ágiles interesan las informativas
 ¿Cómo las tomamos? Preguntado al equipo
 ¿Cuándo las tomamos?
 En el Scrum diario  Medidas de coordinación
 En la retrospectiva  Medidas de proceso

Diagrama Burndown
 Muestra el progreso de tareas completadas en un Sprint
 ¿Se van a conseguir los objetivos del Sprint?
 Por encima de la diagonal  Exceso de historias
 Por debajo de la diagonal  Pocas historias

Diagrama Burndown
 Inicializarlo en la planificación del
Sprint
 Marcando en el eje X el Nº de días
 Y en el eje Y el Nº de horas de
trabajo estimadas
 Marcar la tendencia ideal
 Si el ritmo de trabajo fuera
constante
 Diariamente se actualiza el valor
 ¿Qué hiciste ayer? ¿Qué harás
hoy? ¿Qué problemas tienes?
110-
100-
90-
80-
70-
60-
50-
40-
30-
20-
10-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

Diagrama Burndown
 Diariamente se monitoriza
 Mirando las tareas pendientes
 Seleccionando las mejores tareas
para no desviarnos del ideal
 Cono de +/- 20%
 Si nos salimos del cono por debajo
 Añadir nuevas historias de la pila
 Porque somos así de buenos! XD
 Si ocurre a menudo hay que
mejorar las predicciones
 Si nos salimos del cono por encima
 Eliminar impedimentos
 Hacer las cosas de otro modo
 Reducir el alcance
110-
100-
90-
80-
70-
60-
50-
40-
30-
20-
10-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

Diagrama Burndown
 NO OCULTAR EL DIAGRAMA
 Es una medida del progreso del proyecto y es importante
que el equipo y cualquiera que le interese pueda verlo
 ACTUALIZARLO A DIARIO
 Si no se actualiza a diario surgen tendencias horizontales
que nada tienen que ver con la realidad
 NO TENER EXCESO DE ESPECIALIZACIÓN
 El equipo podría elegir sólo las tareas que le interesa a
cada individuo y dejar las “aburridas” sin hacer
 UTILIZAR EL DIAGRAMA PARA CORREGIR
 Si la tendencia no es buena tomar medidas cuanto antes

Diagrama Burnup
 Representa las historias de usuario completadas
 Estimadas mediante puntos de historia
 Para un Sprint concreto
 Pero sólo cuentan las historias completas (hecho-hecho)
 Hecho-hecho
 Se ha construido de manera adecuada
 Se ha construido el módulo adecuado
 Análisis, diseño, codificación, pruebas y aceptación
 Criterio de Aceptación

Diagrama Burnup
 Inicializarlo en la planificación del
Sprint
 Marcando en el eje X el Nº de días
 Y en el eje Y el Nº de puntos de
historia comprometidos
 Diariamente
 Marcar las historias hechas-hechas
 Esto impone un énfasis en terminar
las historias
 Las historias sin completar no
aportan valor
 No importa el trabajo “en progreso”
 Importa el feedback temprano
50-
45-
40-
35-
30-
25-
20-
15-
10-
5-
0-
‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘ ‘
1 2 3 4 5 6 7 8 9 10 11

Diagrama Burnup
 NO DESESTIMAR EL DIAGRAMA BURNDOWN
 El diagrama de Burndown refleja el progreso del equipo
 El diagrama de Burnup refleja qué tal lo están haciendo
 REALIZAR LAS PRUEBAS DE ACEPTACIÓN
 Si no se acepta, una historia no está hecha-hecha y no se
puede añadir al diagrama y pasará al siguiente Sprint
 UTILIZARLO PARA OBTENER FEEDBACK
 De manera continua y temprana
 Centrándonos en aportar valor de negocio

Velocidad del Equipo
 Medida de la cantidad de trabajo que puede realizar el equipo
en un Sprint
 Medido en cada Sprint
 Basado en el trabajo real que han completado
 Importan los resultados, no el esfuerzo (Hecho-hecho)
 Es una base para la planificación de tiempos
 Varía al cambiar miembros del equipo
 Cuando hay vacaciones
 Al aumentar la experiencia del equipo
 Cuando se presentan problemas o impedimentos
 …
 Permite estimar qué hará el equipo en sucesivos Sprints

Velocidad del Equipo
 Estimar la Pila de Producto
 Extraer las historias a comprometernos para el Sprint
 Ejecutar el Sprint y calcular la velocidad
 No se consideran las historias no terminadas
Velocidad
real = 18

Estimación de la Velocidad
 Opción 1: El tiempo que hizo ayer
 Nos comprometemos a realizar tanto trabajo como el que
completamos en el/los último/s Sprint
 Sólo sirve con equipos experimentados
 No sirve cuando el equipo cambia o hay vacaciones
 Opción 2: Cálculo de recursos
 Calcular la disponibilidad del equipo los días de Sprint
 Considerar el factor de dedicación del equipo pasado
Velocidad = [d/h disponibles] * [Factor de dedicación]

Seguimiento de la Velocidad
 La velocidad debería ser constante
 Si varía mucho algo están haciendo mal
 En los Sprints 3 y 4 es posible que estén pasando por alto
algunas pruebas y el sistema puede volverse inestable
 Por eso en los Sprints 5 a 8 la velocidad ha bajado
0
5
10
15
20
25
30
35
1 2 3 4 5 6 7 8
Velocidad

En resumen
 El gráfico de Burndown muestra el esfuerzo
pendiente en el Sprint actual
 El gráfico de Burnup muestra la cantidad de
software completo que se puede entregar
 La velocidad registra el histórico de software
completado por el equipo

Cultura y Estructura
 Personas
 Es necesario tener un equipo de desarrolladores expertos
 Es necesaria una cultura de formación constante
 Procesos
 Los procesos pesados interfieren en los Métodos Ágiles
 Los equipos ágiles se autogestionan
 Herramientas
 Las herramientas ayudan a realizar el trabajo
 Pero no cambian la cultura de la empresa por sí solas

7 Rasgos de un Gestor Efectivo
1. Habilidad para gestionar y manejar riesgos
2. Orientación a los resultados
3. Mucha energía
4. Sentirse parte del equipo
5. Ser capaz de dedicarse a múltiples tareas
6. Orientación a la mejora
7. Primero escuchar, después hablar

Efectividad del equipo
 El equipo tiene autoridad para tomar decisiones
 El equipo tiene acceso al dueño del producto
 El equipo tiene un gran Scrum Master
 El equipo se reúne diariamente y está al tanto de los
proyectos actuales y futuros
 Todos los implicados asisten a reuniones regulares
 El equipo utiliza la retrospectiva para mejorar
 El equipo sabe lo que significa hecho-hecho
 El equipo es responsable de las tareas a las que se
compromete y lo hace de manera seria
 El equipo es eficiente, productivo, responsable, está
motivado, organizado, dedicado, bien gestionado

Cosas que “huelen mal”
 Falta de energía en el equipo
 No respetar los compromisos
 Equipo preocupado por el tiempo y no por la productividad
 El equipo no quiere hacer demos
 El equipo no quiere hacer reuniones diarias
 El equipo tiende a sobrestimar
 El equipo está desanimado
 Las reuniones diarias no son para el equipo
 Los roles son muy especializados
 El Scrum Master asigna las tareas

Sugerencias
 No buscar culpables, la culpa es del equipo
 Trabajar en conjunto como una unidad
 Mantener al equipo centrado y motivado
 Medir el nivel de agilismo de la empresa
 Personal
 % Cambios
 Cultura corporativa
 Impacto del producto
 Tamaño del equipo
 Dispersión del equipo

Diagrama de Radar
 Permite ver varias variables de un golpe

Diagrama de Radar
 Peor cuanto más disperso

Diagrama de Radar
 Mejor cuanto más centrado

Más Claves [Antes de nada]
 Verificar que el proyectos necesita agilismo
 Si el tiempo o el presupuesto son críticos SÍ
 Si la funcionalidad/características es fija NO
 Si no estaríamos buscando un problema que no existe
 El enfoque incremental siempre es beneficioso
 Aplicar iteraciones en el momento adecuado
 Se puede iterar en cualquier momento (1-2 actividades)
 Cada iteración debe ser lo más compacta posible
 Iterar más rápido donde haya mayor riesgo
 Las release
 Planificarlas de manera interactiva y en ciclos cortos
 En ocasiones son puramente internas

Más Claves [Equipo]
 En general, realizar series de Sprints suele ser más sostenible
que semanas de 40 horas
 Realizar Sprints pequeños
 El progreso del proyecto es más visible
 Mantiene alta la moral
 Minimiza los cambios de rumbo
 Equipo = Desarrollador + QA + Gestor + Cliente
 Mejora la toma de decisiones
 Y esto mejora la ejecución
 Es importante un equipo disciplinado (Teoría Y)
 Utilizar estándares de codificación y buenas prácticas

Más Claves [Pruebas]
 Realizar integraciones y compilados diarios
 Utilizar frameworks de pruebas unitarias
 Automatizar las pruebas de regresión
 Practicar TDD
 Mejora la calidad y minimiza el tiempo para detectar fallos
 Requiere una cultura centrada en los desarrolladores
 Aprender de las retrospectivas
 Permite “afilar el hacha” de manera frecuente
 Permite añadir más valor al proyecto
 Evitar las reuniones “por reunirse”
 Realizar reuniones más cortas

Espacio vital
 La mayor parte de las discusiones interesantes y
valiosas sobre el diseño tienen lugar
espontáneamente frente al tablón de tareas.
 Por esta razón, tratamos de organizar esta área
como una “esquina de diseño” explícitamente.
 No hay mejor manera para obtener una visión
general del sistema que estar de pie en la esquina
de diseño y observar ambas paredes, entonces
echar un vistazo en el ordenador y probar la última
compilación del sistema.

La Pared del Diseño
 La “pared de diseño” es sólo una pizarra grande
que contiene los garabateos más importantes sobre
el diseño y la documentación impresa más
importante:
 Diagramas secuenciales
 Prototipos de la interfaz de usuario
 Modelos de dominio
 etc.

El equipo debe estar junto
 A la gente le cuesta cambiar de sitio.
 No quieren tener que coger todas sus cosas,
desenchufar el ordenador, mover todos los trastos
a una nueva mesa y volver a enchufarlo todo otra
vez.
 Cuanto menor sea la distancia, más resistencia.
“Venga YA, Jefe, ¿Qué necesidad hay de mudarse
a sólo cinco metros?”.
 Pero es necesario. Se notará para cada Sprint.

¿Qué significa estar juntos?
 Audibilidad
 Cualquier miembro del equipo puede hablar con cualquier
otro sin tener que levantarse de su sitio.
 Visibilidad
 Todo el mundo puede ver a los demás.
 Todo el mundo puede ver el tablón de tareas. No
necesariamente tan de cerca como para poder leerlo,
pero si por lo menos verlo.

¿Qué significa estar juntos?
 Aislamiento:
 Si todo el equipo necesitase levantarse y agruparse para
una animada y espontánea discusión sobre el diseño,
nadie fuera del equipo está tan cerca como para ser
molestado. Y viceversa.
 No significa que el equipo tenga que estar completamente
aislado.
 En un entorno cubicular, puede ser suficiente que el
equipo tenga su propio cubículo y paredes
suficientemente gruesas como para filtrar la mayoría del
ruido de los elementos fuera del equipo.

¿Y qué pasa si es un equipo
distribuido?
 Bueno, entonces mala suerte.
 Usa tantas técnicas como sea posible para
minimizar el daño:
 videoconferencia
 webcams
 herramientas de compartición de escritorio
 etc.

Mantén al Dueño de Producto a
mano
 El Dueño de Producto debería estar
suficientemente cerca como para que:
 El equipo pueda caminar hasta donde está y preguntarle
algo
 Para que él pueda acercarse al tablón de tareas.
 Pero no debería sentársele junto al equipo.
 Porque lo más probable es que no sea capaz de
controlarse e interrumpa constantemente entrometiéndose
en cualquier detalle, y el equipo no podrá “fluir”
adecuadamente (es decir, alcanzar un estado centrado,
autogestionado e hiperproductivo)

Mantén a los coachs a mano
 Trabajar tan próximo al equipo como fuera posible.
 Formar los equipos.
 Moverse entre ellos
 Programar por parejas con sus miembros
 Formar a otros Scrum Masters
 Organizar reuniones de Planificación de Sprint
 etc.

¿Cómo hacer los Scrums diarios?
 Empiezan exactamente a su hora.
 Cada día en el mismo sitio.
 Sala aparte para la planificación de Sprints.
 O frente al tablón de tareas.
 Normalmente hacer las reuniones de pie.
 Ya que eso reduce el riesgo de sobrepasar los 15
minutos.

Actualizar el tablón
 Actualizamos el tablón de tareas durante los Scrum
diarios.
 El Scrum Master:
 Conforme cada persona describe lo que hizo el día
anterior y lo que hará hoy, mueve los post-it en el tablón.
 Conforme describe elementos no planificados, pone un
pos-it nuevo para cada uno de ellos.
 Conforme actualiza sus estimaciones, escribe una nueva
estimación en el post-it correspondiente y tacha la anterior
estimación.

 Algunos equipos tienen la política de que cada
persona debe hacer la actualización del tablón que
le corresponda antes del cada reunión.
 Sea cual sea el formato de tu Pila de Sprint, intenta
involucrar a todo el equipo en la labor de mantener
la Pila de Sprint actualizada.

Desventajas de que el Scrum
Master solo actualice
 El Scrum Master pasa demasiado tiempo
administrando asuntos, en vez de dar soporte al
equipo y eliminando impedimentos.
 Los miembros del equipo no están al corriente del
estado del Sprint, ya que la Pila del Sprint es algo
de lo que no necesitan preocuparse.
 Esta falta de feedback reduce la agilidad y el
enfoque generales del equipo.
 Si la Pila de Sprint está bien diseñada debería ser
igual de fácil para cada miembro del equipo
actualizarla el mismo.

Última actualización del tablón
 Inmediatamente tras el Scrum diario alguien suma
todas las estimaciones de tiempo (ignorando los de
la columna “terminado”, por supuesto).
 Y dibuja un nuevo punto en el burn-down de Sprint.

Tratando con problemas
 Tardones:
 Cuando llegas tarde, incluso aunque sea sólo por un
minuto, añades una cantidad prefijada en la lata.
 Sin preguntas.
 Si llamas antes de la reunión y avisas de que vas a llegar
tarde, aun así tienes que pagar.
 Solo te salvas de la multa si tienes una buena excusa
como una cita con el médico, tu propia boda o algo
similar.
 El dinero de la lata puede usarse para eventos sociales.
 Pero solo es necesario en equipos donde es frecuente
que la gente llegue tarde

 “No se qué hacer hoy”
 “Ayer hice bla bla bla, pero hoy no tengo la más remota
idea de lo que hacer o lo que emprender”
 Seguimos con la reunión, se actualizan los pos-its con lo
que ha dicho todo el mundo.
 Si aún así hay gente “libre” hay dos opciones:
 Programación por parejas
 La siguiente conversación

 Scrum Master: “OK, ¿quién quiere demostrar la versión
beta a todo el mundo?” (suponiendo que ese sea el objetivo
del Sprint)
 Equipo: (silencio confuso)
 Scrum Master: “¿No hemos terminado?”
 Equipo: “Um…No”
 Scrum Master: “Oh, vaya, ¿Por qué no? ¿Qué falta por
hacer?”
 Equipo: “Bueno, ni siquiera tenemos un servidor de pruebas
en el que ejecutarla, y el script de compilación no funciona”
 Scrum Master: “Aham.” (Añade dos post-it más a la pared
de las tareas). “Joe y Lisa, ¿Cómo podéis ayudarnos hoy?”
 Joe: “Um…Supongo que trataré de encontrar algún servidor
de pruebas en algún sitio”
 Lisa: “…Y yo trataré de arreglar ese script de compilación”.

 Acabar demasiado pronto
 Da la enhorabuena al equipo por el buen trabajo que han
realizado
 Agarra una o dos historias de la sección “siguientes” del
tablón y colócalas en la columna de “pendiente” a la
izquierda.
 Entonces haz de nuevo el Scrum diario.
 Notifica al Dueño de Producto que habéis añadido
algunos elementos más al Sprint.

 Historias indemostrables
 Miembro del equipo: “No voy a demostrar esta historia
porque no puede demostrarse. La historia es ‘mejorar la
escalabilidad de forma que el sistema pueda aguantar
10.000 usuarios simultáneos’. A ver como leches invito a
10.000 usuarios simultáneos a la demo.”
 Scrum Master: “¿Has terminado la historia?”
 Miembro del equipo: “Sí, por supuesto”
 Scrum Master: “¿Cómo lo sabes?”
 Miembro del equipo: “Monté el sistema en un entorno de
pruebas de rendimiento, arranqué ocho servidores de
carga y le di caña al sistema con solicitudes simultáneas”.

 Scrum Master: “Pero no tienes ninguna indicación de que
el sistema pueda aguantar 10.000 usuarios simultáneos”
 Miembro del equipo: “Sí. Las máquinas de pruebas
están echas polvo, pero aun así pudieron aguantar 50.000
solicitudes simultáneas durante el test”.
 Scrum Master: “¿Cómo lo sabes?”
 Miembro del equipo: (frustrado) “¡Bueno, tengo este
informe! ¡Puedes verlo por ti mismo, muestra cómo se
montó la prueba y cuántas solicitudes se enviaron!”
 Scrum Master: “¡Oh, excelente! Entonces ahí tienes tu
‘demo’. Simplemente muestra el informe y coméntaselo a
la audiencia. Mejor que nada, ¿no?”
 Miembro del equipo: “Ah, ¿basta con eso? Pero está
muy feo, necesito ponerlo en bonito y…”
 Scrum Master: “Vale, pero no pierdas mucho tiempo. No
se trata de que sea bonito, simplemente informativo”.

Todos los Sprints acaban con
una demo
 El equipo obtiene reconocimiento por sus logros. Se
sienten bien.
 Otras personas se enteran de lo que está haciendo el
equipo.
 La demo consigue feedback vital de los interesados.
 Las demos son (o deberían ser) un evento social donde
diferentes equipos pueden interactuar unos con otros y
discutir su trabajo. Esto es muy valioso.
 Hacer una demo fuerza al equipo a acabar realmente las
cosas y entregarlas (incluso aunque sea sólo en entorno
de pruebas).
 Sin las demos, seguimos consiguiendo enormes
montones de cosas terminadas al 99%.

Todos los Sprints acaban con una
demo
 Con las demos puede que consigamos menos cosas
terminadas, pero estas están realmente terminadas, lo
que (en nuestro caso) es mucho mejor que tener una
enorme pila de cosas que están más o menos listas y que
se pulirán en el próximo Sprint.
 Si un equipo se ve obligado a hacer una demo de Sprint,
incluso aunque no tengan mucho que realmente esté
funcionando, la demo será embarazosa. En el próximo
Sprint, el equipo intentará por todos los medios tener
cosas terminadas.

Lista de comprobación para
demos de Sprint
 Asegúrate de presentar claramente el objetivo del Sprint.
Si hay personas en la demo que no saben nada sobre tu
producto, tomate un par de minutos para describirlo.
 No pierdas mucho tiempo preparando la demo,
especialmente en llamativas presentaciones. Déjate de
milongas y concéntrate mostrar código funcionando.
 Mantén el paso rápido, es decir, concentra tu preparación
en hacer que la demo sea rápida en lugar de bonita.
 Mantén la demo a nivel de negocio, deja los detalles
técnicos aparte.
 Concéntrate en “qué hemos hecho” en lugar de “cómo lo
hemos hecho”.

Lista de comprobación para
demos de Sprint
 En la medida de lo posible, deja que la audiencia pruebe
el producto por si misma.
 No muestres un montón de pequeños errores
solucionados y funcionalidades triviales. Menciónalos,
pero no los muestres, ya que normalmente se tarda
mucho y desvía la atención de las historias más
importantes.

Retrospectivas de Sprint
 Lo más importante de las retrospectivas es asegurarse de
que tienen lugar.
 Reservamos 1-3 horas, dependiendo de cuánta discusión
esperemos.
 Participantes: el Dueño de Producto, el equipo y el Scrum
Master mismo.
 Nos vamos a una reunión cerrada, un rincón cómodo con
sofás, el patio del tejado o algún sitio similar. Que
podamos tener una discusión sin interrupciones.
 Normalmente no hacemos retrospectivas en la sala del
equipo, ya que la atención de la gente suele diluirse.
 Alguien es designado secretario.

Retrospectivas en Sprint
 El Scrum Master muestra la Pila de Sprint y, con ayuda
del equipo, resume el Sprint. Eventos importantes,
decisiones, etc.
 Hacemos “la ronda”. Cada persona tiene una oportunidad
de decir, sin ser interrumpida, qué piensan que ha ido
bien, que podría haber ido mejor y que piensan que
debería hacerse de forma diferente en el próximo Sprint.
 Observamos la velocidad estimada frente a la real. Si hay
una gran diferencia, intentamos analizar por qué.
 Cuando el tiempo casi se ha acabado, el Scrum Master
trata de resumir las sugerencias concretas cobre qué
puede hacerse mejor el próximo Sprint.

 Tres columnas:
 Bien: si hiciéramos el Sprint otra vez, volveríamos a hacer
estas cosas igual.
 Mejorable: si hiciéramos otra vez el Sprint, haríamos
estas cosas de forma diferente.
 Mejoras: ideas concretas sobre cómo podemos mejorar
en el futuro.

 Después de que el equipo genere todas estas ideas en
post-its, utilizan “votación por puntos” para determinar en
qué mejoras centrarse el próximo Sprint.
 Cada miembro del equipo tiene tres imanes y se les invita
a votar sobre cualquier mejora en la que les gustaría
trabajar en el próximo Sprint.
 Cada miembro del equipo distribuye los imanes como
quiera, incluso colocando los tres en el mismo elemento.
 Basándonos en esto, seleccionamos 5 mejoras de
procesos en los que concentrarse, y los evaluamos en la
siguiente retrospectiva.
 Es importante no ser demasiado ambicioso. Concéntrate
en unas pocas mejoras en cada Sprint.

Difundiendo las lecciones entre
los equipos
 La información que surge durante una retrospectiva
de Sprint es casi siempre tremendamente valiosa.
 Una retrospectiva de Sprint no trata sólo de cómo
este equipo puede hacerlo mejor el próximo Sprint,
tiene implicaciones más amplias que esa.
 Una persona atiende a todas las reuniones de
retrospectiva y actúa como puente de
conocimiento.
 Una alternativa sería que cada equipo Scrum
publique un informe de la retrospectiva de Sprint.

El Puente del Conocimiento
 Debería ser bueno escuchando.
 Si la retrospectiva es poco activa, debería estar listo para
realizar preguntas simples pero bien apuntadas para
estimular la discusión dentro del grupo. Por ejemplo, “si
pudierais rebobinar y hacer este Sprint otra vez desde el
día 1, ¿qué haríais de forma diferente?”
 Debe estar dispuesto a pasar tiempo visitando todas las
retrospectivas de todos los equipos.
 Debería tener algún tipo de autoridad, de forma que
pueda actuar sobre las sugerencias que estén fuera del
control del propio equipo.

Ejemplo de cosas que pueden surgir
en las retrospectivas
 “Deberíamos haber pasado más tiempo
dividiendo historias en subhistorias y tareas”
 Esta es muy habitual. Cada día en el Scrum diario, los
miembros del equipo se encuentran a si mismos diciendo
“Realmente no se qué hacer hoy”. Así que después de
cada Scrum diario tienes que pasar un tiempo
encontrando tareas concretas. Es generalmente más
efectivo hacer este trabajo desde el principio.
 Acciones típicas: ninguna. El equipo probablemente
corregirá esto por si mismo en el próximo Sprint. Si esto
ocurre repetidas veces, incrementa el tiempo para la
planificación de Sprint.

 “Demasiadas distracciones”
 Pide al equipo que reduzca su factor de dedicación el
próximo Sprint de forma que tengan una planificación más
realista.
 Pide al equipo que lleven un registro de las interrupciones
el próximo Sprint. Quién interrumpe, cuánto tiempo. Así
será más fácil resolver el problema más adelante.
 Pide al equipo que canalicen todas las distracciones a
través del Scrum Master o el Dueño de Producto.
 Pide al equipo que designe a una persona como “portero”,
y que todas las interrupciones se le envíen a él, de forma
que el resto del equipopueda concentrarse. Podría ser el
Scrum Master o una posición rotatoria.

 “Nos sobre-comprometimos y sólo hicimos la
mitad”
 Acciones típicas: ninguna. El equipo probablemente no
se sobre-comprometerá en el próximo Sprint. O al menos
no se sobre-comprometerá tanto.

 “Nuestro entorno de oficina es demasiado
ruidoso y desordenado”
 Intenta crear un ambiente mejor, o llévate al equipo fuera
de la oficina.
 Alquila una habitación de hotel. Lo que haga falta. Mira
“cómo distribuimos la sala del equipo”.
 Si no es posible, dile al equipo que reduzca su factor de
concentración el próximo Sprint, y que declaren
claramente que esto es así debido a lo ruidoso y
desordenado del ambiente en el que trabajan. Con suerte
esto causará que el Dueño de Producto comience a
hostigar a la alta dirección sobre este tema.

Descansos entre Sprints
 En la vida real no puedes estar siempre
esprintando. Si siempre estás esprintando, en
realidad acabarás haciendo footing.
 Los Sprints son muy intensos.
 Provoca agotamiento en el desarrollador.
 Después de la demo y la retrospectiva tanto el
Dueño de Producto como el Equipo estarán llenos
de información y de ideas por digerir.
 Intentamos introducir descanso.

Como hacemos planificación de
entregas y contratos a precio cerrado
 A veces necesitamos planificar por adelantado más
de un Sprint a la vez.
 Define tus umbrales de aceptación
 Estimación de los elementos más importantes
 Estimar la velocidad
 Uniéndolo todo en un plan de entregas (release
plan)
 Adaptando el plan de entregas

Umbrales de aceptación
 Además de la Pila de Producto habitual, el Dueño
de Producto define una lista de umbrales de
aceptación, que son una simple clasificación de
qué significan los niveles de importancia de la Pila
de Producto en términos del contrato.

Ejemplos Umbrales Aceptación
 Todos los elementos con importancia >=100 deben estar
incluidos en la versión 1.0, o seremos penalizados hasta
la muerte.
 Todos los elementos de importancia 50-99 deberían estar
incluidos en la versión 1.0, pero podríamos pasar sin ellos
si los incluyésemos en otra entrega poco después.
 Los elementos con importancias 25-49 son requisitos,
pero podemos incluirlos en una versión 1.1.
 Los elementos con importancia <25 son puramente
especulativos y puede que ni siquiera hagan falta.

 Importancia Historia
 130 Plátano
 120 Manzana
 115 Naranja
 110 Guayaba
 100 Pera
 95 Pasa
 80 Cacahuete
 70 Donut
 60 Cebolla
 40 Uva
 35 Papaya
 10 Arándano
 10 Melocotón
 Rojo = debe incluirse en la versión 1.0 (plátano – pera)
 Amarillo = debería incluirse en la versión 1.0 (pasa –
cebolla)
 Verde = puede hacerse más tarde (uva – melocotón)

Estimación de los elementos más
importantes

importantes
 Para poder hacer la planificación de entregas el dueño de
producto necesita estimaciones, al menos para todas las
historias incluidas en el contrato. Al igual que en la
planificación de Sprint, se trata de un esfuerzo
cooperativo entre en Dueño de Producto y el equipo – el
equipo estima, el Dueño de Producto describe los
elementos y responde a las preguntas.
 Una estimación de tiempos es valiosa si resulta ser casi
correcta, menos valiosa si resulta que falla por, digamos,
un 30% y completamente inútil si no tiene ninguna
conexión con la realidad.

importantes
 Todo esto no ha sido más que una forma
complicada de decir:
 Deja que el equipo haga las estimaciones.
 No dejes que le dediquen demasiado tiempo.
 Asegúrate de que entiendan que se trata de estimaciones,
no compromisos.

 Import. Historia Estimación
 130 Plátano 12
 120 Manzana 9
 115 Naranja 20
 110 Guayaba 8
 100 Pera 20
 95 Pasa 12
 80 Cacahuete 10
 70 Donut 8
 60 Cebolla 10
 40 Uva 14
 35 Papaya 4
 10 Arándano
 10 Melocotón

Estimar la velocidad
 El siguiente paso es estimar nuestra velocidad media por
Sprint.
 Esto significa que debemos decidir nuestro factor de
dedicación.
 El factor de dedicación significa, básicamente, “cuanto del
tiempo del equipo se emplea en las historias a las que se
ha comprometido”. Nunca es el 100%, ya que el equipo
gasta tiempo en elementos no planificados, haciendo
cambios de contexto, ayudando a otros equipos,
chequeando el correo, arreglando sus ordenadores rotos,
discutiendo de política en la cocina, etc.

Estimar la velocidad - Ejemplo
 Digamos que determinamos que el factor de dedicación
del equipo es del 50% (bastante bajo, normalmente
oscilamos en torno al 70%). Y digamos que la duración
del Sprint es de 3 semanas (15 días) y el tamaño del
equipo es 6 personas.
 Así que cada Sprint tendría 90 días-hombre ideales, pero
solo podemos pretender producir el equivalente a 45 días-
hombre ideales (debido al factor del 50%).
 Así que nuestra velocidad estimada es 45 puntos de
historia.
 Si cada historia tiene una estimación de tiempo de 5 días
(que no es así), entonces este equipo podría producir
aproximadamente 9 historias por Sprint.

Uniéndolo en el Plan de Entregas
 Importancia Historia Estimación
 Sprint 1
 130 Plátano 12
 120 Manzana 9
 115 Naranja 20
 Sprint 2
 110 Guayaba 8
 100 Pera 20
 95 Pasa 12

 Importancia Historia Estimación
 Sprint 3
 80 Cacahuete 10
 70 Donut 8
 60 Cebolla 10
 40 Uva 14
 Sprint 4
 35 Papaya 4
 10 Arándano
 10 Melocotón Scrum y Métodos Ágiles 127

 Cada Sprint incluye tantas historias como sea posible sin
exceder la velocidad estimada de 45.
 Así, podemos ver que probablemente necesitemos 3
Sprints para finalizar todos los “debe” y los “debería”.
 3 Sprints = 9 semanas de calendario = 2 meses. Así que
esa es nuestra fecha de entrega. Ahora bien, ¿es la fecha
que se prometió al cliente? Depende enteramente de la
naturaleza del contrato: como de fijo es el alcance, etc.
 Usualmente añadimos un buffer o colchón significativo
para protegernos contra las malas estimaciones,
problemas inesperados, etc. Así que en este caso
podríamos acordar fijar la fecha de entrega dentro de 3
meses, dándonos así un mes de “reserva”.

 Lo bonito es que podemos mostrar algo usable al cliente
cada tres semanas e invitarle a introducir cambios en los
requisitos conforme avanzamos (dependiendo por
supuesto de lo que permita el contrato).

Adaptando el Plan de Entregas
 Después de cada Sprint comprobamos la velocidad real
de dicho Sprint.
 Si la velocidad real ha sido muy diferente de la estimada,
revisamos la velocidad estimada para próximos Sprints y
actualizamos el plan de entregas.
 Si esto nos coloca en una situación problemática, puede
que el Dueño de Producto empiece a negociar con el
cliente o se dedique a averiguar cómo podemos reducir el
alcance sin romper el contrato. O quizás él y el equipo
encuentren una forma de aumentar la velocidad
eliminando algún impedimento severo que se haya
identificado durante el Sprint

Cómo hacemos pruebas
 En el mundo Scrum ideal, un Sprint produce una
versión potencialmente instalable de nuestro
sistema. Así que la instalamos, ¿no?

Cómo hacemos pruebas
 Si la calidad tiene algún valor para ti, es necesario
algún tipo de fase de pruebas de aceptación
manuales.

Minimiza la fase de pruebas
 Maximizando la calidad del código desarrollado por
el equipo Scrum.
 Maximizando la eficiencia del trabajo manual de
pruebas (es decir, encontrar los beta-testers, darles
la mejores herramientas y asegurarnos de que
informan de las tareas que pueden automatizarse).

Ciclos de Sprint vs. Ciclos de
Pruebas
 Mundo perfecto:

Pruebas
 Más realista:

Pruebas
 Con equipo de pruebas:

Enfoques de solución
 Enfoque 1: “No empieces a desarrollar nada nuevo
hasta que esté en producción lo que has
desarrollado”

 Enfoque 2: “OK, desarrollamos cosas nuevas, pero
priorizamos el poner en producción lo que ya está
desarrollado”

 Mal enfoque – “centraos en producir cosas nuevas”
 El gerente (o el Dueño de Producto) pide al equipo que
siga incluyendo nuevas funcionalidades mientras la bolsa
de código-casi-listo-para-producción va volviéndose más
y más pesada, ralentizándolo todo.

Como dividir el equipo de Scrum
 Ejemplo 1: Escoges tener un equipo grande. Pero
cuando observas quién habla con quién durante el
Sprint notas que el equipo se ha separado a todos
los efectos en dos sub-equipos.

Como dividir el equipo de Scrum
 Ejemplo 2: Escoges tener tres equipos más
pequeños. Pero cuando empiezas a ver quién
habla con quién durante el Sprint notas que el
equipo 1 y el equipo 2 hablan todo el rato, mientras
que el equipo 3 trabaja por su cuenta.

Tamaño óptimo del equipo

¿Sprints sincronizados, o no?

Un rol de “guía de equipo”

¿Equipos especializados – o no?

Como hacemos Scrums de
Scrums

Intercalando los Scrums diarios

¿Dividir la Pila de Producto – o
no?
 Estrategia 1: un Dueño de Producto, una Pila de
Producto

no?

no?
 Estrategia 2: un Dueño de Producto, múltiples Pilas
de Producto

no?
 Estrategia 3: múltiples Dueños de Producto, una
Pila de Producto por Dueño.

Lista de comprobación del Scrum
Master
 Comienzo del Sprint
 Tras la reunión de planificación de Sprint, crea una página
de información. Añade un enlace a la página desde la
página principal del Wiki. Imprime la página y ponla en la
pared por la que pase la gente cerca de tu equipo.
 Manda un correo a todo el mundo anunciando que ha
comenzado un nuevo Sprint. Incluye el objetivo del Sprint
y un enlace a la página de información del Sprint.
 Actualiza el documento de estadísticas de Sprint. Añade
tu velocidad estimada, tamaño del equipo, longitud del
Sprint, etc.

Master
 Todos los días
 Asegúrate de que el Scrum diario comienza y termina a su
hora.
 Asegúrate de que todas las historias son añadidas o
eliminadas de la Pila de Sprint cuando sea necesario para
mantener el Sprint en fecha.
 Asegúrate de que se notifica al Dueño de Producto sobre
estos cambios.
 Asegúrate de que el equipo mantiene actualizados la Pila
de Producto y el burn-down.
 Asegúrate de que los problemas o impedimentos son
solucionados o reportados al Dueño de Producto y/o el
Jefe de Desarrollo. Scrum y Métodos Ágiles 156

Master
 Final de Sprint
 Haz una demo de Sprint abierta.
 Todo el mundo debería ser notificado acerca de la demo
uno o dos días antes.
 Haz una retrospectiva de Sprint con todo el equipo y el
Dueño de Producto. Invita al Jefe de Desarrollo también,
de forma que pueda ayudar a difundir las lecciones
aprendidas.
 Actualiza el documento de estadísticas de Sprint. Añade
la velocidad real y los puntos clave de la retrospectiva..

Preguntas y Cuestiones

¡Estamos en las Redes Sociales!
http://www.linkedin.com/company/cleformaci-n
https://twitter.com/CLEFormacion
¡ Síguenos !
cursos@cleformacion.com
#CLEscrum

Seminario Scrum CLEFormacion

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Seminario Scrum CLEFormacion

Más de CLEFormación

Seminario Scrum CLEFormacion