Learning Agile (por Andrew Stellman y Jennifer Greene) es una guía sensata sobre un concepto que a menudo se malinterpreta: ágil. La razón de ese malentendido es simple: con demasiada frecuencia, Agile se presenta como una solución única para todas las dificultades organizacionales concebibles. Andrew Stellman y Jennifer Greene, practicantes ágiles desde hace mucho tiempo, no lo ven de esa manera. Para ellos, Agile es una gran herramienta, pero hay que saber cómo, cuándo y por qué, usarla. Y eso comienza con comprender los principios subyacentes de Agile.
Hay muchas formas de trabajar ágilmente, pero cada enfoque se basa en los mismos principios básicos. El primero es la capacidad de respuesta. Los procesos ágiles tienen que ver con la retroalimentación. No espera hasta el final de un proyecto para probar el software que ha creado: lo saca a la luz lo antes posible. Las pruebas del mundo real identifican los problemas de manera temprana y ayudan a su cliente a aclarar qué necesitan que haga ese software. ¿El segundo principio? No existe tal cosa como 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.
Una introducción al Aprendizaje Ágil
Los clientes no siempre saben lo que quieren o necesitan. Como dijo una vez Henry Ford, si le hubiera preguntado a la gente qué querían, habrían dicho «caballos más rápidos».
Por supuesto, Ford les dio autos. Pero imagina si no lo hubiera hecho. Se habrían perdido años tratando de satisfacer esa demanda. Lo más probable es que, para cuando el producto de Ford llegue al mercado, alguien más ya habría comenzado a vender autos baratos y confiables. Su producto habría estado muerto al llegar.
En este resumen, hablaremos de desarrollo de software, no de automóviles. Pero estaremos viendo el mismo problema. Ese problema se puede resumir en una sola pregunta: ¿Cómo entrega un producto valioso a su cliente, incluso si no puede decirle lo que realmente quiere o necesita?
Una respuesta es el conjunto de prácticas y principios conocidos como ágiles . Si ha escuchado esa palabra antes, probablemente también haya encontrado algunos conceptos relacionados, como scrum , kanban , XP y lean . A menudo, existe la tentación de apresurarse a discutir estas metodologías junto con las metodologías ágiles.
Para Andrew Stellman y Jennifer Greene, los autores de Learning Agile , se corre el riesgo de poner la carreta delante del caballo. Después de todo, no tiene sentido entrar en el meollo de la cuestión si no hemos demostrado por qué usted y su organización deberían siquiera considerar ágil en primer lugar. Así que eso es lo que haremos en este resumen: ver el por qué de la agilidad.
Para ello, seguiremos un proyecto de principio a fin. En el camino, veremos cómo los principios ágiles pueden ayudar a un equipo de desarrolladores de software a trabajar de manera más eficiente y eficaz, y a ofrecer un mejor producto.
Las metodologías de Aprendizaje Ágil
No se puede diseñar un buen software en el vacío.
Hablemos de los lectores de libros electrónicos por un segundo.
Es fácil ver por qué son tan populares. El objeto en sí tiene aproximadamente el tamaño de un libro de bolsillo normal, pero contiene miles de libros. Aún mejor, cada texto responde a usted, el lector. Puede ampliar las palabras, cambiar la fuente o saltar entre el texto principal y las referencias. Con un solo clic, puede acceder a bibliotecas y catálogos; con otro clic, puede tomar prestados o descargar nuevos libros en su dispositivo.
En resumen, este es un gran software. Está bien diseñado. Conveniente. Intuitivo. Satisface a todas las partes interesadas. Los lectores lo encuentran fácil de usar y muestra los textos con precisión, lo cual 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 hicieron todas estas cosas. De hecho, tomó 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. Solo sabemos eso hoy porque la retrospectiva es 20/20, lo que nos lleva a nuestro pequeño experimento mental.
Retrocedamos en el tiempo. Imagine que se nos ha encomendado la tarea de desarrollar el software para mostrar libros electrónicos en dispositivos portátiles nuevos. ¿Cómo abordaremos nuestra tarea?
Bueno, en realidad lo haremos de la peor manera posible porque este no es el tipo de empresa que está explorando nuevas formas de crear software. Esta es una operación de la vieja escuela, con líderes que lideran y seguidores (somos nosotros, los desarrolladores) que siguen. En resumen, este no es el tipo de oficina donde escuchará la palabra «ágil». Así que vamos a ver cómo se desarrollan las cosas.
El equipo de hardware ya ha hecho un prototipo. Imagine una tableta negra gruesa con un puerto USB para cargar libros y un teclado pequeño y complicado para interactuar con el lector. Depende de nosotros crear el software que mostrará los libros electrónicos en este dispositivo.
Nuestra empresa aplica a sus proyectos lo que se conoce como proceso en cascada . Lo que eso significa es que los proyectos se cargan por adelantado. Todos los requisitos del producto se definen desde el principio. Como dijimos, los líderes lideran y los seguidores siguen. Todas las partes interesadas (los altos directivos, los representantes de publicaciones, los minoristas en línea, etc.) se sientan y elaboran un plan. Describen los requisitos y presentan una especificación que marca todas sus casillas respectivas. Todas las demás etapas del proceso, desde el diseño hasta el desarrollo y las pruebas, fluyen aguas abajo de estas decisiones de la misma manera que una masa de agua fluye río abajo desde una cascada.
Entonces, ¿qué hay en la especificación? En una palabra, todo . Este lector de libros electrónicos va a ser revolucionario. Va a tener toneladas de características. Capturará estadísticas de mercado para los editores. Tendrá una tienda en Internet para que los lectores compren libros. Los autores podrán obtener una vista previa y editar sus libros a medida que los escriben. Y todo va a estar listo en 18 meses.
Avance rápido un año y medio. Dado que se trata de un experimento mental, no tenemos que ser realistas, por lo que diremos que el proyecto se completó a tiempo. Y todo está ahí: todos los requisitos de la especificación han sido implementados, probados y verificados. Todos están felices.
¿Puedes adivinar lo que sucede a continuación? El lector golpea el mercado. . . y fracasa. Difícil. Nadie lo compra.
¿Qué salió mal?
La cuestión es que las necesidades de las personas no son estáticas: cambian con el tiempo. Si su única opción es un caballo, quiere un caballo más rápido. Pero un caballo, por rápido que sea, no sirve de mucho si todos los demás ya conducen automóviles. Del mismo modo, el software que la gente necesitaba hace 18 meses no es el software que necesitan hoy. Desde que comenzó nuestro proyecto, ha surgido un nuevo estándar de la industria para los libros electrónicos. Ningún minorista quiere publicar nuestro formato no estandarizado, es demasiado molesto. Y, por lo tanto, ninguna de nuestras características revolucionarias es compatible, lo que significa que no son útiles para nadie.
Esto también significa que hemos perdido mucho tiempo y dinero creando software que no es muy valioso. Entonces, ¿qué deberíamos haber hecho diferente?
Metodologías de Aprendizaje Ágil aplicadas a proyectos
Lance software imperfecto hoy y obtendrá un mejor producto final mañana.
Aquí es donde nos equivocamos: no respondimos. Pasamos 18 meses trabajando en una burbuja para implementar un plan que estaba desactualizado incluso antes de que llegara al mercado. No hubo ajustes. No éramos 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 recopilando comentarios. Esa retroalimentación es la base para las mejoras, que luego se envían a los clientes, nuevamente, lo más rápido posible, para que puedan proporcionar una nueva retroalimentación. En ese momento, el ciclo se reinicia. Después de todo, iterar significa «realizar repetidamente».
Este circuito de retroalimentación está en el corazón de los procesos ágiles. Piense en la palabra «agilidad» tal como la usamos en el lenguaje cotidiano. Describe una forma de moverse con rapidez y agilidad, de responder al entorno y comprometerse con lo que está frente a usted. Un escalador ágil, por ejemplo, responde a cada punto de apoyo para manos y pies que encuentra. Hacen ajustes rápidos para evitar resbalones y agarres torpes. Es lo mismo con ágil en el diseño de software. Los equipos ágiles usan procesos iterativos para responder rápida y ágilmente a errores y confusiones a medida que los encuentran. Es posible que no construyan el software que se propusieron construir, pero eso es mucho mejor que construir algo inútil.
Así que ahí está el primer principio de ágil. Podemos expresarlo así: la máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.
Ahora, analicemos ese principio aún más.
El software solo se puede construir en el mundo real: el mundo de los humanos imperfectos. Incluso los equipos más trabajadores se pierden detalles importantes. Los desarrolladores más talentosos no logran anticipar los requisitos vitales. La única forma en que podemos corregir los errores es poner el software que estamos construyendo en manos de los clientes, las personas que realmente lo usarán. Como desarrolladores, dependemos completamente de sus comentarios. Es por eso que necesitamos lanzar el software antes.
El lanzamiento anticipado de software no es solo un antídoto contra el perfeccionismo, sino que ofrece valor a los clientes. Si tienen una sola función hoy, por muy defectuosa que sea, pueden hacer algo que no podían hacer ayer. Al usar 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 estamos atrapados en este ciclo de retroalimentación, estamos en camino de crear un producto final que realmente satisfaga esas necesidades.
Aplicación de las Metodologías de Aprendizaje Ágil
Aceptar el cambio se trata de adoptar la mentalidad correcta.
Así que ahí está la respuesta a la pregunta que hicimos antes: lo que deberíamos haber hecho es poner nuestro software en manos de los clientes, para que pudieran usarlo y darnos su opinión. Si hubiéramos hecho eso, 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 costoso fiasco.
Por supuesto, cambiar el rumbo a la mitad de un proyecto es más fácil decirlo que hacerlo. En la práctica, suele ser una experiencia dolorosa y desagradable. Has tomado las decisiones difíciles. Sabes lo que estás construyendo. Sabes lo que esperan tus clientes. Su flujo de trabajo está establecido. No es un camino de rosas, exactamente, pero estás progresando. Y luego alguien de fuera del proyecto viene y dice que has estado en el camino equivocado todo el tiempo. Que toda esa planificación y trabajo fue en vano. Que tienes que dar la vuelta y empezar de nuevo. Peor aún, ¡la persona que te dice que cambies de rumbo es la misma persona 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 cosa. Es desmoralizador, incluso irrespetuoso. No es de extrañar que te pongas a la defensiva y te resistas a hacer cambios.
¿Comprensible? Por supuesto. ¿Útil? De nada. Sin embargo, la pregunta importante es, ¿cómo puedes superar este sentimiento?
Bueno, es una cuestión de mentalidad y tiene dos partes. La primera es aceptar que es realmente difícil crear software valioso si no está revisando y revisando constantemente sus antecedentes. Sí, cambiar de rumbo a la mitad de un proyecto es frustrante, pero no es tan desalentador como llegar al final de un proyecto y darse cuenta de que ha construido un pedazo de basura.
La segunda parte trata sobre la perspectiva, y toma la forma de un ejercicio.
Este no siempre es un ejercicio fácil: requiere una mente fría y más empatía de la que podría querer extender a la persona que acaba de arruinar su día. Pero puede ser esclarecedor. Comience haciéndose estas dos preguntas: Primero, ¿su cliente lo envió deliberadamente por el camino equivocado? Probablemente no, ¿verdad? Y segundo, ¿cómo se sintieron cuando se dieron cuenta de que la cagaron y le costaron meses de trabajo? Lo más probable es que estuvieran bastante avergonzados. Probablemente no querían acudir a ti y admitir su error. es un buenLo que hicieron, sin embargo, ¡simplemente te ahorraron aún más tiempo perdido! Y no es solo su fecha límite lo que se ha sobrepasado. La línea de tiempo de su cliente también está retrasada ahora. Su empresa está gastando mucho dinero para crear software que satisfaga sus necesidades, y este error significa que el proyecto no está funcionando. En otras palabras, esto es frustrante para todos.
Cuando te pones manos a la obra, ambos están en una posición difícil. En teoría, la única forma en que podría evitar errores sería leer la mente de su cliente. Tu cliente, a su vez, tendría que ser capaz de predecir el futuro. En un mundo ideal, ambos podrían hacer esas cosas. Pero el software no está construido en un mundo ideal; no estarás trabajando con clarividentes telepáticos. Acéptalo y los errores, junto con los cambios que traen consigo, serán mucho más fáciles de manejar.
Procesos iterativos de Aprendizaje Ágil
Los procesos iterativos lo mantienen en contacto con sus clientes
Bien, volvamos a donde empezamos. ¿Cómo pueden los principios ágiles que hemos explorado ayudar a nuestro problemático proyecto de lector de libros electrónicos? Averigüémoslo ejecutando el proyecto nuevamente.
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 admitir un formato estándar de la industria. Tenga en cuenta, sin embargo, que este problema no se podría haber previsto ni evitado. Cuando nuestro equipo se puso a trabajar, no había un estándar de la industria. Nuestro énfasis, entonces, tiene que estar en la capacidad de respuesta del equipo a lo que descubre una vez que su trabajo ya ha comenzado.
Esta vez, el proyecto va a ser ágil. Comenzaremos con una gran reunión en la que analizaremos los requisitos y las especificaciones, pero no nos apegaremos a ese plan durante 18 meses seguidos. En cambio, dividiremos ese año y medio en sprints de un mes : un ciclo único del circuito de retroalimentación que discutimos anteriormente. Dicho de otra manera, actualizaremos nuestro diseño en respuesta a los comentarios todos los meses.
No habrá mucho que probar al principio, por supuesto, así que avanzaremos rápidamente hasta el cuarto sprint. Cuando el gerente del proyecto, el equipo y las partes interesadas se reúnen, uno de los desarrolladores informa que existe un nuevo estándar de la industria para los formatos de libros electrónicos. El equipo incorpora esta nueva información en su próximo sprint y crea una biblioteca que admite el nuevo formato. Para el sexto sprint, está listo para incorporar ese formato en la interfaz de usuario del lector.
Como puede ver, cada sprint se asigna aproximadamente a cada iteración o versión del software que está construyendo el equipo. Así que saltemos al mes once: el undécimo sprint y la undécima iteración. Ahora tenemos una compilación que funciona, que se puede cargar en los prototipos que se le ocurrieron al equipo de hardware. Tiene errores, pero es lo suficientemente bueno para las pruebas del mundo real, que es exactamente lo que quiere el equipo. Cuando el director 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 periódicos y archivos PDF a sus dispositivos. Ese es el enfoque para el próximo sprint del equipo.
Sin embargo, este enfoque no se trata solo de probar e incorporar nuevas funciones; algunas funciones también se pueden descartar. Por ejemplo, tal vez ese escaparate de Internet no tenga sentido. Después de todo, existe un formato de libro electrónico estandarizado, por lo que no tenemos que crear una plataforma única propia. Eso es útil porque libera tiempo para trabajar en otras funciones más importantes.
Es mucho más probable que esta versión del proyecto termine bien. Hemos estado lanzando continuamente software para pruebas en el mundo real y realizando cambios oportunos en respuesta a esas pruebas. La gran diferencia aquí es que estamos en contacto con clientes y usuarios. Cuando usamos el proceso de cascada, quedamos completamente aislados de estos grupos una vez que se aprobaron los requisitos del proyecto. Esta vez, sin embargo, no hemos perdido de vista nuestro objetivo final: crear software valioso y funcional que satisfaga necesidades reales. Y ese es el porqué de ágil.