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.
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.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024