Leer en inglés

Compartir a través de


¿Qué es Agile?

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

El término Agile describe los enfoques para el desarrollo de software que resaltan la entrega incremental, la colaboración en equipo, el planeamiento y el aprendizaje continuos. El término Agile se acuñó en 2001, en el Manifiesto Agile. El manifiesto estableció principios para un mejor enfoque para el desarrollo de software. En esencia, el manifiesto declara cuatro valores que representan los cimientos del movimiento Agile. Tal y como está redactado, el manifiesto afirma:

Hemos venido a valorar:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software de trabajo sobre documentación general.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta al cambio sobre seguimiento de un plan.

El manifiesto no implica que los puntos a la derecha de estas afirmaciones no sean importantes o necesarios. Por el contrario, los elementos de la izquierda son simplemente más importantes.

Técnicas y procedimientos Agile

Es importante entender que Agile no se trata de una cosa. Una persona no hace Agile. Por el contrario, Agile es una mentalidad que impulsa un enfoque del desarrollo de software. Dado que no existe un enfoque único que se adapte a todas las circunstancias, el término Agile ha surgido para representar diversos métodos y procedimientos que se ajustan a las declaraciones de valores del manifiesto.

Los métodos Agile, que se suelen conocer como marcos, son enfoques amplios de las fases del ciclo de vida de las DevOps: planeamiento, desarrollo, entrega y operaciones. Establecen un método para realizar el trabajo con directrices y principios claros.

Scrum es el marco Agile más habitual y con el que la mayoría de las personas se inicia. Por otro lado, los procedimientos Agile son técnicas que se aplican durante las fases del ciclo de vida de desarrollo de software.

  • Póker de planeamiento es una práctica de estimación colaborativa concebida para animar a los miembros del equipo a compartir su comprensión de lo que significa finalizado. Muchas personas consideran que el proceso es divertido, y se ha demostrado que ayuda a fomentar el trabajo en equipo y a mejorar las estimaciones.
  • La integración continua (CI) es una práctica habitual de ingeniería Agile que consiste en integrar con frecuencia los cambios de código en la rama principal. Una compilación automatizada comprueba los cambios. Como resultado, hay una reducción de la deuda de integración y una rama principal continuamente disponible.

Estas prácticas, como todas las prácticas Agile, llevan la etiqueta Agile, ya que son coherentes con los postulados del manifiesto Agile.

Lo que Agile no es

A medida que Agile ha ido ganando popularidad, muchos estereotipos y malas interpretaciones han ensombrecido su eficacia. Es fácil decir "Sí, estamos poniendo en práctica Agile", sin ninguna responsabilidad. Teniendo esto en cuenta, piense en algunas cosas que Agile no es.

  • Agile no es codificación de vaqueros. Agile no debe confundirse con un enfoque del desarrollo de software del tipo "lo iremos descubriendo sobre la marcha". Una idea como esa no podría estar más lejos de la verdad. Agile requiere una definición de finalizado y de valor explícito que se entrega a los clientes en cada sprint. Si bien Agile valora la autonomía de las personas y los equipos, hace hincapié en la autonomía alineada para garantizar que la mayor autonomía produzca un mayor valor.
  • Agile no funciona sin rigor ni planeamiento. Por el contrario, los métodos y procedimientos Agile suelen resaltar la disciplina en el planeamiento. La clave está en el planeamiento continuo a lo largo de todo el proyecto, no solo al principio. El planeamiento continuo garantiza que el equipo pueda aprender del trabajo que se ejecute. A través de este enfoque, se maximiza la rentabilidad de la inversión (ROI) en planeamiento.

