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

2.
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

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

4.
Scrum y Métodos Ágiles 4
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)
 …

5.
Scrum y Métodos Ágiles 5
1. ¿Por qué Métodos Ágiles?
 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

6.
Scrum y Métodos Ágiles 6
1. ¿Por qué Métodos Ágiles?
 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…

7.
Scrum y Métodos Ágiles 7
1. ¿Por qué Métodos Ágiles?
 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

8.
Scrum y Métodos Ágiles 8
1. ¿Por qué Métodos Ágiles?
 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

9.
Scrum y Métodos Ágiles 9
1. ¿Por qué Métodos Ágiles?
 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

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

11.
Scrum y Métodos Ágiles 11
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

12.
Scrum y Métodos Ágiles 12
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

13.
Scrum y Métodos Ágiles 13
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

14.
Scrum y Métodos Ágiles 14
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

15.
Scrum y Métodos Ágiles 15
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

16.
Scrum y Métodos Ágiles 16
¿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

17.
Scrum y Métodos Ágiles 17
¿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

18.
1. Prácticas Ágiles

19.
Scrum y Métodos Ágiles 19
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

20.
Scrum y Métodos Ágiles 20
Historias de Usuario
 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

21.
Scrum y Métodos Ágiles 21
Historias de Usuario
 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

22.
Scrum y Métodos Ágiles 22
Historias de Usuario
 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

23.
Scrum y Métodos Ágiles 23
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

24.
Scrum y Métodos Ágiles 24
Planning Poker

25.
Scrum y Métodos Ágiles 25
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

26.
Scrum y Métodos Ágiles 26
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

27.
Scrum y Métodos Ágiles 27
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
 …

28.
Scrum y Métodos Ágiles 28
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

29.
Scrum y Métodos Ágiles 29
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

30.
Scrum y Métodos Ágiles 30
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 2 Proyecto 2
Proyecto 3Proyecto 3
Proyecto 1
Proyecto 2 Proyecto 2
Proyecto 1
Proyecto 2
Proyecto 3
Proyecto 3 Proyecto 3

31.
Scrum y Métodos Ágiles 31
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

32.
1. Scrum

33.
Scrum y Métodos Ágiles 33
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

34.
Scrum y Métodos Ágiles 34
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

35.
Scrum y Métodos Ágiles 35
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

36.
Scrum y Métodos Ágiles 36
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

37.
Scrum y Métodos Ágiles 37
Roles en Scrum (Gallinas)
 Usuarios finales
 Marketing
 Áreas comerciales
 Áreas contables
 Administradores
 Etc

38.
Scrum y Métodos Ágiles 38
Ciclo de Scrum

39.
Scrum y Métodos Ágiles 39
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

40.
Scrum y Métodos Ágiles 40
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

41.
Scrum y Métodos Ágiles 41
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

42.
Scrum y Métodos Ágiles 42
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

43.
Scrum y Métodos Ágiles 43
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

44.
Scrum y Métodos Ágiles 44
Scrum Diario

45.
Scrum y Métodos Ágiles 45
Alarmas
 Tareas terminadas de baja prioridad
 Exceso de tareas no planificadas

46.
Scrum y Métodos Ágiles 46
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

47.
Scrum y Métodos Ágiles 47
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

48.
1. Métricas y Medidas

49.
Scrum y Métodos Ágiles 49
¿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

50.
Scrum y Métodos Ágiles 50
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

51.
Scrum y Métodos Ágiles 51
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

52.
Scrum y Métodos Ágiles 52
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

53.
Scrum y Métodos Ágiles 53
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

54.
Scrum y Métodos Ágiles 54
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

55.
Scrum y Métodos Ágiles 55
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

56.
Scrum y Métodos Ágiles 56
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

57.
Scrum y Métodos Ágiles 57
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

58.
Scrum y Métodos Ágiles 58
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

59.
Scrum y Métodos Ágiles 59
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]

60.
Scrum y Métodos Ágiles 60
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

