Software

Diagnóstico de Arquitectura de Software con Escenarios de Uso

Introducción

Esta es mi segunda publicación sobre una serie dedicada al Diagnóstico de Arquitectura de Software. En la anterior, te introducía al concepto de arquitectura de software, revisábamos el valor para la organización de este activo y la importancia de evaluar los atributos cualitativos de su diseño.

En esta ocasión, quiero centrarme en la práctica del diagnóstico de arquitectura de software. Esta práctica es fundamental para las organizaciones que basan su negocio en el uso intensivo de software. Sobre su evaluación vas a encontrar un corpus documental gigantesco. Las metodologías pueden seguir estrategias muy planificadas, propias a las aproximaciones analíticas de comienzo del siglo, o enfoques más empíricos, característicos de la más actual gestión ágil de proyectos. Pueden centrarse en qualities muy concretos (seguridad, estandarización, modificabilidad, etc.) o sobrevolar los aspectos generales de la arquitectura.

En este artículo y en el siguiente de la serie, te plantearé dos alternativas ágiles y generalistas para realizar el diagnóstico de arquitectura de software. Aquí nos centraremos en una estrategia basada en la colaboración entre el equipo de desarrollo y el analista. Se trata del diagnóstico dirigido por Escenarios de Uso.

Diagnóstico de Arquitectura de Software empleando Escenarios de Uso

Llevamos más de 15 años trabajando con metodologías basadas en escenarios. Son un marco de trabajo probado para conducir esto procesos. ATAM (Architecture Tradeoff Analysis Method) es el referente más destacado, pero existen numerosas variaciones para hacerlo más ligero y ágil. Diseñado originalmente con un enfoque waterfall, los principios son sólidos y lo podemos adaptar fácilmente a un proceso iterativo incremental.

Como su nombre ya te habrá sugerido, la principal herramienta que emplearemos son los escenarios de uso. Pero…

¿Qué son los Escenarios de Uso?

Se trata de descripciones muy concretas del uso que queremos darle al sistema.

Tomemos el caso de una compañía de distribución on-line. El Product Owner señala que la fluidez del proceso de pago del carrito de la compra es crucial para garantizar el éxito de la venta. Es más. La tasa de éxito en este proceso de checkout (porcentaje de clientes que confirman el pago del carrito, frente a los que abandonaron) es uno de los KPIs para evaluar el desempeño de toda el área de eCommerce.

Trabajando con el PO y el equipo de desarrollo, identificamos que, en el pasado, la falta de robustez de la pasarela de pagos fue una fuente recurrente de frustración para los clientes. Y, así, definimos uno de los escenario de uso como:

“El tiempo máximo de pérdida de servicios de la pasarela de pagos no puede ser superior a 5 minutos para clientes de Francia y Países Bajos empleado MasterCard, Visa, Carte-Blue, iDEAL o PayPal”

Partiendo de un aspecto muy relevante para el negocio, planteado excelentemente por el PO, llegamos a refinar varios Escenarios de Uso (el ejemplo anterior y varios más asociados al proceso de checkout) que nos permitieron definir objetivos muy concretos para la arquitectura y métricas para evaluar su cumplimiento.

Los escenarios de uso para el análisis de requerimientos cualitativos van a jugar el mismo papel que las historias de usuario en el análisis funcional.

De hecho, los escenarios de uso se pueden describir con la sintaxis de BDD (Given+When+Then), habitualmente empleada para las Historias de Usuario. Siguiendo con el anterior ejemplo. Una forma de redactar este Escenario de uso es:

Given: Sistema funcionando en condiciones normales de Operación
When: Se produce una caída de servicio de la pasarela X de pagos para los clientes de Francia y Holanda.
Then: La pasarela alternativa Y debe asumir las operaciones en curso para los medios de pago compatibles (a,b,c..) en menos de 5 min sin que el cliente pierda el estado de checkout.

¿Cómo se crean los Escenarios de Uso?

Los escenarios de uso no surgen espontáneamente. Son consecuencia de la colaboración directa entre el analista, expertos de negocio (ej. Product Owner, Product Manager) y tecnología (ej. Lead Developer, Architect). En las sesiones de trabajo, se sigue un proceso de refinamiento progresivo. En cada iteración se revisa el trabajo anterior, surgen nuevos atributos cualitativos y escenarios de uso, los priorizamos y refinamos. Se obtienen objetivos concretos o aspectos técnicos y de negocio a aclarar para la siguiente reunión.

La labor del analista está en facilitar la colaboración entre negocio y tecnología en la definición de objetivos razonables en relación con su impacto en negocio. Así, buscamos cuantificar el coste para el negocio de la no conformidad con el requerimiento (pérdida de negocio, impacto en cualificación pública del servicio, falta de competitividad, etc.) versus el esfuerzo necesario para implementar su cobertura. En última instancia, el equipo de diagnóstico (negocio + tecnología) valorará los escenarios de uso atendiendo a los criterios de riesgo y coste para obtener una lista priorizada de acciones a desarrollar (un backlog).

¿Cómo priorizamos los Escenarios de Uso?

