Kent Beck: Pasos pequeños, confianza real

7 min de lectura

Hizo del feedback parte del trabajo

La prueba llega antes que la excusa

Kent Beck ayudó a convertir el desarrollo guiado por pruebas en una disciplina de trabajo práctica. Su ritmo conocido es sencillo: escribir una prueba para el siguiente comportamiento, verla fallar, escribir el código justo para que pase y después mejorar la estructura sin alterar el comportamiento. La explicación de TDD de Martin Fowler sitúa el desarrollo de esta práctica en el trabajo de Beck con Extreme Programming a finales de los años noventa.

El orden importa. Una prueba fallida demuestra que puede detectar el comportamiento ausente. Una prueba que pasa después de un cambio pequeño aporta evidencia sobre ese cambio. La refactorización con las pruebas todavía verdes permite mejorar el diseño sin reescribir el acuerdo en silencio. Ninguno de esos pasos es magia. Juntos hacen visible la incertidumbre mientras resolverla aún resulta barato.

Pensemos en un proceso interno de facturación. El requisito dice: «Nunca envíe una factura sin referencia de cliente». Lo fácil es añadir un campo al formulario y descubrir tres semanas después que la importación por lotes sigue creando facturas sin referencia. La mejor primera pregunta se puede ejecutar: ¿qué ocurre si la importación recibe un registro sin esa referencia? Hacer que ese caso falle. Añadir la regla en el límite que usan ambas rutas. Después comprobar juntas la interfaz y la importación.

El objetivo no es coleccionar más marcas verdes. Es averiguar si la regla de negocio vive en el sistema o solo en el acta de una reunión.

Las prácticas se sostenían entre sí

La trayectoria de Beck suele reducirse a una lista de nombres conocidos: JUnit, TDD, refactorización, Extreme Programming. En su propio balance recalca que el trabajo fue colectivo y explica cómo se sostenían esas ideas. JUnit facilitó escribir pruebas en el mismo lenguaje que el código de producción. Las pruebas hicieron más seguros los pequeños cambios de diseño. La refactorización mantuvo modificable un sistema en crecimiento. Extreme Programming conectó esa disciplina técnica con personas que trabajaban juntas y con usuarios capaces de responder al software funcionando.

El trabajo anterior también fue compartido. En su artículo de 1989, Beck y Ward Cunningham describieron las tarjetas CRC: fichas baratas para pensar en las responsabilidades y colaboraciones de los objetos. Importaban porque las personas podían moverlas, cuestionar un diseño incompleto y cambiar de opinión sin una entrega formal. Cunningham llevó más tarde ese interés por la comprensión compartida al wiki y a la metáfora de la deuda técnica. Su historia merece estar al lado de la de Beck.

Beck también firmó el Manifiesto Ágil. Ese dato es menos útil que las prácticas que había detrás. Un equipo puede celebrar todas las ceremonias del calendario y aun así retrasar su primer feedback técnico sincero hasta la semana del lanzamiento. El calendario quedará impecable. Puede que el lanzamiento no.

Los pasos pequeños permiten avanzar deprisa

«Pasos pequeños» puede sonar a una petición de ir más despacio. Beck defiende lo contrario. En su comparación entre TDD y Kanban, limitar el trabajo en curso hace visibles los problemas antes. Una prueba fallida concentra la atención en un comportamiento necesario. Una prueba superada indica que el código satisface esa demanda concreta. El conjunto anterior de pruebas comprueba que lo nuevo no haya roto lo que ya funcionaba.

Ese ritmo cambia la forma de abordar un requisito difícil. En lugar de diseñar en una pizarra todas las reglas de una futura plataforma de facturación, el equipo puede tomar un caso real, expresar el resultado esperado, implementarlo y preguntar a operaciones dónde falla el ejemplo. El caso siguiente quizá revele una excepción. El diseño cambia mientras todavía es pequeño.

