principios-desarrollo-agil-renacens

Principios del desarrollo ágil. Cómo aplicar metodologías ágiles.

En el mundo de la gestión de proyectos tecnológicos (especialmente software), es muy común escuchar cierta terminología específica que puede no ser conocida para los recién llegados a este entorno. Un ejemplo es el desarrollo ágil. Hoy te contaremos los principios del desarrollo ágil, para que conozcas mejor en qué consiste este enfoque.

Historia del desarrollo ágil

Una forma de saber qué es el desarrollo ágil es tener claro “qué no es” el desarrollo ágil. Antes de que esta forma de trabajar se extendiera, era normal desarrollar software partiendo de los principios del desarrollo en cascada.

En el desarrollo en cascada, cada etapa del proceso da lugar a la siguiente una vez que ha finalizado. Data de los años 70, y suele conllevar una etapa de análisis de requisitos, diseño del sistema, codificación, pruebas, verificación y mantenimiento. El problema es que, si por ejemplo se encuentra algún error durante la fase de pruebas, es posible que esto conlleve un rediseño del sistema, con el coste (en tiempo y dinero) asociado. Por lo general, es un esquema bastante fácil de implementar ya que sigue el proceso lógico de definir, diseñar y codificar. Sin embargo, la práctica del desarrollo de software a menudo no se ajusta a un modelo tan lineal, y es necesario un nuevo paradigma que aporte flexibilidad y capacidad de adaptación al desarrollo.

Las metodologías ágiles permiten enfrentare a desarrollos dinámicos, aportando flexibilidad con un mínimo impacto

Nacieron así una serie de metodologías ágiles que trataban de dar respuesta a las necesidades de proyectos cada vez más cambiantes y dinámicos. Si bien el término de “desarrollo ágil” no fue acuñado hasta el año 2001, lo cierto es que ya existían algunas formas de trabajo que se basaban en los mismos principios, como Scrum (del que hablaremos otro día, y que data de mediados de los años 80).

Principios del desarrollo ágil

Si tienes que enfrentarte a un proyecto en el que los requisitos pueden cambiar sobre la marcha, añadirse o eliminarse funcionalidades, o simplemente necesitas poder contar con versiones del producto funcional que puedas mostrar a tu cliente conforme lo vas mejorando y completando, necesitas un enfoque ágil, flexible y con una retroalimentación constante del estado del proyecto en sí. Esto se traduce en desarrollos incrementales e iterativos.

esquema-desarrollo-agil

Esquema típico de una metodología ágil para desarrollo de software (Fuente: Wikipedia)

Trabajando mediante iteraciones de algunas semanas de duración (conocidas como Sprints, especialmente en Scrum), cada una de ellas se planifica, se analizan sus requisitos, se diseña, codifica, prueba y documenta, hasta obtener un software sin errores funcional. En la siguiente iteración se continúan añadiendo mejoras al resultado de la anterior, hasta obtener un software final terminado.

Las metodologías ágiles se basan en desarrollos incrementales e iterativos que van sumando funcionalidad al software entregable

Además del modelo incremental, algunos otros aspectos diferenciales de las metodologías ágiles son, sin duda, los siguientes:

  • Equipos auto-gobernados,auto-organizados y multi-funcionales. No es necesario que haya un jefe de equipo, ya que el propio equipo es capaz de autorregularse.
  • El equipo regularmente reflexiona sobre cómo mejorar la eficiencia, y se ajusta para conseguirlo.
  • La motivación de los miembros del equipo es absolutamente imprescindible.
  • Prioriza las comunicaciones cara a cara frente al exceso de documentación.
  • Co-localización. Derivado de lo anterior, es habitual que todo el equipo comparta una misma sala de trabajo abierta (las famosas bullpens que tanto suelen verse en Silicon Valley, y cada vez más en España también).

    oficina-bullpen

    Ejemplo de oficina bullpen (Fuente: www.mattblodgett.com)

  • Acepta sin problemas los requisitos cambiantes que, de hecho, son parte fundamental de su razón de ser.
  • Se realizan entregas de software funcional con una frecuencia de entre 1 a 4 semanas. Es la principal medida de progreso.
  • Desarrollo sostenible con un ritmo constante.
  • Búsqueda de la excelencia técnica y del mejor diseño posible.
  • Se busca la simplicidad, maximizar la cantidad de trabajo que no es necesario hacer, para hacer lo mejor posible el resto.