En mi anterior entrada sobre diagnóstico de arquitectura de software, hacía hincapié en que el diagnóstico debe tener unos objetivos concretos y limitados en tiempo. Por lo tanto, la elección correcta de los atributos cualitativos y de sus escenarios de uso es fundamental para el proyecto.

Para hacer más ágil el proceso de priorización, las estimaciones de riesgo y coste se realizan asignando valores de un conjunto se realizan asignando valores como “Alto, medio, bajo” o tallas de camiseta (M, L , XL).

Los árboles de utilidad son una herramienta visual que funciona muy bien en este proceso. Partiendo de las raíces con los atributos cualitativos, llegamos a los escenarios de uso en las ramas. Los escenarios de uso están etiquetados con (Valor de Negocio, Coste). Opcionalmente, podemos ir valorando cada subnivel, de forma que nos enfocamos rápidamente en los más prometedores.

Utility Map — Ejemplo de Árbol de Utilidad con los Escenarios de uso valorados en Alto, Medio y Bajo para (Valor,Coste)

Finalmente, es muy útil asignar un valor cuantitativo a las estimaciones. De esta forma, podemos acordar una ordenación basada en la puntuación final de cada escenario. Además, la suma de los pesos asignados a cada paso intermedio del camino raíz->rama nos da una valoración más exacta de la prioridad del escenario.

Una técnica común consiste en distribuir un número limitado de puntos que cada miembro del equipo debe asignar a los escenarios. Para facilitar la toma de decisiones, se suele emplear una cuantificación de crecimiento rápido (como Fibonacci). Así, por ejemplo: B = 3, M=5 y A=8.

Otra alternativa que, personalmente, me gusta mucho por su claridad y porque obtiene rápidamente ganadores es el cálculo de Rank Ordered Centroids (ROC).

El analista como facilitador del proceso de Diagnóstico de Arquitectura de Software.

En un diagnóstico de arquitectura de software basado en escenarios, el analista debe poseer un conocimiento experto sobre estilos de arquitecturas y porfolio de herramientas. Pero, al mismo tiempo, debe poseer habilidades de gestión de personas y facilitación del trabajo en equipo. De esta forma, ayudará a identificar los aspectos claves de la arquitectura y conducirá las dinámicas de trabajo para conseguir resultados significativos.

Con esta metodología, no es necesario que el analista sea un experto en el negocio y las tecnologías empleadas en el sistema. Su labor no va a ser a consistir en señalar las debilidades de la solución. Sino en emplear su experiencia profesional para hacer posible una reflexión crítica-constructiva de las oportunidades de mejora. Por otro lado, la presencia de un facilitador externo, no implicado directamente en las decisiones sobre la arquitectura, hace posible que el proceso de análisis se centre en sistema real y no el el “deseado” o idealizado por sus autores.

La dinámica de Escenarios de Uso aporta una gran ventaja. Las conclusiones del diagnóstico surgen como consecuencia de una reflexión interna de la organización. Por lo que sus miembros las asumen como propias.

Como consecuencia de esta labor, además de los habituales entregables (descritos en el artículo anterior), se obtienen unos resultados intangibles que aportan gran valor a la cultura de la organización. Así, el equipo técnico obtenemos una visión coherente con Negocio sobre objetivos de la organización. Y, en el sentido opuesto, los expertos en negocio adquieren conocimiento sobre los aspectos clave de la arquitectura y las decisiones técnicas tomadas para darles soporte.

Riesgos

El mayor inconveniente de esta estrategia basada en escenarios es la necesaria implicación de personas claves de la organización durante un prolongado periodo de tiempo. El impacto de esta dedicación pude diluirse empleando una aproximación iterativa-incremental, evitando secuestrar a los expertos durante un periodo continuado de tiempo. También es útil planificar las acciones coincidiendo con los ciclos productivos de la organización. Por ejemplo, al comienzo de las iteraciones de desarrollo, los miembros del equipo suelen disponer de más tiempo y pueden afrontar las reuniones con menos distracciones.

Otro riesgo de esta metodología es que el equipo emplee la oportunidad del diagnóstico y a la figura del analista como canal de comunicación priorizado. Y, así, trate de promover iniciativas que en el contexto habitual no consigue justificar. El Analista debe emplear su experiencia profesional y personal para no situarse como intermediario de esta comunicación. Proporcionar su opinión, pero promover un diálogo debate entre los actores implicados en la arquitectura de software.

Conclusiones:

En esta ocasión te he presentado las prácticas basadas en Escenarios de Uso para la realización práctica de Diagnóstico de Arquitectura de Software. Hemos visto el papel que juegan los Escenarios de Uso en el refinamiento y priorización de los atributos cualitativos del sistema de software, el rol del Analista-Facilitador en este proceso y te he descrito algunas ventajas y riesgos de la aproximación. Sin duda, hay mucho más que profundizar, pero las bases están ahí. Si te interesa incorporar estas prácticas de Diagnóstico de Arquitectura de Software a tu organización, podemos acompañarte.

En mi próxima publicación, me centraré en una aproximación muy distinta. El diagnóstico basado en experto. Considero que esta dos estrategias son complementarias. Con ellas, afrontamos necesidades o escenarios muy distintos de la organización. Por lo que combinándolas cubrimos un abanico muy amplio de necesidades.