61.
Scrum y Métodos Ágiles 61
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

62.
1. Claves del Éxito

63.
Scrum y Métodos Ágiles 63
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

64.
Scrum y Métodos Ágiles 64
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

65.
Scrum y Métodos Ágiles 65
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

66.
Scrum y Métodos Ágiles 66
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

67.
Scrum y Métodos Ágiles 67
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

68.
Scrum y Métodos Ágiles 68
Diagrama de Radar
 Permite ver varias variables de un golpe

69.
Scrum y Métodos Ágiles 69
Diagrama de Radar
 Peor cuanto más disperso

70.
Scrum y Métodos Ágiles 70
Diagrama de Radar
 Mejor cuanto más centrado

71.
Scrum y Métodos Ágiles 71
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

72.
Scrum y Métodos Ágiles 72
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

73.
Scrum y Métodos Ágiles 73
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

74.
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.
Scrum y Métodos Ágiles 74

75.
Scrum y Métodos Ágiles 75

76.
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.
Scrum y Métodos Ágiles 76

77.
Scrum y Métodos Ágiles 77

78.
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.
Scrum y Métodos Ágiles 78

79.
¿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.
Scrum y Métodos Ágiles 79

80.
¿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.
Scrum y Métodos Ágiles 80

81.
¿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.
Scrum y Métodos Ágiles 81

82.
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)
Scrum y Métodos Ágiles 82

83.
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.
Scrum y Métodos Ágiles 83

84.
¿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.
Scrum y Métodos Ágiles 84

85.
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.
Scrum y Métodos Ágiles 85

86.
Actualizar el tablón
Scrum y Métodos Ágiles 86

87.
Actualizar el tabló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.
Scrum y Métodos Ágiles 87

88.
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.
Scrum y Métodos Ágiles 88

89.
Ú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.
Scrum y Métodos Ágiles 89

90.
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
Scrum y Métodos Ágiles 90

91.
Tratando con problemas
 “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 y Métodos Ágiles 91

92.
 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”.
Scrum y Métodos Ágiles 92

93.
Tratando con problemas
 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.
Scrum y Métodos Ágiles 93

94.
Tratando con problemas
 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 y Métodos Ágiles 94

95.
 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”.
Scrum y Métodos Ágiles 95

96.
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%.
Scrum y Métodos Ágiles 96

97.
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.
Scrum y Métodos Ágiles 97

98.
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”.
Scrum y Métodos Ágiles 98

99.
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.
Scrum y Métodos Ágiles 99

100.
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.
Scrum y Métodos Ágiles 100

101.
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.
Scrum y Métodos Ágiles 101

102.
Scrum y Métodos Ágiles 102

103.
Retrospectivas en 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.
Scrum y Métodos Ágiles 103

104.
Retrospectivas en Sprint
 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.
Scrum y Métodos Ágiles 104

105.
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.
Scrum y Métodos Ágiles 105

106.
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.
Scrum y Métodos Ágiles 106

107.
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.
Scrum y Métodos Ágiles 107

108.
Ejemplo de cosas que pueden surgir
en las retrospectivas
 “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.
Scrum y Métodos Ágiles 108

109.
Ejemplo de cosas que pueden surgir
en las retrospectivas
 “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.
Scrum y Métodos Ágiles 109

110.
Ejemplo de cosas que pueden surgir
en las retrospectivas
 “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.
Scrum y Métodos Ágiles 110

111.
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.
Scrum y Métodos Ágiles 111

112.
Descansos entre Sprints
Scrum y Métodos Ágiles 112

113.
Descansos entre Sprints
Scrum y Métodos Ágiles 113

114.
Descansos entre Sprints
Scrum y Métodos Ágiles 114

115.
Descansos entre Sprints
Scrum y Métodos Ágiles 115

116.
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
Scrum y Métodos Ágiles 116

117.
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.
Scrum y Métodos Ágiles 117

118.
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.
Scrum y Métodos Ágiles 118

