Metodologías Ágiles Desde Una Perspectiva De Project Management

Resumen

La palabra ágil se está convirtiendo últimamente en una palabra bastante usada en el mundo de desarrollo de software donde existe cada vez más la necesidad de ser ágil, esta tendencia hacia una gestión más ágil del proyecto plantea algunas preguntas importantes para los gerentes de proyectos y a las organizaciones que dependen de una disciplina efectiva gestión de proyectos para la implementación exitosa de proyectos de desarrollo de software. Sin embargo existen muchos conceptos equivocados o malas interpretaciones de lo que quiere decir realmente ser ágil temas sobre los cuales se hará mucho hincapié y se tratará de explicar en detalle.

Introducción

El movimiento ágil fue en sus inicios una revolución contra los métodos de cascada tradicional, por lo que muchas personas decidieron distanciarse en la medida de lo posible de las prácticas asociadas con el enfoque tradicional de cascada. Por esa razón, cuando el movimiento ágil empezó, se movió como un péndulo de un extremo al otro del método de cascada tradicional, lo cual implicaba tener poca o ninguna documentación, proceso o metodología, etc. Desde ese momento, el movimiento ágil ha madurado considerablemente.

En el otro extremo del péndulo algunos profesionales defensores del enfoque tradicional de cascada han conservado este enfoque, muchos son muy orientado hacia el control y su principal orientación es la estimación precisa en los costos y en duración del proyecto, por otra parte eso es lo que muchas empresas esperan de su Gerentes de Proyecto, porque es así como son medidos, por lo tanto es muy comprensible por qué se deban sentir muy incómodos con las metodologías ágiles que hacen hincapié en la flexibilidad para adaptarse al cambio.

La selección de una de estas alternativas es una decisión estratégica muy importante para todas las organizaciones que dependen de la gestión eficaz de los proyectos. El enfoque que tomen debe estar bien alineado con la estrategia de negocios dentro de la compañía, así como con los riesgos y complejidad de los proyectos individuales. Por ejemplo la NASA nunca pensarías de una metodología ágil para el software de un transbordador espacial, debido a que los riesgos incurridos serian demasiados altos.

Visión General

Haciendo Historia.

Crecimiento de las metodologías agiles.

Las metodologías ágiles no son nuevas la gente ha estado haciendo varios tipos de proyectos ágiles durante mucho tiempo; Sin embargo, en el mundo actual, el movimiento para adoptar metodologías cada vez más ágiles parece estar creciendo mucho más por las muchas razones:

• Algunas de las metodologías y herramientas para implementar proyectos ágiles como Scrum se están convirtiendo en mucho más comprendidas y aceptadas.

• Muchas empresas han demostrado éxito en implementar proyectos ágiles en la vida real y se han sumado a la base de conocimientos de lo que funciona y qué no funciona en diferentes proyectos y entornos.

• Las ventajas y desventajas asociadas con lograr el equilibrio entre un control suficiente del proyecto y el del alcanzar una mayor agilidad son mejor entendidas y hay muchas maneras de lograr un equilibrio apropiado de estos objetivos con la combinación adecuada de metodologías ágiles y tradicionales.

Proceso de una metodología Ágil – SCRUM.

El Manifiesto Ágil

El manifiesto ágil bastante simple y consiste de cuatro enunciados:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas.

Este es posiblemente el principio más importante del manifiesto.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo y deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa cerrada de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.

• Valorar más el software que funciona que la documentación exhaustiva.

Poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece una retroalimentación muy estimulante y enriquecedor que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma que no hagan falta. Los documentos son soporte de la documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto. Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto. Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.

• Valorar más la colaboración con el cliente que la negociación contractual.

Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.

En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

• Valorar más la respuesta al cambio que el seguimiento de

...