Con Scrum, puedes cambiar las prioridades de las tareas, añadir nuevos requisitos sin demasiado esfuerzo, y aun así, tienes la información suficiente para saber en que situación se encuentra el proyecto en cualquier momento. Además, planificar un proyecto completo se puede hacer tedioso, con la ayuda de tu equipo puedes valorarlo mejor y en pocas horas. La idea principal de la metodología Scrum (y la mayoría de las metodologías ágiles), es que en vez perder tiempo en tratar de desgranar todos los detalles del proyecto, se trata de que el equipo sea capaz de entregar mas rápido, solucionar más rápido y estar preparado para soportar los nuevos requisitos.
Scrum, una metodología de trabajo iterativa
Scrum, divide el tiempo de desarrollo de un proyecto en Sprints (iteraciones). Un Sprint, es un periodo de entre 1 semana y 4 semanas (siempre el mismo), en el que el equipo se centra únicamente en entregar las tareas acordadas al inicio de este periodo. Al bloquear el tiempo de esta manera, evita que el equipo se pierda en cambios de contexto, se tiene suficiente previsión como para poder centrarse en el desarrollo y permite que al final del Sprint se pueda volver a reencaminar el proyecto con los nuevos requisitos que puedan llegar. Un periodo muy corto en un Sprint, puede hacer perder tiempo en la gestión, mientras que periodos muy largos, pueden hacer que el proyecto no se adapte con la suficiente velocidad a los cambios. Es tarea de todas las personas involucradas decidir cual es el tiempo adecuado del Sprint.
Para decidir que tareas se van a incluir en un Sprint, primero se desgrana el proyecto en historias de usuario (User Stories). Una historia de usuario es una descripción corta de la funcionalidad que debe proveer el sistema que se esta desarrollando. Normalmente se utiliza la plantilla de Mike Cohn.
Como <tipo de usuario>, quiero <alguna meta> para que <alguna razón> (As a <type of user>, I want <some goal> so that <some reason>). Un ejemplo de historia de usuario sería: Como usuario, quiero que en la pantalla principal haya un menú para que pueda acceder a las opciones del perfil. El conjunto de estas historias forman el Product Backlog, que no es más que una lista de historias priorizadas. Para introducir estas historias de usuario en el sistema, aparece la figura del Product Owner, que es el responsable de descubrir estos requisitos y priorizarlos.
[caption id="" align="alignnone" width="800"]
Ejemplo de Product Backlog[/caption]
Para priorizar las historias de usuario, al principio del proyecto, y a intervalos regulares durante el proyecto, se va estimando el esfuerzo de cada una en puntos de usuario. Normalmente se utilizan los números 0, 1, 3, 5, 8, 13, 20, 40 y 100 como puntos de usuario. 0 indica una historia con esfuerzo prácticamente nulo, mientras que una con 100, indica que el esfuerzo es extremo y que incluso no es asumible ahora mismo. El Product Owner expone cada una de las historias y el equipo intenta llegar a un consenso con el esfuerzo asignado. Se suelen utilizar otras historias para comparar. Si la historia de usuario recibe una puntuación de 20 o más, esta se divide en historias más pequeñas. Algunos equipos utilizan Planning Poker como técnica para obtener la estimación de una historia de usuario. Este proceso de refinamiento, se produce durante el Backlog Grooming Meeting y debe ocupar poco tiempo al equipo más o menos un 5% del tiempo total y puede ocurrir dentro o fuera de un Sprint. El Product Owner ordena las historias según su valor de negocio.
[caption id="" align="alignnone" width="250"]
Cartas utilizadas en una Planning Poker[/caption]
En cuanto tengamos un Product Backlog priorizado y estimado con suficientes historias, es momento del Sprint Planning Meeting, que tiene como objetivo seleccionar las historias de usuario que se van a incluir en el siguiente Sprint. Para ello se cuentan los puntos de usuario de las mas prioritarias hasta que se alcanza el número de puntos de usuario que puede hacer un equipo en un Sprint. Este número se conoce como la velocidad del equipo y permite al Product Owner estimar cuando puede estar disponible una nueva funcionalidad. Se necesitan varios Sprints para tener una idea de esta velocidad. Durante este reunión el equipo divide cada historia de usuario en tareas de hasta 16 horas, cada una de estas tareas pasara a formar parte del Sprint Backlog.
Ahora es el momento de empezar el Sprint, durante los siguientes días el equipo trabajará para completar todas las historias de usuario del Sprint Backlog y entregar un producto que sea aceptado por el Product Owner. Cada mañana, una reunión Daily Scrum Meeting de 5 minutos del equipo, sirve para repartir tareas, compartir la evolución de las mismas y explicar cualquier impedimento que deba solucionar el Scrum Master, que se encarga además de asegurar de que el equipo sigue las reglas de Scrum, y ayuda a este a mejorar. Durante el Sprint se puede ver el estado del mismo simplemente consultando el Burndown Chart, que basicamente es una gráfica de la evolución del numero de puntos de historia solucionados.
[caption id="" align="alignnone" width="853"]
Ejemplo de Burdown Chart[/caption]
Una vez acabado el Sprint, se hace un Sprint Review Meeting con todas las partes interesadas (clientes, jefes, etc.), en el que se hace una demostración de las historias de usuario completadas.
En una última reunión, conocida como Sprint Retrospective se explica como ha ido el Sprint, que cosas han funcionado bien y en que se puede mejorar. Y vuelta a empezar...