Cómo realizar un diagnóstico de Arquitectura de Software

¿Qué es la Arquitectura de Software?

Hoy en día, las tecnologías de la información (IT) están omnipresentes en la estrategia de las organizaciones. Se apoyan en ellas para ganar ventajas competitivas y perfiles como CIO o CTO tienen pesos significativos en los consejos de administración. El Diagnóstico de la Arquitectura de Software evalúa la capacidad de los sistemas IT para soportar los objetivos de negocio. Su atención ha pasado del contexto técnico a extenderse por todos los ámbitos de gestión. Pero ¿Qué queremos decir cuando hablamos de Arquitectura de Software?

La Arquitectura de Software o de Sistemas (vamos a emplear los dos términos indistintamente) es central al desarrollo de software. Así que vas a encontrar corpus documental gigante al respecto. Las definiciones son muy técnicas y llenas de contexto. Creo que una definición sencilla puede ser: El conjunto de piezas con los que está construido un sistema IT y la forma en la que se comunican entre sí para implementar los servicios de la organización. Si, ya sé que “piezas” no suena muy técnico.

Para entenderlo mejor, déjame hacer un paralelismo con la arquitectura de un edificio. Sus espacios, distribución y atributos (capacidad, versatilidad, cumplimiento de normativas) definen lo bueno que es el edificio para los usos que la compañía le quiere dar. De la misma forma, en el ámbito de los servicios IT, sus componentes (orígenes de datos, servidores de aplicaciones, sistema de monitorización, …), la forma en la que se comunican (canales, protocolos, políticas, …) y sus atributos (capacidad de adaptarse a la demanda, modificabilidad, cumplimiento de estándares, …) nos informan sobre lo conveniente que es para el negocio.

Nota.- Esto es solo un ejemplo. Que me disculpen los miembros de la Architect Registration Board que defiende el uso del término “Architect” en exclusiva en el contexto de la edificación.

Descripción de la Arquitectura de Software

Las características de la arquitectura no siempre son evidentes y, desde luego, no son conocidas por todos los miembros de la organización. La documentación sobre la arquitectura puede ser costosa de mantener y suele estar expresada en un lenguaje muy técnico. Lo que nos va muy bien a los ingenieros para crear una barrera de protección. Pero, en organizaciones ágiles, basadas en equipos autosuficientes y multidisciplinares, esta distancia acaba siendo un gran problema. El objetivo de una descripción de la arquitectura es que toda la organización entienda la situación actual, y las decisiones de negocio y técnicas que están detrás de esa realidad. Con el objetivo de que toda la organización entienda su aplicación y límites.

Para describirla, debes crear visión de la arquitectura actualizada y real. Sin idealizaciones basadas en diagramas y opiniones (mánchate las manos, revisa código y la realidad de producción). Exprésala de forma que puede ser comprendida, en sus aspectos fundamentales (vamos, lo que de verdad importa), y compartida por equipo técnico y de negocio (prioriza lenguaje natural y abstracciones de alto nivel cuando uses diagramas). Identifícala como los objetivos de negocio clave tienen su soporte (o no!) en las decisiones arquitectónicas y, finalmente, las soluciones técnicas para implementarlas.

¿Cuándo debemos realizar un diagnóstico de la arquitectura de software?

El foco en la arquitectura de software debe ser constante en cualquier proyecto IT. La abordamos desde las primeras iteraciones de desarrollo y nos preocupamos de que sus líneas directrices sean familiares a todos los miembros de la organización. Los equipos realizan diagnósticos de la arquitectura de software como parte normal de su proceso de evaluación y adaptación. Revisan los atributos clave, sus implementaciones y posibles alternativas. En el caso de equipos Scrum, el Product Owner y el Equipo de Desarrollo hablan de la arquitectura como parte de la retrospectiva, es evolucionada como contenido del Backlog y el mantenimiento de su documentación se incluye en la Definition of Done.

El diagnóstico de la arquitectura de software puede también iniciarse como un proceso ad-hoc, a demanda de un interesado en el sistema (ej. CTO, Product Owner, Development Team). En este artículo, Grady Booch, presenta algunas motivaciones frecuentes. Debajo te dejo algunos ejemplos de momentos en los que deberíamos realizar este ejercicio. Sobre todo en situaciones en los que efectuamos cambios significativos en el negocio o en la plataforma tecnológica de la organización:

Migración a la nube
Cambio de Monolito a SOA
Organización DevOps
Lanzamiento en nuevos mercados
Ampliación de servicios

El error es parte del aprendizaje, así que también es común realizar el diagnóstico cuando el sistema tiene problemas concretos conocidos por la organización. En este caso, el análisis tendrá un foco muy concreto, con ejemplos como:

Elevado coste de mantenimiento o adaptación de los servicios.
Incumplimiento de normativas.
Un prolongado time-to-market
Percepción de baja calidad por los clientes

¿Quién debe realizar el diagnóstico de arquitectura?

