Después de varias semanas de retiro en las lejanas tierras de Huelva, obligado por razones familiares, y después del fenomenal éxito del libro “Diseño Ágil con TDD” que mi buen amigo Carlos Blé me ha dejado prologar, debo reconocer que ahora mismo no tengo mucho que aportar en este blog salvo extraer ese prólogo. Me siento bastante orgulloso de él, no sólo porque es original, sino porque creo que resume bastante bien cómo enfocar un desarrollo de software guiado por las pruebas además de reflejar el espíritu del cambio (aunque tardío) que se está produciendo en nuestro sector y que desde iniciativas como Agile Spain o agilismo.es trato de apoyar en primera persona. Espero que os guste:
Érase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián, que además eran hermanos. Ambos eran los cerditos más listos de la granja y por eso el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de ordenador para controlar el almacén de piensos. Les explicó que quería saber en todo momento cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes, pero les advirtió de que en una semana quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.
Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir lineas y lineas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera, pero bueno, esto del software va de reutilizar lo que ya funciona, ¿no?
Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabrían que efectivamente estaba terminada cada cosa. Iván quería poder conocer cuanto antes cuántos sacos de grano había en cada parte del almacén porque sospechaba que en algunas partes del almacén se estaban acumulando sacos sin control y se estaban estropeando. Como constantemente tenían que entrar y salir sacos del almacén, no podía saber cuántos había ahora mismo, así que acordaron ir contabilizando cuántos había en cada zona del almacén y que cada vez que entrara o saliera un saco apuntarían a qué zona iba o de qué zona venía. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.
Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván!
Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó además las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa, pero salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en ningún momento. Claro, todo lo que enseñó lo había probado muchísimas veces antes de hacer la demostración gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una linea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván. El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serían necesarias para lo que había pedido Iván, pero tenía un aspecto “muy profesional”.
Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un 50% más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré nada.”. Era una oferta complicada porque por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis. Mmmmm.
Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.
Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un webservice que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.
Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso aprovechó para anotar algunos criterios que luego les servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo. Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dió por concluida la reunión y se dispuso a trabajar. Antes que nada resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara. A continuación se marchó a casa a descansar. Al día siguiente, cogió la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había venido desde América a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y éste hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este Hudson era realmente veloz e incansable!
A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Le terminaron echando la culpa a todo el mundo. A Iván porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices porque no tenían ni idea de cómo funciona una granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y a partir de ahí generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco tiempo, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aun renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.
Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado. Les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez: “¿Qué estará haciendo Adrián? ¿Cómo lo llevará?”.
Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando, que cada vez que arreglaba una cosa le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde funcionaba a duras penas) y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados… y lo peor de todo: el programa no hacía lo que habían acordado con Iván.
Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.
Moraleja:
Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar “criterios de aceptación”, Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente.
En este libro que ahora tienes entre tus manos, y después de este inusual prólogo, te invito a leer cómo Carlos explica bien clarito cómo guiar el desarrollo de software mediante la técnica de escribir antes las pruebas (más conocido como TDD).
Un cordial saludo,
Jose Manuel Beas
Hacía tiempo que quería hacer un ejercicio interesante (al menos para mi) que consiste en hacer una codekata muy sencilla a pequeños pasos o, como dice Kent Beck en su libro “TDD: By Example“, con baby-steps. Me interesa estudiar cuáles son las fuerzas que empujan a refactorizar hacia un mejor diseño y para eso verlo en un ejercicio de laboratorio me parece ideal. En este sentido, también me interesa ver cómo se aplica la “Premisa de la Prioridad de las Transformaciones” expuesta recientemente por UncleBob.