Requisitos, control de versiones, pruebas, entrega y el recorrido de una solicitud

De una idea a un requisito

El software empieza con una necesidad: un restaurante quiere recibir pedidos en línea, un hospital quiere que los pacientes reserven sus citas ellos mismos. Convertir esa necesidad en algo que un equipo pueda construir es el trabajo de los requisitos. Algunos requisitos describen qué debe hacer el sistema ("un cliente puede pagar con tarjeta"); otros describen con qué calidad debe hacerlo ("el pago se completa en menos de dos segundos para el 95% de los clientes"). El Capítulo 2 muestra que el segundo tipo, los atributos de calidad, impulsa la mayoría de las decisiones arquitectónicas.

Muchos equipos recogen las necesidades funcionales como historias de usuario: descripciones breves escritas desde el punto de vista del usuario. Kent Beck las introdujo en Extreme Programming a finales de la década de 1990, y un equipo de la empresa londinense Connextra ideó en 2001 la plantilla que hoy usa la mayoría:

As a hungry customer,
I want to reorder a meal I have ordered before,
so that I can eat sooner without searching the menu again.

Acceptance criteria
- My last 10 orders appear on the home screen.
- Tapping "Reorder" fills the basket with the same items.
- Items that are no longer available are flagged, not silently dropped.

Una historia es deliberadamente pequeña e incompleta. Ron Jeffries la describió como una tarjeta, una conversación y una confirmación: la tarjeta es un recordatorio, los detalles se concretan conversando entre quienes quieren la funcionalidad y quienes la construyen, y los criterios de aceptación confirman cuándo está terminada. Los profesionales no se ponen de acuerdo sobre cuánto debe escribirse por adelantado. Los equipos de sectores regulados, como los dispositivos médicos y la aviación, deben mantener requisitos formales y trazables; los equipos de producto suelen preferir historias más ligeras que se refinan justo antes de empezar el trabajo. Ambas opciones son legítimas en su contexto.

Control de versiones con Git

El código fuente es el documento compartido más valioso del equipo, y muchas personas lo modifican cada día. El control de versiones registra cada cambio, quién lo hizo y por qué, permite trabajar en paralelo sin sobrescribir el trabajo de otros y hace posible restaurar cualquier estado anterior. Hoy casi todos los equipos usan Git, creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux, normalmente junto con un servicio de alojamiento como GitHub, GitLab o Bitbucket.

Unas pocas ideas cubren la mayor parte del uso diario. Un commit es una instantánea guardada de un conjunto de cambios, con un mensaje que lo explica ("Add tip button to checkout"). Una rama es una línea de trabajo separada: un desarrollador crea una rama a partir de main, hace commits en ella sin molestar a nadie y, al terminar, fusiona la rama de vuelta (merge), combinando los dos historiales. Si dos personas cambiaron las mismas líneas, Git informa de un conflicto de fusión que una persona debe resolver.

En los servicios de alojamiento, la fusión suele pasar por un pull request (GitLab lo llama merge request): una página web que muestra el cambio propuesto, donde se ejecutan comprobaciones automáticas y los colegas hacen la revisión de código, leyendo el cambio, haciendo preguntas y sugiriendo mejoras antes de aprobarlo. La revisión detecta defectos, pero sus mayores beneficios son difundir el conocimiento (al menos dos personas entienden cada cambio) y mantener la coherencia del diseño. Los arquitectos suelen participar en las revisiones de cambios que afectan a la estructura o a las interfaces.

git switch -c feature/tip-button     # create a branch and move onto it
# ... edit files ...
git add checkout.py test_checkout.py
git commit -m "Add tip button to checkout"
git push -u origin feature/tip-button  # upload; then open a pull request
# after review and green checks, the branch is merged into main

Los equipos difieren en cómo usan las ramas. Algunos mantienen ramas de larga duración por funcionalidad o por versión; otros practican el desarrollo basado en trunk, fusionando cambios pequeños en main al menos una vez al día y ocultando las funcionalidades sin terminar tras interruptores llamados feature flags. La investigación del programa DORA asocia las ramas de corta duración con un mejor rendimiento de entrega, pero la elección correcta también depende de cómo lanza el equipo sus versiones.

