Los cambios de requisitos son bienvenidos con Scrum, pero ¿a qué precio?
La gestión de proyectos predictiva afirma que la forma más eficiente de hacer un trabajo es hacerlo bien a la primera. ¿Es más eficiente la gestión de proyectos predictiva que la gesitón de proyectos ágil?.
La ingeniería de software tradicional necesita requisitos detallados y estables.
Para la gestión de requisitos tradicional, (una de las cinco áreas de conocimiento de la ingeniería de requisitos según SWEBOK) cada modificación de requisitos es una "incidencia". Un torpedo contra el éxito del proyecto que requiere un estudio de impacto y medidas de reparación.
Sin embargo , los requisitos genéricos y los cambios durante el desarrollo son las premisas del desarrollo ágil, que afirma cosas como "Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente".
La clave de esta aparente contradicción está en los ciclos de vida empleados por unos y por otros: El desarrollo secuencial o en cascada necesita requisitos detallados y estables, algo que no sucede si se usan modelos iterativos.
Requirements Management in an Agile-Scrum
Pero... todo tiene su precio. La agilidad se adapta al cambio y da más valor a la visión del producto, en cada modificación que va descubriendo mientras lo construye... pero claro, los cambios de requisitos repercuten en la eficiencia del equipo y en la calidad entregada.
Porque es evidente que "La forma más eficiente de hacer un trabajo es hacerlo bien a la primera".
¿Sí?.
¿Alguien lo ha comprobado, o simplemente se da por supuesto porque parece obvio?.
Esto es lo que se plantearon los profesores de la Universidad de San Marcos en Texas Elizabeth Oyeyipo y Carl Mueller, y para comprobarlo han realizado un estudio con 33 alumnos de Ingeniería de Software, formando 8 equipos de 4 ó 5 programadores y cuyos resultados publica la Universidad en el reciente informe "Requirements Management in an Agile Scrum "
Los 8 equipos construyeron el mismo sistema con el mismo product backlog y trabajando con el mismo propietario de producto: un programa de gestión de agendas.
Siete equipos trabajaron con Scrum, admitiendo al propietario de producto realizar cambios en el backlog de requisitos durante la ejecución del proyecto.
Un equipo se empleó como referencia para contrastar los datos, de forma que usó un ciclo de desarrollo iterativo (4 iteraciones en lugar de los 4 sprints) pero sin modificar los requisitos, para analizar las diferencias de eficiencia y calidad.
Las métricas empleadas en el estudio han sido 29, agrupadas en 4 categorías: Esfuerzo del equipo, Funcionalidad producida, Impacto de los cambios de requisitos y calidad entregada.
(El grupo I trabajaba con Scrum y el II no)
El estudio concluye que los grupos trabajando con Scrum permitiendo cambios en el backlog entregaron más calidad, más funcionalidades e invirtieron menos horas que los que trabajaron con iteraciones sin permitir cambios.
Comentarios