¿Puede ser ágil un caracol?

Como algunos ya sabréis, esta semana he participado junto a y en el lanzamiento de una campaña llamada . Entre otras muchas cosas, está siendo una experiencia de la que estoy aprendiendo mucho. Trabajar con una antropóloga y un diseñador es algo mucho más complicado de lo que yo me imaginaba al principio sobre todo porque muchas veces nuestros presupuestos son muy diferentes e incluso en ocasiones divergentes. (Y del lenguaje ese gótico que usan, ni contaros…) :-)

Sin embargo, está siendo una de las experiencias más excitantes y enriquecedoras de mi vida, no sólo de mi vida profesional, sino también de mi vida personal. Pedro y Maica, además de polifacéticos, son personas tremendamente exigentes y con unos puntos de vista muy creativos, tanto que a veces me dejan tan descolocado que no soy capaz de seguirlos. Pero a la vez son muy generosos y capaces de tener paciencia, explicar su punto de vista, escuchar los puntos de vista de los demás, e incluso dar una oportunidad aunque no lo vean nada, nada, nada claro. Eso no significa que todo vaya como la seda. Somos un equipo con personalidades muy fuertes y eso a veces nos para. Pero lo más bonito de este proyecto está siendo cómo, especialmente en esos casos de disensiones profundas, nos detenemos a analizar el porqué y tratamos de aprender de ello.

Voy a poner un ejemplo. es, no voy a desvelar ningún secreto a estas alturas, una campaña que trata de comunicar, de una manera desenfadada, valores que nos parecen interesantes como los del Movimiento Slow, el Decrecimiento, la recuperación de las tradiciones populares, etc. Es una campaña que tiene un ritmo diferente a las campañas que estamos acostumbrados a ver: campañas explosivas que tratan de captar muchos usuarios y ser trending topic en menos de una hora. Nosotros empezamos (casi sin quererlo, para ser honestos) hace ya algunas semanas con aquello del que habréis visto alguna que otra vez en vuestro timeline si me seguís por twitter. Sin embargo, es curioso cómo, a pesar que los tres estamos muy motivados por esta idea de “lo lento”, hemos caído en muchos de las trampas del tiempo en este tipo de proyectos. Nos hemos puesto fechas y ¡hemos corrido detrás de ellas!.

- ¡Ay, Beas! ¿No decías que eras agilista? :(

Pues sí, ya véis, en casa de herrero, cuchillo de palo. No hemos respetado la revisión de la segunda iteración.

- ¡Beas, Beas! ¿Agilista tú? ¡Vamos, anda! :(

Estamos aún en el proceso de retomar nuestro ritmo sostenible. Pero en vez de echarnos las manos a la cabeza, volvernos locos y seguir improvisando o tirarnos trastos unos a otros, nos hemos reunido, hemos visto qué podíamos hacer para recuperar el ritmo y dónde estabamos patinando más. Nos hemos preocupado también de si la campaña estaba funcionando también o no, hemos tomado decisiones para ir corrigiendo, pero con tranquilidad porque es una campaña lenta. :)

- ¿Es eso una retrospectiva? No lo parece :(

¡Ejem! Bueno, ya sé que va a sonar a excusa de “todo a 100″ pero es que no somos un equipo con dedicación exclusiva y no es nuestra prioridad DEFCON 1. Además, uno de los objetivos que nos hemos marcado Maica, Pedro y yo es no aplicar ninguna práctica ni metodología porque sí. Lo mismo aplica a la retrospectiva. De momento hacemos el seguimiento del proyecto de manera iterativa, con revisiones semanales del avance (sería algo así como la “demo” en un desarrollo con Scrum), revisiones del proceso desde un punto de vista de equipo y metodológico (que de momento implementamos como una retrospectiva formal) y la replanificación de los alcances (que vendría a ser como la sprint planning meeting de Scrum). Y además, hacer encajar Scrum en este tipo de proyectos es tremendamente complicado:

  • no estamos llevando un único proyecto adelante ( es sólo uno de ellos),
  • sólo somos tres personas en el equipo (cosa que afecta sobre todo a las dinámicas y al reparto de actividades),
  • estamos repartidos geográficamente (Pedro está en Sevilla),
  • no todos tenemos experiencia en un desarrollo iterativo e incremental de un proyecto,
  • todos somos equipo, dueño de producto y cliente a la vez (lo peor con diferencia) :-)

Pero seguiremos trabajando en ello porque es uno de los objetivos que perseguimos. Entre otras cosas estamos empeñados en ver de primera mano los retos que un equipo pequeño de emprendedores se encuentra a la hora de sacar a la calle un producto, con poco tiempo y mucha presión. Cómo manejar la incertidumbre y el feedback (o la carencia del mismo) es algo donde los principios ágiles y los principios lean nos están siendo de mucha ayuda. Con estamos aprendiendo mucho y lo aplicaremos en el futuro. Stay tuned!

P.S.
Por favor, no dejéis de ayudar al pobre Félix. ;)

