Agile

Diferencias entre la gestión tradicional y la gestión ágil de Proyectos de Software

proyectos software¿Ha tenido usted alguna vez la experiencia de un proyecto software que haya fracasado? Si ha estado trabajando en este sector algún tiempo, es casi seguro que le ha pasado alguna vez. ¿Recuerda la sensación cuando se iba dando cuenta de que no iba a ser posible cumplir el plazo, o que el producto sería inaceptable? Usted intentó alertar a la Dirección, pero ellos no querían escucharle. Más bien al contrario, declaraban abiertamente lo bien que iba el proyecto. A usted le parecía un tanto “surrealista” lo convencidos que estaban de que todo iba bien, cuando era obvio que todo iba mal. Los que sabían que su proyecto iba en caída libre, tampoco querían hacer nada al respecto. En vez de intentar salvar el proyecto, se concentraban en salvarse a ellos mismos: El proyecto no iba tan mal (por lo menos en su área no había problemas).

¿Recuerda el estilo de gestión que se utilizaba en este proyecto? Apuesto a que la comunicación no era buena, y había poca realimentación por parte de los miembros del equipo sobre requisitos, funcionalidad, tamaño, etc. Si alguno de ellos trataba de decir algo sobre la situación real del proyecto, se le tachaba de “negativo” o “poco colaborador”.

Ese proyecto fracasó, básicamente, porque los miembros del equipo sabían la verdad y la dirección se negaba a admitirla. No había espíritu colaborativo ni verdadera comunicación. Fue una mala experiencia y no quiere que se repita ahora que está a punto de comenzar otro nuevo proyecto software.

¿Por qué fracasan los proyectos software?

Muchos proyectos software fracasan porque se hacen de la forma tradicional. La forma tradicional de gestionar un proyecto software se denomina “ciclo de vida en cascada“. En estos proyectos, se planifica en profundidad al principio y se pretende reducir los cambios en fase de ejecución. Se llama “en cascada” porque las fases del proyecto (requisitos, especificaciones funcionales, diseño, implementación y pruebas) transcurren como los saltos de agua de una cascada (cuando una fase acaba, se baja al siguiente nivel, sin posibilidad de vuelta atrás).

El método de trabajo inflexible, orientado a cumplir exhaustivamente la planificación, hace que cuando estos grandes proyectos terminan, muchas veces el cliente no obtiene lo que quería  que no hayan producido lo que el cliente quería, lo que suele explicarse porque una vez se supera la planificación, ya no hay comunicación eficaz con el cliente. Como tampoco se analizan las lecciones aprendidas, los mismos errores se repiten una y otra vez en los proyectos siguientes.

Los problemas de la gestión de proyectos tradicional

Los proyectos software que se gestionan de forma predictiva, siguiendo estrictamente una planificación inicial, no se entrega valor al cliente hasta que se produce la entrega final. No se hacen buenas pruebas hasta las últimas fases del proyecto, los grandes problemas permanecen encubiertos, y cuando se descubren ya es demasiado tarde para repararlos. Tampoco se produce ninguna validación por parte del cliente hasta el final del ciclo de vida, cuando, cuando sus requisitos pueden haber cambiado drásticamente.

En este tipo de proyectos, si el Director del Proyecto es sustituido (o se va de la empresa), el proyecto está en peligro porque suele depender demasiado de la dirección de una sola persona.

Usando métodos ágiles para gestionar proyectos software

Cada vez más empresas están cambiando a métodos ágiles porque el tipo tradicional de gestión no está funcionando.

Los métodos ágiles han evolucionado durante años a partir de los procesos de fabricación como “just-in-time” (JIT). JIT trataba de reducir los desperdicios y la sobreproducción determinando qué partes se necesitaba por el cliente en cada fase, mejor que producir masivamente demasiados productos que se quedaban en el almacén. JIT surgió como resultado de las nuevas capacidades de computación, que permitían gestionar inventarios y predecir cuántas unidades serían requeridas, dónde y cuándo. Antes de JIT, había que mantener grandes almacenes porque nadie sabía calcular qué cantidades serían requeridas, y quedarse sin producto era peor que tener productos sobrantes. Después de JIT, los suministros llegarían justo a tiempo para ser usados. Este concepto ha sido extendido y adaptado hasta convertirse en una herramienta útil para gestionar proyectos de software.

Los métodos ágiles se parecen a JIT porque los componentes de software son entregados tan pronto como están listos: no se “almacenan” con el objeto de entregar todo a la vez.

La idea básica de los métodos ágiles

La forma ágil de trabajar consiste en lo siguiente: En vez de pasar mucho tiempo planificando un proyecto al principio, luego ejecutando el plan sin revisión ni comunicación frecuente con el cliente, se planifica una pequeña funcionalidad que se puede entregar rápidamente.

A diferencia de lo que ocurría con los métodos predictivos, con los métodos ágiles (o adaptativos) se puede empezar el proyecto sin un plan completo. Dicho plan irá surgiendo poco a poco, según se avanza. En los métodos predictivos, donde se tiene un plan completo desde el principio, los cambios se toleran peor porque también hay que modificar la planificación.

En los métodos ágiles, se comienza planificando una pequeña parte inicial, se asigna un equipo con las habilidades necesarias y comienza a trabajar. No se pierde tiempo esperando a que alguien termine algo en otra parte de la organización. Se desarrolla el elemento de software y se va probando según se avanza. Al final de una corta iteración, hay algo que poder enseñar al cliente, ya sea un prototipo o una demo. El cliente percibe un valor en esa entrega y transmite buena realimentación sobre la funcionalidad y la usabilidad. Después comienza una siguiente iteración incremental.

Según se avanza iteración a iteración, se va reduciendo la sobrecarga del proyecto que no aporta valor (como es la planificación sobre demasiados supuestos, funcionalidad interesante pero no realmente necesaria, etc.).

Autor:

José Barato, PMP. Instructor de ESI International España

proyectos agiles ESI

3 pensamientos en “Diferencias entre la gestión tradicional y la gestión ágil de Proyectos de Software

  1. Si el metodo Agile es implementado en este tipo de proyectos de software, que decir de la forma de gestionar el tiempo de entregas de avances que es lo que el cliente espera, en la fecha que él espera. Surge por ejemplo que entre la 2da. y la 3ra.entrega de avaces puede existir una serie de dificultades en programación (proyecto complejo por ejemplo) como gestionar lo que pueda ocurrir en ese lapso de tiempo, debería haber una estrechaintegración con

    Me gusta

  2. Hola, a mi opinión las metodologías ágiles ayudan más en la administración de un proyecto, por otro lado en la fase de entregas lo que los usuarios piden es documentación lo que en las ágiles no es necesario, pero ya se está llevando a cabo un nuevo método que metodologías híbridas que hacen una combinación de metodologías tradicionales tomando formatos para complementar a las ágiles, de está forma hacemos ágil el proyecto y se entrega documentación a los usuarios.

    Me gusta

  3. Me acabo de acordar de un proyecto que usamos el programa PRIMAVERA, hace unos años, necesitvamos acabar una actividad para poder comenzar otra, o bien, necesitavamos haber completado una actividad para poderla facturar por certificaciones. Fue un regalito, habia partidas de pavimentos que por faltar las tapas de las arquetas, no se podian facturar cuantias muy importantes de dinero, cuando veo el nombre del programa me hecho a temblar..

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s