En este artículo voy a mencionar una de las diferencias más importantes entre la gestión de proyectos ágiles y la tradicional y por qué esta última tiene una tasa de fracaso tan elevada.
Como cliente de cualquier producto o servicio voy a querer saber qué voy a obtener, en qué medida se van a satisfacer mis necesidades, con qué calidad, cuanto tiempo voy a tener que esperar para comenzar a utilizarlo, que garantía me ofrecen y cuánto me va a costar todo eso. Toda esta información es relevante para decidir si es conveniente ejecutar el proyecto o no. Luego de cerrado el acuerdo, si alguna de las condiciones mencionadas no se cumple me voy a sentir en derecho de reclamar, cancelar el trato y obtener mi dinero de regreso por incumplimiento de contrato.
La Gestión Tradicional
La gestión tradicional de proyectos en ocasiones busca aplicar esa misma lógica en la industria del software. El cliente quiere asegurar sus intereses exigiendo que se le defina de antemano las tres dimensiones de los proyectos de software (costo, duración y alcance) y por supuesto con la mejor calidad posible (sin defectos, sin deuda técnica, etc.).
Por desgracia, la complejidad intrínseca del desarrollo de software hace que en la mayoría de los proyectos no sea posible predecir (y por lo tanto fijar) con precisión aceptable la duración, el costo y el alcance.
El problema aparece cuando no se reconoce esto ante el cliente y las estimaciones se traducen como compromisos.
La Dicotomía de las Estimaciones
Cuando un desarrollador de software hace una estimación de un requerimiento está tomando suposiciones y haciendo conjeturas para llegar a un número que tiene un margen de error asociado (por lo tanto, no es un número sino una distribución). Esta estimación es muchas veces tomada como un compromiso del desarrollador de cumplir con esa estimación.
Una estimación, dice Mike Cohn, está asociada a una probabilidad de que ocurra y un compromiso no puede tener una probabilidad asociada, por eso una estimación nunca puede ser un compromiso.
Como consecuencia, una cantidad importante de proyectos de software terminan cancelados por no cumplir con algunas de las dimensiones, mientras que la mayoría continúan pero renegociando las dimensiones (incluso a veces afectando también la calidad), ya que el costo de la oportunidad perdida suele ser mayor si se cancela el proyecto. El cliente termina con un producto que le costó más, le demoró más y/o cuenta con menos funcionalidades de las originalmente prometidas.
Los desarrolladores tienden a subestimar
Como agravante al tema de las estimaciones, se sabe que es más probable que el error sea por subestimación que por sobreestimación. Esto es un agravante porque subestimar resulta más costoso que sobreestimar. Algunas razones este fenómeno son las siguientes:
- Las personas son optimistas y tienen un fuerte deseo de complacer.
- Las experiencias pasadas son recordadas de forma incompleta.
- Enfoque sesgado: cuando el programador hace la estimación sólo tiene en cuenta su parte o la etapa principal y no tiene en cuenta otros aspecto del trabajo que también consumen tiempo, como el testing, la documentación, las correcciones, la implementación etc. (la etapa de programación representa sólo entre 14 y 37% del trabajo total.)
- «Wishful Thinking» y «The Planning Fallacy» son estudios que demuestran que las personas imaginan el futuro como el escenario deseable.
El Cono de la Incertidumbre
El Cono de la Incertidumbre de Barry Boehm representa el nivel de desconocimiento que se tiene de un proyecto en las distintas etapas del mismo y su impacto en las estimaciones. Como se puede ver en el gráfico en la etapa inicial la estimación puede variar ente 60% – 160%. Es interesante además notar que la estimación siempre tiene un error asociado, incluso en etapas avanzadas del proyecto. Sólo se puede saber cuánto duró el proyecto una vez terminado.
The Chaos Report
Por otra parte, The Standish Group ofrece un estudio estadístico (conocido como «The Chaos Report») con resultados reveladores en base a miles de proyectos relevados a lo largo de varios años. Los resultados son los siguientes:
- Proyectos Exitosos: sólo el 16.2% de los proyectos son exitosos, es decir, completado dentro del tiempo y presupuesto estimados y con todas las funcionalidades especificadas implementadas.
- Proyectos Problemáticos: el 52.7% del total de proyecto fue completado y es operacional pero costó más de lo estimado, demoró más de lo estimado y ofrece menos funcionalidades de las inicialmente especificadas.
- Proyectos Fracasados: el 31.1% del total de los proyectos fracasaron, es decir no llegaron a completarse por cancelarse en algún punto durante el ciclo de desarrollo.
Con cifras tan alarmantes resulta de interés profundizar en cada una, para lo cual podemos segmentar por tamaño de empresa:
Sólo 9% de los proyectos en grandes empresas son exitosos, 16.2% en el caso de medianas empresas y 28% para las pequeñas. Los proyectos problemáticos, en las grandes empresas es del 61.5%, en el caso de las medianas el 46.7% y para las pequeñas 50.4%. Los proyectos fracasados representan el 29.5% en las grandes empresas, 37.1% en las medianas y 21.6% en las pequeñas.
Si analizamos cómo cada una de estas variables resulta afectada en los proyectos problemáticos y fracasados, vemos que en promedio los proyectos cuestan un 189% con respecto al presupuestado. La duración promedio es de 222% con respecto al estimado original y con respecto al alcance, los productos ofrecen, en promedio, sólo el 61% de las funcionalidades originalmente especificadas.
Factores determinantes
El estudio del Standish Group también se extiende a relevar qué factores son clave para determinar el éxito de los proyectos. El resultado es el siguiente:
- Involucramiento del usuario (15.9%)
- Soporte de la alta gerencia (13.9%)
- Requerimientos claros (13%)
- Planificación apropiada (9.6%)
- Expectativas realistas (8.2%)
- Hitos más pequeños (7.7%)
- Personal competente (7.2%)
Para más detalles el reporte original: The Chaos Report
El Triángulo de Hierro
Los datos dejan en evidencia la importancia del «Triángulo de las Restricciones» o «Iron Triangle» tan mencionado en las metodologías ágiles y administración de proyectos, donde se reconoce que no se puede fijar las tres variables básicas, sino por lo menos dos dejando la tercera libre y que modificando cualquiera de ellas va a tener un impacto en las otras dos.
La diferencia en metodologías ágiles
Una diferencia clave entre la gestión tradicional de proyectos y la gestión ágiles es que la primera busca fijar la dimensión de alcance, congelando desde el inicio qué funcionalidades debe ofrecer el sistema. A partir de allí el costo del desarrollo y la duración son estimados.
En la gestión ágil, el triángulo se invierte: el tiempo y el costo son fijos, y el alcance es estimado. Se desarrolla por iteraciones que tienen una duración fija, al final de la iteración se entrega un producto de software funcional y con calidad integrada. El costo de la iteración también es conocido de antemano y el cliente puede decidir cuantas iteraciones desea pagar para obtener en cada una el incremento de software estimado.
Este enfoque es más «ágil» porque permite al cliente obtener las funcionalidades más prioritarias primero, implementadas y funcionales generando valor y feedback desde temprano. Decidir qué funcionalidades implementar en la siguiente iteración, pudiendo cambiar las prioridades entre iteraciones de acuerdo al feedback, el aprendizaje del dominio (negocio) y los cambios en el contexto y decidir cuando detener el desarrollo por alcanzar el retorno deseado por la inversión realizada (ROI).
Fuentes
- Estimating and Planning (Mike Cohn)
- The Clean Coder (Robert C. Martin)
- The Standish Group Chaos Report
- Underestimation is Underestimated (
http://blog.karmona.com/index.php/2010/04/19/underestimation-is-underestimated)
Damián Buonamico
Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico
[mc4wp_form id=»228″]
Camino Ágil 