Tales from the Scrum: Informando el estado

Esta práctica me resultó muy útil, cuando la adoptamos para varios equipos, hace ya como dos años. Cada equipo tiene una lista de correo, y al final de la reunión diaria, uno informa en la lista las tareas que se tomaron. Eso permite que interesados en el proyecto, que no están en la reunión diaria, ya sea porque no son parte del equipo, o porque están físicamente alejados, vaya enterándose de lo que se toma para ese día.

Pero además, cada integrante, va enviando a la lista de correo, su estado. Este es un ejemplo, del que envíe al comienzo día el pasado lunes:ç

En el estado pongo algo más detallado en pasos las tareas que tomé en la reunión diaria de Scrum.

Luego, a medida que va avanzando el día, digamos, cada 3 horas, o cuando se termina una cantidad de tareas que puede interesar al grupo, envío un email con el estado de avance Y verificación:

 

Lo que está informado acá, debería estar ya disponible en el repositorio de código del proyecto. La verificación es importante: permite informar en detalle qué página web o qué programa, o que directorio, cambió, y en qué forma, y eso ayuda para que cualquier otro miembro del equipo se base en esa información, para sus propias tareas. Por ejemplo, tal vez otro miembro del equipo encuentre interesante la implementación que hicimos de algún algoritmo, al informar que ese código está listo, y en qué lugar, y ya puesto en el repositorio, esa persona puede ir a verla y aprovecharla para su propia tarea. Los “screenshots” dan información más visual de lo hecho, y sirven como una verificación de que estuvimos probando lo que hicimos (lo que no impide que haya una verificación como otra tarea, tal vez tomada más adelante por otro miembro del equipo).

Al ser informado de forma escrita y en la lista de correo del equipo, queda registrado, y se puede poner información detallada, que tal vez se pierde o se olvida si se informa oralmente. El equipo de desarrollo está físicamente en la misma sala, pero este tipo de información sirva para pasar en limpio cualquier avance o bloqueo que hagamos durante el día.

El poner la lista al principio, y exponerla en la lista, también tiene su efecto psicológico: nos pone en compromiso con el equipo, con el product owner, con otros suscriptos a la lista, y con un mismo, sobre lo que hay que hacer ese día. Es una forma de contrato, de compromiso fuerte, que cada uno se impone y publica.

Vean que en el estado, voy colocando el estado en colores. Eso también tiene un efecto, como cuando tenemos tests de TDD. Es bueno ir viendo, a lo largo del día, cómo disminuye lo rojo y pardo, pasando cada vez más al verde.

Al final del día, envío un último email de “Mi Estado”, si hubo un cambio desde el último, y así todos van viendo qué se terminó y qué quedó pendiente. Uno debe entrenarse y aprender de sus capacidades, para que cada día quede todo en verde. No ponerse compromisos y tareas que no pueda cumplir.

El título tiene su sentido: al tener siempre la frase “Mi Estado”, se puede filtrar en los clientes de correo. Si todos los miembros del equipo siguen esta práctica, pueden producirse muchos emails de este tipo. Pero si hay miembros de la lista que no están interesados en leer todos estos emails, pueden filtrarlo por título.

A veces se plantea tener una lista aparte para este tipo de comunicación. Me parece que atenta contra la comunicación del equipo y los interesados. Debe estar toda la información disponible, sobre el avance, los problemas y soluciones, y verificaciones.

La verificación está, porque no basta decir “terminé tal reporte”. Hay que poner cómo salió, especificar qué pasos y qué formularios o páginas tuvimos que usar para producirlo, que usamos la base de datos de prueba de siempre, etc…  Poner todo lo necesario, como para que cualquier miembro del equipo, pueda basarse en eso y reproducir la tarea o mejorarla.

Cuando la verificación es rica en “screenshots”, se produce un interesante efecto: esas mismas pantallas e informaciones de verificación sirven para alimentar la presentación de finalización del sprint.

Hay otra herramienta, físical, visual, que podemos manejar para todo esto, pero no he podido participar aún de un equipo que la haya aceptado y mantenido de forma saludable: un tablero físico, donde se van colocando las tomas de tareas y sus cumplimientos. Creo que puede ser complementaria a la práctica que describo hoy. Ese tema, dará para otro post.

Nos leemos!

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

This entry was posted in 10549, 2752, 3463. Bookmark the permalink.

One Response to Tales from the Scrum: Informando el estado

  1. Ernesto Cullen says:

    No es un poco excesivo? Me parece que con la reunion diaria es suficiente. La carga impuesta por el informe parcial puede sentirse (de parte del trabajador) como indicador de falta de confianza, y en general creo que el exceso de informacion es tan malo como la falta de la misma. Si alguien quiere saber en que punto de sus tareas esta una persona, que le pregunte ya sea por mail o mensaje instantaneo o personalmente… no es necesario llenar la lista con mensajes de los cuales el 99% pasaran directamente a la papelera o a alguna carpeta que no se leerá nunca.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>