Todas las personas que nos dedicamos a hacer proyectos software nos han hablado del triángulo de hierro. Este triángulo en su versión tradicional funciona de la siguiente manera:
Realizamos una fase de análisis que suele durar bastante y fijamos un alcance; tras eso, hacemos un cálculo del tiempo y del coste que nos va a suponer hacerlo. Además, tratamos de mantener equilibrado el triángulo para que la calidad no sufra.
La experiencia acaba por demostrar que al tener el alcance y el tiempo cerrados, y el coste es limitante (porque por muchos desarrolladores que pongas llega un momento que no avanzas) será la calidad la única variable de la ecuación. Esto supone que acabamos por reducir la calidad para que todo cuadre. Esto ya lo estudiamos en este artículo sobre la calidad en proyectos que es normal que no le acabemos prestando atención (porque prioricemos las demás variables).
La reacción Agile a esto es mantener la palabra proyecto y darle la vuelta al triángulo.
De esta manera la idea es que fijamos el tiempo (un Sprint), fijamos el coste (un Scrum Team) y dejamos que el alcance sea el que de tiempo respetando la calidad. Esta aproximación muchas veces funciona. Fijamos el tiempo y dejamos que el alcance sea “el que de tiempo”. Esto nos debería permitir hacer Scrum a priori ya que el alcance es abierto y esto nos permite trabajar.
Ahora os contaré una historia. Imaginad que vais a trabajar con nuevo cliente y decidís que antes de hablar de números vais a hacer un pequeño análisis en Agile a lo que llamaréis Sprint 0. En el alcance consensuais la decisión de que no bajareis del nivel épica para que el alcance sea abierto. Una vez consensuadas las épicas firmamos un tiempo que estime el Equipo de Desarrollo. ¿Qué podría fallar?
Imagina que empezáis la épica que habéis nombrado “usuarios” donde se den de alta y se gestionen usuarios. El cliente te pide una funcionalidad que sea crear un usuario y hacer login, algo básico para la primera versión y pasáis a otra épica. Ahora, imaginad que se acerca la fecha de entrega final de proyecto y un stakeholder pregunta “¿No hay recordar contraseña?”. Y entonces se entra en un debate bastante absurdo con frases como “es que si no tiene recordar contraseña la épica no vale”, “esto no es un módulo completo”, “así no lo quiere un usuario”, “esto es básico tenerlo”, “sin eso no salimos”.
Este tipo de debates también podrían aparecer, si el alcance es abierto y la confianza no existe entonces cualquier cosa puede “entrar” en ese alcance.
Os pongo algunas preguntas que recomiendo en un alcance abierto:
- ¿Qué ocurrirá si vamos a una velocidad inferior a la que quiere el Product Owner o su organización?
- ¿Qué pasa si lo que estamos construyendo no llega al MVP que tienen en mente?
- ¿Qué ocurrirá si el alcance que da tiempo respetando la calidad no cubre la aplicación que vamos a sustituir?
- ¿El cliente tiene en mente un alcance que si no está completo entonces no le vale nada?
Por muy abierto que sea el alcance, si estamos ante un cliente con mentalidad de proyecto siempre creerá que hay un mínimo que vas a entregar y que sino no le vale nada. Ese el gran problema de la mentalidad de proyecto, nos cerramos mucho a que el éxito es tener una cantidad de software en una fecha.
Por encima de un alcance abierto quizás lo más importante sea construir confianza. Para eso el equipo tiene que tener muy claro que hay que demostrar que siempre se entrega el máximo trabajo posible y que, si está bien priorizado, se genera el máximo valor posible. Enseñar técnicas para que los usuarios puedan ver el incremento, dar feedback y demostrar que estamos descubriendo la solución que de verdad quieren los usuarios. ¡Ahí está el éxito!.
Aunque el alcance abierto es una buena estrategia, analiza las expectativas reales de tu cliente y actúa en consecuencia, no te conformes con un “el alcance es abierto” porque podría generar un problema futuro.
Tabla de contenido
Entradas relacionadas
Transformación Digital según Nacho y Alberto0 (0)
Comentarios recientes