sprint

Equipos de trabajo

Como hemos comentado, la importancia de contar con un buen equipo de trabajo, motivado, multidisciplinar y auto-gobernado es fundamental. En el equipo tendrán que existir varios roles diferentes que garanticen el correcto desarrollo de cada tarea necesaria. Uno de estos roles es un “Representante del cliente”, que debe actuar en nombre el mismo y responder todas las dudas que puedan surgirles al equipo de desarrollo durante el proyecto. Esta es la mejor forma de asegurarse de que el desarrollo sigue cumpliendo siempre los requerimientos del cliente, y una de las ventajas de trabajar con unos ciclos de feedback tan cortos.

Los equipos de trabajo suelen reunirse en una reunión diaria en la cada miembro expone su situación en el desarrollo. Estas reuniones, como veremos más adelante, no están pensadas para resolver problemas.

Filosofías

agileUna vez vistos los principios del desarrollo ágil, conozcamos ahora su filosofía comparada con otros esquemas de desarrollo. Las características que definen a las metodologías ágiles pueden extraerse fácilmente de dicha filosofía de trabajo, y como veremos se yuxtaponen a otros métodos radicalmente.

Mientras que los métodos más tradicionales se basan en la predicción (para planificar de antemano todos los aspectos del proyecto lo más fielmente posible), las metodologías ágiles cuentan con la capacidad de adaptación. Esto lleva a las empresas que las implementan a contar con desarrolladores muy experimentados, divididos en pequeños equipos, y predispuestos para el cambio.

En lo referente a las diferencias con el modelo en cascada, al integrar las fases de testing en cada iteración, no sólo hace que sea más sencillo incluir cambios en el proyecto, sino que el propio cliente final, tras cada iteración, puede tener una idea más fiel de cómo será el resultado final, y ajustar sus propias exigencias en consecuencia.

Por último, queda clara también la dicotomía código-documentación. En metodologías ágiles, no es que no se cuente con documentación del proyecto, sino que dicha documentación es la justa y necesaria para poder dar el soporte adecuado a quien deba recurrir a ella, pero sin caer en un exceso de material. La documentación en el mundo del software a menudo queda obsoleta con rapidez, por lo que hay que pensar muy bien qué documentos redactar y cuándo, para que su creación y consulta sean lo más eficaces posible.

Adaptación, testing en cada iteración, y documentación justa y necesaria, son algunos de los aspectos clave de las metodologías ágiles

Esto no significa que las metodologías ágiles vayan a ser siempre y en todo momento la mejor opción de entre todas las posibles para llevar a cabo un desarrollo. Esto dependerá del tipo de desarrollo que se esté realizando, pero también del cliente en sí, de la propia empresa desarrolladora (de su organización, de sus equipos e individuos), etc. Lo importante es, por tanto, conocer la existencia de todas las posibilidades que tenemos a nuestro alcance para poder elegir en consecuencia la más adecuada en cada caso.

Problemas típicos

