“Scope Creep” en proyectos de software. ¿Qué es y cómo controlarlo?
Foto de Daria Nepriakhina 🇺🇦 en Unsplash

“Scope Creep” en proyectos de software. ¿Qué es y cómo controlarlo?

Cada año más del 50% de los proyectos de software fracasan total o parcialmente según un estudio, siendo la ampliación del alcance en los proyectos (Score Creep) uno de los factores más destacados que provocan el no cumplimiento de lo estimado inicialmente.

Concretamente, cuando hablamos de “Score Creep” nos referimos a los cambios de alcance que se introducen una vez ya se ha iniciado el proyecto, haciendo que sea necesario realizar más tareas pero manteniendo los plazos y los costes estimados inicialmente.

Otro concepto relacionado es el que se conoce como “Feature Creep”. Este concepto hace referencia a todas las nuevas funcionalidades que se añaden a un producto pero que no estaban en el alcance inicial del proyecto. Estas nuevas funcionalidades pueden acabar cambiando completamente el alcance del proyecto, derivando en este caso en la ampliación del alcance total del proyecto (Score Creep). 

¿Cómo podemos controlarlo? 

Una de las cosas que debemos entender es que los cambios de alcance en realidad son inevitables, de ahí que las metodologías ágiles sean las metodologías más utilizadas para la gestión de proyectos de software, ya que tener todo definido y cerrado desde un principio no es un enfoque válido en proyectos reales. En cualquier caso, esto no significa que no debamos prestar especial atención a estos cambios de alcance e intentar minimizarlos al máximo. 

En la fase inicial de definición del proyecto, es de vital importancia que los objetivos a conseguir queden perfectamente claros. En muchas ocasiones, se acaban realizando estimaciones con objetivos poco definidos, sin realizar una definición de qué entregables tendrá el proyecto o sobre unos requisitos poco bajados. Todo esto provoca que una vez se realice la cotización del proyecto bajo estas hipótesis, los cambios de alcance que se produzcan en mitad del desarrollo provocarán que el proyecto fracase en términos de costes y de plazos, haciendo además que el equipo del proyecto entre en el conocido “burnout”.

Para que podamos mejorar las estimaciones, debemos descomponer esta fase de definición en pequeñas subfases que ayuden a definir el alcance del proyecto: 

  • Definición del proyecto, incluyendo los objetivos de negocio que se busca alcanzar, las necesidades de los usuarios y los límites del proyecto
  • Preparación de un prototipo que pueda ser validado por todos los stakeholders. Esta fase servirá para tener una visión compartida del proyecto, validando así lo establecido en la fase anterior. 
  • Definir el mínimo producto viable. En este punto, con una definición clara del proyecto y unos prototipos validados, se puede cerrar la primera versión que se desarrollará del proyecto. Definir este punto ayudará a reducir lo máximo posible el “Score Creep”, ya que cualquier funcionalidad que no sea vital para el lanzamiento, no será priorizada para su desarrollo.

Realizar estimaciones con alcances más cerrados ayudará a reducir la incertidumbre del proyecto. Una vez lanzado el MVP, las sucesivas iteraciones serán más fáciles de definir y estimar si lo comparamos con realizar una estimación total del proyecto en una fase muy temprana, sobre todo si no se han definido al detalle los requerimientos. 

Sigue el mantra Yagni 

Yagni o “You Aren’t Gonna Need It”, es un mantra utilizado en extreme programming y en metodologías de desarrollo ágiles que propone que no debemos desarrollar nuevas funcionalidades hasta el momento en que sean necesarias, ni tan siquiera aunque presumiblemente creamos que en un futuro serán necesarias. 

Este concepto nos puede ayudar también a combatir el “Scope Creep”, ya que en muchas ocasiones se acaban añadiendo nuevas funcionalidades que finalmente nunca acaban siendo utilizadas (además de añadir complejidad al código actual de manera innecesaria).  

Este enfoque es necesario que lo tengan todos los miembros del equipo, ya sean desarrolladores o el resto de stakeholders, ya que nos ayudará a no realizar cambios de alcance, sobre todo si son funcionalidades que no se acaban utilizando. 

¿Qué otros aspectos son importantes? 

La priorización de las tareas es un aspecto clave para el éxito del proyecto, ya que deberíamos estar centrados en las tareas más importantes y que sean necesarias en la actualidad (siguiendo Yagni), evitando así retrasos por estar realizando tareas no prioritarias. 

Finalmente, en cada proyecto debería haber una única persona responsable de tomar la decisión de qué cambios de alcance son aceptados y cómo se priorizará con el resto de tareas, ya que si hay varias partes decidiendo, es probable que las distintas solicitudes entren en conflicto y no se puedan priorizar correctamente, haciendo que el alcance del proyecto se haga inmanejable.

Inicia sesión para ver o añadir un comentario.

Otros usuarios han visto

Ver temas