Han sido días oscuros en el desarrollo de nueva tecnología sobre todo en épocas en las que el panorama está nublado y lleno de incertidumbre. Para nuestra fortuna existen algunos guardianes de la galaxia encargados de traer al mundo nuevos Titanes que nos permitan lidiar con este mundo cambiante.
Cuando hablamos sobre agilidad el término suele verse ampliamente influenciado sobre temas de humanidad y apoyo a las personas. Sin embargo, existen un montón de temas, si somos ese pequeño grupo de personas que se encarga de “meter las manos al fuego”, es decir; personas encargadas de construir esa obra de arte que seguro cambiará la vida de las personas. Pero he aquí uno de esos “pequeños grandes detalles”: ¿cómo sabemos que nuestra obra de arte cumple las necesidades?, al menos las necesidades, ni siquiera hablemos de las expectativas.
Existen las mejores prácticas , las cuales promueven mejorar un producto de software en al menos uno de sus aspectos de calidad. Pero un montón de prácticas no asegura nada. Lo que en realidad necesitamos es una guía que nos permita ir viendo el sitio en el que estamos parados. A continuación desarrollare un par de temas de los más apasionantes para mí en agilidad.
En mi experiencia puedo hablar acerca de un panorama de desarrollo de tecnología siempre muy cercano a la construción de software y su mantenimiento. Cuando me asignaban corregir bugs, mi pasos a seguir eran:
- Verifica el error
- Haz unos cuantos cambios y “REZA AL SEÑOR”
- Vuelve a ejecutar la aplicación (a veces hasta 8 minutos de espera)
- Si el problema persiste vuelva al paso 1
Efectivamente vuelva al paso 1 , quizá haya generado nuevos problemas.
Este proceso de corrección de errores hace que los desarrolladores “tronemos como pistaches” o lo único que busquemos sea la salida más próxima. En verdad es frustrante y en muchas ocasiones parece que los “bugs” son una quimera que lo único que quiere es tu sueldo, tus esperanzas y tu fe por el mundo.
Sigamos con esta charla.
Existen un par de ideas que pondré a dar vueltas en tu cabeza, claramente sólo si me permites.
Cuando hablemos de ahora en adelante en ¿qué guía tu desarrollo ? Piensa en Test Driven Development (TDD) y Behaviour Driven Development (BDD). Piensa en otros dos grandes guías cómo si pensarán en Martin Fowler o Kent Beck.
Cuando existen dos alternativas siempre hay que decidir una, excepto hoy. Test Driven Development ha sido un tema bastante escondido dentro de la agilidad, pero ¡hoy dejará de serlo! TDD se refiere a un flujo como el siguiente
- Escribe una prueba
- Ejecuta esa prueba
- Escribe código mínimo para que pase la prueba
- Cuando la prueba pase, realiza las mejoras necesarias a ese código
- Vuelve a correr
Toma un café y termina la tarde viendo un capítulo de Game of Thrones.
Generalmente el tipo de pruebas que suelen hacerse en TDD son las llamadas pruebas unitarias; estas pruebas sólo requieren del código y una herramienta que las ejecute. Pero no es la única forma de probar las cosas. Existen pruebas de integración y pruebas de interfaz; pero esa es otra historia. Recordemos: “¡Desarrollo guiado por pruebas: Pruebo, codifico luego existo!”
El tema no es muy diferente cuando hablamos acerca de BDD , las pruebas siguen haciéndolo pero ahora se realizan con un enfoque un poco más abstracto. Realizamos pruebas que pretendan verificar el comportamiento de lo que desarrollamos, seguimos el mismo proceso pero ahora revisamos la forma en que se comporta.
Existen herramientas que siguen estas filosofías de pruebas. En el caso de TDD existen el framework XUnit; en el caso de BDD existe cucumber y spock para las aplicaciones del mundo java, sólo por mencionar algunas.
Entonces, existen más formas de hacer software que prueba y error, te invito a seguir las redes sociales de Agile Academy y Banana Soluciones Creativas, en las que hablaremos cada vez más a profundidad de estos temas. Pero por favor te pido de la manera más atenta, di sí a hacer pruebas.