Archivo por meses: diciembre 2014

Primeros pasos en SCRUM

De cara a poner en marcha un proyecto gestionado con SCRUM son muchas las cuestiones a tener en cuenta. Algunas de las más importantes, en mi opinión, son las siguientes.

El primer punto a considerar es el equipo de desarrollo del que se dispone. Las metodologías ágiles recomiendan la utilización de equipos pequeños que se autogestionen. Esto, en realidad, no es algo nuevo de las metodologías ágiles, sino que parte del sentido común y la experiencia. Los equipos con pocos miembros (4-6) son más sencillos de controlar y la información fluye mejor entre los componentes.

En segundo lugar hay que tener en cuenta el espacio en el que se ubica el equipo. Es muy aconsejable que todos los componentes estén juntos y que tengan la lista de tareas visible en todo momento. En mi opinión, no hay herramienta más potente  para recoger la lista de tareas de un sprint que un tablón visible por todos los miembros del equipo y ante el que realizar el SCRUM diario. Yo utilizo este:

Además del tablón, es útil emplear una herramienta informática en la que registrar toda la lista de tareas (pila de producto y pila de sprint) y poder asociarla a cambios de código. Son muchas las herramientas disponibles en el mercado para ello.  Yo utilizo Microsoft Team Foundation Server porque es el gestor de configuración del que disponemos.

En tercer lugar, hay que definir cómo tratar las diferentes clases de tareas que intervienen en el desarrollo de software y definir el concepto de terminado para cada una de ellas. Cuando digo los diferentes elementos del desarrollo me refiero a análisis, bugs, tareas de configuración de los sistemas, pruebas, manuales de usuario, etc. Cómo gestionar estos elementos depende del tipo de proyecto en el que se esté trabajando e incluso puede ser conveniente realizar adaptaciones a medida que se avanza. Te cuento cómo tratamos nosotros algunos elementos, por si te sirve de ayuda:

  • Los bugs los gestionamos como cualquier otro elemento no planificado que surja en un sprint, es decir, se registra, se valora su importancia y se estima el esfuerzo necesario para resolverlo. En base a esto se decide qué hacer con él. Un error muy común en el desarrollo, y al que tienden todos los equipos irremediablemente, es abandonar el trabajo que estaban haciendo cuando aparece un error, por poco importante que sea.
  • La inclusión de tareas de análisis en SCRUM es complicada. Son elementos complicados de estimar y que tienden a retrasarse. No hay una regla para incluir estos elementos. Una buena idea puede ser demorar el inicio del sprint algunos días realizando tareas de análisis con el objetivo de poder estimar mejor posteriormente el esfuerzo de cada tarea y no tener que incluir en el sprint elementos de análisis. Esta demora también puede servir para romper (no por mucho tiempo porque también es un riesgo) el alto ritmo de desarrollo en el que se encuentra un equipo durante un sprint y proporcionarle un respiro.
  • Las pruebas de cualquier elemento desarrollado se incluyen dentro del concepto terminado de la tarea, es decir, para que una funcionalidad esté terminada tiene que incluir sus diferentes pruebas (unitarias, integración, aceptación, etc.).
  • Los manuales o guías de usuario los considero un elemento más de una funcionalidad, por lo que se añaden y planifican como el resto de elementos. Cuando no lo hemos hecho así, este tipo de tareas tiende a dejarse para última hora, con mucho riesgo de no hacerse al final.

En cuarto y último lugar, lo fundamental es implicar al equipo en el proceso de gestión del proyecto. Una tarea fundamental del SCRUM master es conseguir que el equipo crea en el sistema, participe en su mejora, sea participativo en las reuniones y aprenda a utilizar las herramientas de gestión disponibles. Esto genera equipos autogestionados y mucho más productivos.