Ágil, cascada y cambios de requisitos

10

¿Alguien ha tenido este problema de un proyecto definido como 'Ágil' siendo invadido por cambios de requisitos? Trabajo en un proyecto de desarrollo que se ejecuta en Sprint durante 4 semanas, pero siempre hay cambios entre estos Sprints. ¿Todavía se define como Ágil entonces? Siento que es una especie de proceso sub Ágil: los requisitos de un proceso Ágil deben definirse al comienzo de un sprint y revisarse hacia su final. ¿Estoy en lo cierto en esto? Por favor, hágame saber sus experiencias en esto.

agile requirements

— Aravind A
fuente

"Cambio de requisitos" es un término suelto. ¿Es el cambio porque el cliente realmente cambió de opinión sobre un requisito aprobado? ¿Qué desencadenó ese cambio? Si esto sigue sucediendo, debe volver a examinar cómo recopila los requisitos. Ninguna metodología SE podría satisfacer la falta de recolección de requisitos adecuada.

— NoChance

@Emmad Los cambios de requisitos se producen durante UAT cuando los usuarios sienten que la usabilidad podría mejorarse por ciertos medios. Esto provoca una acumulación de problemas antes de la producción. Esto ciertamente no es ágil.

— Aravind A

@Aravind A: UAT ocurre al final del sprint, ¿no? Entonces, cualquier nueva idea / cambio que surja durante UAT normalmente debería convertirse en una historia para el próximo sprint (si usa sprints).

— sleske

Tal vez lo que sugiere @sleske funcione para usted, pero también, la facilidad de uso se puede crear de antemano si el usuario tiene requisitos excepcionales. A veces, en proyectos vinculados por recursos, debe controlar sus ambiciones de usuario.

— NoChance

9

Los requisitos de un proceso ágil deben definirse al comienzo de un sprint y revisarse para cumplirlo. ¿Estoy en lo cierto en esto?

No, esto depende de la naturaleza del proyecto (y el proceso).

Hay algunos modelos de desarrollo ágiles en los que los requisitos deben fijarse durante un sprint, y solo deberían cambiar para el próximo sprint (un ejemplo destacado es Scrum).

Sin embargo, también hay procesos en los que los cambios pueden ocurrir casi en cualquier momento (siempre que el cliente acepte los retrasos y el trabajo adicional que causa el cambio). Kanban a menudo se usa para administrar estos flujos de trabajo (aunque Kanban también se puede combinar con Scrum).

El modelo que sigas depende de los detalles de cada proyecto.

Entonces sí, si el cliente siente que necesita la posibilidad de cambiar constantemente los requisitos, entonces un proceso ágil puede adaptarse a esto. Sin embargo, el cliente debe ser consciente de las consecuencias de los cambios constantes y debe comprender que ralentizará el proyecto.

Esto se reduce a los principios del manifiesto ágil : "Individuos e interacciones sobre procesos y herramientas", y "Responder al cambio sobre seguir un plan".

— sleske
fuente

¿No hace que el proceso sea abiertamente ágil? Quiero decir, ¿hasta dónde puede llegar la agilidad? Si un desarrollador cumple un requisito por primera vez, seguramente habrá una demanda la próxima vez. Siento que este es uno de los muchos problemas que hace que se pierda la calidad del código.

— Aravind A

@AravindA La calidad del código debe ser una preocupación separada e independientemente de cuántas veces cambie el código, el equipo debe centrarse en los mismos estándares de calidad del código en todo momento. De hecho, la calidad del código es más importante porque los requisitos y el código cambian constantemente.

— maple_shaft

2

@maple_shaft es correcto: la calidad es (al menos en su mayoría) ortogonal al cambio de requisitos. Dame un requerimiento: empiezo a escribir un buen código. Si he terminado y obtengo una nueva solicitud, o estoy a medio hacer y obtengo un cambio, empiezo a (re) escribir un buen código. Después de haber resaltado el impacto en el cronograma / compromiso / etc actual.

— sdg

