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.

Modelo de desarrollo de software en cascada sin modificar

Modelo de desarrollo de software en cascada sin modificar

Marco de desarrollo ágil Scrum:

Algo más realista sería tener en cuenta que van a venir cambios, que es mejor hacer iteraciones cortas que grandes plazos de entrega, involucrar al promotor y usuarios clave desde el inicio, disponer de un equipo estable con conocimientos apropiados, seleccionar aquellas necesidades que realmente aportan valor, ser totalmente transparente con el promotor (Product Owner), con la organización, con el equipo de desarrollo y pruebas (Equipo Scrum), validar las entregas en varios ciclos tempranos y favorecer que equipos auto organizados entreguen productos de calidad.

Scrum fue pensado para la mejora de productos con un desarrollo incremental en lugar de planificación, basándose en la calidad del resultado y permitiendo solapamientos de las diferentes fases del desarrollo.

Esto suena genial, o por lo menos a nosotros nos lo parece. Para afrontar un proyecto con Scrum se necesita que las organizaciones piensen en “Productos terminados de calidad” y que entiendan que tienen que conceder al promotor (Product Owner), Scrum master y equipo de Scrum la confianza necesaria para implantar Scrum e iterar hasta conseguir un alto rendimiento y un incremento de valor de producto.

Ciclo de Sprint en Scrum

Ciclo de Sprint en Scrum

Modelo de fases solapadas en Scrum

Modelo de fases solapadas en Scrum

¿Entonces qué hago? ¿Empleo Scrum o desarrollo en cascada?

 

Pues para decidir qué es lo mejor para tu proyecto o producto, se tendrían que analizar las inquietudes de la organización, objetivos, medios con los que se cuenta y decidir…. Nuestra opinión: Depende y depende de muchos factores.

En sumamoOs nos apasiona escuchar, estaremos encantados en ayudarte a tomar la decisión más acertada. Ponte en contacto con nosotros desde nuestro formulario.

Por cierto, Scrum NO es un desarrollo en cascada con tablero, post-it de colores y reuniones matinales de diez minutos, si estas en una organización que pasa esto, ten en cuenta que tu producto no obtendrá las mejoras que profesa Scrum.

Enlaces:

Desarrollo de software en cascada: Wikipedia

Desarrollo de software con Scrum: Wikipedia