Este documento presenta una introducción a Scrum y métodos ágiles. Explica por qué los métodos ágiles son útiles, definie qué son los métodos ágiles y sus principios clave. Luego describe varias prácticas ágiles como historias de usuario, planning poker y programación en parejas. Finalmente, introduce Scrum enfocándose en sus valores fundamentales de equipos auto-organizados y auto-dirigidos.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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