“- ¡Ven hija, vamos a almorzar!

– ¿Está listo, papá?

– Casi.

– ¡Entonces no está listo!

Me reí. Como si fuera el hechizo que se vuelve contra el mago porque el personaje principal de este discurso era Pietra, mi hija cuando tenía 4 años.

¿Cuántas veces nos encontramos con situaciones similares? Tratamos de acelerar algunos procesos, que pueden llevar a esperas innecesarias y a consiguientes retrasos, lo que nos impide mantener la atención en otros temas que podrían ser más importantes.

Estar listo ya no es algo habitual, sin mucha importancia, ahora desempeña un papel importante en la rutina de quienes trabajan con algún método ágil, ya que ayuda a garantizar la calidad de las entregas. En Scrum, por ejemplo, se denomina como “definición de listo” (definition of done) y se utiliza “para comprobar si el (…) producto está listo” (SCHWABER y SUTHERLAND, 2017, p.20). Para que algo pueda definirse como listo, ya sea una parte, un incremento que pueda utilizarse, o un producto final completo, es necesario que las personas que participan en su construcción (equipo, dev team o equipo de desarrollo) tengan un consenso de lo que es “estar listo”, o cada uno entenderá de una forma diferente y al final todavía puede surgir la expresión “¡pero yo pensé que estaba bien!”.

Si existe alguna norma interna o mercadológica de lo que debe contener esa entrega, o si esa definición de listo “forma parte de las convenciones, normas o directrices de la organización del desarrollo” (ibidem), el equipo puede orientarse hacia allá. De lo contrario, deben llegar a un consenso y definir. Un buen parámetro es guiarse por las aportaciones del cliente (en Scrum esta información proviene del Product Owner (Propietario del Producto)) y esta decisión en conjunto garantiza la transparencia del proceso. Siempre vale la pena recordar que la definición de listo debe hacerse al principio de cada planificación del ciclo de desarrollo (en el sprint planning) y para cada elemento que se trabaje, pero puede revisarse y mejorarse antes de los siguientes desarrollos.

¿Una entrega lista entonces es un producto (o incremento) probado y aprobado? ¿No puede haber una coma fuera de lugar? Depende. Si estamos desarrollando un sistema de lanzamiento de cohetes y no queremos explotar con todo, es mejor mantener las comas en su lugar, porque de lo contrario podemos sorprendernos con un resultado menos positivo. Pero si no afecta a la entrega y puede ser ajustado rápidamente en el siguiente ciclo sin comprometerlo, tal vez.

Guíese por una checklist para verificar que se han cumplido todos los puntos preestablecidos. Y la próxima vez que piense en cómo hacer una entrega, considere algunos de estos puntos – ¡especialmente cuando llame a su hija para almorzar!”

Leonardo Magalhães

DIRECTOR DE PROYECTO

Referencia bibliográfica:

SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide: La guía definitiva para el Scrum. 2017. Disponible en:  https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. Acceso el: 14 de Octubre de 2020.