Scrum para Dummies

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?

• El cliente puede ver resultados desde el primer momento.


• Se ahorra el tiempo que en las metodologías tradicionales se dedica en conseguir especificaciones y documentaciones exhaustivamente documentadas.


• Se hace equipo: comunicación contínua, se reparten éxitos.


• El cliente interviene en todas las fases del proyecto.


• Se reducen los riesgos por retrasos acumulados, entregas que difieren de lo que el cliente esperaba, y por tanto influye de manera decisiva en el éxito del proyecto.


• Es una metodología sencilla y nada rígida. Se puede complementar con otras. Por ejemplo, nosotros la combinamos con eXtreme Programming.

¿Qué se necesita para aplicar Scrum?

• Actores: usuarios con distintos tipos de roles.

Product Owner: Representa la voz del cliente. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master: Protege al equipo de distracciones y de otros elementos externos (presiones no razonables,...). Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona.
Equipo: Tiene la responsabilidad de entregar el producto.

Product Owner, Scrum Master, y Equipo, son roles llamados "Cerdo". También hay roles "Gallina", que no forman parte de Scrum (Cliente, Usuario, Manager).

• Product Backlog o Pila de Producto:

Traducción poco afortunada, por cierto, ya que no sería una estructura "pila", es más bien una lista ordenada y priorizada de Historias de Usuario. Es confeccionada por el Product Owner o el Cliente.

Las Historias de Usuario son requisitos a muy alto nivel de lo que debe hacer la aplicación. Por ejemplo: Como administrador quiero dar de alta un usuario en el sistema.

• Estimación:

El Scrum Master y el Equipo estiman cada una de las Historias de Usuario del Product Backlog. Para ello, cada miembro del Equipo, dispone de una baraja Scrum, que contiene los valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, ?. Estos valores son llamados Puntos de Historia y sirven para valorar el "esfuerzo" necesario para desarrollar cada "Historia de Usuario". Los valores de la baraja sigue una sucesión de Fibonacci aproximada, y redondeada. No nos interesa afinar demasiado, sobretodo en los valores más altos, ya que son los más susceptibles de desviarse. Los Puntos de Historia nos sirven para comparar Historias. Es decir, si dos Historias están estimadas en "5", nos costará el mismo esfuerzo (aproximadamente) llevarlas a cabo, y seguramente se tarde lo mismo en ser concluidas, pero de "tiempos" hablaremos más adelante.

Si una Historia está estimada con valores altos, 100 o infinito, seguramente deberá ser dividida en varias Historias "más pequeñas". El infinito se suele usar cuando una Historia no está suficientemente definida, y normalmente conlleva una rescritura de la Historia por parte del cliente o el Product Owner.

El Equipo debe discutir y debatir cada uno de las estimaciones, y llegar a un acuerdo sobre los Puntos de Historia de una Historia de Usuario.

Normalmente, después de las estimación, el Cliente, ayudado por el Product Owner, debe priorizar las tareas, sabiendo lo que "tardan" en realizarse las tareas (aunque sea por comparación).

Las estimaciones son muy aproximadas, solo se concretan cuando se van a realizar durante el Sprint.

• Sprint:

Es un ciclo de producción dentro de un desarrollo iterativo e incremental. Una vez tenemos el Product Backlog estimado y priorizado, se procede a decidir las Historias que se van a resolver durante el Sprint, dependiendo de los Puntos de Historia que "cuesten" las Historias, valga la redundancia. El Sprint es un periodo de tiempo que suele variar de una semana a un mes. En nuestro caso el Sprint es de dos semanas.

El número de Puntos de Historia, que se resuelve en un Sprint suele aumentar a medida que el equipo se va conociendo, y va madurando. En los comienzos de los proyectos, se pueden producir desviaciones en el número de Puntos de Historia que se resuelven en un Sprint, por falta de experiencia, falta de conocimiento del grupo,... estas desviaciones deben tenerse en cuenta cuando se plantee el número de Puntos de Historia que se deben resolver en futuros Sprints. Por ejemplo, si he estimado que el equipo va a resolver 40 Puntos de Historia en un Sprint, y solo resuelve 20, en el futuro Sprint, se estimará un número cercano a los 20 Puntos de Historia.

Las Historias de Usuario que se van a resolver durante el Sprint, se colocan en el Sprint Backlog. Se priorizan por el Product Owner, y solo el Scrum Master puede modificar su orden durante el Sprint.

Durante el Sprint es conveniente organizar un Tablón de Trabajo con las Historias ordenadas por: Tareas a realizar, Tareas en Ejecución, Tareas Finalizadas.

El número de Puntos de Historia que se llevan a cabo por Sprint se denomina Velocidad, y de aquí podemos extraer el tiempo.

Para medir el rendimiento solemos realizar un gráfico Burndown:
- Eje de abcisas: Sprints
- Eje de ordenadas: Número de Puntos de Historia

• Daily Scrum:

Reunión diaria (durante el tiempo que dure el Sprint) de cinco minutos de duración (en ningún caso debe exceder de diez minutos) en el que cada miembro del equipo debe responder a las siguientes preguntas:

¿Qué has hecho?
¿Qué prevés hacer hoy?
¿Qué impedimentos te has encontrado?
¿Qué necesitas de otro miembro del equipo?

Cada miembro se debe dirigir al Equipo, no al Scrum Master ni a ningún otro miembro en concreto.
Lo que necesite de otro miembro del equipo, se debe solicitar, anotar, pero no discutir durante la reunión. Eso implicaría una duración mucho mayor.

• Presentación del Producto:

A la finalización del Sprint, se hace una revisión, que en ningún caso excederá de dos horas.

Al llegar a este punto, debemos tener "algo" que el Cliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Equipo y personas que podrían estar involucradas en el proyecto. El Equipo es quién muestra los avances realizados en el Sprint.

Se le presenta al Cliente la parte de producto terminada.

• Restrospectiva:

Se realiza una reunión informal, normalmente fueras de las oficinas, en el bar por ejemplo, donde se plantean los inconvenientes tenidos durante el desarrollo del Sprint, así como las mejoras posibles para trabajos futuros.

Nosotros solemos salir media hora antes los viernes de finalización de Sprint, con objeto de poder realizar la Retrospectiva, que aun siendo trabajo, debe llevarse a cabo en ambientes informales.