Diseño emergente

Mientras preparaba una sesión del curso online de Lean Software Development que imparte Alan Shalloway tuve que leer un artículo de él mismo titulado algo así como “Guía para desarrolladores ágiles sobre Lean Software Development” (traducción libre). En este artículo se recopilan detalles interesantes como los principios fundamentales del desarrollo de software “lean” (Nota: demonios, necesito una traducción para este término), pero lo que quizás más me ha gustado ha sido la definición de Diseño Emergente.

Shalloway explica que al abordar un diseño hay básicamente dos opciones: diseñar estríctamente para cubrir los requerimientos (con lo que el código resultante irá siendo progresivamente más difícil de mantener) o diseñar pensando en el futuro (con lo que frecuentemente introducimos más complejidad de lo necesario). Aquí introduce Shalloway una tercera opción que denominamos Diseño Emergente y que resulta de la combinación de tres disciplinas (ojo, dice disciplinas):

  • basar el diseño en patrones para crear arquitecturas resistentes y flexibles a la vez, abaratando así el coste de mantenimiento del código
  • limitar el diseño sólo a los requisitos actuales (no adelantarse a requisitos futuros), consiguiendo así reducir el tamaño y complejidad del código
  • escribir pruebas de aceptación y unitarias automatizadas antes de escribir el propio código, favoreciendo así la construcción de un mejor diseño y haciendo que sea más seguro aplicar cambios

Shalloway también dice que el Diseño Emergente nos ayuda a añadir código nuevo desacoplado del viejo pero sin incorporar complejidades innecesarias. Esto, dicho así, puede resultar un poco difícil de entender, pero en el contexto de desarrollos iterativos tiene mucho sentido.

Trabajar sin un diseño completo desde el principio es algo incómodo por el nivel de incertidumbre que se maneja, pero si lo pensamos fríamente, es muchor mejor postergar las decisiones de diseño mientras tengamos dudas sobre los requisitos. En cualquier caso, me gustaría añadir que trabajar con un Diseño Emergente NO significa trabajar SIN diseño o con un diseño IMPROVISADO. Me remito a las tres disciplinas que enumera Shalloway:

Patrones de diseño

Emplear patrones de diseño contribuye definitivamente a que tengamos un diseño fácil de transimitir (incluso fácil de documentar). (Nota para los arquitectos: es una buena práctica documentar con gran detalle los patrones empleados -aunque no sean del GoF y nos los hayamos “inventado”- y pedir a los desarrolladores que documenten en su código qué piezas de los patrones están implementando.)

Por otro lado, los patrones de diseño nos permiten construir soluciones extensibles puesto que no resuelven nuestro problema sino un problema más general.

Me gustaría añadir que también podemos añadir patrones de análisis (ver libro de Fowler “Analysis Patterns“, p.ej.) a nuestra caja de herramientas con el objetivo de ser capaces de plantear el diseño más adecuado a nuestro problema, pero con la “puerta abierta” a futuras necesidades.

No adelantarse al futuro

Nuestro pequeño gran ego de programador nos empuja indefectiblemente a demostrarle al mundo entero lo listos que somos al ser capaces de ver el futuro y adelantarnos a todos prediciendo las necesidades de los clientes. Para ello solemos diseñar soluciones tan virtuosas como inútiles para el 80% de las necesidades reales de los clientes. Frecuentemente nos encontramos con diseños que transforman datos entre capas una y otra vez hasta llevarlas a la base de datos, validando una y otra vez los datos (antes y después de persistirlos)… aunque esos datos en realidad el cliente nunca los ha necesitado guardar. Alguien decidió en algún momento que era mejor guardarlo todo “por si acaso” y la consecuencia es un código tremendamente difícil de explicar, con muchos defectos de desarrollo y un rendimiento muy mejorable. Muchas veces somos nosotros mismos los que diseñamos así: “por si acaso”.

Pues bien, está demostrado que es mejor no diseñar “por si acaso”. En la mayoría de las ocasiones no estamos haciendo una inversión sino introduciendo complejidad que nunca se verá compensada. En términos económicos eso no es rentable.

Propongo que hagáis el ejercicio de identificar algunas de esas “características avanzadas” que se incorporan “por un pequeño esfuerzo más” y que al final del proyecto nunca se han utilizado. Si además sois capaces de saber cuánto ha sido ese “pequeño esfuerzo más”, quizás lo podáis sumar a los defectos y retrasos provocados por esas “características avanzadas”. Claro, un diseño sin “características avanzadas” es menos “cool”. :-)

Pruebas automatizadas