Pruebas: la pirámide

Cada cambio corre el riesgo de romper algo que antes funcionaba, lo que se llama una regresión. Las pruebas automáticas son programas que comprueban otros programas, así que pueden ejecutarse con cada cambio en minutos en lugar de a cargo de personas durante días. Se organizan en capas. Una prueba unitaria comprueba una pieza pequeña, como una función, de forma aislada, y se ejecuta en milisegundos. Una prueba de integración comprueba que las partes funcionan juntas: el código de pedidos con una base de datos real, o la tienda con el entorno de pruebas de un proveedor de pagos. Una prueba de extremo a extremo maneja el sistema completo como lo haría un usuario, por ejemplo tocando la app desde el menú hasta la confirmación del pedido.

La pirámide de pruebas de Mike Cohn, publicada en su libro de 2009 Succeeding with Agile, sugiere las proporciones: muchas pruebas unitarias, menos pruebas de integración y pocas pruebas de extremo a extremo. Las capas superiores son más realistas, pero más lentas, más caras de mantener y más propensas a fallos intermitentes (flaky), que van y vienen por motivos ajenos al cambio. Algunos profesionales defienden otra forma, por ejemplo más pruebas de integración en sistemas que son sobre todo pegamento entre servicios; el principio en el que todos coinciden es detectar la mayoría de los problemas con pruebas rápidas, fiables y focalizadas.

def delivery_fee(basket_total, distance_km):
    if basket_total >= 25:
        return 0.0                      # free delivery on larger orders
    return round(1.50 + 0.40 * distance_km, 2)

def test_free_delivery_over_threshold():
    assert delivery_fee(30.00, 5) == 0.0

def test_fee_grows_with_distance():
    assert delivery_fee(10.00, 5) == 3.50

Entornos: de desarrollo a producción

El código pasa por varios entornos en su camino hacia los clientes, cada uno una copia separada del sistema con sus propios servidores, datos y configuración. El objetivo es encontrar los problemas donde son baratos e inofensivos, antes de que lleguen a producción, el entorno real del que dependen los usuarios reales.

Cuanto más se diferencian los entornos de producción, más problemas se cuelan: una base de datos de pruebas con cien filas no revelará el índice que falta y que hace que una consulta tarde cuarenta segundos contra diez millones. Mantener los entornos parecidos es más fácil cuando se construyen a partir de las mismas imágenes de contenedor y la misma configuración automatizada mediante scripts, un tema de la infraestructura como código.

Integración, entrega y despliegue continuos

La integración continua (CI) es la práctica de fusionar el trabajo de todos en la línea principal compartida con frecuencia, al menos a diario, con una compilación y una ejecución de pruebas automatizadas que comprueban cada cambio. Surgió de Extreme Programming en la década de 1990. Su sentido es que los problemas de integración se detectan en minutos, mientras el cambio sigue fresco en la mente de su autor, en lugar de en una dolorosa "fase de integración" semanas después. Un equipo que practica CI trata una compilación fallida como una emergencia: arreglarla va antes que cualquier trabajo nuevo.

La entrega continua (CD) amplía la CI para que el software esté siempre listo para lanzarse: cada cambio que supera el pipeline podría ponerse en producción pulsando un botón, y lanzar se convierte en una decisión de negocio rutinaria en lugar de un acontecimiento arriesgado. Jez Humble y David Farley expusieron este enfoque en su libro de 2010 Continuous Delivery. El despliegue continuo va un paso más allá y lanza automáticamente cada cambio que supera las comprobaciones, sin aprobación humana; los equipos que lo hacen pueden desplegar muchas veces al día.

La automatización que lleva un cambio desde el commit hasta producción es un pipeline. Como cada paso está automatizado y es idéntico cada vez, los lanzamientos dejan de depender de que una persona recuerde una lista de comprobación a medianoche.

Formas de trabajar: cascada, Scrum y Kanban