agilPuede haber varios factores que influyan en que un desarrollo ágil no llegue a buen puerto. Estos son algunos de ellos:

  • Equipo poco experimentado. Puede dar la sensación, si se compara con otros esquemas, de que la carga de trabajo es menor cuando se llevan a cabo desarrollos ágiles (precisamente por dividir el ciclo de desarrollo global en pequeñas iteraciones). Eso se puede deber a una falta de experiencia por parte de los desarrolladores, ya que el trabajo queda perfectamente planificado y distribuido si se conoce correctamente la metodología.
  • Falta de análisis inicial. Que las metodologías ágiles estén abiertas al cambio  no significa que no haya que realizar una planificación inicial. Llevar a cabo un desarrollo ágil no es sinónimo de ir diseñando sobre la marcha, sino de ir afinando y perfeccionando, pero la fase de análisis inicial es imprescindible. Eso sí, el caso contrario es igual de perjudicial: no es necesario como hemos dicho que, de partida, se sepa perfectamente cómo se va a comportar el producto final y definir cada caso de uso al milímetro, ya que en las iteraciones se podrá ir mejorando y completando el desarrollo
  • El rol de “Representante del cliente” no está cubierto correctamente. A menudo se intenta asignar esta labor a uno de los desarrolladores, y esto puede ser un problema si se pierde la visión de negocio que hay por detrás del desarrollo en sí.
  • Equipos poco enfocados. Es necesario, en cada iteración, entregar un software funcional como resultado de la misma. Para ello, el equipo de desarrollo debe enfocarse en ese proyecto, tratando de huir de tareas paralelas siempre que sea posible.
  • Usar la reunión diaria del equipo (la famosa daily) para resolver problemas. En las reuniones diarias, el equipo debería hablar de su avance en el proyecto, pero por lo general no es el mejor lugar para tratar de resolver problemas. Si surgieran temas que requieran de la ayuda de distintas personas para ser resueltos, habría que intentar acometerlos tras la daily por las personas adecuadas, liberando al resto del equipo.
  • Intentar abarcar demasiado en una iteración. Hay que tener claro hasta dónde se debe llegar en cada ciclo, ya que la sensación puede ser de un continuo cambio global sin principio ni final, pero esto es un error. Fijando los objetivos de cada iteración se ayuda a gestionar mejor el tiempo de cada persona y a enfocar sus esfuerzos para el entregable más próximo.
  • Cambios en los plazos, en la calidad, en los recursos o en el alcance. Se debe tratar de fijar, antes de cada iteración, lo que se va a llevar a cabo en ella, qué recursos se usarán o el nivel de calidad a alcanzar. Si variamos estos conceptos durante un ciclo, podemos encontrarnos con problemas que afectarán a sucesivas iteraciones. Cuando decimos que la metodología ágil está abierta al cambio nos referimos a que de una iteración pueden surgir nuevas ideas, nuevos enfoques, aspectos a mejorar… que pueden ser llevados a cabo posteriormente. Pero hay que evitar, en la medida de lo posible, que esto afecte a la iteración en curso.

Estos y muchos otros son los problemas que pueden afectar a que tu compañía no lleve a cabo satisfactoriamente desarrollos ágiles. Pero no te preocupes, teniendo en cuenta estos puntos que te hemos comentado podrás aplicar las correcciones necesarias y tendrás la idea general para saber qué acciones tomar.

En cualquier caso, si necesitas un desarrollo de cualquier tipo y no estás especializado en software o se escapa de tu ámbito de actividad, no dudes en contactar con nosotros. Contamos con un equipo de desarrollo con amplia experiencia en todo tipo de proyectos para que, sea cual sea tu necesidad, podamos cubrirla en el menor tiempo posible gracias, entre otras cosas, a estos principios del desarrollo ágil.

Post escrito por Joaquín Alviz (@rayjaken)

Ingeniero de Telecomunicación. Máster en Administración y Dirección de Empresas. Máster en Dirección Comercial y Marketing. Apasionado de la tecnología, la gestión y los negocios, cuenta con una amplia experiencia gestionando todo tipo de proyectos. En su tiempo libre le gusta el diseño gráfico, los videojuegos, y escribir sobre cualquier gadget que pase por sus manos.

Este post tiene 5 comentarios
  1. Pingback: Desarrollo ágil: ¿Fácil de emplear en todas las empresas?

  2. Ana Ruiz Reply

    Muy interesante! Buen resumen!

    • Joaquín Alviz (@rayjaken) Reply

      ¡Muchas gracias Ana! Me alegro de que te haya resultado útil.
      ¡Un saludo!

  3. Jorge Cuevas V Reply

    Excelente explicación sobre métodologia ágil, lo más importante y que muchas veces se pasa por alto es que nada es perfecto y que pueden haber problemas en la implementación ya sea porque no es la métodologia más adecuada para el proyecto/empresa o simplemente por poca experiencia en ella…

    • Joaquín Alviz (@rayjaken) Reply

      ¡Muchas gracias por tu comentario Jorge! Totalmente de acuerdo contigo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Confirma que eres un humano *