“El Desarrollo dirigido por comportamiento trata sobre la implementación de una aplicación mediante la descripción de su comportamiento desde la perspectiva de sus grupos de interés.”

En estos últimos días he estado leyendo “The RSpec Book” , que tal como dice su descripción no es un libro sobre RSpec, ni Cucumber, ni Ruby, si no, un libro sobre como desarrollar buen software por medio de una metodología ágil como BDD, aunque claro está, el libro está repleto de ejemplos basados en Ruby.

Ya he leído bastante y la verdad es sorprendente como, ahora que ya termino mi vida Universitaria de pre-grado, vuelvo a notar que la Universidad me enseño muy poco en varios aspectos, uno de esos aspectos es metodologías para el desarrollo de software. Si bien tuve 1 año completo sobre Ingeniera de Software, dicho curso fue enfocado demasiado clásico y metodologías que a mi parecer ya son pseudo-arcaicas y que no logran su cometido: Desarrollar software de calidad (Software that matters).  Ya desde ese momento me gusto el enfoque agil, pero lamentablemente no era posibles aplicar alguna de esas metodologías (Scrum, XP, Crystal, etc) ya que se nos pedia otra cosa. Pero este es el momento de trabajar con este tipo de desarrollo en los proyectos personales y (espero :S ) trabajos.

Bueno, al grano, ¿Qué es BDD? o más bien ¿De que trata BDD?

BDD comenzó como una simple modificación de TDD (Test Driven Development), pero actualmente ha crecido hasta convertirse en una completa metodología de desarrollo de software.

La descripción de BDD que puedes leer al principio de este post implica un gran número de cosas. Primero, sugiere la necesidad de entender el mundo desde el mundo de vista de nuestros “stakeholders”, es necesario entender su dominio, las oportunidades y desafíos que enfrentan y el lenguaje que utilizan para describir el comportamiento que desean para la aplicación.

Segundo, implica que existe más de un “stakeholder”. No solo debemos ver el mundo desde el punto de vista del usuario final o de la persona que nos provee del dinero para pagar nuestras cuentas, si no, de cualquiera con un interés en el proyecto que se desarrolla.

BDD cuenta con tres principios básicos:

1. Suficiente es Suficiente: La planificación por adelantado, el análisis y el diseño tienen un rendimiento decreciente. No debemos hacer menos de lo que se necesita para empezar, pero más que eso es un esfuerzo inútil.
2. Entregar valor a nuestros “stakeholders”: Si te encuentras haciendo algo que no entrega valor o incrementa tu habilidad/posibilidad de entregar valor, deja de hacerlo y haz algo distinto.
3. Todo es comportamiento: Ya sea a nivel de código, de aplicación o más allá, podemos usar el mismo pensamiento y la misma lingüística para describir comportamiento a cualquier nivel de granularidad.

BDD define como “stakeholder” a cualquiera que sienta que nuestro proyecto es relevante, ya sean estos las personas a las que intentamos resolverles el problema – “core stakeholder” – o las personas que ayudarán a resolverlo – “incidental stakeholder”. Este grupo final incluye la gente de operaciones, el equipo de soporte, los expertos legales y de seguridad, etc. Todos aquellos que representan los “requerimientos no funcionales”. Claro que desde el punto de vista de BDD no existen los “requerimientos no funcionales” solo  caracteristicas para “incidental stakeholders”.

Aquí la labor de cada uno es: los “core stakeholders” deben definir la vision y los “incidental stakeholders” deben ayudarlo a entender que es posible y a que costo.

Una vez que la visión de lo que se quiere es definido, podemos comenzar a trabajar, para esto, primero debemos entender que significa la visión creada, así que se debe trabajar con los “core stakeholders” para definir los objetivos y resultados. Solo deben existir unos pocos resultados y objetivos si no, es posible que el proyecto pierda su norte.

Una definidos los resultados y objetivos debemos pensar en que necesitamos para lograrlo, en este caso, desarrollar un software. Se describe los que el sofware debe realizar como un conjunto de características o temas (themes). Temas son cosas como: reportes, registro de clientes,etc. siempre demasiado alto nivel para comenzar a “codear” pero lo suficientemente especifico para poder conversar al respecto.

Finalmente se puede hablar de características especificas o historias (stories) que componene esos temas. Este es el nivel donde se trabaja día a día, esto describe el comportamiento que se implementará en el software.

Esto nos permite trazar de regreso cada característica a un “stakeholder”. Cada característica está ahí, solo por que añade valor a un tema o conjunto de características. Cada tema contribuye  a uno o más resultados, y cada resultado es parte del proposito general del proyecto.

Aquí es donde comienza el ciclo de desarrollo. Una vez que los “stakeholders” pueden articular sus requerimientos como una caracteristica que les haga sentido. Luego el analista del negocio trabaja para determinar el alcance de las “stories“, una vez identificado que escenarios son importantes para dicha “historia” , nuestro “stakeholder” puede especificar cuando desea que se realice o cuanto esfuerzo quiere para una caracteristica en particular. Los desarrolladores solo deben invertir lo suficiente para satisfacer los acordado, nada más.

La tarea final antes de que los “programadores” comiencen su trabajo, es automatizar los escenarios donde sea neceario.

Ahora ya es posible comenzar con la parte de “picar código”, aquí es donde entra en juego RSpec, un desarrollador (en general mejor un par de ellos) usan RSpec para codigicar por ejemplos para obtener un escenario funcional. Comenzamos por escribir un “código de ejemplo” para describir el comportamiento que se desea, luego se implementa el código para que el ejemplo funcione y después se realiza la fase de refactorización (Red/green/refactor cycle). Eventualmente se logra suficiente software para hacer que el escenario funcione, así que es posible iterar hacia otro escenario, permitiendonos siempre poder mostrar a nuestro “stakeholder” software funcional en poco tiempo, permitiendonos tener gran feedback de lo que estamos haciendo y lo que realmente se quiere, se está mas cerca de la realidad.

En los proximos días continua…