Scrum for human beings

Hoy quiero dedicar este post a tratar de explicar la metodologia scrum. Si no conoces esta metodologia, es muy probable que cuando diga scrum te imagines esto:

alt text

Pero no, la metodologia scrum hace referencia a la gestion y desarrollo de software como un proceso, comúnmente, agil.

Algunos terminos frecuentes que se emplean al utilizar scrum:

Scrum Master: Referente o encargado de hacer que el proceso se cumpla y se respete Sprint: Medida de tiempo. Generalmente es corta, 3 a 4 semanas. Backlog: Lista de requerimientos priorizados por el Product Owner Product Owner: Cliente

Si estas pensando que scrum es meramente una forma sofisticada de renombrar entidades que intervienen en nuestro proceso, deberias seguir leyendo.

Scrum básicamente propone ejecutar un proceso e ir ajustándolo durante esa ejecución. Para esto debemos tener una excelente comunicación no solo con el cliente sino tambien con el equipo.

Scrum no es solo una daily meeting. Scrum pretende informar a cada miembro del equipo que es lo que esta pasando en diferentes puntos del proceso. En el libro The Mythical Man-Month : Essays on Software Engineering, Fred Brooks comenta lo siguiente:

Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero? Respuesta: ¡De a un día a la vez! Pequeñas demoras incrementales en variados frentes eventualmente se acumulan para producir un enorme retraso. Permanente atención al alcance de pequeñas metas individuales se requiere en todos los niveles del proyecto.

Scrum interviene casi inmediatamente, con daily meetings(reuniones diarias cuyo unico proposito deberia ser decir que tareas que hicimos, que es lo que estamos haciendo y con que vamos a trabajar en un futuro proximo), lo que permite conocer la existencia de estos retrasos a todo el equipo y modificar el backlog, si fuese necesario, de acuerdo a la resolubilidad de los mismos.

Estas reuniones no deberian demorar mas de 15 minutos, ya que no se deberian tocar otros temas mas que los mencionados anteriormente.

Esta metodologia tambien propone un momento en donde el equipo puede hacer una suerte de "catarsis" (hablando mal y pronto) y decir que fue, para cada miembro del equipo, lo que se estuvo haciendo bien y debe mantenerse y lo que debe ajustarse un poco mas. Esto permite aprender de las fallas e ir mejorando el proceso.

Siempre deberiamos recordar que no existen balas de plata y que estas metodologias tienen que aplicarse a nuestro trabajo, no nuestro trabajo a ellas. Pero mientras mas conozcamos, mayor va a ser nuestra capacidad para elegir la mejor herramienta para cada tarea.