Muchísimas veces me he encontrado con que teníamos tanto miedo de hacer cambios en el diseño que retorcíamos el diseño existente hasta límites insospechados. En ocasiones, cambiar aquí hacía que allí dejara de funcionar. Lo más terrible era cuando nos enterábamos de ese impacto cuando nos llamaba el cliente para decirnos que les había salido un mensaje muy extraño en la pantalla…. Ay, si hubieramos contado con un conjunto de pruebas automatizadas que cubrieran los requisitos de nuestros clientes…

Hoy día, este problema está claramente superado, si no tenemos un motor de integración continua y desarrollamos nuestras pruebas unitarias y de aceptación es o porque no sabemos o porque no queremos, pero no nos podemos escudar en que no es posible o que es muy costoso.

Instalar Hudson, Continuum o CruiseControl se hace en dos patadas y desarrollar pruebas unitarias con JUnit o TestNG está ampliamente documentado. Si tenéis un frontal web podéis usar Selenium, HttpUnit o algún otro framework similar. Si tenéis web services podéis usar SoapUI o haceros vuestro propio framework “ad hoc” basándolo en HttpUnit, por ejemplo. Y finalmente, para escribir las pruebas de aceptación tenéis desde el viejo Fit (o Fitnesse) hasta Concordion (lógicamente mi recomendación) o incluso easyb o jBehave. Para cada clavo seguro que tenéis vuestro martillo.

Pero Shalloway va un poco más allá y pide escribir las pruebas ANTES que el código. Hay mucho escrito sobre TDD (test-driven development), ATDD (acceptance test-driven development) o BDD (behaviour-driven development), pero os puedo asegurar que practicar el “red-green-refactor” termina dando como resultado diseños y código de mucha mejor calidad, con el beneficio añadido de que tenemos una estupenda red de seguridad formada por las pruebas que hemos ido escribiendo para explicar qué queríamos que hiciera el software y no para explicar lo que ya hacía el software. Además, reducimos el número de defectos y, yo no sé a vosotros, pero a mi no me gusta nada estar resolviendo defectos… a mis jefes tampoco. :-)

Proceso de descubrimiento

Otra afirmación de Shalloway con la que estoy muy de acuerdo es que:

El proceso de desarrollo de software es más un proceso de descubrimiento que de construcción.

Podría dedicar un artículo entero a esta afirmación pero sólo quiero señalar que parte de lo que se va
descubriendo durante este proceso es justamente el Diseño Emergente.

Viendo el desarrollo de software dentro del proceso mayor que lo engloba, el desarrollo del producto, podemos decir (simplificando mucho) que hay 3 fases para desarrollar un producto:

  • descubrir las necesidades del cliente
  • imaginar cómo construir los artefactos que cubrirán esas necesidades
  • construir los artefactos

Shalloway explica muy bien en su artículo cómo empleamos un gran esfuerzo en las dos primeras fases a pesar de que normalmente no somos casi ni conscientes (¿inconscientes?) de ello. Si de repente tuvieramos la oportunidad de reconstruir nuestro sistema tardaríamos digamos un 50%-80% menos del tiempo empleado la primera vez. Ese tiempo “perdido” es el correspondiente a las dos primeras fases: descubrir necesidades y diseñar los artefactos.

El artículo de Shalloway del que he extraído las principales ideas que os he comentado es mucho más rico porque recorre los principios fundamentales de “Lean” y va mostrando qué prácticas ágiles surgen a partir de ellos. Esta muy bien porque así es posible tener un fundamento teórico para unas prácticas y, cuando en ocasiones no es posible aplicarlas, podemos sustituirlas por otras pero respetando los principios, es decir, buscando los mismos beneficios. También compara los procesos de producción JIT (just-in-time) con los procesos ágiles de desarrollo de software, pero esto casi merece otro artículo sólo para él.

Estaría encantado de conocer vuestras opiniones.

Seminario gratuito sobre Lean Software Development

Han extendido la fecha para registrarse en un seminario online titulado “Free Online Lean Training“, organizado por Alan Shalloway (NetObjectives) y que se celebrará en seis sesiones virtuales de dos horas hasta mediados de Abril. Requiere un buen nivel de inglés y un cierto trabajo previo antes de cada sesión pero creo que merece la pena porque pretende aportar a los que ya practicamos (o creemos que practicamos) el agilismo, una base teórica-científica para que dejemos de guiarnos por creencias y pasemos a aplicar y poner a prueba principios que residen en una teoría: Lean (que me atrevo a traducir como “ajustada”, en el sentido de “desarrollo o producción ajustado”).

El proceso para registrarse es un poco laborioso (hay que registrarse en varios grupos de Yahoo! y además en el wiki que NetObjectives está preparando para dar soporte al curso) y además añadirse a alguno de los grupos de “asistentes” al curso (en España ya hay al menos dos grupos en el momento de escribir esto).

Gracias a Jorge Uriarte por ponernos en Agile Spain sobre la pista.