Desmitificando la planificación predictiva

Desmitificando la planificación predictiva

El ciclo de vida del software empieza con los requisitos, el análisis y el diseño, continua con el desarrollo, las pruebas, la puesta en producción y el mantenimiento y se cierra el círculo para volver a empezar. El modelo en cascada pretende dar solución a este círculo con un planteamiento lineal y secuencial. Pretende ir pasando etapa a etapa y volver a la etapa anterior en caso de problemas o errores.

Las premisas por las que se rige la planificación predictiva son:

  • Todos los proyectos mantienen características y comportamientos regulares.
  • El objetivo de la ejecución de un proyecto es lograr el producto previsto en el tiempo planificado si desbordar los costes estimados.

La primera premisa hace referencia a la universalidad de los proyectos. Todos comparten patrones comunes de ejecución. En este caso las prácticas de gestión se basan en estos patrones comunes. Se asume que resultan válidos para cualquier tipo de proyecto.

La segunda premisa hace referencia al carácter predictivo de los proyectos. Primero se define de forma detallada el producto previsto. Se elabora un plan de desarrollo y se calculan los costes y fechas a partir del plan de desarrollo. Para el cálculo de costes se hace una estimación del tiempo que ocupará. Conscientes de las posibles desviaciones también se definen planes de seguimiento y vigilancia.

Todo esto estaría muy bien, sino fuera por, a palabras de Richard Moore, desarrollador de KDE: La diferencia entre la teoría y la práctica es que, en teoría, no hay diferencia entre la teoría y la práctica.

Un primer error en las premisas de la planificación predictiva es que no hay una forma única y válida para todos. Existen distintas características diferenciales:

  • Componente innovador que se espera del resultado
  • Grado de estabilidad de los requisitos durante el desarrollo
  • Costes de prototipado y desarrollo
  • Maleabilidad del producto para ser modificado una vez desarrollado

Un segundo error es el choque del valor y la innovación contra el cumplimiento del plan. Algunos proyectos tienen como objetivos:

  • Salir al mercado con un nuevo sistema lo antes posible
  • Evolucionar la visión del proyecto con su uso
  • Mejorar el valor de forma continua

Si quieres aprender una forma de calcular más empíricamente la cantidad de trabajo para realizar una tarea puedes leer este artículo.

Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

Pitu Sabadí
Pitu Sabadí
Agile enthusiast & Fullstack developer

CEO y Product Owner de Pleasepoint, profesor de Agile en el Máster de UIUX en ESDi, fullstack developer y believer en la vida. Las experiencias vividas en la creación de productos digitales, el trabajo en equipo, la mejora continua y la aceleración de grupos dan contenidos al blog.

También te puede interesar...