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

Por qué proyectos tradicionales fallan

La mayoría de estos modos de fallo ocurre con personas inteligentes tratando de hacer un buen trabajo. Para la mayor parte del software, las personas son diligentes y bien intencionadas. También es poco probable que los
errores en los proyectos son el resultado de la incompetencia o la incapacidad. Debe haber otra razón.
Tal vez este tipo de fracaso es un resultado inevitable del enfoque que hemos estado tomando (el método tradicional o cascada de entrega de software). No importa cuán inteligentes o bien intencionadas sean las personas, las cosas se pueden crear para el fracaso, y es sólo por los esfuerzos sobrehumanos que el software se entrega totalmente terminado.

Cómo funcionan los proyectos tradicionales

La mayoría de los proyectos de software se basan en la secuencia familiar de Planificación, Análisis, Diseño, Código, pruebas, implementación. Su proceso puede tener diferentes nombres, pero las actividades básicas en cada fase será bastante consistente. (Estamos asumiendo una especie de justificación de negocio que ya ha ocurrido, aunque incluso, no es siempre el caso)

Empezamos con la Fase de planificación: ¿cuánta gente, cuánto tiempo, qué recursos se necesitan, básicamente, ¿cual es el costo de entregar este proyecto y qué tan pronto vamos a ver algo funcionando?
Luego nos adentramos en una fase de análisis. Aquí es donde se articula en detalle el problema que estamos tratando de resolver, lo ideal sería sin prescribir cómo debe ser resuelto, aunque esto casi nunca es así.

Entonces tenemos una fase de diseño. Aquí es donde pensamos en cómo podemos utilizar un sistema informático para resolver el problema que tenemos articulado en análisis. Durante esta fase que pensamos sobre el diseño y la arquitectura, las decisiones técnicas a gran y pequeña escala, las diversas normas en torno a la organización, y poco a poco se descompone el problema en fragmentos manejables para que podemos producir especificaciones funcionales.

Ahora pasamos a la fase de codificación, donde escribimos el software que va a resolver el problema, de acuerdo a las especificaciones que salieron de la fase de diseño. Una suposición común es que en esta etapa, todo es coser y cantar, porque todo el pensamiento duro ya se hizo. Esto no es tan malo como parece, lo que estamos diciendo es que ahora se deben realizar las actividades de programación y pruebas (testing) a un riesgo relativamente bajo debido a que ya hicimos la planificación por adelantado (el análisis y diseño).

Ahora ya somos adultos responsables que tienen una fase de testing en la que probar el software para asegurarse de que hace lo que tenía que hacer. Esta fase incluye actividades con nombres como Testing de aceptación por los usuarios o Performance testing para destacar que nos estamos acercando a la entrega final.

Finalmente llegamos a la fase de implementación en la que desplegamos la aplicación en producción. Con un nivel adecuado de fanfarronería, se desliza nuevo software en producción y comenzamos a ganar dinero!

Todas estas fases son necesarias. No se puede comenzar a resolver un problema que no se ha articulado, no se puede iniciar la aplicación de una solución que no se han descrito, no se puede probar software que no existe y no se puede (o al menos no se debería) implementar software que no ha sido probado.
Por supuesto, en realidad, se pueden hacer cualquiera de estas cosas pero por lo general termina en lágrimas.

¿Cómo funcionan realmente los proyectos tradicionales

Hemos entregado proyectos en más o menos de esta manera desde que empezamos a escribir los sistemas informáticos. Ha habido varios intentos de mejorar el proceso y hacerlo más eficiente y menos propenso a errores, utilizando los documentos para formalizar la mano de fuerza, la creación de plantillas para los documentos, montaje de comités de revisión de las plantillas de los documentos, el establecimiento de normas y la acreditación formal para los comités de examen. . . . Por supuesto que podemos ver cuando el esfuerzo se ha ido.

La razón de toda esta ceremonia alrededor del hands-offs, opiniones, y cosas semejantes es más tarde en el ciclo de vida de entrega de software, detectar un defecto -o introducir un cambio- es más caro que ir por el camino correcto. Y no sólo un poco más – de hecho, la evidencia empírica en los últimos años ha demostrado que es exponencialmente más caro cuanto más tarde se averigua.

Con esto en mente, tiene sentido de adelantar el proceso. Queremos asegurarnos de que hemos reflexionado sobre los posibles resultados y cubierto todos los ángulos de manera temprana para que no nos sorprendamos por “desconocidos desconocidos” al final del día.

Están también, por supuesto, las cuestiones de la rendición de cuentas y responsabilidad cuando las cosas van mal inevitablemente. En una organización con una cultura de culpa tradicional cada grupo tiene que ser capaz de demostrar que no era culpa de ellos: los analistas, los arquitectos, los programadores, testers, el equipo de operaciones y en última instancia, el director del proyecto. Esto hace que, al reunir a un grupo de personas para firmar una declaración de que un artefacto -un plan de proyecto, un documento de requerimientos, especificación funcional, código – cumple con el nivel adecuado de fiabilidad. Si algo va mal ahora, debe ser debido a un error humano (es decir, la incompetencia, y más importante incompetencia de otra persona ) más adelante en el proceso.