Lo puede realizar internamente la organización. Evidentemente, los equipos que han venido trabajando en el sistema son los que mejor lo conocen. Además, tiene la ventaja de que las conclusiones van a emanar de forma natural y son asumidas como propias. El riesgo estará en que el diagnóstico esté condicionado por nuestra vinculación con decisiones pasadas y acabe reflejando el status quo de la organización.

Frecuentemente, recurrimos a una tercera parte que aporte un nuevo enfoque y cierta distancia sobre la historia y las relaciones de influencia establecidas. La llegada de un consultor externo puede percibirse como una amenaza por el equipo. Por ello es importante aclarar los objetivos del diagnóstico e implicar a las personas clave en la elaboración de las conclusiones.

El análisis comienza con una sesión de presentación a interesados. Y, uno de los primeros objetivos consiste, en obtener una definición consensuada sobre el alcance. Cuando iniciamos el diagnóstico para resolver preguntas o problemas concretos, el alcance está relativamente claro. Con proyectos más abiertos, puede necesitar algún refinamiento. En cualquier caso, es importante entender que no todos los interesados sabrán o querrán expresar abiertamente sus expectativas. Hay una labor muy importante de facilitación, comunicación y transparencia para hacer emerger posibles agendas ocultas.

El diagnóstico debe contar con un patrocinador a un nivel ejecutivo. De esta forma se asegurará la disponibilidad de los miembros clave del equipo (siempre ocupados) y el acceso a recursos restringidos de la compañía (código fuente, entorno de producción, etc.)

¿Cuál es el objetivo del diagnóstico?

Los sistemas basados en software son construcciones muy complejas, con multitud de interrelaciones y dependencias. Sería irrealista esperar que en una o dos semanas de trabajo (duración típica de un proyecto de diagnóstico) se alcancen conclusiones detalladas sobre un sistema que puede llevar años en evolución. El diagnóstico de la arquitectura de software debe centrarse en sus aspectos menos volátiles y el alcance del mismo de limitarse a uno o dos atributos prioritarios para el negocio. Este es el enfoque que recomendamos en nuestro servicio de Diagnóstico de Arquitectura de Software

La limitación en su duración controla el coste (interno y externo), facilita que nos enfoquemos en generar resultados concretos y adelanta el feedback.

Los componentes más estables de la arquitectura son los más viejos, los que han acumulado durante su vida más dependencias. También lo puedes ver al revés. Los componentes con más dependencias son los más difíciles de modificar (por los cambios en cascada que generan) y, por lo tanto, son los más estables. Sea como sea, están en en el centro de la red de dependencias de la arquitectura y, como tal, son los que tienen mayor peso en sus características. La lógica de negocio y, especialmente, la gestión de entidades maestras, suele jugar este rol central en la arquitectura.

Si nos centramos en aspectos que cambian con facilidad o que, de hecho, deben ser fácilmente modificables sin necesidad de consenso, generará resultados que se volverán rápidamente obsoletos. Un ejemplo son los patrones o frameworks empleados en la construcción de interfaces de usuario. Con esto no quiero minusvalorar, ni mucho menos, estos componentes tecnológicos. Pueden aportan un valor diferencial al servicio y, de hecho, suelen ser objeto de trabajos de diagnóstico específicos. Solo digo que no suelen ser objeto prioritario de un diagnóstico general.

La arquitectura representa las decisiones significativas de diseño que dan forma al sistema, donde significativas se mide por el coste de su modificación.
Grady Booch

Los requerimientos no funcionales suelen ser los marginados de los proyectos IT. Tanto en análisis como en documentación. Frecuentemente, nos centramos en los la funcionalidad del sistema y los atributos se limitan a una WishList del estilo “las interfaces de usuario deben ser fluidas y atractivas”. Sin embargo, los requerimientos no funcionales, alias, atributos cualitativos, alias, ilities (de usab-ility, deployab-ility, etc), son el principal motor de las decisiones sobre arquitectura.

A la hora de explorarlos puedes usar mapas. Las taxonomías de atributos cualitativos se pueden emplear como referencia y se encuentran fácilmente en Internet (aquí te dejo un ejemplo). Las hay especializadas en aspectos como seguridad o robustez y en ámbitos tecnológicos como operaciones y desarrollo. Algunos atributos muy habituales son:

Prestaciones, medida en tiempo de respuesta (mean response time) o capacidad para atender peticiones por segundo (throughput).
Resistencia, medida en tiempo de medio de recuperación ante errores (Mean Time to Restore).
Modificabilidad entendida como el tiempo necesario para llevar un nuevo servicio a producción (Change Lead Time), o la tasa de errores tras un cambio (Change Fail Percentage).

¿Cuál es el objetivo del diagnóstico?

El objeto del diagnóstico de la arquitectura de software será identificar los atributos cualitativos de la arquitectura que tiene mayor impacto en el negocio y las decisiones de técnicas que los soportan. Por ejemplo, en organizaciones enfocadas a mercado, la capacidad de reaccionar rápidamente es fundamental. Vemos que la modificabilidad es un atributo clave y el diagnóstico se centrará en los aspectos técnicos que lo facilitan: desacoplamiento, arquitecturas de servicios, test automáticos, independencia de despliegue, etc. Una empresa centrada a la gestión de maestros priorizará la veracidad y coherencia, o el cumplimiento de estándares. Más en general, los atributos de Testabilidad y Facilidad de Despliegue son objeto de especial atención en las organizaciones DevOps y se han demostrado claramente correlacionados con el éxito de las compañías basadas en uso intensivo de IT.

