Tales from the Scrum: Terminando la tarea

Los que manejan Scrum, saben que el trabajo se realiza de a etapas, llamadas Sprint. Cada una es una iteración de duración fija, donde se va completando lo que se llama el Sprint Backlog, la lista de tareas que se decidió encarar en esa etapa.

Una tarea pendiente puede ser tomada por uno o más miembros del equipo, al comienzo del día, en la reunión diaria de Standup:

Tales from the Scrum- la reunión diaria de standup

Pero no hay que olvidar algo: no sólo hay que hacer la tarea, sino también verificarla. Qué significa esto?

Si estamos agregando una nueva funcionalidad al sistema (supongamos que estamos trabajando en un sistema de presupuesto de seguros) por el ejemplo, el cálculo correcto del costo de un seguro para un tipo de camión, tenemos no sólo que completar la tarea, sino, en algún momento del Sprint, verificarla: ver de realizar en el sistema un pedido de presupuesto de ese tipo de camión, y ver que se calcule correctamente el importe del seguro.

En general, la verificación la hace otro miembro del equipo.

Si no se realiza la verificación, suele pasar que al final del sprint, se le entrega al cliente algo que no funciona, y vuelve como defecto.

Esto es importante: NO DEBERIAN ENTREGARSE DEFECTOS. Todo el sprint está pensando para entregar lo que estipulamos en el sprint backlog. Se debería entregar lo que está listo para usar. Por supuesto, podemos poner restricciones, como que el costo se calcula bien para tal tipo de camión, no para todos. Pero para el tipo de camión que especificamos al principio del Sprint, el cálculo debería funcionar bien.

Si algo no está verificado, no debería entregarse al final del Sprint.

La idea es: se entrega algo terminado. Habría más para comentar sobre eso de “trabajo terminado”. Por ahora, es hecho y verificado.

Las pruebas automáticas nos ayudan y soportan en el desarrollo del programa. Pero igual tenemos que verificar que lo que se hizo sea tal cual se esperaba.

Algo que ayuda, es escribir historias de uso al principio del Sprint, tipo: ingreso al sistema, cargo estos datos de este camión en particular, y el sistema me responde con tal importe. Eso sirve para quien va a verificar la tarea, sepa cómo probarla, con qué datos, de qué manera. Puede servir como criterio concreto de aceptación por parte del Product Owner y el cliente, al final del Sprint: si el sistema cumple con la historia de uso, cumple con lo pedido.

Ahora bien: el que hagamos algo y otro miembro del equipo lo verifique, no implica que descuidemos la tarea. Nosotros debemos implementarla y probarla, de tal forma que pase la verificación posterior. No debería volver la tarea a desarrollo porque se encontró problema en la verificación. El que realiza la tarea debería preocuparse de hacerla de tal forma, que esté confiado de pasar la verificación.

Esto es parte de “hacerlo bien, hacerlo una vez”. Si uno realiza una tarea con descuido, y la da por terminada, por terminarla rápido, y luego de verificar, se descubre que tiene defectos, hay que volver a trabajar en ella. Y eso ocupa tiempo del Sprint. No, hay que recordar el viejo refrán “Vísteme despacio que estoy apurado”.

Cuando el equipo va madurando, va haciendo carne todo esto. Es común encontrar, en las primeras iteraciones, saltos en el proceso, como el olvido de una verificación. Pero con el tiempo, se va transformando en un “rito”, una de las cosas que se hacen en el Sprint. Y el equipo aprende que esa actividad no está por que sí, porque vino en un libro o curso de Scrum: ven que actuando así, se ahorran problemas, y van sintiéndose más seguros en lo que van armando.

Nos leemos!

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

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

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>