Por qué Scrum: proceso definido vs proceso empírico

Hay proyectos que son bastante sencillos y relativamente predecibles, donde se pueden aplicar herramientas racionales de planificación y toma de decisiones. Otros proyectos que son más complejos o impredecibles requieren un enfoque diferente que se base más en la autoorganización y la innovación.

La mayoría de los proyectos de desarrollo de software se consideran de naturaleza compleja e impredecible debido a la convergencia de tres factores: personas, requisitos y tecnología. Los diversos enfoques utilizados para entregar y administrar proyectos podrían entenderse más fácilmente en el contexto de los modelos de control de procesos y la complejidad del proyecto.

Proceso definido: un enfoque tradicional basado en un plan

Tradicionalmente, una vez que comienza un proyecto, se crea un paquete de requisitos y luego se «aprueba». El gerente del proyecto asume que esta aprobación da como resultado un conjunto fijo de requisitos y que ahora puede comenzar la planificación. El director del proyecto estima cuánto tiempo llevará completar los requisitos y crea el plan del proyecto. El plan predice que el proyecto estará terminado en una fecha determinada, y esa fecha se comunica al cliente.

El defecto fundamental de este enfoque es que el plan, que impulsa todo, se basa en la suposición de que los requisitos son fijos y no cambiarán. La experiencia nos ha demostrado que este nunca es el caso; los requisitos nunca son fijos, siempre cambian. Cuando los requisitos cambian, el plan se ve afectado; y como resultado, la fecha de finalización también debe cambiar. Desafortunadamente, en muchos casos, eso es imposible y el equipo tiene que entregar en la fecha a la que se comprometieron. Es entonces cuando se produce una gran crisis y el proyecto empieza a salirse de control.

Proceso empírico: enfoque ágil impulsado por el valor

El enfoque ágil impulsado por el valor se basa en el  empirismo  que cambia toda la mentalidad. Asume desde el principio que los requisitos que existen por adelantado no son fijos y que cambiarán.

La mentalidad ágil también supone que debe entregar en una fecha determinada. Este enfoque fija el tiempo y los recursos y deja los requisitos sin determinar. Para nosotros, este enfoque se parece más a la realidad de crear software. Ahora toda la noción de impulsado por el valor tiene mucho sentido. Cuando tiene una cantidad fija de tiempo en la que no está seguro de poder cumplir con todos los requisitos (porque cambiarán y, por lo tanto, cambiará el tiempo necesario para terminarlos), la reacción natural es priorizar los requisitos y terminar primero. aquellos que agregan más valor al cliente.

Puede estar pensando: «¿Qué pasa con los requisitos que no están terminados para la fecha de entrega?» Esa es la razón por la que utiliza el enfoque basado en el valor. Usted reconoce el hecho de que no todos los requisitos se completarán en la fecha de entrega. La pregunta importante que debe hacerse es si ha proporcionado suficientes funciones para admitir un sistema que proporcione valor al cliente.

Tasa de fracaso de los proyectos de software

El Informe CHAOS 2015   ha sido publicado recientemente por  Standish Group . Los Informes CHAOS se han publicado todos los años desde 1994 y son una instantánea del estado de la industria del desarrollo de software. Este año, el informe estudió 50 000 proyectos en todo el mundo, desde pequeñas mejoras hasta implementaciones masivas de reingeniería de sistemas. Este año, el informe incluye una definición mejorada de éxito que analiza algunos factores adicionales que se cubrieron en encuestas anteriores.

Los resultados indican que aún queda trabajo por hacer para lograr resultados exitosos de los proyectos de desarrollo de software. Esta tabla resume los resultados de los proyectos durante los últimos cinco años usando la nueva definición de factores de éxito (a tiempo, dentro del presupuesto con un resultado satisfactorio).

Con la adopción de métodos de desarrollo ágiles en los últimos años, fue posible comparar los resultados de los proyectos entre los proyectos en cascada ágiles y tradicionales. En todos los tamaños de proyectos, los enfoques ágiles dieron como resultado proyectos más exitosos y menos fallas absolutas, como se muestra en esta tabla

¿Cuáles son los problemas del enfoque tradicional?

El enfoque tradicional basado en un plan no es defectuoso en sí mismo; simplemente no es adecuado para la industria del software actual. El enfoque basado en planes se basó originalmente en los conceptos tradicionales de gestión de proyectos, que se originaron en la industria de la construcción. En la industria de la construcción, el enfoque basado en planes es adecuado: los planos, que son los requisitos, son fijos y probablemente no cambiarán mientras se construye el edificio. Puede estimar cuánto tiempo llevará construir los pilares de acero, verter el hormigón, etc.

La razón por la cual el enfoque tradicional basado en planes es adecuado para la industria de la construcción pero no para la industria del software se remonta a la diferencia en la forma en que controlamos los sistemas empíricos (como el desarrollo de software) y la forma en que controlamos los sistemas definidos (como la construcción o la fabricación). ). La siguiente tabla muestra las diferencias entre las características de un proceso definido y las de un proceso empírico.

Después de leer la tabla, es fácil ver que el desarrollo de software es definitivamente un proceso empírico, no un proceso definido. El problema es que llevamos años abordando el desarrollo de software como un proceso definido, y ese enfoque no funciona.

Referencias

1. Informe de Caos 2015 de Standish Group
2. Volverse ágil en una palabra imperfecta — por Greg Smith y Ahmed Sidky

Otras lecturas de Scrum

• Scrum en 3 minutos
• ¿Cuáles son los 5 valores de Scrum?
• ¿Qué es la Evolución de Scrum?
• Gestión de proyectos clásica frente a gestión de proyectos ágil
• ¿Por qué Scrum es difícil de dominar?
• ¿Qué es la velocidad en Scrum?
• ¿Qué es Ágil? ¿Qué es Scrum?