Como ves, las opciones son ilimitadas. Si te limitas a preguntar, todos queremos que nuestros sistemas tengan todas las -ilities: seguro, modificable, interoperable, usable, … Como responsable del análisis tienes que limitar su alcance. Para ello, hay que concretar el significado de los atributos con definiciones claras (implementables y mensurables). Poniendo sobre la mesa la relación coste-beneficio de su análisis. Debe realizar un esfuerzo de facilitación para alcanzar un consenso sobre uno o dos atributos claves para la organización. De otra forma, se corre el riesgo de que la diagnóstico se quede en la superficie y no llegue a conclusiones accionables.

¿Qué resultados genera el Diagnóstico?

El principal objetivo del diagnóstico de la arquitectura de software es generar conocimiento sobre la arquitectura real del sistema y su adecuación a los objetivos de la compañía. Las conclusiones se deben reflejar en documentación que los equipos puedan mantener tras la finalización del proyecto. Aunque su contenido puede variar en función de los objetivos concretos del diagnóstico, es habitual que se genere un informe recogiendo los siguientes puntos:

Vista de la arquitectura de software: Modelo del estado actual de la arquitectura.
Puntos sensibles, Riesgos y Fortalezas del sistema. Elementos de la arquitectura que hay que vigilar para mantener los niveles de calidad; decisiones arquitectónicas que no están claramente definidas o que no soportan convenientemente los atributos de calidad en los niveles esperados y; finalmente diseños que se demuestran como sólidos activos de la solución.
Acciones Recomendadas. Lista priorizada de oportunidades que pueda llevarse a un plan de acción o roadmap para su desarrollo.

Además de la documentación detallada para los equipos, es común crear un resumen ejecutivo con las conclusiones más relevantes.

En futuros artículos te hablaré sobre ámbitos en la Arquitectura de Sistemas, formas de visualizar la arquitectura y metodologías para su diagnóstico Diagnóstico de Arquitectura.

¿Es la deuda técnica un síntoma de mala gestión?

Cuando se habla de deuda técnica, a menudo se achaca a algo por lo que los equipos de desarrollo son responsables. Nada más lejos de la realidad, la deuda técnica es un reflejo de una falta de madurez en la gestión empresarial. El motivo es que, a pesar de que los equipos puedan entregar software que no esté terminado, una organización madura invitará a esos equipos a subir el nivel de calidad del producto Sprint a Sprint.

¿Qué es la deuda técnica?

La deuda técnica es el equivalente en software a no haber ahorrado para ir de vacaciones y pedir un préstamo de alto interés para irse a Cuba, teniendo dudas sobre si tendremos trabajo a la vuelta. Las consecuencias son desastrosas y, a pesar de lo evidente que pueda parecer, es un aspecto común de las organizaciones con las que trabajo.

La deuda técnica es la suma de todas las cosas que no hemos hecho anteriormente y que había que haber hecho para tener un software decente y de calidad. El caso más típico de deuda técnica es cuando alguien dice: – Bueno, lo dejamos así, que funciona, y ya lo resolvemos cuando tengamos tiempo. ¡Error! No hay nadie que haya dicho nunca: Ahora que tengo tiempo, voy a a resolver todas los arreglos de mi código.

Solo existen dos cosas que sobrevivirán un ataque nuclear: Las cucarachas y ese apaño que le hiciste al código para salir del paso

Además, existe un segundo problema: ¿Durante cuanto tiempo crees que podrás entender lo que hiciste sin tardar más tiempo que el que tardaste haciéndolo? Una de las características del buen código no es solamente que funcione, sino que sea legible y mantenible. Y eso muchas veces excluye también al código brillante. Todos hemos tenido ataques de genialidad en los que hemos hecho algo que funcionaba pero no entendíamos muy bien por qué.

Este es quizás el mayor coste de la deuda técnica. Conforme va pasando el tiempo, el conocimiento sobre el código se desvanece y hay que empezar de nuevo. Cuando la complejidad es muy alta, el “pago” de deuda será aún mayor, por el simple motivo de que puede llevar días o semanas entender qué ocurre y que se quiere hacer.

La deuda técnica es un riesgo que hay que gestionar

Desde el punto de vista de gestión y dirección de la organización, la deuda técnica, ya sea por estar implícita en el código, por ser parte de la infraestructura o del despliegue de la aplicación es cómo una deuda en el banco a un alto tipo de interés.

Cuanto más tiempo se tarde en gestionarla, más intereses se pagaran. El problema añadido es que muchos equipos eligen trabajar rápido al principio de un proyecto a costa de generar deuda técnica, lo cual además crea una falsa sensación de velocidad que más adelanta se vuelve en contra.

¿Que el equipo no es capaz de entregar? Pero si ahora hay mucha más gente y al principio desarrollaban software muy rápido. Hay algo que tenéis que estar haciendo mal

