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.

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.