Un panel de trabajo o pizarra de tareas (como se conocía desde hace años) no es más que un apoyo visual para que el equipo se pueda gestionar mucho mejor. Hay una serie de reglas para que el panel nos diga algo pero cada uno debería de adaptarlo a su proyecto o equipo como mejor le funcione.
Un ejemplo de tablón es el que usamos en el proyecto actual. Es simplemente un apoyo a la aplicación, que es TFS y que de un vistazo podamos ver como está la situación del trabajo en el Sprint.
Como referencia al panel de arriba, lo ideal es, si se trabaja con una herramienta del tipo TFS, Jira Agile (Greenhooper), Redmine, HP QC o Test Manager, entre otras muchas, es sacar las gráficas adecuadas a nuestro proyecto y que a los integrantes del equipo le den una información concreta. En mi caso tenemos gráficas de velocidad, de flujo acumulado, de carga de trabajo, el resultado de las pruebas y comparaciones entre el sprint actual y el anterior.
Estas gráficas nos darán una idea de lo que hemos estado haciendo en el sprint anterior y lo podemos ir comparando al trabajo que tenemos actualmente, así veremos si tenemos que coger otro rumbo o seguir igual para que sprint a sprint nuestro equipo mejore.
justo al lado de las gráficas del sprint tenemos una pequeña leyenda de que significa cada cosa en el tablón y debajo un tablón independiente para las tareas internas del propio equipo. Este tablón es exclusivo para nosotros y tiene un flujo típico y sencillo de "To Do, in progress y Done".
Para facilitar el trabajo de los compañeros también he minimizado el flujo de trabajo y explicado con breves notas los pasos por si existe alguna duda que lo puedan consultar rapidamente.
En el tablón grande, donde ya entra todo el proyecto (aunque el panel es exclusivo del equipo y lo configuro y mantengo según me conviene), tenemos cuatro columnas de estado y cuatro columnas de equipos. En las cuatro columnas de estado copiamos el mismo flujo de trabajo que tengamos y así trabaja remos de manera adecuada.
Cada Post It es un PBI diferente y en el viene explicado a donde pertenece (funcionalidad), el ID y la persona que se encarga de ello (esto todavía no lo he implementado y tengo en mente hacerlo en breve, aunque también he pensado adjudicar a cada uno un color para que sepan cuales son los suyos).
Si el PBI tiene defectos le ponemos una etiqueta azul para saber que está bloqueado en nuestro entorno y si el PBI es prioritario le ponemos una etiqueta verde (estas etiquetas posiblemente sufrirán cambios ya que he tenido que utilizar los que hay ahora mismo en papeleria).
Hay muchas maneras de crear un tablón y de adaptarle a nuestro proyecto. No os cerréis a ideas que os da un libro o un manual ya que en muchos casos no valdrán o os será demasiado engorroso actualizarlo o llevarlo a cabo.
0 Comentarios