CAPÍTULO I
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
¿Qué es Agile?
La agilidad está en todas partes. Y paradójicamente, en ninguna parte.
En los 20 años transcurridos desde que el tren de mercancías ágil irrumpió en la conciencia de los desarrolladores de software, el número de empresas que se autodenominan "ágiles" aumentó en órdenes de magnitud. ¿El número de equipos que realmente aplican un enfoque ágil a su trabajo? No tanto. "Ágil", el nombre que se repite fácilmente, tiene un éxito enorme. Las ideas que hay detrás de "Ágil", bueno, la mayoría se ignoran.
Arreglémoslo.
Génesis de Agile
En los años 90, se creía que el desarrollo de software estaba en crisis. De hecho la llamaron "La crisis del software". Los proyectos de software sobrepasaban el presupuesto, se retrasaban, no cumplían los requisitos y -según el muy citado y ominosamente llamado "Informe CHAOS"- casi un tercio de ellos se cancelaron directamente. [Standish1994]
La agilidad no fue una respuesta a esta crisis. Ni mucho menos. Agile fue una respuesta a la respuesta.
Para controlar el desarrollo de software, las grandes organizaciones habían creado procesos muy detallados que definían exactamente cómo debía crearse el software. Todo estaba estrictamente controlado para que no se cometieran errores. (En teoría, al menos).
En primer lugar, los analistas empresariales entrevistarían a las partes interesadas y documentarían los requisitos del sistema. A continuación, los arquitectos de software leerían los documentos de requisitos y crearían documentos de diseño detallados en los que se especificaría cada componente del sistema y cómo se relacionan entre sí. A continuación, los programadores convertían los documentos de diseño en código. En algunas organizaciones, esto se consideraba un trabajo de baja cualificación, un mero ejercicio de traducción mecánica.
Mientras tanto, los jefes de pruebas utilizarían los mismos documentos para generar planes de pruebas, y cuando se terminara la codificación, ejércitos de personal de control de calidad seguirían manualmente esos planes de pruebas e informarían de las desviaciones como defectos. Después de cada fase, todo se documentaría, revisaría y aprobaría cuidadosamente.
Estos enfoques basados en fases llegaron a denominarse "desarrollo en cascada" o "desarrollo por fases".1 Si suenan como un ridículo hombre de paja, bueno, considérate afortunado. No todas las empresas utilizaban un proceso basado en fases y repleto de documentos en los años 90, pero estaba ampliamente reconocido como una forma lógica y sensata de trabajar. Por supuesto que había que definir los requisitos, luego diseñar, luego implantar y luego probar. Por supuesto que había que documentar cada fase. Esto era disciplina. Esto era ingeniería. ¿De qué otra forma podrías tener éxito?
Nacido de la crisis
Las grandes empresas definían sus procesos con un detalle insoportable. Funciones, responsabilidades, plantillas de documentos, lenguajes de modelado, juntas de control de cambios... cada aspecto del desarrollo estaba estrictamente definido y controlado. Si un proyecto no tenía éxito -y, según el "Informe CHAOS", menos de una sexta parte de ellos lo tenían- era porque el proceso necesitaba más detalles, más documentos, más aprobaciones. El resultado era una cantidad ingente de documentación. Martin Fowler lo llamó "El ruido sordo todopoderoso". [Fowler1997]
No era una buena forma de trabajar. Era burocrática y deshumanizadora. La habilidad no parecía importar tanto como el cumplimiento de los procesos. Los programadores se sentían engranajes intercambiables de una máquina impersonal. Ni siquiera funcionaba del todo bien.
Así que varias personas crearon métodos más sencillos, más ligeros y menos prescriptivos para desarrollar software. Se les llamó "métodos ligeros", en contraste con los métodos pesados que utilizaban las grandes empresas. Estos nuevos métodos tenían nombres como "Desarrollo de Software Adaptativo", "Crystal", "Desarrollo Orientado a las Características", "Método de Desarrollo de Sistemas Dinámicos", "Programación Extrema" y "Scrum".
A finales de los 90, estos métodos estaban atrayendo mucha atención. La Programación Extrema, en particular, experimentó una explosión de interés popular entre los programadores. En 2001, 17 de los defensores de la metodología ligera se reunieron en una estación de esquí de Utah para hablar de unificar sus esfuerzos.
El Manifiesto Ágil
"Personalmente, no esperaba que este grupo concreto de [personas] se pusiera nunca de acuerdo en algo sustancial", dijo más tarde Alistair Cockburn.
Y, de hecho, al cabo de dos días, sólo consiguieron dos cosas: el nombre "Ágil" y una declaración de cuatro valores (véase la Figura 1-1). Durante los meses siguientes, por correo electrónico, elaboraron 12 principios complementarios (véase la Figura 1-2). [Beck2001]
Esto fue el Manifiesto Ágil. Cambió el mundo. Así que, como continuó diciendo Alistair, al fin y al cabo estaban de acuerdo en algo importante.2
Figura 1-1. Valores ágiles
Pero no existía un método Ágil unificado. Nunca lo ha habido y nunca lo habrá. Ágil son tres cosas: el nombre, los valores y los principios. Eso es todo. No es algo que puedas hacer. Es una filosofía. Una forma de pensar sobre el desarrollo de software. No puedes "usar" Agile ni "hacer" Agile... sólo puedes ser Agile. O no serlo. Si tus equipos encarnan la filosofía Ágil, entonces son Ágiles. Si no, no lo son.
La esencia de Agile
Martin Fowler ha hecho carrera convirtiendo complicados temas de software en explicaciones ponderadas y ecuánimes. Su explicación de "La esencia del desarrollo ágil de software" es una de las mejores:
El Desarrollo Ágil es adaptativo más que predictivo; orientado a las personas más que a los procesos.3
Martin Fowler
Figura 1-2. Principios ágiles
Adaptativo más que predictivo
¿Recuerdas el "Informe CHAOS", que decía que sólo una sexta parte de los proyectos de software tenían éxito? Tenía una definición muy concreta del éxito:
- Éxito
-
El proyecto se completa a tiempo y dentro del presupuesto, con todas las características y funciones especificadas originalmente.
- Desafiado
-
El proyecto está terminado y operativo, pero supera el presupuesto, el plazo estimado y ofrece menos características y funciones de las especificadas originalmente.
- Deteriorado
-
El proyecto se cancela en algún momento del ciclo de desarrollo.
Estas definiciones ilustran perfectamente la mentalidad predictiva. Tienen que ver con la conformidad con el plan. Si hiciste lo que dijiste que ibas a hacer, tuviste éxito. Si no lo hiciste, ¡no lo tuviste! Fácil.
Al principio tiene sentido. Pero mira más de cerca. Falta algo. Como escribió Ryan Nelson en CIO Magazine [Nelson2006]:
Los proyectos que cumplían todos los criterios tradicionales de éxito -tiempo, presupuesto y especificaciones- pueden acabar siendo fracasos porque no atraen a los usuarios previstos o porque, en última instancia, no aportan mucho valor a la empresa... Del mismo modo, los proyectos considerados fracasos según las métricas informáticas tradicionales pueden acabar siendo éxitos porque, a pesar de los problemas de coste, tiempo o especificaciones, el sistema gusta a su público objetivo o aporta un valor inesperado.
Los equipos ágiles definen el éxito como aportar valor, no ajustarse a un plan. De hecho, los equipos verdaderamente Ágiles buscan activamente oportunidades para aumentar el valor cambiando sus planes.
Repasa el Manifiesto (véanse las Figuras 1-1 y 1-2). Tómate un momento para estudiar realmente los valores y principios Ágiles. ¿Cuántos están relacionados con la entrega de software valioso y la adaptación a los comentarios?
Orientado a las personas más que a los procesos
Los procesos pesados intentaban evitar los errores definiendo cuidadosamente cada aspecto del desarrollo del software. Al poner la "inteligencia" en el proceso, la habilidad individual perdía importancia. En teoría, se podía aplicar el mismo proceso una y otra vez, con personas diferentes, y obtener los mismos resultados. (Ahora que lo pienso, más o menos lo hicieron, sólo que no los resultados que querían).
Agile dice que las personas son el factor más importante para el éxito del desarrollo de software. No sólo sus habilidades, sino todos los aspectos de su humanidad. Lo bien que trabajan juntos los miembros del equipo. Cuántas distracciones encuentran. Cómo de seguros se sienten para hablar, y si están motivados por su trabajo.
Los equipos ágiles tienen un proceso -todos los equipos lo tienen, aunque sea implícito-, pero el proceso está al servicio de los humanos, no al revés. Y los equipos Ágiles son responsables de su propio proceso. Cuando se les ocurre una forma mejor de trabajar, la cambian.
Vuelve a mirar el Manifiesto (véanse las Figuras 1-1 y 1-2). ¿Qué valores y principios se relacionan con poner a las personas en primer lugar?
Por qué ganó Agile
En los primeros 10 años posteriores al Manifiesto, el Ágil se enfrentó a enormes críticas. Era "indisciplinado", decían los críticos. "Nunca podría funcionar". Otros 10 años después, los críticos callaron. Agile estaba en todas partes, al menos de nombre. Los pesados métodos en cascada estaban efectivamente muertos. A algunos programadores jóvenes les cuesta creer que alguien haya podido trabajar así.
No es que los procesos basados en fases estén intrínsecamente estropeados. Tienen sus defectos, seguro, pero si se mantienen delgados y operan en un dominio bien entendido, los métodos de cascada pueden funcionar. El problema eran los enfoques pesados que utilizaban las grandes empresas. Irónicamente, los procesos diseñados para evitar problemas causaban en realidad muchos de los problemas que veían las organizaciones.
Es muy difícil imaginar cómo funcionará el software antes de utilizarlo realmente, y es aún más difícil pensar en absolutamente todo lo que debe hacer tu software. Esto es doblemente cierto para las personas que no participan activamente en el desarrollo de software. Como resultado, es de vital importancia poner el software en funcionamiento delante de la gente lo antes posible. Tienes que recibir comentarios sobre lo que falta o está mal, y luego cambiar tus planes basándote en lo que aprendas. Como dice el Manifiesto: "El software operativo es la principal medida del progreso". Aprender y responder al cambio son la esencia de Agile.
Esos procesos pesados ponían tanto énfasis en los controles de procesos y la documentación y las aprobaciones, que incurrían en una enorme cantidad de retrasos y gastos generales. Tardaron años en producir un software que funcionara, y no tuvieron nada concreto que mostrar hasta casi el final. En lugar de aceptar los cambios, trabajaban activamente para evitarlos. De hecho, tenían una parte dedicada al proceso, la Junta de Control de Cambios, cuyo objetivo principal era decir "no" a las solicitudes de cambio. (O, más exactamente, "Sí, pero os costará").
Todo esto se sumaba a proyectos que pasaban años en desarrollo antes de tener nada que mostrar. Cuando lo tuvieron, era demasiado tarde y demasiado caro hacer cambios. Al final entregaban un software que no hacía lo que los clientes necesitaban.
Aunque existen diversos enfoques de Agile -y algunos de ellos consisten más en cooptar un nombre popular que en seguir la filosofía real-, algo que todos tienen en común es centrarse en hacer visible el progreso y permitir que las partes interesadas corrijan el rumbo sobre la marcha. Esto parece poca cosa, pero es increíblemente poderoso. Por eso ya no oímos hablar de la Crisis del Software. El software sigue llegando tarde. Sigue sobrepasando el presupuesto. Pero los equipos Ágiles muestran el progreso con software funcional, no con documentos. Desde el principio. Y eso es enorme.
El Ágil es mucho más que proporcionar visibilidad. ¿Pero esta única cosa? Esto era suficiente. Por eso todo el mundo quería Agile.
Por qué funciona Agile
El primer gran éxito de Agile fue Extreme Programming (XP), un método con el lema "Abraza el cambio". XP mezclaba una buena dosis de filosofar sobre el desarrollo de software con un énfasis pragmático en marcar la diferencia. Como dice el prefacio del primer libro de XP:
En resumen, XP promete reducir el riesgo de los proyectos, mejorar la capacidad de respuesta a los cambios empresariales, mejorar la productividad a lo largo de la vida de un sistema y añadir diversión a la creación de software en equipo, todo al mismo tiempo. De verdad. Deja de reírte. [Beck2000a]
Programación Extrema Explicada, Primera Edición
Algunos se rieron. Pero otros lo probaron y descubrieron que -en contra de la sabiduría común sobre cómo se suponía que debía funcionar el desarrollo de software- XP realmente cumplía todo lo que prometía. Y así, a pesar de las risas, XP prosperó, y Agile con él.
XP fue la imagen original de Agile, donando una columna vertebral de ideas y terminología que aún se utilizan hoy en día. Pero la fuerza de la comunidad Ágil es que siempre ha sido una gran carpa. Ágil no se limita a un único método. Está en constante expansión para incluir a nuevas personas e ideas. Lean Software Development, Scrum, Kanban, Lean Startup, DevOps y muchos, muchos más, han contribuido a lo que la gente considera "Ágil" hoy en día.
Si tomas sus ideas y las agrupas en categorías, aparecen cinco conceptos básicos.
-
Confía en las personas. Construye procesos que comprendan y trabajen con la humanidad esencial de las personas. Pon las decisiones en manos de quienes están más cualificados para tomarlas. Basa tu trabajo en relaciones sanas y de colaboración.
-
Aporta valor. Busca opiniones, experimenta y adapta tus planes. Céntrate en producir resultados valiosos. Considera el trabajo parcialmente realizado como un coste, no como un beneficio. Entrega con frecuencia.
-
Elimina el despilfarro. Trabaja en pasos pequeños y reversibles. Acepta la posibilidad del fracaso y diseña tus planes para fracasar rápido. Maximiza el trabajo no realizado. Busca el rendimiento más que la eficacia.
-
Busca la excelencia técnica. Habilita la agilidad mediante la calidad técnica. Diseña para lo que se conoce, no para lo que se especula. Empieza por lo sencillo y añade complejidad sólo en respuesta a las necesidades reales. Crea sistemas que sean fáciles de evolucionar, incluso -o especialmente- en direcciones imprevistas.
-
Mejora tu proceso. Experimenta con nuevas ideas. Afina y adapta lo que funciona. Nunca des por sentado que la forma establecida y popular es la mejor para ti.
Agile se define por el Manifiesto, pero el Manifiesto es sólo el punto de partida. Agile funciona porque la gente lo hace funcionar. Toman las ideas de Agile, las adaptan a su situación y nunca dejan de mejorar.
Por qué fracasa Agile
Agile comenzó como un movimiento de base. Su éxito inicial fue impulsado en gran medida por programadores que buscaban mejores resultados y una mejor calidad de vida. A medida que ese éxito crecía, el ímpetu de Agile pasó de las ideas subyacentes al bombo publicitario. En lugar de decir: "Consigamos mejores resultados adaptando nuestros planes y dando prioridad a las personas", los líderes de las organizaciones empezaron a decir: "Todo el mundo habla de Agile. Consígueme algo de Agile".
La cuestión es que no hay un "Ágil" al que ir a buscar. Es sólo un montón de ideas. Hay enfoques Ágiles específicos, como la Programación Extrema y Scrum, que te dirán cómo ser Ágil, pero aun así tienes que estar de acuerdo con la filosofía subyacente.
Y para muchas organizaciones, esa filosofía subyacente -adaptar los planes y poner a las personas en primer lugar- es muy, muy extraña.
La tragedia del Culto a la Carga es su adhesión a los signos superficiales y externos de alguna idea, combinada con la ignorancia de cómo funciona realmente esa idea. En la historia, los isleños reproducían todos los elementos de los lanzamientos de carga -la pista de aterrizaje, la torre, los auriculares- pero no comprendían la vasta infraestructura que permitía la llegada de los aviones.
La misma tragedia ocurre con Agile. La gente quiere la carga de Agile: mejores resultados, más visibilidad, menos fracasos empresariales. Pero no entienden la filosofía subyacente y, a menudo, no estarían de acuerdo con ella aunque la entendieran. Quieren comprar Agile, pero no se puede comprar una idea.
Lo que pueden comprar son los signos externos de Agilidad. ¡Reuniones de pie! ¡Historias! Herramientas ¡Certificaciones! Hay muchas cosas etiquetadas como Ágiles, y mucha gente deseosa de vendértelas. A menudo se vende como "de nivel empresarial", que es una forma de decir "no te preocupes, no tendrás que cambiar". Se ignoran ideas incómodas como "planificación adaptativa" y "centrado en las personas".
Y así es como se consigue un Culto de Carga. Toda la actividad; ninguno de los resultados. Falta la parte Ágil.
"En mi antigua empresa se desperdiciaban muchísimas horas de trabajo en reuniones".
"[Agile] costó el puesto de trabajo a todo un equipo (más de 30 personas) que no produjo casi nada durante casi un año".
"Lo único que significa [Agile] es que los desarrolladores se ven perjudicados cuando el proyecto cambia... el día antes de la entrega".
Comentarios reales sobre Agile en la web
El nombre Ágil está en todas partes. Las ideas de Agile no. Se ha autoperpetuado: para muchos, el único Ágil que conocen es el Ágil del Culto a la Carga.
Es hora de arreglarlo. En el resto de este libro, te mostraré cómo aplicar las ideas Ágiles de verdad. Vigila a los Agilistas del Culto a la Carga que se han infiltrado en el libro. (También puedes encontrarlos en el índice.) Te enseñarán lo que no debes hacer.
¿Preparados? Vamos.
1 A menudo se atribuye erróneamente la cascada a un artículo de Winston Royce de 1970. Pero los enfoques basados en fases se remontan a la década de 1950, y el documento de Royce se ignoró en gran medida hasta finales de la década de 1980, cuando se utilizó para describir lo que la gente ya estaba haciendo. [ Bossavit2013] (cap. 7).
2 Alistair Cockburn, citado por Jim Highsmith en [Highsmith2001]. La cita completa es: "Personalmente, no esperaba... que este grupo concreto de agilitas se pusiera de acuerdo en algo sustancial... Hablando por mí, estoy encantado con la redacción final [del Manifiesto]. Me sorprendió que los demás parecieran igualmente encantados con la redacción final. Así que nos pusimos de acuerdo en algo sustancial".
3 Fowler ha expresado esta idea de muchas formas a lo largo de los años. Se originó en [Fowler2000a].
4 Fuentes: Testimonio de Mueller ante el Congreso el 3 de febrero de 2005 y testimonio del Inspector General Glenn Fine ante el Congreso el 2 de mayo de 2005.
5 La primera vez que vi esta historia fue en los escritos de Richard Feynman, basados en su discurso de graduación en Caltech en 1974. [ Feynman1974] Se basa en rituales del mundo real practicados en Melanesia después de la Segunda Guerra Mundial.
Get El Arte del Desarrollo Ágil, 2ª Edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