119.
 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)
Scrum y Métodos Ágiles 119

120.
Estimación de los elementos más
importantes
Scrum y Métodos Ágiles 120

121.
Estimación de los elementos más
importantes
Scrum y Métodos Ágiles 121
 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.

122.
Estimación de los elementos más
importantes
Scrum y Métodos Ágiles 122
 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.

123.
 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
Scrum y Métodos Ágiles 123

124.
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.
Scrum y Métodos Ágiles 124

125.
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.
Scrum y Métodos Ágiles 125

126.
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
Scrum y Métodos Ágiles 126

127.
Uniéndolo en el Plan de Entregas
 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

128.
Uniéndolo en el Plan de Entregas
 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”.
Scrum y Métodos Ágiles 128

129.
Uniéndolo en el Plan de Entregas
 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).
Scrum y Métodos Ágiles 129

130.
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
Scrum y Métodos Ágiles 130

131.
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?
Scrum y Métodos Ágiles 131

132.
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.
Scrum y Métodos Ágiles 132

133.
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).
Scrum y Métodos Ágiles 133

134.
Ciclos de Sprint vs. Ciclos de
Pruebas
 Mundo perfecto:
Scrum y Métodos Ágiles 134

135.
Ciclos de Sprint vs. Ciclos de
Pruebas
 Más realista:
Scrum y Métodos Ágiles 135

136.
Ciclos de Sprint vs. Ciclos de
Pruebas
 Con equipo de pruebas:
Scrum y Métodos Ágiles 136

137.
Enfoques de solución
 Enfoque 1: “No empieces a desarrollar nada nuevo
hasta que esté en producción lo que has
desarrollado”
Scrum y Métodos Ágiles 137

138.
Enfoques de solución
 Enfoque 2: “OK, desarrollamos cosas nuevas, pero
priorizamos el poner en producción lo que ya está
desarrollado”
Scrum y Métodos Ágiles 138

139.
Enfoques de solución
 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.
Scrum y Métodos Ágiles 139

140.
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.
Scrum y Métodos Ágiles 140

141.
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.
Scrum y Métodos Ágiles 141

142.
Tamaño óptimo del equipo
Scrum y Métodos Ágiles 142

143.
¿Sprints sincronizados, o no?
Scrum y Métodos Ágiles 143

144.
¿Sprints sincronizados, o no?
Scrum y Métodos Ágiles 144

145.
Un rol de “guía de equipo”
Scrum y Métodos Ágiles 145

146.
¿Equipos especializados – o no?
Scrum y Métodos Ágiles 146

147.
¿Equipos especializados – o no?
Scrum y Métodos Ágiles 147

148.
¿Equipos especializados – o no?
Scrum y Métodos Ágiles 148

149.
Como hacemos Scrums de
Scrums
Scrum y Métodos Ágiles 149

150.
Intercalando los Scrums diarios
Scrum y Métodos Ágiles 150

151.
¿Dividir la Pila de Producto – o
no?
 Estrategia 1: un Dueño de Producto, una Pila de
Producto
Scrum y Métodos Ágiles 151

152.
¿Dividir la Pila de Producto – o
no?
Scrum y Métodos Ágiles 152

153.
¿Dividir la Pila de Producto – o
no?
Scrum y Métodos Ágiles 153
 Estrategia 2: un Dueño de Producto, múltiples Pilas
de Producto

154.
¿Dividir la Pila de Producto – o
no?
Scrum y Métodos Ágiles 154
 Estrategia 3: múltiples Dueños de Producto, una
Pila de Producto por Dueño.

155.
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.
Scrum y Métodos Ágiles 155

156.
Lista de comprobación del Scrum
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

157.
Lista de comprobación del Scrum
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..
Scrum y Métodos Ágiles 157

158.
Scrum y Métodos Ágiles 158

159.
Preguntas y Cuestiones
Scrum y Métodos Ágiles 159

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

161.
Scrum y Métodos Ágiles 161