Inicio arrow Blog arrow Ágiles arrow Los cambios de requisitos son bienvenidos con Scrum, pero ¿a qué precio? Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Los cambios de requisitos son bienvenidos con Scrum, pero ¿a qué precio?
16.02.2011

comparandoLa 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.

requisitos: secuencial vs ágil
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.


resultados esfuerzo
(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)
Comentarios (7)Add Comment
...
escrito por Joserra, February 16, 2011
Pero esa ya lo sabíamos, no? smilies/tongue.gif

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.
...
escrito por Juan, February 16, 2011
Nosotros sí que lo sabíamos ;-)
Pero en muchos textos de Ingeniería del Software se daba por supuesto que la agilidad no es una forma eficiente de trabajar y de dudosa calidad. La frase de "La forma más eficiente de hacer un trabajo es hacerlo bien a la primera" es uno de los "axiomas" de Watts Humprey en un libro sobre PSP y CMMI.
Por eso está bien que haya algún estudio para comprobar con criterios más objetivos.

Estoy contigo. no hubiera comparado las métricas de 7 equipos con uno solo de control. Parece más lógico que hubieran contrastado 4 equipos con otros 4.

Un saludo.
No entiendo el resultado
escrito por Luis, February 17, 2011
La verdad es que este resultado me sorprende y me pone en guardia sobre la metodología. Además de sólo poner un equipo de control que ya habéis comentado, no me cuadra que "todos" los demás hayan sido mejores.

Al fin y al cabo, del "universo" de todos los posibles requisitos, el conjunto de los que permanecieron sin modificar son un caso particular.
Me explico con un ejemplo:

Todos los equipos parten con A, B y C como requisitos.

El equipo de control acaba entregando ABC y el resto (por ejemplo) AXZY, ABCDE, QWERTY y el cuarto XYZ.

Si todos hubieran partido de XYZ ¿Qué hubiera pasado? - ¿El cuarto hubiera sido el peor?


Lo único que se me ocurre que pudiera justificar racionalmente el resultado del experimento es que un equipo sometido a cambios trabaja más motivado. Lo que es interesante de por sí
El punto medio
escrito por Santi, February 17, 2011
¿y si se desarrolla con el framework Scrum y con buena ingeniería de requisitos?
¿por qué una cosa quita la otra?
¿por qué no aprovechar los beneficios de cada modelo?
¿por qué no elegir una metodología según lo que se quiera abordar?
¿por qué hay que ser Scrum, o Waterfall, o Xtremme Programming, ......?

Sobre resultado y punto medio.
escrito por Juan, February 17, 2011
Comparto tus dudas, Luis; y me encanta el planteamiento de Santi: pura "síntesis" :-)

El que lo haya hecho una universidad y no una consultora que comercializa herramientas o servicios para Scrum es un punto a favor para presuponer rigor y objetividad, pero como suele pasar, al ir a "tapar" una duda, se abren otras.

Lo bueno de un estudio "científico" es que los resultados debe ser repetibles. Ojalá se repliquen pruebas e informes similares, cambiando el nº de equipos de control, etc. para contrastar y despejar dudas, en especial (por lo menos para mi) sobre la imparcialidad y objetividad.
Pero a falta de más datos, mejos sospechar para bien que para mal. ;-)

Un saludo.
Qué pasa cuando tenemos usuarios "cambiantes"
escrito por Liliana, February 17, 2011
Estoy totalmente de acuerdo con el hecho de que realizar los ajustes durante el desarrollo, es menos costoso que realizarlo después. No obstante, cuando se lidera equipos de trabajo, se debe lidiar con usuarios que muchas veces:
- cambian los requerimientos a cada rato
- o que cada vez que ven la aplicación se les ocurre algo nuevo

En resumen, que no permiten cerrar nada!

El cambio es bueno, pero siempre que aporte valor real al producto que estamos generando. Siempre debemos validar lo que se está solicitando, mostrar los pro y contra que implica, para luego decidir, canjear/ negociar aplicando criterio.

Finalmente, estoy totalmente de acuerdo con Santi, quien escribió acerca del punto medio. A mi parecer, nada debe ser rígido, debemos aplicar lo que realmente aplique en cada caso. Todos los proyectos son diferentes y no necesariamente lo que aplica a uno, resolverá mágicamente las necesidades de otro.

Salu2!
...
escrito por Joserra, February 18, 2011
Liliana, precisamente por lo que comentas es por lo que las ágiles se adaptan mejor! Cada iteración se busca cómo proporcionar el valor máximo al cliente, las funcionalidaddes/historias que más valor aportan. Si introduce mucho ruido, no importa, por que si la priorización es buena por aporte de valor, el ruido no se llega a implementar nunca smilies/smiley.gif
Y nada de canjear o negociar... la palabra clave es COLABORACION smilies/wink.gif

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative