Una introducción a la agilidad.

Los clientes no siempre saben lo que quieren -o necesitan-. Como dijo una vez Henry Ford, si hubiera preguntado a la gente qué querían, habrían dicho “caballos más rápidos”.

Por supuesto, Ford les dio coches. Pero imagínate si no lo hubiera hecho. Se habrían perdido años intentando satisfacer esa demanda. Lo más probable es que, para cuando el producto de Ford llegara al mercado, alguien más ya hubiera empezado a vender coches baratos y fiables. Su producto habría muerto nada más llegar.

En este resumen hablaremos de desarrollo de software, no de coches. Pero analizaremos el mismo problema. Ese problema puede resumirse en una sola pregunta: ¿Cómo entregas un producto valioso a tu cliente, aunque no pueda decirte lo que realmente quiere o necesita? 

Una respuesta es el conjunto de prácticas y principios conocidos como ágiles. Si has oído esa palabra antes, probablemente también te hayas topado con algunos conceptos relacionados, como scrum, kanban, XP y lean. A menudo, existe la tentación de apresurarse a hablar de estas metodologías junto con las ágiles.

Para Andrew Stellman y Jennifer Greene, autores de Aprender Agile, eso podría poner el carro delante de los bueyes. Al fin y al cabo, no tiene sentido entrar en los detalles si no hemos demostrado por qué tú y tu organización deberíais plantearos ser ágiles en primer lugar. Así que eso es lo que haremos en este resumen: analizar el por qué de lo ágil.

Para ello, seguiremos un proyecto de principio a fin. Por el camino, veremos cómo los principios ágiles pueden ayudar a un equipo de desarrolladores de software a trabajar de forma más eficiente y eficaz, y a ofrecer un producto mejor.

Es fácil ver por qué son tan populares. El objeto en sí tiene el tamaño de un libro de bolsillo normal, pero en él caben miles de libros. Aún mejor, cada texto responde a ti, el lector. Puedes ampliar las palabras, cambiar el tipo de letra o saltar hacia delante y hacia atrás entre el texto principal y las referencias. Con un solo clic, puedes acceder a bibliotecas y catálogos; con otro clic, puedes tomar prestados o descargar nuevos libros en tu dispositivo. 

En resumen, se trata de un gran software. Está bien diseñado. Cómodo. Intuitivo. Satisface a todas las partes interesadas. Los lectores lo encuentran fácil de usar, y muestra los textos con precisión, lo que es importante para los autores. También ayuda a los libreros y editores a vender y distribuir libros.

Sin embargo, los primeros lectores de libros electrónicos no hacían todas estas cosas. De hecho, se necesitó más de una década de desarrollo antes de que el software llegara a donde está hoy. A principios de la década de 2000, no estaba claro qué haría valioso a un lector de libros electrónicos. Sólo lo sabemos hoy porque la retrospectiva es 20/20 – lo que nos lleva a nuestro pequeño experimento mental.

Volvamos atrás en el tiempo. Imagina que nos encargan desarrollar el software para mostrar libros electrónicos en los nuevos dispositivos portátiles. ¿Cómo abordaremos nuestra tarea?

Bueno, en realidad vamos a hacerlo de la peor forma posible, porque ésta no es la clase de empresa que explora nuevas formas de crear software. Se trata de una operación de la vieja escuela, con líderes que dirigen y seguidores – eso somos nosotros, los desarrolladores – que siguen. En resumen, no es el tipo de oficina donde oirás la palabra “ágil”. Así que veamos cómo se desarrollan las cosas.

El equipo de hardware ya ha fabricado un prototipo. Imagínate una tableta negra y gruesa con un puerto USB para cargar libros y un pequeño teclado para interactuar con el lector. A nosotros nos toca crear el software que mostrará los libros electrónicos en este artilugio.

Nuestra empresa aplica a sus proyectos lo que se conoce como proceso en cascada. Esto significa que los proyectos se cargan en la parte delantera. Todos los requisitos del producto se definen al principio. Como hemos dicho, los líderes dirigen y los seguidores siguen. Todas las partes interesadas -los gerentes, los representantes de las editoriales, los minoristas en línea, etc.- se sientan y elaboran un plan. Esbozan los requisitos y elaboran una especificación que cumpla todos sus requisitos respectivos. Todas las demás fases del proceso, desde el diseño hasta el desarrollo y las pruebas, fluyen aguas abajo de estas decisiones, igual que una masa de agua fluye aguas abajo de una cascada.

