1 - Producto
Es el software que se construye
durante el proyecto.
2 – Propietario de producto
Persona que se ocupa del producto.
¿Qué funcionalidades debe tener? ¿Cómo será más competitivo? ¿Qué mejoras se le
pueden aplicar? Etc.
3 –Scrum master
Persona que se ocupa del proceso
es decir, de que se utilice el método Scrum adecuadamente y que el trabajo de
los equipos fluya evitando impedimentos.
4- Historias de usuario
Es la descripción de lo que el
producto debe hacer. Es decir, recopilan
el conjunto de funcionalidades y otras características que se espera tenga el
software que se va a construir.
5 – Puntos historia
Es una medida cuantitativa que
asigna el equipo a cada historia. Los puntos historia miden la dificultad que se
intuye que tendrá la historia para ser construida, comparada con el resto de
las historias de la pila. Es decir no es una medida absoluta, es una medida de
comparación. Existe una técnica llamada
“Planning poker” para medir puntos historia.
6 – Pila de producto
El propietario de producto es el
responsable de la pila de producto. La pila de producto es una lista que
contiene todas las historias que describen el producto. El propietario de
producto prioriza las historias, al principio coloca las que se prevea que aportarán
más valor para el negocio. Las historias del principio de la pila deben estar suficientemente
detalladas para que el equipo de desarrollo tenga la información necesaria para
poder construir el software, el resto de ellas pueden estar definidas más
vagamente. Esto se debe a que en SCRUM el cambio es bienvenido, es decir, puede
ocurrir que una historia que en principio se identificó como tal, después de
varias iteraciones (sprints) se considere que ya no es importante y se elimine.
También que aparezcan nuevas historias o cambien historias existentes. Por eso,
no es útil que las historias de usuario del final de la pila, que todavía no se
van a implementar o quizás no se implementen nunca, estén perfectamente
detalladas.
7 – Sprint
Periodo de tiempo previamente
fijado durante el cual el equipo desarrolla las funcionalidades y
características descritas en las historias de usuario. Los sprints se suceden
de forma iterativa en el tiempo, hasta que se haya terminado el producto. Los
sprints se acaban cuando acaba el tiempo prefijado, si hay trabajo no terminado
se reajustará en subsiguientes sprints. Se recomiendan sprints de 1 a 4 semanas
y nunca de más de 6. Es importante que las historias de usuario que se acuerde
llevar a cabo en un sprint, no se cambien durante el transcurso del sprint, el objetivo es no alterar el trabajo del
equipo.
8 – Reunión de planificación del sprint
El equipo de desarrollo se reúne
con el propietario de producto y trabajan sobre la pila de producto. El equipo
analiza las historias de usuario, debatiendo con el propietario de producto
sobre su naturaleza. Se seleccionan tantas historias del principio de la pila
de producto como el equipo considere que va a poder desarrollar durante el
sprint, los puntos historia ayudan a saber cuántas historias seleccionar. Las
historias seleccionadas pasan a la pila del sprint y se subdividen en tareas,
de tal manera que el equipo desmenuza cada historia en las actividades
necesarias para implementarla.
Se prepara el tablero SCRUM del
sprint (“Por hacer”, “Haciendo”, “Hecho”) y se colocan las tareas de las
historias seleccionadas en la columna “Por hacer”.
9 – Reunión SCRUM diario
Esta reunión se celebra cada día
de cada sprint, normalmente al comienzo de la jornada de trabajo. Es una
reunión breve, no más de 15 minutos. En esta reunión cada miembro del equipo
dice como le fue con las tareas del día anterior y que tareas planifica hacer
hoy.
10 – Reunión de revisión del sprint
Terminado el sprint el equipo
hace una demo del software construido al propietario de producto y a los
clientes/usuarios. El objetivo es mostrar el software construido y obtener
retroalimentación sobre la perspectiva de clientes/usuarios y el propietario
del producto. En caso de que se cumplan las expectativas de todos ellos seguir
adelante, en caso de que no hacer los cambios necesarios para cumplirlas.
11 – Reunión de refinamiento de pila de producto
Se reúne el propietario de
producto con el equipo de desarrollo, para revisar las historias que se prevé
abordar en el próximo sprint. En base al software construido y a posibles
cambios producidos en el transcurso del tiempo, se refinan las historias de usuario:
re-priorizar, eliminar, modificar y/o
crear nuevas historias. La idea de refinamiento es doble, por un lado se
trata de aportar más detalles sobre las historias del próximo sprint y por otro
lado reajustar la priorización de las historias para adaptarse al momento (gestión
de los cambios).
En Scrum desde el primer sprint
el usuario dispone de software construido. Esto permite que el desarrollo del producto se
realice siguiendo unas especificaciones que se basan en la realidad de un
software funcionando en vez de hipótesis sobre lo que debería de hacer o no el producto.
12 – Reunión de retrospectiva
Al final de cada sprint se celebra una reunión de retrospectiva.
La retrospectiva vigila el proceso, no el producto. La retrospectiva, lo que
persigue es que el equipo: desarrolladores, propietario de producto y clientes/usuarios,
pongan de relieve aquellas cosas que creen que pueden hacer mejor para el
próximo sprint. Por ejemplo: los SCRUM diarios se han alargado cada día durante
más de 2 horas y el equipo ha perdido mucho tiempo. Aquí una mejora es
proponerse mantener el scrum diario en los 15 minutos estipulados para los
próximos sprints.
