Las Tareas Son del Equipo

Es común en ek planeamiento de una iteración, elegir las tareas del backlog, por prioridad dada por los “stakeholders”. Una vez elegidas las tareas, se van ejecutando, generalmente teniendo subtareas. Hay tareas de programación, de diseño de interfaz, de deployment, etc…

He visto dos formas de encarar la ejecución las tareas: o se las asigna UNA persona, o se la ejecutan entre varios, tal vez UN miembro del equipo por SUBTAREA. Y luego de ver mucho éxito en la segunda forma, pienso que es lo más adecuado (siempre dependiendo del context y las fuerzas del proyecto, el estado del equipo, etc…). Incluso participé de un proyecto donde no había más de DOS tareas abiertas, de tal forma que los miembros del equipo colaboraban para terminar cualquiera de esas dos tareas (en este caso en particular, las dos tareas en general eran de programación o de diseño).

El que varios trabajen en una tarea, y no se pase a la siguiente hasta tenerla terminada, veo que favorece el “ownership” colectivo, donde no se forman silos de programación, donde cada miembro del equipo termina colaborando viendo el proyecto en general, y no solamente la parte que a él/ella le toca. Permite también la adopción de programación de pares, la difusión del conocimiento, y un “code review” permanente, adoptando agilidad, en lugar de etapas de codificación y “code review” por separado.

En un equipo maduro, debería adoptarse esta forma de encarar las tareas del “sprint” (siempre y cuando, respetando el contexto y las fuerzas del proyecto en particular). Por lo menos, he visto mejora en el resultado cuando se adopta esa forma de trabajo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

 

This entry was posted in Desarrollo Agil, Programacion. Bookmark the permalink.