Muchas organizaciones ignoran la deuda técnica a la hora de hacer predicciones. Simplemente cierran los ojos y asumen que si en el pasado han sido capaces de salir adelante, esta vez no tiene por qué ser diferente. El problema es que efectivamente tienen razón hasta que un día están equivocados. Es una bomba a punto de explotar que nadie quiere tener en las manos.

Resolver la deuda técnica requiere de un esfuerzo conjunto

Un plan para resolver deuda técnica requiere de un esfuerzo coordinado a cuatro bandas.

El equipo de desarrollo tiene que trabajar con los responsables técnicos u otros equipos dibujando una hoja de ruta para resolver los problemas principales. No tiene que ser extremadamente detallado pero tiene que dejar claro cual es la dirección a seguir. Muchos de mis equipos han usado un poster que refleja su arquitectura actual y un poster que refleja la arquitectura deseada y conforme se iban implementando piezas, se hacían green checks, lo que ayudaba a no perderse.

El Product Owner debe entender que resolver los problemas de hoy y de mañana supone entregar software a un menor ritmo y cuando este se entregue, que siga unos estándares de calidad. El Product Owner es quien maneja el presupuesto en Scrum y quien puede hacer esto realidad. Para ello ha de trabajar con los Stakeholders.

Los Stakeholders deben entender, mediante el trabajo con el Product Owner y el equipo de Desarrollo, que una inversión en resolver la deuda técnica es precisamente eso, una inversión que facilitará las cosas a futuro y les permitirá reducir todo el riesgo asociado al proyecto.

La velocidad en Scrum no se mide en Story points, sino en software terminado y entregado

Eso no significa que el equipo de desarrollo se ponga exclusivamente a resolver deuda técnica y no haga nada más, nada más lejos de la realidad. El objetivo de Scrum es entregar, así que como mínimo el equipo deberá de seguir entregando una pequeña pieza de funcionalidad terminada, que mostrar en la sprint review. En ese momento, y después de varios sprints el equipo tendrá una verdadera visión de cual es su velocidad real.

Algunas herramientas que pueden ayudar

Integrar siempre, como mínimo, una vez por Sprint. La deuda técnica se acumula en equipos que producen software que no es integrado y entregado al menos una vez por Sprint. Algunos de estos equipos intentan evitar esto porque el trabajo de integración es muy grande, lo cual es un Oxímoron, dado que el trabajo será mucho más grande cuando llegue la hora de integrarlo de verdad, y la deuda técnica se habrá apoderados de un código que más que probablemente haya que borrar y volver a hacer.

Usar herramientas como SonarQube® para medir los posibles problemas del código. Estas herramientas miden la calidad del código desde distintos puntos de vista: facilidad de lectura, complejidad ciclomática, complejidad npath, así como hacer transparente que se respetan unas normas comunes a la hora de escribir código.

Usar Integración Continua como Jenkins o Travis y sólo desplegar código que esté integrado y medido. En ambos, se pueden configurar puertas que permitan que sólo se despliegue aquellas features que realmente cumplen con los estándares que se esperan.

Per último, a nivel organización, hablar y medir cual es el riesgo acumulado durante todo el tiempo anterior. No hablar de ello no ayudará a mejorar la situación. Herramientas como SonarQube ofrecen una idea estimada de cual es el coste en días de resolver la deuda técnica de la organización. Ponerlo encima de la mesa y discutirlo cómo se discutiría cualquier otro asunto de riesgo que afecta a la organización es señal de madurez empresarial.

El sistema de tres pasos para pagar la deuda técnica

Dejar de crear nueva deuda técnica.
Pagar una pequeña parte de la deuda cada Sprint.
Repetir el paso 2.

Empezar desde cero NO es una solución

¿Qué ocurre cuando alguien propone empezar todo desde cero solamente por la dimensión de la deuda técnica? Ese comportamiento es muy poco profesional. A pesar de que en un momento dado, empezar de cero pueda parecer la opción más viable, es un espejismo, ya que no tiene en cuenta muchas de las cosas “buenas” que tiene ahora mismo nuestro producto. Tirarlo todo a la basura para volverlo a hacer es tan poco profesional cómo dejar que la deuda técnica se acumule durante años.

10 prácticas técnicas en equipos Scrum, Kanban y XP

Uno de los temas más controvertidos en torno a marcos como SCRUM es el de las prácticas técnicas. En este artículo recorro el camino desde la ausencia total de prácticas técnicas hasta adquirir la capacidad de hacer Continuous Delivery (CD). No es un camino fácil, pero tampoco es opcional. Cualquier equipo o empresa que quiera construir un software excelente, debe plantearse seriamente implementar esas prácticas.

Una de los tópicos más repetidos cuando trabajo con clientes es: “No puedes esperar los beneficios de hacer las cosas fáciles (las ceremonias de Scrum) si no estás dispuesto a invertir en las difíciles (las prácticas técnicas)”. Scrum evita deliberadamente recomendar prácticas técnicas, ya que estas deben ser dejadas a elección de los equipos. Un buen Scrum Master sabrá introducir una curiosidad en todas las que pongo a continuación.

1. Refactorización