Los equipos también eligen cómo organizar el propio trabajo. En un enfoque secuencial, a menudo llamado en cascada, el proyecto avanza por fases en orden: requisitos, diseño, implementación, pruebas, despliegue. Cada fase termina antes de que empiece la siguiente. El nombre suele atribuirse a un artículo de Winston Royce de 1970, aunque Royce no usó esa palabra y de hecho advirtió que pasar una sola vez por las fases era arriesgado. Los planes secuenciales siguen siendo adecuados para trabajos en los que los requisitos son fijos y los cambios son muy costosos, como algunos proyectos regulados o que dependen del hardware. Su debilidad para la mayor parte del software es que los usuarios no ven nada hasta muy tarde, así que los malentendidos salen a la luz cuando son más caros de corregir.

Los enfoques ágiles, bautizados en el Manifiesto Ágil de 2001, entregan software que funciona en ciclos cortos y ajustan los planes a medida que aprenden. Scrum es el marco de trabajo más usado: un equipo pequeño trabaja en ciclos fijos llamados sprints, de un mes o menos, cada uno de los cuales empieza con una planificación y termina con una revisión del trabajo y una retrospectiva sobre cómo ha trabajado el equipo. La Guía de Scrum de 2020 define tres responsabilidades: el Product Owner (que decide qué es lo más valioso), el Scrum Master (que ayuda al equipo a usar Scrum con eficacia) y los Developers (que hacen el trabajo). Kanban, adaptado al software a partir del sistema de producción de Toyota, no tiene ciclos fijos: los elementos de trabajo fluyen por un tablero visible (por hacer, en curso, revisión, hecho), y el equipo limita cuántos elementos puede haber en curso a la vez para terminar el trabajo antes de empezar más.

Ninguno de ellos es adecuado para todos los equipos, y muchas organizaciones los combinan: Scrum para los equipos de producto, Kanban para soporte y operaciones, un plan más secuencial en torno a un plazo regulatorio fijo. Llamar "ágil" a un proceso no lo convierte en ágil; lo que importa es si el software que funciona llega a usuarios reales con la frecuencia suficiente para aprender de ellos.

DevOps: la responsabilidad de un solo equipo, del código al cliente

Tradicionalmente, los desarrolladores escribían el software y un equipo de operaciones separado lo hacía funcionar, con incentivos opuestos: a los desarrolladores se les recompensaba por el cambio y a operaciones por la estabilidad. DevOps es el movimiento, bautizado en la primera conferencia DevOpsDays de Gante en 2009, que une a ambos. Es ante todo una cultura de responsabilidad compartida ("you build it, you run it": quien lo construye, lo opera), apoyada en prácticas como CI/CD, la infraestructura como código, la monitorización y la revisión sin culpables de los incidentes. No es un puesto de trabajo ni una herramienta, aunque ambas cosas se venden con ese nombre. El programa de investigación DORA es conocido sobre todo por medir el rendimiento de entrega con cuatro métricas clave: con qué frecuencia despliega un equipo, cuánto tarda un cambio en llegar a producción, con qué frecuencia fallan los cambios y con qué rapidez se restablece el servicio tras un fallo.

Ejemplo práctico: el recorrido de un toque

Todo lo visto en este capítulo se une en un solo momento. Un cliente ha llenado un carrito en una app de reparto de comida y toca Hacer pedido. En un segundo o dos la pantalla dice "Pedido confirmado", y veinte minutos después el teléfono vibra: "Tu repartidor está en camino". Esto es lo que ocurre, paso a paso, con el concepto que hay detrás de cada paso y dónde se presentó.

Por qué esto importa para la arquitectura

El recorrido de un toque usa una docena de componentes, tres organizaciones y comunicación tanto síncrona como asíncrona, y aun así hubo que diseñarlo: alguien decidió que el pago es síncrono y las notificaciones no, que los pedidos residen en una base de datos relacional, que el servicio se ejecuta en contenedores repartidos en dos zonas, que el proveedor de pagos queda aislado detrás de un único módulo. Decidir cómo se organizan estas partes, qué cualidades logra cada organización y cuánto cuesta, y dejar constancia de por qué, es arquitectura de software. La forma en que se construye el software también importa a la arquitectura: una arquitectura que no se puede probar por partes, o que no se puede lanzar sin coordinar a diez equipos, ralentiza cada cambio. El Capítulo 1 comienza con qué es la arquitectura de software.