Si alguna vez te has sentido infeliz escribiendo código y desarrollan software, o participando en un proyecto , no estás solo . Desde hace más de cuarenta años personas que también sintieron eso y que creen que debe existir algo mejor han invertido tiempo y esfuerzo en mejorar el trabajo de todos los que nos dedicamos al desarrollo de sistemas de información. Nunca se ha dejado de perseguir el éxito y de luchar contra proyectos que se estancan y que no funcionan y que su principal logro es convertir un trabajo creativo y apasionante como es escribir código y construir sistemas en algo frustrante, gris y negativo.

Software_components_lecture_large

Conferencia de ingeniería del software organizada por la OTAN en 1968, dónde se acuñó el término "crisis del software" porque ya en aquella época los proyectos se pasaban de tiempo y presupuesto.

Un grupo de estas personas, hace más de veinte años, dieron forma a un mensaje tan potente y atractivo que cambió completamente la concepción del desarrollo de software, a pesar de que apenas tenía cuatro frases. Su nombre: el manifiesto ágil , dio lugar a una manera de concebir el desarrollo de software.

Una de las características principales de entornos y organizaciones ágiles es su rápida adaptación al cambio , porque, lo queramos o no, el software va a cambiar. Si los requisitos cambian, las tecnologías cambian, las ideas y necesidades de los clientes y usuarios cambian, nuestros compañeros de trabajo cambian ¿por qué dejamos que el cambio nos afecte negativamente en vez de utilizarlo para ganar valor?

Autores del manifiesto ágil.

Autores del manifiesto ágil. si alguna vez te tropiezas con alguno de sus libros ¡¡¡léelo!!

En entornos no ágiles un cambio puede suponer un coste grande de actualización de requisitos re-analisis, re-diseño, grandes y modificaciones de código, etc . Un entorno ágil , en cambio, busca procesos de trabajo para los que el cambio suponga el mínimo desgaste posible y que, un cambio, no se vea como un desperdicio de tiempo y recursos sino como una oportunidad de mejorar y avanzar. Esta filosofía nos lleva a desear el cambio en lugar de impedirlo.

Pero esto no sucede sólo leyendo un libro de Scrum , haciendo reuniones todos los días y llamándolas daily meetings o diciéndole a todo el mundo que nuestra empresa es ágil no se está preparado para hacer del cambio un motor de evolución. Se necesita un conjunto de técnicas y prácticas maduras y equipos especializados en su uso.

No podemos conseguir velocidad y agilidad necesaria si nos quedamos atascados porque nuestro código funciona y no sabemos ni dónde ni porqué, o si al hacer un cambio comienzan a fallar muchas partes del código, incluso algunas que no deberían verse afectadas por el cambio. Tampoco podemos alcanzar la agilidad si un cambio en un requisito, historia de usuario, nuevo añadido, etc. implica cambiar muchas partes distintas del código. En este caso claramente hemos hecho un mal diseño y este mal diseño nos penaliza.

Una de las técnicas ágiles que más difusión ha alcanzado es el desarrollo dirigido por pruebas o TDD en sus siglas en inglés. Esta técnica propone el diseño del código de manera interactiva, planteando el desarrollo desde la perspectiva de cuál es la manera más adecuada de utilizar el código en lugar de qué elementos debe tener, y creando un conjunto de pruebas que nos avisen inmediatamente hemos introducido algún cambio que modifique su funcionamiento.

Flujo de trabajo con TDD.

Flujo de trabajo con TDD. ¿De qué color pintarías cada rectángulo?

La manera de trabajar con TDD sería la siguiente:

  1. Piensa cuál es el resultado que quieres obtener del próximo fragmento de código a implementar

  2. Escribe un caso de prueba que verifique dicho resultado

  3. Asegúrate que la prueba falla porque si funciona a lo mejor tu código ya es capaz de hacer lo que quería, o a lo mejor la prueba está mal implementada.

  4. Escribe el mínimo código posible para que la prueba funcione.

  5. Comprueba que la prueba funciona

  6. Refactoriza tu código y prepáralo para que sea fácil de modificar.

Algunos de los pasos anteriores puedes ir en contra de la intuición, ¿ejecutar una prueba antes de escribir el código que verifica? ¿Escribir el mínimo código posible en vez concéntrate y escribirlo todo de golpe? Sí, todo tiene su razón de ser. Con TDD buscamos descubrir qué es lo correcto (nombre adecuado de métodos, parámetros, manera de devolver resultados, etc.) antes de hacerlo correctamente. Escribiendo el mínimo código intentamos evitar gastar tiempo en funcionalidad que ahora mismo no necesitamos y que ya implementaremos en el futuro cuando de verdad las vayamos a utilizar. Con la refactorización no solo quitamos apaños de nuestro código sino que nos preparamos para que cualquier cambio o modificación pueda aplicarse sin tener que tirar a la basura o cambiar de arriba abajo todo lo que tenemos. Ah, y además hasta tenemos algunas pruebas por si más adelante cambiamos algo sin darnos cuenta.

Si no quieres esperar para saber más de TDD o quieres refrescar conocimientos aquí tienes unos enlaces que te puede ayudar. Puedes empezar repasando el manifiesto ágil . En una historia que pasa todos los días tienes una divertida introducción a TDD escrita para no programadores (y un ejemplo en Python). Hay dos estupendos libros gratuitos en español, el primero Diseño Ágil con TDD y el segundo, aún en desarrollo pero que ya se puede descargar, Desarrollo Dirigido por Pruebas Práctico . Que los disfrutéis.