"Los planes son no valen nada, pero el planeamiento lo es todo". — Dwight D. Eisenhower

  • Agile no es una excusa para la ausencia de una hoja de ruta. Este concepto erróneo es probablemente el que más daño ha hecho al movimiento Agile en general. Las organizaciones y los equipos que siguen un enfoque Agile saben perfectamente hacia dónde se dirigen y los resultados que quieren conseguir. Reconocer el cambio como parte del proceso es diferente de girar en una nueva dirección cada semana, sprint o mes.
  • Agile no significa desarrollo sin especificaciones. En cualquier proyecto resulta necesario mantener al equipo alineado en el por qué y el cómo es que se produce el trabajo. Un enfoque Agile para las especificaciones incluye garantizar de que las especificaciones tengan un tamaño adecuado y que reflejen la manera en que el equipo secuencia y entrega el trabajo.
  • Agile no es incapaz de adaptarse al trabajo no planeado y a otras interrupciones. Es importante finalizar los sprints en el plazo correspondiente. Pero que surja un problema que desvíe el desarrollo no significa que un sprint tenga que fracasar. Los equipos pueden planear las interrupciones designando recursos con antelación para los problemas y los imprevistos. De este modo, pueden resolver esos problemas sin perder de vista el desarrollo.
  • Agile no es inadecuado para las grandes organizaciones. Una queja habitual es que la colaboración, un componente clave del método Agile, resulta difícil en equipos grandes. Otra queja es que los enfoques escalables de Agile introducen estructuras y métodos que ponen en riesgo la flexibilidad. A pesar de estos conceptos erróneos, es posible escalar con éxito los principios de Agile. Para obtener información sobre cómo sobreponerse a estas dificultades, consulte Escalado de Agile en equipos grandes.
  • Agile no es ineficaz. Para responder a las necesidades cambiantes de los clientes, los desarrolladores invierten tiempo en cada iteración para mostrar un producto que funcione y obtener comentarios. Es verdad que estos esfuerzos reducen el tiempo que dedican al desarrollo. No obstante, incorporar las necesidades de los clientes desde el principio ahorra mucho tiempo más adelante. Cuando las características se alinean con la perspectiva del cliente, los desarrolladores evitan grandes revisiones a largo plazo.
  • Agile no es una mala opción para las aplicaciones actuales, que a menudo se centran en el flujo de datos. Tales proyectos suelen implicar más cargas de trabajo de modelado de datos y de extracción-transformación-carga (ETL) que de interfaces de usuario. Esto hace difícil demostrar un software utilizable con una programación coherente y ajustada. Ahora bien, si se ajustan los objetivos, los desarrolladores pueden seguir aplicando un enfoque Agile. En lugar de trabajar para realizar las tareas en cada iteración, los desarrolladores pueden centrarse en ejecutar experimentos de datos. En lugar de presentar un producto de trabajo cada pocas semanas, pueden intentar comprender mejor los datos.

¿Por qué elegir Agile?

¿Por qué alguien consideraría aplicar un enfoque Agile? No caben dudas de que las reglas del juego en torno a la creación de software han cambiado radicalmente en los últimos 10-15 años. Muchas de las actividades se asemejan, pero el paisaje y los entornos en los que las aplicamos son claramente diferentes.

  • Compare lo que supone comprar software hoy en día con lo que suponía a principios de la década de 2000. ¿Con qué frecuencia la gente se dirige a la tienda para comprar software empresarial?
  • Considere cómo se recogen las opiniones de los clientes sobre los productos. ¿Cómo entendía un equipo lo que la gente pensaba de su software antes de las redes sociales?
  • Considere la frecuencia con la que un equipo desea actualizar y mejorar el software que entrega. Las actualizaciones anuales ya no son viables frente a la competencia moderna.

Diego Lo Guidice de Forrester lo expresa mejor en su blog: Transforming Application Delivery (Octubre de 2020).

"Todo ha cambiado drásticamente. La sostenibilidad, además de verde y limpia, significa que lo que creamos hoy tiene que poder cambiarse fácil y rápidamente mañana. Los planes estratégicos son a corto plazo, y el planeamiento y el cambio son continuos". — Diego Lo Guidice, Forrester

Las reglas han cambiado, y las organizaciones de todo el mundo adaptan ahora en consecuencia su enfoque del desarrollo de software. Los métodos y prácticas de Agile no prometen resolver todos los problemas. Pero sí prometen establecer una cultura y un entorno en los que las soluciones surjan a través de la colaboración, el planeamiento y el aprendizaje continuos, y el deseo de ofrecer software de alta calidad con mayor frecuencia.

Pasos siguientes

La decisión de tomar la ruta Agile para el desarrollo de software puede ofrecer algunas oportunidades interesantes para mejorar su proceso de DevOps. Una serie de consideraciones esenciales se centra en cómo el desarrollo de Agile se compara y contrasta con el enfoque actual de una organización.