El crecimiento de la deuda técnica es similar a los daños causados por las termitas (si no se controlan): ambos pueden causar problemas cada vez mayores. Cuando arrastramos deuda técnica, el desarrollo se hace más difícil, el código base se vuelve frágil y se requiere un conocimiento tribal para entender los hacks y las soluciones alternativas. La deuda técnica debe ser abordada y evitada en el futuro, pero éste es un objetivo difícil de alcanzar.
Con las herramientas de
Atlassian, los equipos pueden reducir la deuda técnica, primero, identificando qué es, desarrollando un plan para reducirla de forma iterativa y, por último, encontrando formas creativas para permitir a los desarrolladores mejorar ellos mismos el código. ¡Sigue leyendo para saber más!
Primer paso: Identificar la deuda técnica
A primera vista, muchas personas asumen que la deuda técnica es igual a “bugs”. Claro que los “bugs” son un cierto tipo de deuda técnica, pero la deuda técnica es más que sólo errores. La deuda técnica es un muy buen trabajo prometido pero no entregado al cliente, defectos en el código, o elementos de trabajo que nada tienen que ver con la agilidad. Debido a que la deuda técnica puede manifestarse de muchas maneras, a menudo hay un punto de discordia entre los equipos de desarrollo y los propietarios del producto. ¿Dónde se traza la línea entre la deuda técnica y las características del nuevo trabajo?
Los equipos pueden crear una página en
Confluence que describa la definición del equipo de deuda técnica. Estas buenas prácticas se pueden utilizar como guía para futuras conversaciones sobre la gestión de la deuda técnica de un equipo, tanto en la planificación como en la entrega.
Nos tenemos que dar cuenta, sin embargo, que no toda la deuda técnica es la misma y que tendrá diferentes prioridades y caminos hacia la resolución.
- Errores: tienden a ser de pequeño alcance y suelen ser de carácter más urgente.
- Trabajo en una funcionalidad incompleta: características que no fueron desarrolladas según las normas de aplicación del equipo. Hay que tener en cuenta que el trabajo en nuevas características que no se han entregado pueden no ser deuda técnica. Esto es a discreción del equipo y de cómo la definen .
- Bibliotecas de código “caducadas”: Código viejo y versiones de código antiguas.
- Construcción y despliegue de herramientas: Problemas de construcción y despliegue que se pueden categorizar como deuda técnica. Hay que asegurarse de que el equipo tiene un proceso rápido de desarrollo y liberación.
JIRA tiene muchas características para ayudar a los equipos a definir y “domesticar” la deuda técnica. Con el uso de los tipos de asuntos de JIRA, es fácil clasificar los diferentes tipos de deuda técnica en cada una de ellas. Las discusiones entre los managers de productos y los ingenieros llevan a mejor puerto cuando existen definiciones claras sobre la deuda técnica en los diferentes tipos de asunto.
Consejo: Usando los tipos de asunto para categorizar la deuda técnica, serás capaz de asignar los flujos de trabajo personalizados para cada uno de ellos. Una alternativa a ello es el uso de campos y etiquetas personalizadas para todos los tipos de deuda técnica y que compartan el mismo flujo de trabajo.
Los cuadros de mando de
JIRA también ayudan a gestionar la deuda técnica, ya que pueden visualizar y realizar un seguimiento de la misma. El gadget de filtros de estadísticas bidimensional ilustra cuándo la deuda técnica fue introducida y para cuándo espera el equipo tener resueltas esas cuestiones.
El gadget de “creado VS resuelto” resalta el flujo de la deuda técnica a través del equipo. En un mundo ideal, este gráfico mostraría más verde que rojo, y es perfecto para una pantalla mural porque es un elemento muy visual.
Estas buenas prácticas y gadgets dan transparencia a la deuda técnica y pueden ayudar a un equipo a evitar fácilmente posibles problemas mayores en el futuro.
Segundo paso: Gestionar el “backlog” o trabajo atrasado
Los equipos pierden la ventaja estratégica de hacer que las prioridades sean globales a lo largo del producto cuando la deuda técnica no está en el mismo “backlog” que las nuevas características. Tener todas las tareas en un mismo lugar hace que el trabajo de todos sea más fácil, porque las prioridades están claras.
Un “backlog” también hace más fácil la planificación del sprint. El enfoque de la planificación del sprint es reunir un conjunto de prioridades para una iteración basándose en las tareas del “backlog”. La mayoría de los equipos asignan una gran parte de las tareas de la iteración para las nuevas características del prodcuto. Eso es lo normal y lo esperado. Los equipos inteligentes tienen una definición estricta de "finalizado" para evitar la adición de nueva deuda técnica, y tener un plan iterativo para la reducción de la deuda técnica excepcional.
Los filtros rápidos hacen que sea fácil ver cómo los equipos pueden priorizar la deuda técnica en el contexto de otras prioridades, especialmente durante una reunión de planificación del sprint.
Entonces es fácil alternar entre todo el “backlog” y destacar la deuda técnica para asegurarse de que el equipo tiene el plan de acción correcto para todo el programa. Esto también da a los gerentes y jefes de proyecto una visión en detalle para asegurarse de que el equipo está cumpliendo con los objetivos de deuda técnica según la hoja de ruta a corto plazo.
Consejo: culturas basadas en buenas prácticas de ingeniería equilibran de una forma efectiva las nuevas características del trabajo con la gestión de la deuda técnica. En otras palabras, es muy importante crear una cultura en la que está bien tomarse un tiempo para arreglar la deuda técnica como un esfuerzo de colaboración con el gerente, mediante el reconocimiento y apremio hacia los miembros del equipo de ingeniería que hacen el trabajo del equipo.
Tercer paso: Habilitar la creatividad utilizando el ¡20% del tiempo y ShipIt!
En Atlassian, todo el mundo tiene un deseo de contribuir más allá de la cadencia de nuestra programación y, como compañía, no hacemos más que pensar en el aprovechamiento de la creatividad propia. Tres ingenieros de desarrollo, Filip Rogaczewski y Arkadiusz Glowacki en Polonia, y Andreas Knecht en Sydney, se aprovecharon de un 20% de tiempo y la competición “
ShipIt"(ver
https://www.atlassian.com/company/about/shipit) para reemplazar la vieja tecnología con mejor rendimiento para los gadgets en JIRA que estaban fuera de sus deseos personales, por hacer que los gadgets sean excepcionales.
Se permite a los desarrolladores que forman el equipo de Atlassian inverir el 20% de tiempo para innovar en nuevas áreas de su ecosistema el 20% de su tiempo de trabajo, y ShipIt es una competición trimestral para que cualquiera pueda construir o arreglar algo que sea:
- Relacionado con productos o procesos de Atlassian.
- Completado y presentado como una demo en un plazo de 24 horas.
Al final de las 24 horas, todos votan sus proyectos favoritos (DATO CURIOSO: ¡acabamos de celebrar los 30 ShipIts!)
Irónicamente, Filip y Arkadiusz comenzaron a arreglar los gadgets de JIRA en Polonia, mientras que Andreas trabajó en el mismo proyecto en Sydney usando el 20% de su tiempo. Ellos estaban conectados cuando se corrió la voz de que tuvieron la misma idea.
Después de ello, los tres ingenieros se reunieron y decidieron abordar el tema de los gadgets a través del 20% de su tiempo y un ShipIt. Con la ayuda de un arquitecto de JIRA, el objetivo del proyecto era enderezar algunas cuestiones, sobre todo la lentitud, y revisar todos los gadgets de JIRA. Hasta este punto, los gadgets de JIRA se ejecutan en OpenSocial, un entorno de hospedaje de Google que fue popular en 2009, pero que desde entonces ha quedado en desuso.
Durante el ShipIt y el 20% de su tiempo, el nuevo equipo de gadgets llegó a la conclusión de que la mejor manera de modernizar los de JIRA era rehaciendo cada gadget de forma individual y liberándolos de forma incremental y ágil. Este plan era de bajo riesgo, sin perjuicio para el cliente y un ejemplo perfecto de cómo hacer frente a la deuda técnica. Era escalable y, a lo largo del tiempo, el equipo podría ver las ganancias de rendimiento desde los tiempos de carga de un tablero en la nube, para asegurarse de que la nueva tecnología estaba funcionando después de ShipIt, y que era capaz de mejorar constantemente los nuevos gadgets.
Ese es el valor de acosar a la creatividad propia - las personas pueden centrarse en las áreas del producto que realmente les importa a la vez que mejorar el producto y su código, ¡especialmente al abordar la deuda técnica!