Pero esto no es toda la historia. Sin embargo somos diligentes en cada una de las fases de desarrollo, cualquiera que haya entregado el software de manera tradicional hará constar la cantidad de trabajo que ocurre “debajo del radar”. El equipo de programación firma el plan del proyecto, resplandeciente en su detalle, las dependencias, los modelos de recursos, y gráficos de Gantt. Entonces los analistas comienzan a recibir a los apretones el detalle del problema y decir cosas como: “Hmm, esto parece estar más complicado de lo que pensábamos. Nos gustaría mejorar el plan, esta va a ser algo grande. ”

A continuación, los arquitectos empiezan a trabajar sobre sus características funcionales, que descubren una serie de preguntas y ambigüedades sobre los requisitos. ¿Cómo estos datos se refieren a esa pantalla? ¿Qué pasa si este mensaje no es recibido por ese otro sistema? A veces los analistas de inmediato pueden responder a la pregunta, pero más a menudo que significa que necesitamos más tiempo de análisis y por lo tanto más de los analistas. Mejor actualización de dicho plan. Y conseguir que fuera firmado. Y firmar el nuevo documento, mayores exigencias.

Usted puede ver cómo este costo de coordinación puede montar rápidamente para arriba. Por supuesto que realmente se inicia durante la fase de prueba. Cuando el probador plantea un defecto, el programador pone sus manos en el aire y dice que hizo lo que había en la especificación funcional, el arquitecto culpa al analista de negocios, y así, sobre derechos de copia de seguridad de la cadena. Es fácil ver donde este coste exponencial viene.

En este ir y venir se convierte más en una carga, nos volvemos con más miedo de hacer cambios, lo que significa que la gente hace el trabajo fuera del proceso y los documentos fuera de sincronización entre sí y con el propio software. Las Pruebas se comprimen, la gente trabaja tarde en la de noche, ya la liberación del software se caracteriza generalmente por llanto y el crujir de los dientes, los ojos inyectados en sangre, y varios intentos fallidos de descifrado las instrucciones de las notas de publicación.

Esto se ve agravado por el hecho de que las personas suelen trabajar en una fase de un proyecto y luego seguir adelante, así que para cuando el probador está señalando los defectos que el analista de negocios hace tiempo que se unió a un proyecto diferente y ya no está disponible.

Una profecía autocumplida

En resumen, los proyectos se vuelven exponencialmente más caros al cambior cuanto más nos adentramos en ellos, debido al efecto acumulativo de mantenimiento de todos los artefactos de proyecto en sincronía, por lo que adelantar el proceso con una gran cantidad de planificación para mitigar los riesgos, actividades de análisis y diseño para reducir la posibilidad de reelaboración.

Ahora, ¿cuántos de estos artefactos (el plan del proyecto, la especificación de requisitos, la alta y documentos de diseño de bajo nivel, el software en sí) existían antes de que comenzó el proyecto? Eso es, exactamente ninguno! Así que todo ese esfuerzo -que crece exponencialmente- se debe a que ejecutamos los proyectos de la manera en que hacemos! Así que ahora tenemos una situación de gallina y el huevo o un bucle de refuerzo en la Terminología del Pensamiento Sistémático.

La ironía del enfoque tradicional de los proyectos es que el propio proceso hace el coste exponencial de cambio! Cuando les preguntamos a nuestros jefes de proyecto la forma en que planifican este coste exponencial de los cambios que nos dicen es “a través de la experiencia.”
Han visto suficiente de proyectos en situaciones bastante pasar por el mismo dolor.

La respuesta de nuestra industria ha de ser reforzar el bucle en lugar de intentar algo que podría romper el ciclo completo. Sin embargo el desarrollo de software es todavía una industria muy joven, así que ¿de dónde viene esta curva de costes, en primer lugar?

Yendo más profundo, resulta que la curva se origina en la ingeniería civil. Tiene sentido que es posible que se desee pasar mucho tiempo en las fases de diseño de un puente o una embarcación. Una vez que los pilares de hormigón estén armados, si se hunden y la infraestructura de hierro fundido está en su lugar, las cosas se vuelven muy caras de corregir!

Sin embargo, estas normas sólo se aplican al desarrollo de software, porque se lo permitimos! El software es, así, suave. Se supone que es la parte que es fácil de cambiar, y con el enfoque correcto y algunas herramientas decentes puede ser muy maleables. Así que utilizando la metáfora de la ingeniería civil e igualando software con acero y concreto, nos hemos hecho a nosotros mismos un flaco favor.

Seguir leyendo la tercera 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