Refactorizar es la A del alfabeto de un desarrollador. Supone escribir código que funcione y luego perfeccionarlo y modelarlo hasta que alcanza una cota de perfección aceptable, a la vez que fácil de leer y mantener por otro desarrollador. Así, intentar preparar de antemano la solución perfecta es muy difícil, aunque seas un programador brillante. Perfeccionar haciendo maravillas con el lenguaje supone que la persona que venga después a mantener el código lo va a pasar mal para entender lo que hace el código.

Una de las implicaciones de esta práctica es encontrar por un lado a desarrolladores que sean lo suficientemente humildes como para aceptar que su código puede ser refactorizado y empresas que tengan suficientemente claro que refactorizar no es un gasto sino una inversión de cara al futuro. Y por si a alguien le quedan dudas, sí, el 100% del código que escribimos puede ser mejorado de múltiples maneras.

Tres principios para grabarse a fuego trabajando en un equipo ágil que aspire a construir software de calidad: KISS, SOLID y DRY

2. Control de versiones y Branching

A pesar de tener varias décadas ya, hay algunas empresas que todavía no entienden los beneficios de un sistema de Control de Versiones. Incluso cuando uno trabaja solo, hacer commits frecuentes y tener una estrategia de branches para implementar cada feature hace mucho más sencillo que la construcción del software sea lo suficientemente sólida como para no tener que volver atrás cada poco tiempo, además de proporcionar un histórico muy necesario para saber donde lo has hecho mal.

Trabajando en un equipo esto no es que sea positivo, es que es totalmente necesario. Saber quien hizo que y que pasó cuando es, literalmente, ahorro de dinero cada hora. Y el que tenga dudas, es que nunca se ha tenido que sentar durante horas a intentar integrar el trabajo de sólo tres personas para ver que estaba fallando, dejando el código plagado de parches y ñapas.

Actualmente el sistema de control de versiones más popular es Git, siendo Github y Gitlab las forjas más populares para el mismo. Aprender a usarlo no lleva más de un par de horas y bien usado es una revolución para cualquier organización.

3. Métricas de calidad del código

Saber en cada momento como es la calidad del código que escribes es necesario cuando trabajas haciendo software empresarial. Mi opinión es que también lo es en una startup cochina.

En este caso no hablamos de lo que hace el código, sino de su estilo. Mantener un código ordenado, bien comentado, con funciones cuya complejidad ciclomática sea lo suficientemente pequeña como para que cualquier programador pueda comprenderla, con métodos bien aislados y que asegure que es fácil de mantener, es algo fundamental cuando el planteamiento es el de una carrera de fondo y no el de terminar el próximo sprint.

Aquí he visto de todo y en distintos sabores. Desde empresas que no permitían más de cuatro líneas por método y no más de 74 caracteres por línea hasta la que preferían métodos con una complejidad ciclomática de 30 porque ellos lo valían y “no vamos a cambiarlo todo ahora”.

SonarQube es una herramienta que se encargará de analizar el código y decirte donde estás fallando, qué puedes mejorar y te dará una estimación de la deuda técnica en número de días. Una de las grandes ventajas de Sonar es que te permite analizar varios proyectos a la vez y darte unas visualizaciones muy bonitas del tamaño de cada proyecto, cobertura de tests unitarios, etc…

4. Test unitarios

El testing ha sido siempre objeto de controversia, pero en los últimos años hay ya pocas personas que aseguren que un código sin testear es un buen código (aunque algunas hay, que las han visto estos ojitos que se han de comer los gusanos). El objeto de hacer testing es triple: en primer lugar, asegurarse de que el código que escribimos efectivamente haga lo que dice que va a hacer. En segundo lugar, proporcionar un andamiaje consistente que hará que, en el futuro cuando refactoricemos el código, nuestro nuevo código sigue haciendo exactamente lo mismo que el antiguo y por último, que cuando estemos tocando una parte de la aplicación, no rompamos en otro sitio sin darnos cuenta.

A pesar de ello, podría decir que todavía encuentro un gran porcentaje de los proyectos que no tienen ni una línea de código referida a los tests. Las excusas son diversas, siendo la más divertida para mi que “hay que contratar testers para eso”. Mi respuesta es, con distintas variaciones, la que sigue: “¿Cuando tu vas al baño, te limpias tu el culo o contratas a alguien para que lo haga?”

Quizás para hacer test de integración si pueda ser razonable tener a un especialista en automatización (ojo, creo que los programadores deberían ser responsables también de esto), pero los tests unitarios deben ser, sin duda alguna, responsabilidad de los programadores.

Sobre la cobertura de tests, el problema es el siguiente: puedes tener una alta cobertura pero unos tests malísimos (que testen varios métodos, por ejemplo) o unos pocos tests que den en el clavo. Como regla no escrita, parece que intentar conseguir una cobertura del 80% debe ser razonable.

5. Integración continua

Llegamos a una herramienta tan básica y que a la vez, muy pocos equipos (comparativamente hablando) han visto. Integración continua, un concepto tan desconocido como sorprendente. Es simple, si tu aplicación tiene una cobertura de tests suficiente, puedes tener un servidor que se encargue de detectar cualquier cambio en el control de versiones y encargarse de ejecutar todos los tests: unitarios, de servicios y de integración. Es como un mono que se encarga de asegurar que los cambios en el código no rompen la aplicación, porque la ejecuta de arriba a abajo (dependiendo de la cobertura de tests) cada vez que hay un cambio.

