Los proyectos de software en cascada o waterfall siempre se retrasan, ¿La solución es Scrum?

Responder a esta pregunta no es nada sencillo, ya que existen varios factores a tener en cuenta para decidir si se afronta un proyecto con metodología en cascada (tradicional) o Scrum. Para contestar a esta cuestión, se van a exponer una serie de aspectos que posiblemente te ayuden a contestar tú mismo a esta pregunta.

Asimismo, en este post, no se intenta identificar las claves para decidir si es mejor o peor uno u otro marco de desarrollo de software, sino tan sólo, pretende dar una visión general de los beneficios y de las licencias que sería necesario conceder para poder seleccionar uno u otro.

También, para evitar que se haga el artículo muy largo, me tomo la libertad de pensar que conoces qué es un desarrollo en cascada y un desarrollo de software con Scrum. Si no es así, más abajo dejo unos enlaces para que puedas echar un vistazo.

Bueno, vamos al lío. Tradicionalmente, los proyectos suelen tener retrasos o cambios de planificación por las siguientes razones:

• Escasa o parcial definición inicial de las necesidades o requisitos.
• Dedicación de mucho tiempo a un análisis funcional que no es validado o se ha validado hace meses, que incluye más una “declaración de intenciones” que unos casos de uso concretos.
• Una mala estimación de recursos, tiempo y coste.
• Descoordinación o no alineamiento inicial entre la organización, promotor, usuarios clave, director o jefe de proyecto y equipo de proyecto.
• Cambios de alcance. Aquí entrarían los aceptados como tal, los que se entienden que entran en el proyecto porque “impactan poco” y los normativos que pueden venir para cumplir con alguna legalidad.
• Mala gestión de riesgos o inexistente.
• Retrasos en desarrollos de terceros.
• Retraso en aceptaciones de entregables.
• Se pidió una necesidad, que se definió una manera y que se desarrolló sin tener en cuenta la necesidad, quien lo pidió y quién lo iba a usar.
• Cambios en la gestión, equipo de desarrollo o pruebas.
• Equipo de trabajo desequilibrado, poca experiencia o con perfiles incorrectos.
• Y así podríamos hacer una lista interminable de motivos reales y realistas por los que se retrasan los proyectos…

¡Aquí viene la sorpresa! Esta lista podría ser totalmente válida para proyectos ejecutados en cascada o Scrum. Vaya faena, ¿verdad?

Entonces da igual emplear cascada o Scrum, ¿no es así? En sumamoOs, creemos que los resultados no son los mismos. Nuestra experiencia nos hace poder confirmar que plantear un proyecto con un método de desarrollo u otro es una importante decisión que retornará diferentes resultados. La elección dependerá de la visión de la empresa, de lo que la organización esté dispuesta a conceder, de los resultados esperados y de la formación del equipo (de las personas). Los proyectos en cascada se enfocan a gestión de proyectos y los proyectos con Scrum en la gestión de personas.

Proyectos de desarrollo de software en cascada:

Ejecutar proyectos complejos en cascada o waterfall, funciona y muy bien, no obstante se tienen que respaldar con una eficiente gestión de proyectos que encarecerá el proyecto y lo hará mucho más complejo de lo que ya es. Este aspecto no es algo negativo, sino que es algo a tener en cuenta.

Los proyectos complejos desarrollados en cascada, bajo mi punto de vista, tienen los tres factores clave del acotamiento:

• Alcance acotado.
• Presupuesto importante acotado.
• Plazos largos acotados.

Estos factores, según nuestra experiencia, no son muy realistas ya que normalmente suelen cambiar durante la implantación de cualquier proyecto.

Para un lector que haya tenido que intervenir en un proyecto mediano, grande o muy grande sabe que los proyectos complejos cambian, siempre hay aspectos que se deciden no afrontar y otros que se identifican como necesarios e imprescindibles para ser incluidos. Esto hará que el proyecto se re-planifique, se elaboren peticiones de cambio y que se amplíe el presupuesto inicial.