Entonces, ¿qué hay en la especificación? En una palabra, todo. Este lector de libros electrónicos va a ser revolucionario. Tendrá montones de funciones. Captará estadísticas de mercado para los editores. Tendrá un escaparate en Internet para que los lectores compren libros. Los autores podrán previsualizar y editar sus libros mientras los escriben. Y todo estará listo en 18 meses.

Un año y medio más tarde. Como se trata de un experimento mental, no tenemos que ser realistas, así que diremos que el proyecto se completa a tiempo. Y todo está ahí – cada requisito de la especificación se ha implementado, probado y verificado. Todo el mundo está contento.

¿Puedes adivinar qué ocurre a continuación? El lector sale al mercado… y fracasa. Rotundamente. Nadie lo compra.

¿Qué salió mal?

La cuestión es que las necesidades de la gente no son estáticas – cambian con los tiempos. Si tu única opción es un caballo, quieres un caballo más rápido. Pero un caballo, por muy rápido que sea, no sirve de mucho si los demás ya conducen coches. Del mismo modo, el software que la gente necesitaba hace 18 meses no es el software que necesita hoy. Desde que comenzó nuestro proyecto, ha surgido una nueva norma industrial para los libros electrónicos. Ningún minorista quiere publicar nuestro formato no estandarizado: es demasiada molestia. Así que ninguna de nuestras revolucionarias funciones es compatible, lo que significa que no son útiles para nadie.

Esto también significa que hemos perdido mucho tiempo y dinero creando un software que no es muy valioso. Entonces, ¿qué deberíamos haber hecho de otra manera?

Lanza hoy un software imperfecto y mañana tendrás un producto final mejor.

Aquí es donde nos equivocamos: no fuimos receptivos. Pasamos 18 meses trabajando en una burbuja para poner en práctica un plan que estaba desfasado incluso antes de llegar al mercado. No hubo ajustes. No fuimos flexibles. Nuestro proyecto, en resumen, no era iterativo.

Un proceso de diseño iterativo no tiene lugar en el vacío. En su lugar, lanza productos rápidamente, haciéndolos llegar a los clientes lo antes posible y recogiendo opiniones. Estos comentarios son la base de las mejoras, que luego se envían de nuevo a los clientes -de nuevo, lo antes posible- para que puedan aportar nuevos comentarios. En ese momento, el ciclo se reinicia. Al fin y al cabo, iterar significa “realizar repetidamente”.

Este bucle de retroalimentación está en el corazón de los procesos ágiles. Piensa en la palabra “agilidad” tal y como la utilizamos en el lenguaje cotidiano. Describe una forma de moverse rápida y ágilmente, de responder al entorno y de comprometerse con lo que tienes delante. Un escalador ágil, por ejemplo, responde a cada mano y punto de apoyo que encuentra. Realiza ajustes rápidos para evitar resbalones y agarres torpes. Lo mismo ocurre con el diseño ágil de software. Los equipos ágiles utilizan procesos iterativos para responder rápida y ágilmente a los errores y confusiones a medida que los encuentran. Puede que no construyan el software que se propusieron, pero eso es mucho mejor que construir algo inútil.

Este es el primer principio de la agilidad. Podemos expresarlo así: La máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso. 

Ahora, desglosemos ese principio aún más. 

El software sólo puede construirse en el mundo real: el mundo de los humanos imperfectos. Incluso los equipos más trabajadores pasan por alto detalles importantes. Los desarrolladores con más talento no consiguen anticipar requisitos vitales. La única forma de corregir los errores es poner el software que estamos construyendo en manos de los clientes: las personas que realmente lo van a utilizar. Como desarrolladores, dependemos totalmente de sus comentarios. Por eso tenemos que lanzar el software pronto.

