La razón de BDD. (Behaviour Driven Development) Parte 3

Redefiniendo el problema

No todo es pesimismo sin embargo. Hay muchos equipos por ahí que hacen sus entregas de proyectos a tiempo, dentro del presupuesto, y deleitan a sus participantes titulares, y se las arreglan para hacer una y otra vez. No es fácil. Se necesita disciplina y dedicación, y se basa en un alto grado de comunicación y colaboración, pero es posible.

El Desarrollo Orientado al Comportamiento es una de varias metodologías ágiles. En concreto se trata de una metodología ágil de segunda generación, construído sobre el labor de unos muchachos realmente inteligentes. Vamos a ver cómo estos métodos Agiles se produjeron y cómo abordar los riesgos de los proyectos tradicionales, entonces podemos ver cómo BDD nos permite concentrarnos en la escritura de software, que es realmente lo que importa.

Cómo hacen frente a los riesgos del proyecto los métodos Ágiles

Los autores del manifiesto van mucho más allá de las pocas líneas antes mencionadas en el mismo. También documentaron los principios que sustentan su pensamiento. Cabe destacar en este es un deseo de “ofrecer software de trabajo con frecuencia, desde un par de semanas a un par de meses, con una preferencia a la escala de tiempo más corto.”
Imaginemos por un momento que usted puede hacer esto, a saber, la distribución de software de calidad de producción cada dos semanas para sus grupos de interés, en su proyecto actual, en su organización actual, con su equipo actual, a partir de mañana. ¿Cómo se hace frente a los riesgos tradicionales de entrega que se indicaron antes?

No más entregas tardías según el presupuesto

Como las entregas son pequeñas, iteraciones de una o dos semanas o mini proyectos, utilizando un equipo pequeño, de tamaño fijo, es fácil de calcular nuestro presupuesto del proyecto: se trata simplemente de la velocidad de producción del equipo en el número de semanas, además de algunos de hardware y licencias.

Siempre partimos de una suposición razonable en el tamaño total del proyecto, es decir cuánto estamos dispuestos a invertir en la solución del problema de negocio en el primer lugar, y se da prioridad a las características apropiadamente, entonces el equipo puede entregar las cosas realmente importantes en las iteraciones tempranas. (Recuerde, estamos entregando por característica, no por módulo). Así
a medida que hacia el momento en que el dinero se acaba, debemos, por definición, trabajar en funciones de menor prioridad. También podemos medir la cantidad que realmente se produce en cada iteración, conocida como nuestra velocidad o rendimiento, y usar esto para predecir cuando en realidad estamos con probabilidades de terminar.

Si, como nos acercamos a la fecha límite, las partes (clientes) siguen teniendo ideas y características nuevas y ven las cosas maravillosas sucediendo, pueden optar por financiar el proyecto de unas pocas iteraciones más. A la inversa que pueden decidir antes el plazo que es suficiente para la funcionalidad que ha sido entregada, o bien que quieren terminar temprano. Esta es otra opción que tienen.

No más entregas de cosas incorrectas

Estamos entregando los programas necesarios para los interesados cada dos semanas (por ejemplo), lo que significa que estamos ofreciendo características demostrables. No tenemos dos semanas de “repetición de esquema de base de datos” o “repetición de middleware.” Después de cada iteración podemos demostrar las nuevas características para los interesados y pueden hacer ningún ajuste o corregir cualquier malentendido cuando la obra está aún fresca en el desarrollo equipo de la mente. Estos regulan, a pequeña escala micro-correcciones que garantizan que no se terminan hasta varios meses abajo de la línea con el software que simplemente no hace lo que los actores querían.

Para dar inicio a la siguiente iteración podemos reunirnos con los interesados para reevaluar las prioridades de las características en caso de que algo ha cambiado desde el pasado tiempo. Esto significa que cualquier nueva idea o sugerencia se pueden programar, y la cantidad correspondiente de trabajo puede ser descomprimida (tiempo extra)

No más inestable en Producción

Estamos entregando cada iteración, lo que significa que tenemos que ser buenos en la construcción y en el despliegue de la aplicación. De hecho contamos con la automatización en gran medida en proceso para manejar esto por nuestra cuenta. No es raro que un equipo Agil con experiencia produzca más de 100 construcciones de buen software cada semana.
En este contexto, liberar a la producción o pruebas de hardware puede ser considerado simplemente otra costrucción para otro ambiente. Los servidores de aplicaciones se configuran automáticamente y se inicializan, esquemas de bases de datos que se actualizan automáticamente, el código es automáticamente incorporado, montado y desplegado a través del cable, todo tipo de pruebas se ejecuta automáticamente para asegurar que el sistema se está comportando como se esperaba. De hecho, en un entorno ágil, la relación entre el equipo de desarrollo y las operaciones “río abajo” y los DBA es a menudo mucho más saludable y más solidaria.

Ya no es costoso mantener

Este último es uno de los mayores beneficios tangibles de un proceso ágil. Después de su primera iteración el equipo está en modo de mantenimiento eficaz. Ellos son la adición de características a un sistema que “funciona” por lo que tienen que ser muy cuidadosos.
Suponiendo que pueden resolver las cuestiones de la seguridad de cambiar el código existente a fin de no introducir a los defectos de regresión, sus prácticas de trabajo deberían ser exactamente las mismas que los desarrolladores de apoyo intermedio. No es raro que un equipo de desarrollo ágil trabaje en varias versiones de una aplicación al mismo tiempo, la adición de características a la nueva versión, la prestación de apoyo directo a una versión temprana recientemente publicada, y proporción de corrección de errores apoyando a una versión de producción de más edad

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1