“comprometerse”

Noviembre 17th, 2009 by testaddict

Durante un planning de iteración, el equipo esta invitado a elegir un compromiso. La mayoría de las veces, el comportamiento esperado es elegir un conjunto de funcionalidades a entregar al fin de la iteración que arranca aquel día.

En Scrum, este ritual de compromiso tiene lugar cada nueva iteración.

La iteración es tiempo para realizar el compromiso. Ahora es cuando los artistas informáticos utilizan su arte para crear un incremento de software con calidad excepcional. Hum… Pero que significa Calidad para ustedes ? Si fuéramos compartiendo un café, probablemente estaríamos de acuerdo con que los profesionales informáticos tienen que entregar software de calidad. Quizá que su “compromiso” tenga algo que ver con “entregar calidad”.

Durante la ultima década se desarrollo una técnica llamada TDD. Me imagino que ya conocen este dibujo del TDD :

Pero, que motiva el Refactoring ? Uno podría opinar que si las pruebas están verdes, podemos entregar. Claro lo difícil es seguir añadiendo funcionalidades. Otras pruebas, otro código. Para ser capaz de seguir con ritmo estable, aprovechamos este tiempo de refactoring para transformar nuestro código en un “código de calidad”. La meta parece ser la calidad.

Dicho de otra manera : el profesional artista-informático produce un código de calidad durante el refactoring. Otra manera de decirlo : el artista-artesano informático respeta su compromiso durante el refactoring. Ahora, dibujandolo así, ya ven adonde voy ?

Mezclando la idea de compromiso de Scrum y el refactoring de TDD, podríamos vivir la situación siguiente : durante un planning de iteración, el Equipo considera los elementos prioritarios del Product Backlog, escribe pruebas automatizadas y hace pasar pruebas – si: durante el planning -, y considera cual puede ser su compromiso : que parte del código escrito para hacer pasar las pruebas podemos convertir en código de calidad durante la iteración ? Por ejemplo un equipo podría haber logrado hacer pasar 4 pruebas pero quedarse con el compromiso de entregar código de calidad solamente para 3.

Esto pone al primer plano la calidad y el profesionalismo de los equipos : la valor de los profesionales de la industria del software se encuentra durante el refactoring. Queda un único lugar para escribir código podrido : el planning.

7 para todos

Noviembre 9th, 2009 by testaddict

Quisiera compartir con ustedes una experiencia mía reciente durante un mantenimiento de Backlog. Seguí una inspiración súbita que no había anticipado y la verdad todo salio muy bien.

La semana pasada una PO había planificado un mantenimiento de Backlog urgente : al cambiar de jefe tenia que entregar un roadmap completo para la mañana siguiente. La transicion hacia una gestión menos predictiva esta aun por delante ahí y la POestaba muy nerviosa. Fijaos : un nuevo jefe !!

Empezamos la reunión con 20 minutos de retraso. Estaba cada minuto mas nerviosa. Después de 10 minutos el Equipo y el PO no habían elegido una estimación para el primer elemento…y había mas de 30 por estimar. El planning poker parecía de poco ayuda, dando el nivel de nerviosismo de todos.

Entonces pregunté de nuevo cual era nuestra meta:

-PO : “tener un backlog completamente estimado”

- yo : “fácil : simplemente eliminar la filas sin estimación…”

Silencio…

- PO : “tener un roadmap para el año”

- yo : “fácil : poner 7 en cada fila sin estimación” – esto fue la inspiración súbita : elegir el 7 ;-)

- todos : “porque 7 ??”

- yo : “porque históricamente durante su mantenimientos de backlog soléis votar 5 o 8. Votar 7 nos permitirá tener una aproximacion del peso del backlog y volver mas tarde y encontrar facilmente la filas porque el 7 no figura entre los valores del planning pokerque usáis”.

Así lo hicimos -> 20 iteraciones en el backlog con solo 4 disponibles. Al llenar las celdas vacías con un 7 muchos habían visto elementos que según ellos nunca serán considerados. Cabía tener la discusión con la PO para verificarlo. Además habían visto elementos para aquellos que el 7 era “muy falso”. Si estaban de acuerdo que eran muy falsos, esto significaba que sabían estimarlos mejor deprisa.

Eso fue la primera discusión : encontrar los muy falsos y sustituir el 7 por algo menos falso. La secunda fue eliminar ellos que todos sabían nunca serán considerados. etc etc.

Lo divertido es que casi todos los elementos que estimaron durante la sesión recibieron un 5 o un 8.

Por fin, terminamos de antemano con mucha animación.