Liberar software pronto no es sólo un antídoto contra el perfeccionismo, sino que aporta valor a los clientes. Si hoy disponen de una sola función, por muy buggy que sea, pueden hacer algo que ayer no podían. Al utilizar realmente un producto, pueden aclarar sus necesidades. Eso significa que podrán darnos una idea más clara de lo que quieren que haga un producto. Y una vez que estemos inmersos en este bucle de retroalimentación, estaremos en camino de crear un producto final que realmente satisfaga esas necesidades.

Afrontar el cambio consiste en adoptar la mentalidad adecuada.

Así que ahí está la respuesta a la pregunta que nos hacíamos antes – lo que deberíamos haber hecho es poner nuestro software en manos de los clientes, para que realmente pudieran utilizarlo y darnos su opinión. Si lo hubiéramos hecho, nos habríamos dado cuenta de que había un problema y habríamos cambiado de rumbo. Eso nos habría ahorrado el tiempo, el esfuerzo y el dinero que invertimos en construir un fracaso caro.

Por supuesto, cambiar de rumbo a mitad de un proyecto es más fácil decirlo que hacerlo. En la práctica, suele ser una experiencia dolorosa y desagradable. Ya has tomado las decisiones difíciles. Sabes lo que estás construyendo. Sabes lo que esperan tus clientes. Tu flujo de trabajo está establecido. No es un camino de rosas, exactamente, pero estás haciendo progresos. Y entonces llega alguien ajeno al proyecto y te dice que has ido por el camino equivocado todo el tiempo. Que toda esa planificación y trabajo no han servido para nada. Que tienes que volver atrás y empezar de nuevo. Peor aún, ¡la persona que te dice que cambies de rumbo es la misma que te puso en ese camino en primer lugar! Te dijeron que construyeras una cosa, y ahora que has construido la mitad, te dicen que hagas otra. Es desmoralizador, incluso irrespetuoso. No es de extrañar que te pongas a la defensiva y te resistas a hacer cambios.

¿Incomprensible? Claro. ¿Ayudable? En absoluto. Sin embargo, la pregunta importante es: ¿cómo puedes superar esta sensación?

Bueno, es una cuestión de mentalidad, y tiene dos partes. La primera es aceptar que es muy difícil crear software valioso si no estás constantemente comprobando -y revisando- tus previsiones. Sí, cambiar de rumbo a mitad de un proyecto es frustrante, pero no es ni mucho menos tan desalentador como llegar al final de un proyecto y darte cuenta de que has construido una chatarra.

La segunda parte consiste en aceptar que es muy difícil construir un software valioso si no estás constantemente comprobando -y revisando- tus previsiones.

La segunda parte trata de la perspectiva, y adopta la forma de un ejercicio.

No siempre es un ejercicio fácil: requiere tener la cabeza fría y más empatía de la que te gustaría mostrar hacia la persona que acaba de arruinarte el día. Pero puede ser esclarecedor. Empieza haciéndote estas dos preguntas: En primer lugar, ¿te ha enviado tu cliente deliberadamente por el camino equivocado? Probablemente no, ¿verdad? Y en segundo lugar, ¿cómo se sintió cuando se dio cuenta de que había metido la pata y te había costado meses de trabajo? Lo más probable es que se sintieran bastante avergonzados. Probablemente no quisieron acudir a ti y admitir su error. Sin embargo, es una buena cosa que lo hicieran: ¡te han ahorrado aún más tiempo perdido! Y no sólo se ha estropeado tu plazo. El plazo de tu cliente también se ha retrasado. Su empresa se está gastando un buen dinero en crear un software que satisfaga sus necesidades, y este error significa que el proyecto no se está cumpliendo. En otras palabras, esto es frustrante para todos.

A la hora de la verdad, ambos estáis en una situación difícil. La única forma en que teóricamente podrías evitar las meteduras de pata sería leer la mente de tu cliente. Tu cliente, a su vez, tendría que ser capaz de predecir el futuro. En un mundo ideal, ambos seríais capaces de hacer esas cosas. Pero el software no se construye en un mundo ideal; no trabajarás con clarividentes telepáticos. Acéptalo, y los errores -junto con los cambios que conllevan- serán mucho más fáciles de tratar. 

