|
 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.
Trackback(0)
 |
TrackBack URI para esta entrada
RSS Comentarios
En serio, el grupo de muestra me parece un poco pequeño, pero es genial que se busquen con evidencias lo que puede funcionar y lo que no en el desarrollo de software.