Desarrollo de Balas Trazadoras

Seguro que habeis oido de la practica militar de disparar con balas trazadoras cuando es de noche para poder apuntar mejor. Basicamente se basa en el hecho de que apuntar con una ametralladora es muy dificil, sobretodo por la noche. Por ese motivo se utilizan balas trazadoras que estan bañadas en fosforo y al ser disparadas dejan una estela de luz con la que el artillero se puede guiar y apuntar mejor.

El Desarollo con Balas Trazadoras (o TBD) hace exactamente lo mismo en un proyecto de software. Basicamente te deja ver a la dirección tomada dejandote apuntar continuamente mucho antes de que este terminado el proyecto.

Hoy en dia hay muchos procesos y metodologias (prefiero llamarlos ecosystemas ya que suelen fallar por eventos sociales) de las que nos podemos nutrir para sacar nuestro proyecto adelante. La mayoria de estas suelen ser o demasiado burocraticas o frustrantes. Sobretodo si vemos el espectro de ecosystemas (desde RUP a XP) todos nos imponen una serie de practicas que segun los creadores son el mejor camino a seguir y si no se practican todas ellas no estamos siguiendo su metodología. En esto estoy de acuerdo, o todo o nada (al menos si quiero decir que estoy en un equipo XP por ejemplo), ya que las metodologías suelen basar sus valores y practicas en las interrelaciones de estas.

Con DBT es diferente. El TDB no te dice como tienes que trabajar sino que mas bien complementa tu forma de trabajar. No te dice si tienes que hacer TDD (Test Driven Development) o escribir historias de usuario. Basicamente se implanta con coste cero y da unos resultados asombrosos. De hecho es posible ir añadiendo practicas al proceso ya que es un proceso muy ligero (comparable los procesos Crystal de Cockburn).

Al user TBD se crea un system punto a punto dejendo todos los componentes vacios. Escribes el codigo de todos los componentes mayores del systema, pero estos no hacen realmente nada. Por ejemplo la rutina de login solo funciona con el usuario "Estrella" y genera un login valido. Basicamente al principio del proyecto el interior de cada objeto tiene que ser acabado, esta esperando a ser terminado (la analogia inglesa "to be done" rinde homenaje al acronimo TBD).

¿Como podemos poner en practica el TBD?

Primero identificamos los componentes del systema y dividimos el proyecto en bloques relacionados (por ejemplo cliente, servidor web, acceso a la base de datos).

Ahora definimos la informacion que estos bloques tienen que intercambian, o sea los interfaces.

Cada uno de los bloques son repartidos a los desarolladores, equipos, o algun sitio en tu cabeza (si estas solo).

Escribe codigo para que todo "parezca" que esta funcionando. Puedes usar la analogia de que toda tu aplicacion esta hecha de Mock Objects. Con este fino esqueleto puedes empezar a poner la logica real en cada uno de los componentes.

Finalmente recuerda que los interfaces van a cambiar y evolucionar en el transcurso del proyecto. El primer disparo siempre falla, asi que se flexible y ajusta el tiro en cualquier momento. Si algun miembro del equipo te pide cambios en tus interfaces cambialos. Es software al fin y al cabo!