Scrumízate
Existe una particularidad importante en el desarrollo de software: se permite la implantación de un producto no acabado o con errores conocidos. Esto provoca que se pueda poner en producción software inestable.
A esta situación podemos sumarle que en muchas organizaciones centran sus políticas de ahorro en recortes sobre los procesos de pruebas, controles de calidad, creación de documentación, optimización del producto...
Estas decisiones comprometen la viabilidad del proyecto a largo plazo.
Entendemos deuda técnica como el concepto del desarrollo de software que hace referencia a los costes adicionales que se generarán en el futuro por la apuesta por un desarrollo sencillo y apresurado, en lugar de haber buscado el mejor enfoque con un mayor tiempo de dedicación
Si queremos resumirlo de forma fácil: la deuda técnica es todo aquello que no hicimos en algún momento del pasado y que deberíamos haber hecho para trabajar profesionalmente en un software decente y de calidad.
No sólo nos debe importar que el código funcione, también se necesita que sea fácil de leer y de mantener. Todos los desarrolladores hemos experimentado esos momentos "creativos" en los que para salir del pozo terminas con una solución que funciona sin saber muy bien porqué. ¿Cuánto tiempo pasará hasta olvidar que hemos hecho? Más allá de la alegría inicial debemos saber que estaremos añadiendo deuda técnica.
Este es uno de los mayores riesgos que existen en el desarrollo de software. A medida que avanza el tiempo del proyecto el conocimiento sobre el código se va diluyendo. Avanzar cada día será más lento y llegará un día que todo quedará frenado. Puedes leer este post acerca de cómo combatir los riesgos de un proyecto mediante el uso de scrum.
Tobias Mayer y Alan Cyment nos dejan algunas reflexiones interesantes acerca de la deuda técnica en su libro Por un scrum popular, notas para una revolución ágil.
Causas de la deuda técnica
Des de 1992, que se propuso por primera vez el término deuda técnica, conocidos desarrolladores han escrito acerca de este concepto. Una de las explicaciones más conocidas es la matriz de Philipe Kruchten (profesor de ingeniería del software en la Universidad Británica de Columbio en Vancouver) en el whitepaper sobre la Deuda Técnica: De la metafora a la teoría y prática.
En la matriz se muestra como la deuda técnica aporta un valor negativo y es invisible, a diferencia de los bugs o caídas del sistema que aportan un valor negativo de una forma visible.
Steve McConnell (autor de libros de texto de ingeniería del software y una de las tres personas más influyentes de la industria del software junto a Bill Gates y Linus Torvalds) define que existen dos vías principales para generar deuda técnica:
- Deuda añadida de forma involuntaria debida a trabajos de baja calidad. Se atribuye al desconocimiento del equipo.
- Deuda añadida intencionadamente para recortar tiempos haciendo las cosas mal. Se atribuye a un bajo sentido de la responsabilidad o de visión a largo plazo del equipo.
Con la deuda técnica pasa igual que con la deuda con un banco: cuanto más tiempo tardamos en gestionar esa deuda más interés vamos a pagar.
Muchos equipos, a menudo en startups o empresas pequeñas, eligen trabajar más rápido al inicio de un proyecto a costa de generar deuda técnica. Esta decisión es doblemente negativa: por un lado estamos incrementando la deuda técnica en las fases iniciales y estamos generando una falsa sensación de velocidad. Ambas se girarán algún día a la contra.
Esta es una lista de posibles causas de generación de deuda técnica:
- Definición previa insuficiente
- Presión del área de negocio
- Falta de procesos o entendimiento
- Componentes fuertemente acoplados
- Baterías de pruebas insuficientes
- Mala documentación
- Falta de colaboración
- Desarrollos en paralelo
- Posponer los refactors
- No seguir los estándares
- Desconomiento
- Liderazgo técnico pobre
- Cambios en las especificaciones de última hora
Cuando tomamos atajos para salir de la presión del cliente, del gerente, de los usuarios, de unos presupuestos bajos... estamos tomando decisiones que fuerzan al equipo a saltarse partes del proceso de creación de software que, aunque puede parecer que no ayudan a avanzar rápidamente en el desarrollo, ayudan a desarrollar de forma segura durante el paso del tiempo. Estas partes no sólo ayudan a ir más rápidos en el futuro, sino que aseguran una estabilidad y calidad del código.
Por más presión que pueda existir es responsabilidad del equipo (y así se le exigerá) que piense en un buen diseño, que realize las pruebas necesarias, mejore los procesos de entrega continua... Nadie de fuera del equipo defensará esta posición!
Responsabilidad sobre la deuda técnica
El mayor peligro de una deuda es no pagarla. Cuando no se paga la deuda técnica ésta no desaparece y se va acumulando en distintas partes del proyecto. Un equipo puede llevar años acumulando deuda técnica.
Toda esta deuda técnica generada un día explotará. Se habrá terminado el crédito. No sabes cuando será ese día, puede que sea hoy, pero cuando pase el equipo quedará totalmente frenado. Avanzar con los desarrollos será difícil y costoso.
El desarrollo de software lo debemos entender como un proceso incremental e iterativo. Sobre todo iterativo. Si quieres saber más acerca del desarrollo iterativo puedes leer este post.
Cuando se habla de deuda técnica es fácil pensar que los responsables de haberla generado son los integrantes del equipo de desarrollo. Así es. Jerónimo Palacios, conocido Agile Coach:
"La deuda técnica es un reflejo de una falta de madurez en la gestión empresarial."
Cuando elegimos dejar un código malo ahí, sin tocarlo, puesto que ahora está funcionando, estamos generando o perpetuando deuda técnica. No podemos ser tan ilusos de pensar que algún día tendremos el tiempo suficiente para empezar a arreglar todas esas partes del proyecto con deuda técnica y dejarlo completamente sano. Nunca existirá este momento!
Las dinámicas que se generan con el día a día es fácil esconderse bajo este "trajín" para no asumir la responsabilidad. Siempre encontraremos cosas más urgentes antes de empezar un cambio profundo en la organización: el pago de la deuda técnica.
No puedes esperar que alguien, de fuera del mundo del desarrollo, venga a solucionarte este problema, no por no querer ayudar sino por desconocimiento total de la situación. A modo de alerta, evita estas frases y combátelas!
- El cliente necesita esta entrega lo antes posible
- Los superiores aprietan con el lanzamiento del producto
- Sólo él conoce esta parte del código
- No tenemos tiempo para sentarnos y pensar como mejorarlo
- Voy más rápido haciéndolo yo que enseñándolo a un compañero
Pronunciar alguna de estas frases es no asumir la responsabilidad. La responsabilidad de cualquier equipo de desarrollo reside en la creación de software que funcione, escale, sea fácil de leer, de mantener o de evolucionar.
En algún momento nos podemos encontrar que empezar a combatir la deuda técnica se ha convertido en una montaña gigante. En esos momentos puede que empieze a cuajar la idea que se debe empezar el proyecto de cero, que lo más apropiado es tirar a la basura lo hecho hasta el momento y volver a empezar.
Empezar desde cero no es aceptable
Proponer empezar desde cero es tener un comportamiento muy poco profesional. Por más que pueda parecer la opción más viable provablemente estaremos en un espejismo y no tendremos en cuenta muchas de las cosas buenas que tiene el producto actual. Iterativo recuerdas?
¿Cómo resolver la deuda técnica con scrum?
Cuando existe deuda técnica en un proyecto, sí existe, es prioritario empezarla a pagar. Cuando empezamos a hacer los nuevos planteamiento pueden aparecer la siguientes preguntas:
- ¿Cómo podemos empezar a pagar la deuda técnica?
- ¿Cómo ponemos en valor arreglar algo invisible?
- ¿De dónde sacamos el tiempo para arreglarlo?
- ¿Cómo afectará el tiempo empleado?
Scrum propone una buena fórmula para ir pagando esta deuda técnica sin que afecte a los tiempos comprometidos y que asegura que se trabaja en ello a medida que se avanza en el proyecto.
Una buena dinámica para empezar a disminuir la deuda técnica sin que esto afecte el rendimiento del equipo (productividad dentro del sprint) es la siguiente:
- Si encontramos un código mal escrito, que no es necesario, que no se entiende, sin pruebas que lo validen... en lugar de empezar a solucionarlo en ese momento, salvo que sea imprescindible en la funcionalidad que se está trabajando, se crea un post-it que lo documenta. Anotamos el archivo, identificamos las líneas afectadas y la funcionalidad implicada. Esta tarjeta se categoriza como deuda técnica. Una vez hecho esto se sigue con el desarrollo de la funcionalidad. De este modo no alteramos el compromiso del sprint y hacemos visible esa deuda técnica.
- Si en una reunión de planificación alguien requiere de una funcionalidad que implica tocar una zona marcada en alguna tarjeta de deuda técnica, se pasa a mencionar la situación, para que todos entiendan que significa esa parte de deuda y así poderlo tener en cuenta en la estimación del esfuerzo del sprint. El equipo nunca trabajará en una funcionalidad que tenga deuda sin solucionarla. El equipo no puede agregar deuda sobre la deuda ya generada.
- El último punto es la elección del product owner: elegir entre pagar la deuda y realizar la funcionalidad o no desarrollarla. Se trata de una decisión binaria.
Con esta técnica no solo conseguimos pagar deuda sino que también ayudamos a hacerla visible, a asegurar sus pagos con la propia evolución del proyecto y crear una dinámica de trabajo que propicie los refactors, haciendo la calidad del código una cosa importante para todos.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