Los procesos iterativos te mantienen en contacto con tus clientes.

Bien, volvamos al punto de partida. ¿Cómo pueden ayudar los principios ágiles que hemos explorado a nuestro problemático proyecto de lector de libros electrónicos? Averigüémoslo ejecutando el proyecto de nuevo.

Primero, recordemos por qué fracasó ese lector. Carecía de algunas características importantes utilizadas por los lectores de libros electrónicos de la competencia, como la compatibilidad con un formato estándar del sector. Sin embargo, ten en cuenta que este problema no se podía prever ni evitar. Cuando nuestro equipo se puso a trabajar, no existía ningún estándar industrial. Nuestro énfasis, por tanto, tiene que estar en la responsabilidad del equipo ante lo que descubre una vez que su trabajo ya ha comenzado. 

Esta vez, el proyecto va a ser ágil. Empezaremos con una gran reunión en la que discutiremos los requisitos y las especificaciones, pero no vamos a ceñirnos a ese plan durante 18 meses seguidos. En lugar de eso, dividiremos ese año y medio en impresiones de un mes, un único ciclo del bucle de retroalimentación del que hemos hablado antes. Dicho de otro modo, vamos a actualizar nuestro diseño en respuesta a los comentarios cada mes.

Por supuesto, al principio no habrá mucho que probar, así que avanzaremos hasta el cuarto sprint. Cuando el gerente del proyecto, el equipo y las partes interesadas se reúnen, uno de los desarrolladores informa de que existe una nueva norma industrial para los formatos de libros electrónicos. El equipo incorpora esta nueva información en su siguiente sprint y crea una biblioteca compatible con el nuevo formato. En el sexto sprint, ya está listo para incorporar ese formato a la interfaz de usuario del lector.

Como puedes ver, cada sprint se corresponde aproximadamente con cada iteración o versión del software que el equipo está construyendo. Así que saltemos al undécimo mes, el undécimo sprint y la undécima iteración. Ahora tenemos una versión funcional, que puede cargarse en los prototipos que el equipo de hardware ha creado. Tiene errores, pero es lo suficientemente buena para las pruebas en el mundo real, que es exactamente lo que quiere el equipo. Cuando la gerente del proyecto habla con los primeros usuarios del software, se entera de que les gustaría poder enviar por correo electrónico artículos de prensa y archivos PDF a sus dispositivos. Ese es el objetivo del próximo sprint del equipo.

Sin embargo, este enfoque no consiste sólo en probar e incorporar nuevas funciones – algunas funciones también pueden descartarse. Por ejemplo, quizá ese escaparate de Internet no tenga sentido. Al fin y al cabo, existe un formato de libro electrónico estandarizado, así que no tenemos que crear una plataforma única propia. Eso es útil porque libera tiempo para trabajar en otras características más importantes.

Es mucho más probable que esta versión del proyecto acabe bien. Hemos estado lanzando continuamente software para probarlo en el mundo real y haciendo cambios oportunos en respuesta a esas pruebas. La gran diferencia aquí es que estamos en contacto con los clientes y usuarios. Cuando utilizábamos el proceso en cascada, estábamos completamente aislados de estos grupos una vez aprobados los requisitos del proyecto. Esta vez, sin embargo, no hemos perdido de vista nuestro objetivo final: construir un software valioso y funcional que satisfaga necesidades reales. Y ese es el porqué de lo ágil.

Conclusiones

Acabas de terminar nuestro Resumen de Aprendizaje de lo ágil, de Andrew Stellman y Jennifer Greene.

El mensaje clave aquí es que:

Hay muchas formas de trabajar de forma ágil, pero todos los enfoques se basan en los mismos principios fundamentales. El primero es la capacidad de respuesta. Los procesos ágiles se basan en la retroalimentación. No esperas al final de un proyecto para probar el software que has creado, lo pones en marcha lo antes posible. Las pruebas en el mundo real identifican pronto los problemas y ayudan a tu cliente a aclarar lo que necesita que haga ese software. ¿El segundo principio? No existe el plan perfecto. Cada proyecto requerirá correcciones, cambios y rediseños ad hoc. Pero eso es bueno: así es como se construye el mejor software.