Lección 7: Extreme Programming (XP) y Desarrollo Guiado por Pruebas (TDD)
Extreme Programming (XP) es uno de los métodos ágiles más conocidos y completos, creado por Kent Beck en 1996, incluso antes de que se acuñara el término 'Ágil'. En esta lección conocemos los cuatro valores centrales de XP (Simplicidad, Comunicación, Retroalimentación y Coraje) y las 12 prácticas en
En resumen: XP dice 'toma las cosas buenas que ya hacemos y amplifícalas': comunicación, simplicidad, retroalimentación y coraje. Y TDD dice: primero escribe una prueba que falla, luego escribe solo el código necesario para que pase, y detente.
- Extreme Programming (XP)
- Un método ágil de desarrollo creado por Kent Beck en 1996, entre los más completos y conocidos; construido sobre cuatro valores (Simplicidad, Comunicación, Retroalimentación, Coraje) y 12 prácticas de ingeniería, sobre la idea de 'tomar lo que funciona y amplificarlo'.
- Desarrollo Guiado por Pruebas (TDD)
- Un método en el que primero se escribe una prueba unitaria que debe ejecutarse y fallar, luego se escribe código hasta que la prueba pasa, y se detiene en el momento en que pasa, sin agregar funcionalidad; ninguna prueba que pasaba antes puede fallar.
- Planning Game
- Una práctica de planificación de XP que separa las decisiones de negocio de las decisiones de los desarrolladores: el negocio presenta y prioriza las historias de usuario, los desarrolladores estiman el esfuerzo, y las iteraciones son cortas (1-2 semanas) y nunca superan el tiempo asignado.
- Historia de Usuario
- Una tarjeta breve (nombre + descripción) de una función que aporta valor al cliente, escrita por el cliente y estimada por los desarrolladores; reemplaza los grandes documentos de requisitos, con un propósito similar al de un caso de uso.
- Programación en Pareja
- Todo el código se escribe en pareja, en una sola estación: uno escribe, el otro piensa si funcionará, en mejores formas de hacerlo, y en escenarios de prueba; intercambian roles aproximadamente cada dos horas y las parejas rotan, lo que favorece la propiedad colectiva y la revisión informal.
- Refactorización
- Mejorar la estructura del código existente sin cambiar su comportamiento, para mantener el diseño simple; una actividad continua, no puntual, en la que las pruebas garantizan que el comportamiento no se rompió.
- Integración Continua (CI)
- Construir y probar todo el sistema varias veces al día (integrando al menos diariamente), con pruebas automatizadas; las pruebas unitarias deben pasar al 100% antes y después de la integración.
- Ritmo Sostenible (semana de 40 horas)
- 'Programar es una maratón, no una carrera corta': el equipo trabaja hasta 40 horas por semana; las personas cansadas no son productivas; en una crisis se permite hasta una semana de horas extra, pero semanas consecutivas son una señal de que algo anda mal.
