Qué es Agile

Qué es agile

Agile, o en español Agilidad, Agilismo o Desarrollo Ágil, es un término acuñado en 2001 para referirse a un nueva forma menos burocratizada y rígida de crear software en oposición a los modelos tradicionales (modelos predictivos, como por ejemplo el célebre Modelo Waterfall) de gestión y desarrollo de software.

Como supongo que te habrás quedado igual con esta definición, vamos a desarrollar un poco más la idea.

Espero que, tras este post, te quede clarísimo en qué consiste eso tan de moda en el mundo del software llamado agile y que, según sus defensores, ha venido para dar solución a los problemas que nos encontramos con la forma tradicional de gestión del software.

Comenzamos.

Antecedentes

Antes de nada, conviene hacer referencia al descontento que existía (y existe) en la industria respecto a los métodos tradiciones de gestión de software.

Aunque desarrollaré este punto más adelante, ya que da para mucho, en una comparativa entre Gestión Tradicional de Software vs Gestión Ágil de Software, te diré a modo de pincelada que ya en el año 1968 se hablaba de la llamada Crisis del Software, en relación a la falta de calidad y desviaciones en tiempo y costes de los proyectos software.

La solución que trató de darse era la que, en principio, parecía la más evidente: reforzar la planificación y el control para que las predicciones fueran más fiables, pero está claro que no surtieron el efecto deseado, lo que llevo al nacimiento de lo que hoy conocemos como agile.

Nacimiento de la Agilidad

El 12 de febrero de 2001 se reunieron en Snowbird (Utah) 17 expertos en desarrollo software críticos con los modelos tradicionales de gestión de proyectos software. El impulsor de esta iniciativa fue Kent Beck, uno de los padres de la metodología XP.

El motivo de esta reunión consistió en plantear una alternativa a los modelos de gestión de software existentes en la industria, modelos que heredaban los principios de la ingeniería más tradicional pero que, por inflexibles, presentaban serios inconvenientes a la hora de trasladarlos a un proyecto software.

Realmente la cuestión no nacía de cero ni mucho menos, pues desde unos años atrás ya existían metodologías que rompían con el paradigma tradicional, rechazando partir de unos requisitos cerrados y aceptando la incertidumbre y los cambios sobre la marcha. Por ejemplo, tenemos XP (Extremme Programming), que nació dos años antes de esta reunión.

Y antes de eso, a partir de un artículo de Takeuchi y Nonaka en 1986 en la Harvard Business Review, ya se empezó a gestar lo que en un futuro sería Scrum.

Pero es que todavía antes, en los años 50, se desarrolló en Toyota un sistema de producción industrial que desembocaría en la filosofía Lean que guarda grandes similitudes con la agilidad, hasta el punto de que podríamos decir que lean y agile son conceptos intercambiables entre sí.

Como puedes observar, hacía tiempo que ya se habían dado los primeros pasos hacia la agilidad…

Pero bueno, volvamos a Snowbird y a nuestros 17 sabios. El caso es que, tras muchas conversaciones, nació el término ágil simplemente por oposición a los métodos tradicionales, que se consideraban demasiado rígidos para ser aplicados exitosamente al software.

Como curiosidad decir que al principio el término que se utilizó fue “ligero”, en oposición a los modelos tradicionales “pesados”, pero finalmente gustó más el adjetivo ágil y con la acuñación de este término los integrantes firmaron un manifiesto que pasaría a la posteridad como Manifiesto Ágil.

El Manifiesto Ágil

El Manifiesto Ágil resumió las conclusiones tras aquella reunión en 12 principios y, sobre todo, en 4 valores.

Manifiesto Ágil
Portada de la web del Manifiesto Ágil, con foto del corro de sabios debatiendo…

Estos valores sintetizan qué es agile y qué no es:

  1. Individuos e interacciones sobre procesos y herramientas.
  2. Software funcionando sobre documentación extensiva.
  3. Colaboración con el cliente sobre negociación contractual.
  4. Respuesta ante el cambio sobre seguir un plan.

