Requisitos descubiertos recientemente en Scrum

Si se descubre un requisito en medio de un proyecto o incluso más tarde, el costo de implementación de este requisito puede ser muy alto.

En esta declaración, está diciendo que el costo del cambio es alto (particularmente al final de un proyecto).

El enfoque ágil reconoce que el cambio sucede y, por lo tanto, se esfuerza por reducir el costo del cambio .

Esta es la diferencia fundamental entre el enfoque ágil y el desarrollo tradicional:

Desarrollo tradicional : seamos realmente buenos para predecir lo que sucederá (planificar bien)

Desarrollo ágil : seamos realmente buenos respondiendo al cambio (responder bien)

La priorización, la entrega continua y la revisión son la forma de controlar el riesgo de entrega para cualquier desarrollo de software, no solo cuando se usa Scrum. Sin embargo, no puedo estar de acuerdo con la primera oración de su pregunta. Si el trabajo se ordena sabiamente, el trabajo más importante y más riesgoso o costoso generalmente viene primero, por lo que el costo del trabajo inesperado debería tender a reducirse a medida que pasa el tiempo en lugar de aumentar. Un equipo experimentado también intentará identificar para un refinamiento temprano cualquier elemento que tenga un impacto arquitectónico amplio o que tenga muchas dependencias.

Ningún método proporciona una garantía contra imprevistos, pero la entrega continua ayuda a evitar sorpresas desagradables al probar el producto temprano y con frecuencia. Por lo general, ese es un método mucho más confiable que confiar solo en el análisis inicial para identificar problemas.

Tu dices:

Si se descubre un requisito en medio de un proyecto o incluso más tarde, el costo de implementación de este requisito puede ser muy alto.

Esto puede ser cierto o puede ser falso. Depende del tipo de cambio al que te refieras . Estoy asumiendo un gran cambio, o algo que falta de manera importante, o algo que se desvía de alguna manera de lo que has construido hasta ese momento. Si este es el caso, entonces sí, el cambio puede ser costoso. Si es solo un requisito como otros similares, entonces la implementación probablemente no sea tan alta.

La forma en que expresó esa primera oración y el resto de la pregunta implica que está utilizando un enfoque predictivo, o un enfoque tradicional en el que reúne los requisitos al principio y luego crea un plan para luego implementarlo. Solo así se puede hablar de "la mitad del proyecto".

Si está creando el producto de una manera ágil, por ejemplo, no sabrá que está en medio del proyecto porque se está enfocando en entregar valor, no en los plazos que le indican dónde se encuentra en el proyecto. Sin embargo, esto no significa que el uso de Agile o Scrum garantizará que un requisito que se encuentre en una etapa avanzada del desarrollo sea económico de implementar. Si está construyendo un avión blanco y en algún momento descubre que necesita un submarino, no puede simplemente cortarle las alas, pintarlo de negro y llamarlo listo. Este tipo de cambio estropeará su implementación sin importar si está utilizando un enfoque tradicional o Agile.

Sin embargo, lo que hace Agile es que le permite darse cuenta antes de que necesita un submarino en lugar de un avión , porque está construyendo cosas de manera incremental e iterativa sobre las que puede recopilar comentarios y aprender lo que se necesita, en lugar de asumir que usted sepa todo desde el principio y puede especificarlo en requisitos que no cambiarán o no faltarán de alguna manera. Como ya se mencionó en las otras respuestas, el enfoque Agile es diferente y reduce las posibilidades de descubrir algo que realmente puede ser muy costoso de implementar en algún momento del camino.

Desde una perspectiva secuencial, la idea de que un requisito que se descubre más adelante en el proyecto probablemente sea más costoso de abordar. Del mismo modo, es probable que un defecto encontrado tarde después de la originación también sea más costoso. Esto se debe a la cantidad de trabajo que se realiza. Considere que en los esfuerzos que se ejecutan utilizando métodos secuenciales, intenta obtener todos los requisitos de manera temprana. Luego, crea una arquitectura y un diseño que aborda todos esos requisitos. Luego implementa el diseño seleccionado. Un cambio, especialmente un requisito nuevo o una modificación a un requisito existente, requiere analizar el conjunto completo de requisitos en busca de problemas y conflictos, luego analizar y actualizar la arquitectura y el diseño, luego actualizar la implementación y luego las pruebas. Los cambios se propagan a lo largo de cada fase del ciclo de vida y todos los artefactos asociados.

Scrum, y la mayoría de los otros métodos ágiles, adoptan un enfoque diferente. Hay suficiente arquitectura y diseño para soportar los requisitos conocidos. El sistema evoluciona con el tiempo para adaptarse a requisitos nuevos o modificados. Eso no significa que un requisito radicalmente diferente no cause una gran cantidad de reelaboración, pero el riesgo se reduce. Al construir gradualmente y obtener retroalimentación para construir lo que se percibe como lo más importante a continuación, se reducirán las posibilidades de algo que es muy importante pero también muy difícil de implementar. Cualquier reelaboración se limitará a las partes del sistema ya construidas, en lugar de pasar por muchas fases de desarrollo.

También agregaría que a medida que aumenta la complejidad, el costo de cambiar la funcionalidad del sistema se vuelve más costoso. Sin embargo, usar un diseño incremental, mantener el diseño simple (piense en principios como KISS y YAGNI ) y pagar la deuda técnica antes de tiempo puede hacer que los cambios futuros sean menos costosos. La complejidad que existe debería cambiar más hacia la complejidad esencial en oposición a la complejidad accidental.