Se discute mucho sobre los pros y los contras de ágile, en cuanto a cuándo es la forma correcta de entregar un proyecto de software y cómo obtener y tasar contratos ágiles. Estas son todas consideraciones importantes, pero como Agile es significativamente diferente del desarrollo en cascada, las organizaciones también deben considerar por adelantado cómo funcionarán las cosas de forma más detallada, día a día..

Las áreas tales como la gobernanza, la composición del equipo, la obtención de comentarios continuos y la ampliación del proyecto deben considerarse debidamente antes de que comience el proyecto..

  • También echa un vistazo a las mejores herramientas de gestión de proyectos

Gestión y gobernanza

Un error común acerca de lo ágil es que está menos controlado porque es menos formal. De hecho, el "libro de texto" ágil deja algo de una brecha en lo que concierne a la gobernabilidad, que muchos han luchado por llenar. Sin embargo, como en cualquier tipo de proyecto, los ágiles deben ser gobernados para que tengan éxito, lo que hace diferente es cómo se hace esto..

Las áreas clave donde se necesita establecer la gobernabilidad son la comunicación, los roles y las responsabilidades. Las estructuras apropiadas deben establecerse y entenderse tanto en la organización contratante como en su socio de desarrollo antes de que el proyecto comience.

La importancia de esto no debe ser subestimada, ya que, a diferencia de los proyectos en cascada, los proyectos ágiles alcanzan a la organización contratante desde el principio, y si alguien no comprende y aprecia su función, o cumple lo que se espera, esto puede descarrilar rápidamente todo el proyecto..

Si bien la gobernabilidad es vital, hay una delgada línea entre muy poco y demasiado. Muy poca gobernanza puede hacer que un proyecto se salga de control, pero igualmente, demasiadas capas de gobernanza estrangularán el proyecto y ahogarán los mismos beneficios que se buscan de Agile..

Esta es la razón por la cual es tan importante para la organización contratante proporcionar un individuo activo y con poder en el rol de Product Owner, que puede tomar las grandes decisiones cuando sea necesario y también controlar cuidadosamente qué características (historias de usuario) se consideran para una iteración determinada..

En los proyectos Scrum, cada sprint tiene un alcance definido, y todos deben entender qué es y que deben permanecer definidos. El peligro de agregar o eliminar historias de usuarios a la mitad de un sprint es que altera el alcance, lo que significa que el sprint puede no entregar el software de trabajo requerido en su conclusión..

Composición del equipo

Mientras que los equipos tradicionales de reparto en cascada están formados por un grupo de especialistas que desempeñan un rol designado (como diseñadores, programadores y evaluadores), los equipos ágiles exitosos están compuestos por personas con múltiples habilidades, cada una de las cuales puede llevar a cabo numerosos papeles. Esto le da al equipo ágil el mayor nivel de control y flexibilidad sobre lo que se puede entregar en una iteración determinada.

También es útil, aunque no es esencial, que los miembros del equipo se conozcan y hayan trabajado juntos antes. Comprender las habilidades de cada uno y cómo las personas trabajan juntas es una gran ayuda cuando se trata de la planificación de Sprint, porque el equipo podrá proporcionar estimaciones más precisas de cuánto esfuerzo requerirá una característica determinada y cuánto tiempo es probable que tomen las cosas..

Realimentación

Si un proyecto ágil es entregar resultados que realmente satisfagan las necesidades subyacentes de la organización, entonces es esencial una retroalimentación continua y de alta calidad para el equipo de desarrollo. Esto se puede entregar a través de la revisión al final de cada iteración, pero también en otras ocasiones según sea necesario. Obtener comentarios oportunos de las partes interesadas debe ser parte de las responsabilidades del Propietario del producto.

La retrospectiva al final de cada iteración es otro mecanismo de retroalimentación importante para el equipo de entrega, permitiendo a todos los involucrados proporcionar sugerencias sobre lo que podría cambiarse para permitir que las futuras iteraciones sean más efectivas.

Escalamiento ágil

Agile ha madurado significativamente durante la última década y ha demostrado ser una metodología de desarrollo creíble. Sin embargo, gran parte de su uso ha sido en proyectos relativamente pequeños (aunque a veces de alto perfil). Eso no quiere decir que no pueda escalarse para ser efectivo en proyectos y programas más grandes, donde múltiples equipos ágiles entregan diferentes elementos.

Para facilitar esto, una organización necesitará un gobierno adicional para coordinar la relación entre los diferentes equipos y garantizar que el trabajo que cada uno está haciendo se integre correctamente con todas las demás piezas del rompecabezas..

Conclusión

Los proyectos ágiles son diferentes de los de cascada, y deben ejecutarse de manera diferente, desde cómo se gobiernan y administran hasta la composición del equipo de entrega. Hacer que estas cosas salgan bien desde el principio es crítico, y requieren un profundo conocimiento de Agile tanto del equipo de entrega como de la organización que está procurando el trabajo..

Al tener un entendimiento completo de sus roles y responsabilidades, cada parte tiene más probabilidades de entregar lo que se requiere, lo que le da al proyecto la mayor posibilidad de éxito.

Owen Philpott, consultor ágil en IPL

  • Estas son las mejores herramientas de gestión de proyectos.