archivo

Archivo de la etiqueta: tablero de Scrum

La definición del flujo de trabajo es algo que está abierto y es lógico que así sea porque cada equipo de trabajo y cada proyecto tiene sus peculiaridades.

Es frecuente encontrarnos con tableros que no tienen una fase para el testing y suele ser provocado porque se entiende que de manera implícita se encuentra en la fase de realización, construcción, desarrollo o como se quiera llamar.

Conociéndonos como nos conocemos los desarrolladores y nuestras prácticas habituales de no probar de manera adecuada los componentes que construimos es una buena idea incluir una fase de testing de manera explícita. Es cierto que no te asegura nada (hacer testing requiere de disciplina y buenas prácticas) pero el simple hecho de considerarse una actividad y visualizarse es algo que tiene mucha fuerza.

Por ese motivo, aunque creas que la inclusión de esa fase no aporta nada, prueba a hacerlo y tras un tiempo, trata de sacar conclusiones de manera objetiva a través del número de defectos que se hayan conseguido solventar antes de alcanzar producción en comparación con los valores que estuvieras obteniendo hasta ahora, a partir de ahí ya tendrás todos los datos necesarios para continuar con estas prácticas de manera general, en proyectos o sprints concretos o tomar la decisión de, como hasta ahora, no incluirla.

Es ciertamente potente, muy potente. Conocer de un solo vistazo el estado de las tareas y detectar cuellos de botella (aplicando Kanban o no) y que esté siempre presente supone una guía muy importante (cómo va cada cosa, qué está terminado, qué no ha empezado, etc…) para el equipo de proyecto y para el conjunto de personas implicadas en el proyecto.

Esa información se puede tener en la cabeza pero la efectividad no es la misma que captarla con la vista, es lo de siempre, no es lo mismo una imagen abstracta, por muy claro que se tenga la situación, que algo que estás viendo con tus propios ojos y más cuando se trata de un trabajo en equipo y hay una serie de personas que tienen que dialogar y tomar decisiones en base a esa información (en general y más allá de la visualización de un flujo de trabajo resulta de mucha utilidad tener esas reuniones cerca de una pizarra, es más, si te es posible pon todas las pizarras que puedas cerca de tu equipo de proyecto).

Hay muchas formas de implementar esto (orientación horizontal o vertical del flujo de trabajo, aplicar Kanban o no, hacer una separación por proyectos o no, etc…), no hay fórmulas magistrales para definir el flujo de trabajo, dependerá del proyecto y también del equipo de trabajo.