A pesar del más que evidente ahorro y capacidad de reacción ante cualquier pequeño cambio respecto de la aplicación, muchos equipos ágiles todavía no ven los beneficios de tener un servidor como Jenkins, Hudson, CruiseControl o Bamboo.

Muchas veces el problema no viene por no ver el evidente ahorro, sino por no querer abordar la evidente deuda técnica asociada a intentar poner en marcha este servidor de integración continua. Porque una cosa es instalarlo y otra cosa es usarlo correctamente. Para lo segundo, es necesario seguir como mínimo tres de los cuatro pasos anteriores, y eso supone una inversión en tiempo y en dinero que no muchos están dispuestos a asumir. Una triste realidad que te conduce inexorablemente a un momento donde tu producto será tan caótico que no habrá solución posible.

6. Test de la capa de servicios

Si estás utilizando una arquitectura N-tier en tu aplicación, que es una de las más habituales, lo más probable es que tu aplicación tenga una capa de servicios que actúe como API para el hacer de intermediario entre la persistencia de datos y la presentación u otras capas.

El problema de hacer testing unitario (métodos) y test de integración (presentación) es que puede ocurrir que algunos de los servicios dejen de funcionar correctamente y no seas capaz de detectarlo correctamente. El ejemplo puede ser un método que, a pesar de tener test unitarios, devuelve un valor aceptado por estos pero que hacen que otro método o función actúe de manera errática. Fitnesse es una tabla de decisión que prueba distintos inputs y espera diversos outputs en la capa de servicios, cubriendo el hueco existente entre los tests de integración y los tests unitarios.

7. Test de integración

Y llegamos al final de la santísima Trinidad del testing ágil: el testing de integración o de la capa de presentación. Existen muchos frameworks para automatizar este trabajo, y caso todos funcionan sobre Selenium. Es el caso de Behat, IntelliJ o Cucumber, por mencionar tres de los más famosos.

El testing de integración, que también puede (y debe) ser automatizado con un servidor de integración continua, asegura que la aplicación responde de la manera deseada en todos los casos. Sorprendentemente, hay muchas empresas que prefieren contratar a 10 o 12 personas para hacer testing manual de lo mismo, cuando podrían automatizar prácticamente el 80% de ese trabajo. No estoy en contra de los test exploratorios o manuales, estoy a favor de automatizar un trabajo que puede realizar una máquina en la mayoría de los casos y que puede proveer de un importante feedback al desarrollador en apenas unos minutos y no en horas, días o incluso semanas.

8. Test de regresión

Los test de regresión no son un tipo concreto de tests sino una suite que implementa test para probar cualquier bug crítico o importante que se haya detectado en la aplicación antes. Así, puede ser que en nuestro código haya un bug, que este sea detectado por una persona haciendo test de exploración y que se arregle pero no se vuelva a testear. Tenemos un cóctel perfecto para que, en poco tiempo ese bug, vuelva a reaparecer. Es por ello que en equipos ágiles se construye una suite de regresión que se ejecuta en el servidor de integración continua para agitar que fallos que sucedieron en el pasado vuelvan a suceder.

9. Continuous deployment

Nos acercamos al final y completamos el ciclo de Continuous Delivery con una de las prácticas más sencillas, siempre que se hayan seguido las anteriores: despliegue continuado. Una vez que el servidor de integración continua ha detectado un cambio en el master del control de versiones, ha ejecutado los test unitarios y pasan correctamente, ha hecho lo propio con los test de servicio y la presentación, lo único que nos queda es, ahora que sabemos que nuestro producto está correcto, poder desplegar de forma automatizada al servidor de preproducción y, tras ver que no hay ningún problema, cada dos o tres sprints y, siempre que haya nuevas features terminadas, desplegar a producción de forma automatizada.

10. Documentación

Por último, todo esto debe ir soportado por la documentación. Lo positivo es que actualizar la documentación no debe suponer más de 30 o 40 minutos con herramientas que te permiten elaborar una ayuda explorando el código, teniendo las releases notes extraídas de una herramienta como JIRA y utilizando los tests como base para explicarlas.

Conclusiones

A pesar del cada vez más creciente hype en torno a las metodologías ágiles, todavía hay mucha candidez en torno a las prácticas técnicas a usar en entornos ágiles. A pesar de que puede parecer una gran inversión en tiempo y en dinero, el retorno es muy alto cuando puedes permitirte hacer releases continuas cada dos semanas en lugar de cada tres meses, donde el 80% del tiempo se pasa en arreglar los problemas que el nuevo código ha provocado. Aquí es donde se pueden empezar a apreciar beneficios como la hiperproductividad del que muchos gurís hablan. Por último, empiezo igual que al principio. Lo fácil es hacer retrospectivas, daily stand-ups y planning meetings. Éstos pondrán en evidencia la necesidad de implementar algunas o todas estas prácticas, y mientras no se haga, es imposible esperar resultados distintos.