22. Ejemplo práctico de aplicación XP

Para consolidar todos los conceptos de Extreme Programming (XP), nada mejor que un ejemplo práctico. A continuación, simularemos el inicio de un proyecto siguiendo las prácticas y el flujo de trabajo de XP, desde la planificación hasta la codificación y la entrega de valor.

22.1. Proyecto: Desarrollo de una API para un Blog

Imaginemos un equipo pequeño de tres desarrolladores (Ana, Carlos y Sofía), un Coach (David) y un Cliente (Laura). El proyecto consiste en crear una API REST para un sistema de blog. El equipo decide adoptar XP con iteraciones de una semana.

El objetivo de la primera semana es tener los endpoints más básicos para leer artículos, sentando las bases de la arquitectura y el proceso de trabajo.

22.2. Historias de Usuario y Planificación Inicial

El lunes por la mañana, el equipo se reúne con Laura para el Planning Game. Laura llega con un conjunto de tarjetas, cada una con una historia de usuario que describe una necesidad del negocio. Para la primera iteración, las más importantes son:

  • HU1: "Como lector, quiero obtener una lista de todos los artículos publicados para ver qué hay de nuevo."
  • HU2: "Como lector, quiero obtener los detalles de un artículo específico por su ID para poder leerlo."
  • HU3: "Como lector, si pido un artículo con un ID que no existe, quiero recibir un error claro para saber que me equivoqué."

El equipo discute las historias con Laura para aclarar dudas. Luego, estiman el esfuerzo de cada una. Acuerdan que HU1 y HU2 son de tamaño similar, y HU3 es un poco más pequeña. Deciden que las tres historias son factibles para la primera iteración de una semana. El plan está listo.

22.3. Aplicación de TDD y Pair Programming

El mismo lunes, Ana y Carlos se sientan juntos para empezar a trabajar en la primera historia (HU1) usando Pair Programming. Deciden usar Python con el micro-framework Flask. Su primera tarea es crear un endpoint `GET /api/articles`.

Ciclo 1: El endpoint devuelve una lista vacía (Red → Green → Refactor)

1. Red (Escribir una prueba que falla): Antes de escribir una sola línea de la aplicación, crean un archivo de prueba `test_app.py`. Usando `pytest`, escriben una prueba que espera que al llamar a `/api/articles`, la respuesta sea exitosa (código 200) y el cuerpo sea una lista JSON vacía.


# test_app.py
import pytest
from app import create_app

@pytest.fixture
def client():
    app = create_app()
    app.config['TESTING'] = True
    with app.test_client() as client:
        yield client

def test_get_articles_returns_empty_list(client):
    """Prueba que GET /api/articles devuelve una lista vacía al inicio."""
    response = client.get('/api/articles')
    assert response.status_code == 200
    assert response.json == []

Ejecutan la prueba. Falla con un error 404 porque la ruta `/api/articles` no existe. ¡Están en rojo!

2. Green (Escribir el código mínimo para que pase): Ahora, en `app.py`, escriben el código más simple posible para que la prueba pase.


# app.py
from flask import Flask, jsonify

def create_app():
    app = Flask(__name__)

    @app.route('/api/articles', methods=['GET'])
    def get_articles():
        return jsonify([])

    return app

Vuelven a ejecutar las pruebas. ¡Ahora pasan! Están en verde.

3. Refactor (Refactorizar y mejorar): El código es muy simple, pero deciden que los datos de los artículos deberían venir de una capa de "servicio" en lugar de estar directamente en la ruta. Crean una estructura inicial para ello, aunque por ahora solo devuelva datos falsos.

Continuación del Proceso

A lo largo de la semana, el equipo continúa este ciclo:

  • Ana y Carlos siguen con la HU1, añadiendo una prueba para que la API devuelva un artículo de prueba. Hacen que la prueba pase y refactorizan.
  • Mientras tanto, Sofía y David (el Coach) hacen pair programming en la HU2 (obtener un artículo por ID), aplicando TDD de la misma manera.
  • A mitad de la semana, Carlos y Sofía intercambian parejas. Carlos ahora trabaja con David y Sofía con Ana. Esto asegura la propiedad colectiva del código y distribuye el conocimiento.
  • Cada vez que una pequeña pieza de funcionalidad está lista, la integran en la rama principal. El servidor de Integración Continua ejecuta todas las pruebas automáticamente, asegurando que nada se haya roto.

22.4. Resultados y Mejoras Obtenidas

El viernes por la tarde, el equipo realiza la revisión de la iteración con Laura, la cliente. Le muestran la API funcionando en un entorno de pruebas.

  • Laura puede hacer una petición a `GET /api/articles` y ve una lista con un artículo de ejemplo.
  • Puede pedir `GET /api/articles/1` y obtiene los detalles de ese artículo.
  • Si pide `GET /api/articles/99`, recibe un error 404 con un mensaje claro, tal como se especificó en la HU3.

Resultados de la primera semana:

  • Software funcional: Se ha entregado un incremento de producto funcional y de alta calidad que cumple con las historias de usuario acordadas.
  • Alta calidad del código: Gracias a TDD y a la refactorización constante, el código está limpio, bien estructurado y tiene una cobertura de pruebas cercana al 100%.
  • Cliente satisfecho: Laura está contenta porque ha visto un progreso tangible en solo una semana y ha validado que el equipo está construyendo lo que ella necesita.
  • Equipo motivado: El equipo termina la semana con un ritmo sostenible, sin horas extra, y con un fuerte sentido de logro y colaboración.

En la retrospectiva de la iteración, el equipo discute qué fue bien y qué se puede mejorar. Se dan cuenta de que su manejo de errores puede ser más consistente. Deciden crear una historia de usuario técnica para la siguiente iteración con el fin de estandarizar los formatos de respuesta de error en toda la API. Así, el ciclo de mejora continua sigue adelante.