Los cambios en los requisitos que tienen una gran influencia en la arquitectura del sistema darán lugar a retrasos importantes o compromisos de calidad. Es por eso que debe hacer un buen análisis antiguo en cascada (también puede ser iterativo) donde intenta reducir el riesgo de su aparición "repentina".

— MaR

@sles Gracias por la explicación. Creo que lo entiendo ahora. Creo que tendré que conocer más a Agile.

— Aravind A

12

Creo que la pregunta que debes hacerte es: ¿por qué te invaden los cambios de requisitos? Las causas comunes incluyen:

Los desarrolladores no tienen (suficiente) contacto con los usuarios finales, por lo que no pueden entender las necesidades de los usuarios. En cambio, tratan los requisitos como un cubo abstracto de Rubik: siguen las letras de los requisitos sin siquiera tratar de comprender su espíritu.
Alguien (por ejemplo, de marketing) está agregando requisitos que no tienen ningún sentido para el usuario final (pero, por ejemplo, suenan bien en un folleto). Así que hay una batalla entre los requisitos "reales" y los "otros" requisitos que se libran a costa de los desarrolladores
El alcance del proyecto no está definido ("Bueno, si está implementando un procesador de texto de todos modos, ¿no podría simplemente agregar un pequeño módulo que hace nuestra contabilidad de nómina? Ah, y Bill del otro equipo de desarrollo preguntó qué tan difícil sería) ser para hacer que el procesador de textos compile también el código C ++? ")

Cualquiera que sea el problema raíz, debe solucionarlo. Ahogarlo bajo capas de "Agile" (o cualquier otra metodología) no funcionará.

— nikie
fuente

@Nike Gracias. Esto es justo lo que pensaba. Tu tercer punto encaja en mi escenario. Algunos clientes simplemente aprovechan el trabajo 'Ágil' pensando que es una bala de plata para hacer el trabajo más rápido.

— Aravind A

9

Al menos en Scrum, que parece ser el proceso ágil que es más popular entre los tipos de administración en estos días, el alcance de un Sprint es fijo. Si su Backlog de Sprint está cambiando durante el sprint, eso no es Scrum, es un caos. El Backlog de Sprint debe crearse al comienzo del sprint y permanecer fijo hasta el final del sprint (en ese momento, crea un nuevo Backlog de Sprint para el próximo sprint).

Si su cartera de productos está cambiando durante un sprint, no es gran cosa. Los cambios se convierten en un nuevo trabajo que se prioriza, estima y selecciona como cualquier otro requisito para el próximo sprint. Sin embargo, si los requisitos cambian tanto que el Propietario del producto tiene que cancelar el sprint regularmente, tiene problemas con una 'T' mayúscula.

¿Quizás necesitas sprints más cortos?

— Adam Jaskiewicz
fuente

+1 por necesitar sprints más cortos. Vuelva a escalar a 2 semanas y vea si ayuda.

— John

1

De hecho, 4 semanas suena bastante largo para un sprint, especialmente en un proyecto que sufre de inestabilidad de requisitos.

— Carson63000

7

Para la cordura de los programadores, es mejor si los requisitos no cambian durante una revisión / sprint.

En su situación, hay dos opciones obvias:

carreras cortas
hacer que el cliente acepte no alterar los requisitos durante una revisión / sprint a menos que se cancele y se vuelva a planificar toda la revisión / sprint

Recomiendo mucho ambos .

— Steven A. Lowe
fuente

3

El principal problema es que crees que estás usando Scrum pero no lo haces. Especialmente el dueño de su producto no lo sigue. En Scrum, un sprint es una zona segura y no se pueden realizar cambios en las historias de usuarios comprometidos a menos que se cancele el sprint actual. Es responsabilidad del maestro Scrum hacer cumplir esto. Si esto no funciona en su entorno, entonces es un problema de proceso = no está utilizando Scrum.

El cambio más simple que puede hacer (si desea seguir a Scrum) es acortar el sprint, por ejemplo, una semana. Los sprints de 4 semanas se consideraron como una opción en los primeros días de Scrum, pero hoy en día es de 1 a 2 semanas y 3 semanas se consideran como límite superior. 4 semanas es mucho tiempo en un entorno cambiante.

— Ladislav Mrnka
fuente