Ahí suelen tropezar las empresas que insisten en que «solo automatizan un proceso». Una hoja de cálculo se convierte en integración. La integración se convierte en una promesa al cliente. De pronto la organización responde por el comportamiento del software, aunque nunca escribiera «producto de software» en el presupuesto. El feedback rápido ya es una necesidad operativa, no una preferencia de los desarrolladores.

Una batería verde no da carta blanca

El desarrollo guiado por pruebas también puede volverse teatro. Los equipos prueban detalles de implementación, sustituyen con simulaciones la integración peligrosa y celebran un panel verde. Una batería que confirma con total fiabilidad una regla de facturación equivocada sigue equivocada.

El propio Beck contó que decidió corregir y publicar un defecto sin prueba automatizada porque escribirla habría exigido horas de investigación. En su relato, la elección dependía del tipo de producto y del feedback que necesitaba entonces. Eso ayuda más que el mandamiento de probar del mismo modo todos los casos imaginables.

Use la comprobación más pequeña que responda a la siguiente pregunta real. A veces será una prueba unitaria. A veces, una prueba de integración, una conversación con quien concilia facturas o un experimento cuidadoso en producción. La disciplina consiste en mantener cerca la pregunta y la evidencia. La capacidad de recuperación sigue importando cuando una prueba no puede anticipar la realidad.

La IA aumenta el valor del ciclo de feedback

Un agente de programación con IA puede producir un proceso de facturación plausible en minutos. Eso reduce el tiempo de tecleo. No dice si todas las facturas necesitan referencia de cliente, si las importaciones antiguas están exentas o quién puede decidirlo. Una implementación más rápida solo reparte una decisión pendiente entre más líneas de código.

El enfoque de Beck mantiene el criterio humano dentro del ciclo. Declarar un comportamiento concreto. Comprobar que el sistema actual no lo cumple. Dejar que un desarrollador o un agente haga un cambio pequeño. Verificar el resultado. Mejorar la estructura mientras todavía está disponible la evidencia. Luego plantear la siguiente pregunta. La misma disciplina que evitaba los grandes diseños especulativos puede impedir que el código generado por IA convierta un requisito supuesto en cinco suposiciones integradas.

Eso no significa que un prompt que diga «usa TDD» sea un sistema de seguridad. Las pruebas superan a las instrucciones para agentes de programación con IA cuando expresan expectativas reales y se ejecutan contra el cambio. Alguien todavía tiene que escogerlas, advertir los casos ausentes y mantener comprensible el sistema.

La decisión de liderazgo

Un CTO no puede exigir lanzamientos fiables mientras premia únicamente la producción visible de funcionalidades. Si los desarrolladores deben justificar cada prueba como una demora, aprenderán a posponer las comprobaciones. Si el equipo no puede revisar el diseño sin un proceso político aparte, aprenderá a proteger un mal diseño. La supuesta velocidad es un préstamo que se paga en el siguiente incidente.

Dé al equipo un camino corto desde la pregunta de negocio hasta el ejemplo ejecutable y el cambio funcional. Mantenga accesibles a quienes conocen las excepciones mientras se construye el software. Ejecute las pruebas con cada cambio y deje espacio para mejorar la estructura cuando revele fricción. Pregunte qué aprendió el equipo esta semana, no cuántos tickets movió.

La lección de Beck nunca fue que todos los cambios deban ser diminutos para siempre. Un equipo se gana la capacidad de hacer cambios importantes construyendo confianza mediante evidencia frecuente. Esa confianza se crea paso a paso, con honestidad.

Referencias

• A Career Accounting, Kent Beck
• TDD is Kanban for Code, Kent Beck
• To Test or Not to Test? That’s a Good Question, Kent Beck
• A Laboratory for Teaching Object-Oriented Thinking, Beck y Cunningham
• Test Driven Development, Martin Fowler
• Autores del Manifiesto Ágil