Pages Menu
Categories Menu

Posted by on Oct 8, 2018 in General | 0 comments

Ideas para gestionar tareas de «deuda técnica» en un modelo de trabajo Ágil

Este post va a ser del estilo a aquel de cómo gestionar las tareas de UX en un modelo de trabajo ágil (una manera (Ágil) de organizar el trabajo, conjunto, de UX y Desarrollo), pero en este caso referido a las tareas de deuda técnica, tareas técnicas.

Sin ir más lejos, el viernes pasado, en Ciudad de México, en la conferencia Agiles 2018, la más grande e importante de Latinoamérica (que este año contaba con 1.000 inscritos) daba una charla (junto con Gilberto e Iván) sobre la importancia que tienen las, por desgracia muy olvidadas, prácticas técnicas en un modelo de trabajo Ágil, y lo imprescindibles que son en cualquier caso, más aún si trabajas en un modelo ágil.

jgarzas_banana_mexico_agiles

Así terminó la charla que di junto con Gilberto e Iván, sobre Prácticas Técnicas, eXtreme Programming y Deuda Técnica en el Agiles 2018 en México

Sobre esto, no hay una estrategia única e inamovible, ya sabes, Shu-Ha-Ri, pero, en cualquier caso, te voy a contar la que yo uso y me parece más sensato.

Para ir calentando, recuerda que, si trabajas en un modelo ágil, en lo que refiere al ciclo de vida, este es, ojo, atento, un tipo especial del ciclo de vida iterativo e incremental. No me voy a enrollar, que para eso ya escribí en su día varios posts sobre esto (te dejo este del 2010, Veterano ciclo de vida iterativo e incremental y este del 2012, el ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental). Esto implica que en cada iteración debiera dejarse un tiempo a “limpiar”, refactorizar, mejorar, quitar deuda técnica (cosa que muy pocos hacen, dicho sea de paso), y no sólo dedicarse a añadir funcionalidades al producto.

En este punto hay quien usa, sin tener que llevarlo a que sea una regla inamovible, la “famosa” regla aquella del 80/20 (post… ojo con frenar la velocidad a corto plazo por, supuestamente, ganarla a largo plazo), 80% del tiempo, puntos historia, items, a ojo, o como lo quieras montar, dedicado a Historias de Usuario (añadir valor funcional) y 20% a tareas más de reducción de la deuda técnica.

Dicho lo anterior… ¿dónde van, y cómo gestionamos, esas tareas (no las llames historias eh, la importancia de llamar a las cosas por su nombre) de “limpiar”, refactorizar, mejorar, quitar deuda técnica, etc.?

Hay tareas técnicas que se derivan de una historia de usuario, típicamente saldrán durante un Srpint Planning y se colocaran en el Sprint Backlog, pero… esas tareas técnicas, de reducción de deuda técnica (o similares) que no se derivan concretamente desde una historia… ¿dónde van? ¿dónde se guardan?

Una opción es meterlas en el Product Backlog, pero es peligrosa y rara. Porque el Product Backlog es territorio del Product Owner, que no tiene porque saber de cosas técnicas, y, además, corremos el riesgo de que nunca les de prioridad… queda raro. No suena bien.

En mi opinión, la mejor opción es tener un backlog para aquellas cosas “técnicas” que no derivan directamente de una historia de usuario. Bajo la premisa de que cualquier backlog debería ser pequeño (la información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones), para evitar desperdicio. Priorizarlo, como cualquier backlog. Y acordar que durante el Sprint se dedique un tiempo a esas tareas.

Ese backlog con tareas de deuda técnica, sería un backlog que gestiona la parte técnica del equipo.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This