Las metodologías ágiles como una aplicación del constructivismo

Visto de manera general, el desarrollo de cualquier producto bajo especificaciones de diseño, es decir, diseñado y construido para cumplir una serie de requerimientos, parecería una aplicación práctica de las ideas del constructivismo.

Los requerimientos son expresados generalmente en forma de observaciones: “El sistema ofrece al usuario una lista con las opciones que el usuario tiene permitido utilizar” o “Cuando el usuario solicita al usuario imprimir un informe, el sistema solicita una confirmación antes de proceder”.

Estas observaciones determinan lo que el sistema puede y lo que no puede hacer, es decir, definen lo que la implementación, la realidad del sistema, debe ser y será una vez terminado el desarrollo. Los requerimientos construyen la realidad del sistema. Pero la afirmación de que la construcción de un producto o sistema es una aplicación del constructivismo no tiene nada de sorprendente, pues se trata finalmente de “construcciones” de cosas, en este caso, de software.

El constructivismo toma su nombre precisamente de la construcción de cosas, edificio, máquinas, etc. Decir ahora que la construcción de una casa es una aplicación de las ideas constructivistas es una necia obviedad. Sería como sorprendernos de que las naranjas sean precisamente de color naranja, siendo que este color se llama así por las frutas.

Pero en el caso de las metodologías ágiles las cosas ya no son tan triviales, pues el enfoque constructivista puede verse mucho más allá de la simple construcción de una cosa. Sobre todo si pensamos en las metodologías que tienen como eje la orientación a pruebas (TDD) como es el caso de la XP.

Un requerimiento en desarrollo de software se expresa tradicionalmente en lenguaje natural, es una redacción que nos dice lo que el sistema debe hacer, lo que no debe hacer, etc. En el caso de la TDD, los requerimientos en redacción libre deben convertirse en tarjetas de responsabilidad atómicas que son aplicadas a los clasificadores de nuestro modelo de domini, y cada una de estas tarjetas de responsabilidad es finalmente traducida a un conjunto de pruebas unitarias. Las pruebas unitarias representan los requerimientos del sistema a un nivel atómico y en el mismo lenguaje en que es desarrollado el sistema.

Una característica esencial en la TDD es que las pruebas unitarias se escriben antes de escribir el código que las verifica, incluso antes de escribir el código que puede ser evaluado por ellas. Es decir, no sólo estamos diciendo lo que queremos observar, sino también cómo lo deseamos observar.

Si pensamos que lo que queremos observar es el comportamiento del sistema, entonces la prueba unitaria nos dice cómo debe ser este comportamiento, qué deben hacer los métodos de nuestras clases por ejemplo; de manera semejante, la prueba unitaria también dice qué métodos debe tener un clasificador, más aún, qué firma debe tener el método en cuestión; la prueba unitaria define cómo vamos a observar el comportamiento del objeto, esto es, cómo hablaremos del sistema, a través de qué nombres.

Si escribiéramos juntas todas las pruebas unitarias que requiere un sistema, y después escribiéramos el sistema, nos encontraríamos ante un escenario muy parecido al desarrollo tradicional, donde nuevamente la afirmación de que estamos aplicando ideas constructivistas es una obviedad.

Lo que me permite decir que las metodologías ágiles son una aplicación de las ideas constructivistas depende no sólo de la TDD, sino del componente iterativo de estas metodologías.

Al inicio de cada iteración, el sistema se encuentra en congruencia con su descripción, es decir, pasa todas las pruebas escritas hasta ese momento. Podemos decir que la realidad del sistema se ajusta a su observación. Entonces comenzamos a escribir las nuevas pruebas que el sistema no pasa porque ni siquiera es posible compilarlo debido a la inconsistencia semántica con las pruebas: Las pruebas requieren de miembros públicos en las clases del sistema que ni siquiera existen en lo que hasta ahora hemos programado.

Lo que hemos creado junto con las pruebas es un nuevo contexto semántico para el sistema, es decir, hemos creado nuevas formas de hablar acerca del sistema. El siguiente paso es hacer que el sistema hable de las mismas cosas que su descripción, lo forzamos a ajustarse a su nuevo contexto semántico. Una vez que se han creado los miembros faltantes, el sistema puede compilarse y pueden evaluarse las pruebas.

Lo común es que el sistema falle las pruebas nuevas, es decir, hemos creado un bug. Este bug representa lo que la realidad del sistema dista de nuestra observación, es una incongruencia de la realidad (no queremos que sea una incongruencia de nuestra observación). Ahora debemos forzar al sistema a cumplir con esos comportamientos que decimos que debemos observar. Modificamos el código y volvemos a compilar. Ahora el sistema pasa todas sus pruebas y nuevamente es congruente con su descripción, al menos hasta el inicio de la próxima iteración.

Ahora bien, al inicio de cada iteración, el equipo de desarrollo se reúne para decidir los cambios que se realizarán, es decir, se acuerda qué es lo que deberá observarse en el sistema al terminar la iteración. El sistema funcionaba correctamente hasta antes del inicio de la iteración, era congruente con su descripción. Una vez iniciada la iteración, la descripción cambia y la realidad deja de ser congruente con la observación, es en ese preciso momento en que la metodología es un reflejo del pensamiento constructivista. Después, el trabajo consistirá en ajustar la realidad a la observación.

One thought on “Las metodologías ágiles como una aplicación del constructivismo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s