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

En estos últimos 6 años, la forma de programar y encarar proyectos de software ha ido evolucionando. Cuando uno comienza a trabajar, siempre elige una manera (sobre todo si se siente cómodo con ella) y la va adaptando según el proyecto en el que se esté realizando.
Muchos de estos cambios se producen por los requerimientos, magnitudes y alcances de los proyectos, y también con el tipo de clientes con el que se esté tratando. En los tiempos actuales, los clientes se han vuelto mucho más exigentes a la hora de solicitar un producto, generalmente van cambiando sus ideas y no solo eso, sinó que muchas veces (la mayoría) lo que el cliente pide no es lo que más necesita.
Esto también obliga a cambios a la hora de desarrollo de productos. Si queremos crecer (como empresa o freelance) obligadamente tenemos que adaptarnos a estos cambios.
BDD (Behaviour Drive Development) es una técnica de desarrollo de software ágil que fomenta la colaboración entre desarrolladores, QA (garantía de calidad) y participantes no técnicos o de negocios en un proyecto de software. Para más info sobre BDD Aquí (en inglés)

A continuación comparto con ustedes una serie de artículos escritos por David Chelimsky del por qué cambiar:

La mayoría del software que escribimos nunca se utilizará. No es nada personal,
es sólo que es una industria en la que no somos muy buenos dándole a la gente lo que
que quieren. La razón subyacente de esto es que los métodos tradicionales de software están diseñados para fallar -trabajan realmente en contra nosotros-. Individuos heroicos ofrecen software a pesar de su proceso de desarrollo y no a causa de él. Veremos cómo y por qué los proyectos fallan, y enfocaremos la atención en algunos de los desafíos que enfrenta el Desarrollo Ágil de Software.

Cómo fallan los procedimientos tradicionales
Los proyectos tradicionales fallan por muchas razones. Una buena manera de identificar los diferentes modos de fallo es preguntarle a tu jefe de proyecto lo que hace por la noche. (Es bueno hacerlo de vez en cuando, ayuda a su autoestima.) Es probable que nuestro jefe de proyecto se planteará una lista de temores similares a los nuestros:

Entrega tardía según el presupuesto

Estimamos, planificamos, tenemos todas las contingencias hasta la enésima potencia y luego, sucede la verdadera decepción de la vida real. Cuando nos deslizamos de la primera fecha, a nadie le importa demasiado. Es decir, sólo será un par de semanas. Si esto sigue sucediendo semanalmente, y así mensualmente, el suficiente número de personas, se han ido y se han unido a que podamos finalmente, poner el proyecto fuera de su miseria. Dieciocho meses a dos años suele ser suficiente. Este es software que no tiene importancia.

Entregando la cosa incorrecta

La mayoría de nosotros usamos un software que se entregó con retraso y más presupuesto en nuestros escritorios, en nuestros teléfonos móviles, en nuestras oficinas y hogares. De hecho nos hemos acostumbrado a los sistemas que se actualizan con correcciones de errores y nuevas características en forma de service packs y actualizaciones del sistema, o sitios web que ofrecen nuevas características con el tiempo. Pero ninguno de nosotros utiliza el software que no resuelve el problema que tenemos.
Es sorprendente cuánto esfuerzo de gestión de proyectos se dedica a cuidar el calendario o el presupuesto cuando el software persigue fines infinitamente más útiles que los mencionados.
Entonces, ¿cómo sucede esto? Tal vez los requisitos cambian después de que estuvimos de acuerdo con ellos, porque el negocio siguió adelante. Tal vez no fueron lo suficientemente claros en primer lugar. Puede ser que entregamos lo que la empresa pidió en vez de que lo que necesitaban. En cualquier caso ponemos una carga de esfuerzo en entregar el proyecto, dentro del presupuesto y a tiempo, pero resulta que nadie conseguirá realmente ningún beneficio de ello. Este es software que no tiene importancia.

Inestable en producción

¡Hurra! El proyecto llegó a tiempo y dentro del presupuesto, los usuarios lo miraron y decidieron que les gustó, por lo que lo ponemos producción. El problema es que el software falla dos veces al día. Creemos que es algo de memoria, o algo de la configuración, o algo de clustering, o de infraestructura, o …, pero ¿a quién estamos engañando? Nosotros no sabemos realmente lo que está causando la excepción, lo que es
más bien embarazoso y nos está costando mucho dinero. Si tan solo hubiéramos pasado más tiempo en probarlo!. La gente lo utilizará esta vez y se dará por vencido cuando se cae “constantemente”. Este es software que no tiene importancia.

Costoso de mantener
Hay una serie de cosas que no necesitamos considerar si estamos escribiendo software disponible. Mantenibilidad es uno de ellas. Sin embargo, si esperamos seguir con la Versión 1, Versión 2, Versión 3, o incluso una versión 2010 Professional Super Vaca Power Edition entonces fácilmente nos podemos pintar en una esquina, por no considerarnos desarrolladores río abajo.
Para empezar es probable que no participamos en la puesta en producción anticipada (early release) y no estamos al tanto de las decisiones y conversaciones que condujeron al diseño actual. Si el código no es obvio, los desarrolladores tendrán que luchar para entenderlo. Del mismo modo si el diseño no es obvio, si hay un montón de acoplamiento o redundancia innecesaria, si un montón de trozos fueron copiados y pegados y éste cambió ligeramente, entonces tendrán que luchar para resolver las implicaciones de los cambios que se hacen, lo cual es un éxito seguro a la hora de introducir defectos de regresión.
Con el tiempo el ritmo al que se pueden introducir nuevas características disminuirá hasta que los desarrolladores terminarán gastando más de su tiempo rastreando regresiones inesperadas y desarmando el “código spaguetti”. En algún momento, costará más mejorar el software que los ingresos que puede generar. Este es software que no tiene importancia.

Seguir leyendo la segunda parte

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