El alcance, el cambios y la incertidumbre desde la perspectiva Scrum

En el post anterior les comenté como Scrum enfrenta algunos problemas que suelen ser recurrentes en la gestión tradicional de proyectos. Hoy les comentaré sobre otros ejemplos.

Alcance y cambios.

Cuando se sigue la gestión tradicional, se trata por todos los medios de fijar un alcance desde el mismo inicio del proyecto, cuando en la mayoría de los casos, el cliente no está ni siquiera seguro de lo que realmente necesita. Luego de fijado ese alcance puede ser realmente difícil aprobar un cambio.

Scrum abraza la posibilidad del cambio y tiene como objetivo fundamental entregar valor al cliente a partir de entregas periódicas de software funcionando. La filosofía de Scrum hace que sea sencillo introducir los cambios, sobre todo porque haciendo uso de este marco de trabajo, las funcionalidades o historias de usuario al terminar cada Sprint o están terminadas o no han comenzado. El dueño del producto es el encargado de priorizar que trabajo realizar que en efecto aporte valor al producto.

El desarrollo por Sprint de 2 a 4 semanas, alrededor de un mes, permite al cliente ir conociendo si realmente eso es lo que necesitaba e ir variando sus necesidades de forma que se obtenga un producto de valor. La priorización de las historias de usuario a desarrollar durante cada Sprint, permite que la introducción de cambios dentro del desarrollo sea relativamente fácil. Esto puede ser menos o más traumático a partir de la variación de presupuestos o del modelo de contratación utilizado. La contratación suele ser el impedimento más difícil de sortear cuando de cambios se trata.

Información suficiente y experiencia.

Cuando se asume un proyecto de software, es común que al inicio del mismo no se cuente con toda la información necesaria y establecer una planificación exacta se vuelve prácticamente imposible. Esto es algo que se conoce como el cono de incertidumbre.

Mientras más al inicio del proyecto, más incertidumbre existe para establecer una planificación y estimación acertada. A medida que se avanza en el desarrollo, la incertidumbre va disminuyendo, sobre todo por las actividades que se han realizado.

Entonces, según la gestión tradicional, mientras más actividades a planificar y desarrollar, mayor es la incertidumbre. ¿y qué tal si se pudiese reducir esa incertidumbre desde el mismo inicio del proyecto?

Precisamente esto es lo que consigue Scrum con su modelo de desarrollo a partir de Sprint. Si se reducen las actividades a desarrollar y el tiempo en que estas serán realizadas, el cono de incertidumbre se reduce significativamente. Un sprint tiene una duración de 2 a 4 semanas aproximadamente, estamos hablando de un mes de trabajo y la cantidad de funcionalidades a desarrollar es la que se haya acordado con el Dueño del Producto y con las cuales el equipo de desarrollo estuvo de acuerdo y se comprometió a entregar.

Cuando el objetivo se centra en determinadas funcionalidades y el tiempo de ejecución está limitado a unas cuatro semanas, sin dudas el cono de incertidumbre se reduce y es más fácil poder hacer una estimación más confiable. Si por el contrario nos centramos en tener en cuenta cada detalle del proyecto para digamos un año de duración, la incertidumbre hará que la planificación y estimación sea muy imprecisa. El equipo de desarrollo participa activamente en esta estimación y responde por ella.

Contar con el equipo, tener en cuenta sus criterios y experiencia.

Este es uno de los mayores errores cuando de gestión de proyectos se habla. En ocasiones las planificaciones las realiza una persona que no será quien desarrolle las actividades y lo que es peor, que no conoce al equipo ni sus habilidades.

En Scrum el equipo de desarrollo es quien realiza la estimación y el desglose de las tareas a realizar. Es el responsable de cumplir con las historias de usuario que fueron seleccionadas para desarrollar en el Sprint. Cuanta más experiencia acumulen, más acertado será el resultado. La experiencia es fundamental, pues en base a proyectos anteriores, donde las actividades a desarrollar puedan ser similares, podría contarse con un criterio que permitiera estimar sobre la base de algo que ya se hizo.

Existen varias técnicas de estimación ágil, pero eso será objetivo de otro post.

Varias personas me han contactado comunicándome que se identifican con algunos de los problemas que he presentado aquí y que les gustaría conocer más sobre Scrum. Mi primer consejo es que se descarguen la guía de Scrum y se la estudian, pero además, dedicaré la siguiente serie de posts a explicar la teoría de Scrum. También los invito a suscribirse a mi canal de youtube, donde trato temas de desarrollo ágil y Scrum.

Como siempre agradeceré sus comentarios y experiencias que quieran compartir.