Scrum MethodologySCRUM es una metodología ágil de desarrollo que me ha aportado una nueva forma de trabajo con más unión y entendimiento con mis compañeros y mayor productividad. Se basa en un desarrollo iterativo e incremental.

El rol principal es el Scrum Manager SM.

El Product Owner PO es normalmente un jefe aunque al principio cuando no se conocía esta metodología era una persona experta de otra empresa contratada para implantarla. Es el que genera el Product Backlog donde se definen las historias del proyecto.

El Team (equipo) lo formamos tanto analistas como programadores.

El desarrollo es incremental dividiendo los requisitos del proyecto en bloques cortos que se llaman sprint y cuya duración habitual es de 10 días / 2 semanas.  Al comienzo de un sprint todos, salvo el SM que puede acudir eventualmente, tenemos una reunión de Planificación de sprint que llamamos PLANI, cuyo objetivo es identificar el trabajo más probable para realizar durante el actual Sprint o el más prioritario o el más significativo-llamativo para el usuario:

  • Story (Historias) que son las partes del Proyecto que el usuario ha pedido acometer, p.ej.: Como usuario necesito modificar unos datos de un cliente
  • Chore (Trabajo no previsto) que son temas que hay que solucionar por algún cambio, p.ej.: Modificar la fecha de la Base de datos de Expedientes porque han cambiado a formato timestamp.
  • Bug (Fallo) que son incidencias anunciadas  o no por los usuarios de algo que está en producción o porque falla algo, p. ej.: El valor del recuadro del código de usuario introducido se ha borrado al volver a la pantalla anterior

En la PLANI cada uno hace una estimación de la duración de las historias mostrando una carta con un número con puntos (importancia, puede ser asimilable a horas) desde 0, ½, 1, 2, 3, 5, 8, 13, 20,40 a 100. A veces se usa una con 4 ? en cada esquina por no saber o no querer votar y también existe otra con una taza de café, que implica una solicitud de parada de descanso pues hay veces que la duración es de 2 a 4 horas.

También se designa la persona que va a realizar la DEMO, demostración al usuario de lo hecho en el sprint que finaliza, y al que va a tener el rol de perseguidor de la DEMO.

Se realiza a diario una reunión de Scrum, daily, de unos 15 minutos en los que el PO con el equipo (en ocasiones acude el SM) explican uno a uno

  • Qué se ha hecho el día anterior.
  • Qué se va a hacer en el día.
  • Qué problemas (impedimentos) ha tenido => muy positivo pues a veces otro miembro del equipo los ha tenido y los ha solventado, bien en este proyecto y no lo comentó o en un proyecto anterior, con lo cual aporta su experiencia o quedan para resolverlo juntos después.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas «post-it» y pizarras hasta software específico. Nosotros hemos usado una pizarra con notas autoadhesivas de colores por parte de cualquier miembro del equipo colocando en fila una para cada historia del sprint y  sus tareas repartidas en  tres columnas dentro de la fila:

  • Tareas pendiente (nuevas sin empezar)
  • Tareas en curso («in progress»)
  • Tareas resueltas («done»)

De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado ya que cada nota-tarea lleva una breve descripción y quien del equipo la tiene asignada o bien se la ha asignado a sí mismo.

Retrospective

Al finalizar el sprint se hace DEMO => PLANI => Retrospectiva, RETRO.

El PO documenta la gráfica de burn down y actualiza qué velocidad media tiene el equipo. Adicionalmente documenta qué historias han formado parte del presente sprint y qué impedimentos han surgido en la consecución del mismo. Se escriben 3 propuestas sobre el proceso y la metodología en «post-it» por cada persona y se pegan en un dibujo en forma de estrella

El resultado de la retrospectiva lo documenta el PO una vez votado sobre cuáles son las mejores.  Actualmente esto más el backlog y el tablero de tareas se gestionan con  la herramienta REDMINE.