La fortaleza del Scrum board

27 Ago La fortaleza del Scrum board

Aclaración: En este artículo me refiero al tablero de Scrum y no al de Kanban. El último limita el WIP (cantidad de tareas en progreso) de forma predeterminada.

Es importante que el equipo de desarrollo de Scrum visualice su trabajo y el flujo del mismo para trabajar colaborativamente, conocer el estado de sus tareas y las de sus compañeros e identificar impedimentos. Generalmente para ello se utiliza el tablero de Scrum que tiene la siguiente estructura:

Tradicionalmente el tablero posee 4 columnas: Story, TO DO, IN PROGRESS y DONE. He visto algunos tableros con más columnas (por ejemplo para testing o fixeo de errores, mejora continua, impedimentos, etc). Si esto le sirve al equipo, está bien. Recordar que las herramientas se deben adaptar al equipo y no viceversa. De nada me sirve tener un tablero “fijo” si al equipo no le agrega valor y no lo va a utilizar.

Una buena práctica es que no existan más tareas en progreso que integrantes del equipo. Esto se debe a que las tareas se ejecutan de a una a la vez y colaborativamente. Una persona no debería comenzar una tarea hasta no haber culminado la anterior; mientras que dos personas podrían estar ejecutando la misma en simultáneo.

Otro aspecto importante es que las horas asignadas a las tareas deben ser reales. De nada me sirve estimar una tarea en 2 horas y que dure 2 días.Como muchas veces existe dificultad para calcular en horas, he visto que a veces los equipos usan medidas relativas a días, por ejemplo: 1 dia, ½ día, ¼ día, etc.

El concepto clave es que una tarea no debería estimarse en más de un día. Si esto sucede, la tarea debería partirse en sub-tareas. Cada día después de la daily meeting el SM debería agregar una marca a las tareas en progreso; esto significa que una tarea con dos marcas está en problemas. Los motivos pueden ser dos: que el desarrollador haya subestimado el esfuerzo de la tarea -lo más común- o que se haya presentado un inconveniente que impida resolverlo (impedimento).

El SM debe guiar al equipo para estimar mejor las tareas. Idealmente la suma de todas las horas de las tareas debería sumar la cantidad de horas que dura el sprint menos las tareas relativas a Scrum (ceremonias).

Si se subestiman las tareas y pasan varios días para culminarlas, entonces no estoy usando el tablero de Scrum correctamente. Si se hace “solo para cumplir”, no representa la realidad, ni agrega valor entonces el equipo no debería utilizarlo.

Hoy en día existen muchos sistemas con un tablero de Scrum incorporado pero considero importante utilizar el tablero físico. Es fundamental que el equipo vea en todo momento el estado de las tareas en la pared, además el impacto psicológico de cuando mueven una tarea a DONE es muy importante.

Las tareas por lo general tienen descripción y cantidad de horas. También les puedo agregar la fecha de inicio, prioridad, etc.

Hay equipos que le agregan la fase a la que pertenecen: análisis, diseño, desarrollo, pruebas; incluso indican el responsable. Desaconsejo esta práctica ya que lo primero es un rezago de Cascada y lo segundo conspira contra el espíritu colaborativo de Scrum, en donde todos los integrantes cooperan bajo un fin común.

Para que el flujo sea continuo las historias elegidas para el sprint deben tener un peso similar. Las tareas deben atravesar el tablero a un ritmo sostenido, como en una cadena de montaje. Cuando tengo demasiado trabajo en progreso significa que el sistema está funcionando mal, las piezas se están amontonando, tengo cuellos de botella y por tanto impedimentos que resolver en forma urgente.

Un aspecto importante del Sprint Planning es que el equipo no sólo tiene que hacer el sizing y el tasking, sino también elaborar una estrategia definiendo el orden en que se van a atacar las historias (en función de su importancia, complejidad, dependencias, etc) y quiénes lo harán.

Las historias se atacan de a una a la vez, de arriba hacia abajo y de izquierda a derecha. Una mala práctica es tener varias historias abiertas al mismo tiempo ya que esto da una falsa sensación de avance, el equipo pierde el foco y no trabaja en forma incremental. Hay que pensar en el peor de los escenarios, en el que un sprint se cancela antes de tiempo. Es mejor tener una sola historia cerrada que cinco abiertas.

Un error común que cometen los implementadores es pasarle las historias a los testers durante los últimos días del sprint. Esto genera dos situaciones indeseables:

1. el tester hace su trabajo apurado para terminar dentro del timebox. Errores no conocidos se pasan a producción.
2. el tester utiliza el tiempo estimado pero luego no hay tiempo en el sprint para que los implementadores hagan los arreglos correspondientes. Errores conocidos se pasan a producción.

Para evitar este problema, el peso que se le otorga a las historias debe incluir todo el esfuerzo y contemplar el criterio de “hecho” (documentación, pruebas unitarias, QA, despliegue, etc) sin lo cual una historia no puede considerarse como cerrada.

En conclusión, en la medida que el trabajo fluya a un ritmo constante, las tareas de desarrollo y testing se harán casi en paralelo. De esta forma se encontrarán errores en forma temprana en el sprint, los mismos se podrán arreglar y las historias cerrar en tiempo y forma.