Los 12 principios vienen a reforzar los cuatro pilares que representan los valores. Se pueden resumir en las siguientes ideas:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Para más información sobre el Manifiesto, aquí tienes el enlace a su web:

https://agilemanifesto.org/

En conclusión, agile es…

  • Priorizar el trabajo del equipo frente a la burocracia y otras cuestiones ajenas a las personas. Un equipo motivado de buenos profesionales hará un gran trabajo. Un equipo mediocre o desmotivado hará un mal trabajo. Así de simple. Ojo, esto no quiere decir que haya que eliminar los procesos o las herramientas, simplemente que éstas deben ser una ayuda, no un fin.

  • Generar software funcional. Si tu proyecto consta de megas y megas de documentación, catálogos de requisitos, documentos de análisis y diseño varios, pero tu software o no funciona, o es obsoleto, o simplemente no lo estás desarrollando aún, quédate con la idea de que no eres ágil. Esto no quiere decir que no documentes, faltaría más. Quiere decir que documentes lo justo y necesario (algún día te hablaré de Confluence) y te centres en lo verdaderamente importante, crear software.

  • Tener al cliente, persona de negocio, o como quieras llamarla, dentro del equipo de trabajo. Repito: DENTRO del equipo de trabajo. Si en tu empresa están los desarrolladores por un lado y la persona de negocio que les proporciona los requisitos está en su despacho en otro edificio y se comunica con “los informáticos” a través de intermediarios y mediante documentos funcionales o emails, tu empresa está bien lejos de ser agile.

  • Adaptarte a los cambios con soltura. Si en tu empresa, antes de tirar la primera línea de código, necesitan semanas (sino meses) para dejar perfectamente apuntalados los requisitos del proyecto y, una vez firmados, no puedes desviarte ni un milímetro de ese plan, pues no, no eres ni remotamente agile. De hecho, estarás despreciando el enorme potencial de mejora que tienen los cambios sobre la marcha sobre el producto final.

Reflexión final

Estas cuatro ideas pueden parecerte de sentido común, ¿17 cracks se reúnen para hablar de los problemas del software y sólo les da para esto? Pero párate un poco a pensar: que estos valores no parezcan secretos insondables no quiere decir que no tengan su miga y lo que es más importante, que las empresas pongan el suficiente foco sobre ellos como para aplicarlos correctamente.

¿Cuántas empresas de software tratan a los desarrolladores como “los que pican software”, como piezas intercambiables, como “recursos humanos”?

¿O utilizan desarrolladores inexpertos en las llamadas “factorías de software” (¿pero a quién se le ocurrió esa abominación?) completamente alejados del cliente y de las necesidades de éste?

¿O cuántos proyectos se van a pique precisamente por no enfocarse en buenos desarrolladores en vez de seguir ciegamente una metodología?

Un desarrollador es un trabajador de la industria del conocimiento, no puede tratársele como alguien que pone piezas aisladas sin tener la menor noción del valor global del producto, al igual que se hacía con los obreros de las fábricas durante la revolución industrial. Y ese error no se arregla añadiendo más procedimientos o más herramientas.

¿O cuántas empresas de software dedican medio año en generar la documentación del proyecto sin dedicar ni un minuto a construir… software? ¿cuánto esfuerzo, tiempo y dinero antes de escribir una sola línea de código?

¿O cuántas empresas de software tienen una brecha entre los que desarrollan y los que saben del negocio para el que se está haciendo dicho software?

¿O cuántas empresas de software exigen que TODOS los requisitos estén perfectamente claros desde el principio del proyecto y si estos cambian una vez comienzan los desarrollos (ya sea porque no se tuvieron en cuenta al principio, por la propia naturaleza de ese negocio o por lo que sea), pues cambio de alcance al canto y mal rollo con el cliente?

Seguro que todo esto te suena.

Estos cuatro valores, como todo lo que rodea al mundo ágil, no son ideas felices que sólo una mente privilegiada entendería. Pero en su sencillez está su belleza y su poder.

A lo largo de este blog iremos viendo cómo llevar a la práctica estos principios de forma que tu empresa o proyecto logre el ansiado calificativo de agile.

Te puede interesar:

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario