¿Es incorrecto usar Agile cuando los requisitos de los clientes no cambian en absoluto?

12

Recientemente he visto muchas publicaciones que dicen que una de las principales razones por las que se usa Agile es porque los clientes a menudo cambian los requisitos.

Sin embargo, digamos que los clientes no cambian los requisitos con frecuencia . De hecho, los clientes tienen requisitos firmes, aunque pueden ser un poco vagos (pero nada irrazonablemente vagos), pero uso Agile de todos modos.

La razón por la que uso Agile es porque el software es lo suficientemente complejo como para que haya detalles, problemas que no reconocería hasta que realmente los enfrentara. Podría hacer un enfoque de planificación pesada a gran escala como una cascada, pero luego tomaría unos meses finalizar todo el diseño de alto nivel y las firmas de codificación de bajo nivel. Sin embargo, hay un diseño arquitectónico fijo muy específico para el sistema.

Mi pregunta es: ¿se consideraría esto malo, codificación de vaquero, antipatrón, etc.? ¿Debemos emplear la cascada y planificar tanto como sea posible con gran detalle antes de comenzar a codificar cuando los requisitos son estables en lugar de esta mentalidad de 'hagámoslo' en Agile?

EDITAR: El punto principal aquí es que: NO PODEMOS culpar a los clientes por los requisitos cambiantes. Suponga que los clientes nos señalaron un problema muy concreto, denos una lista de deseos con detalles muy razonables y déjenos solos (es decir, los clientes tienen sus propias cosas productivas que hacer, no los molesten más. Solo demuéstrales cerca del termina cuando tienes un prototipo de trabajo mínimo). ¿Sería un error usar Agile en este escenario?

agile development-process InformadoA
fuente
2
@randomA: en realidad, en mi humilde opinión, nunca debe probar la cascada pura solo si desea crear un producto que funcione y que necesite más de una semana de esfuerzo.
Doc Brown
10
Por favor, dame a tus clientes
razethestray
77
Daré 2 veces más por sus clientes que @razethestray
Euphoric
2
Si su cliente no quiere "molestarse a diario", aprenda a comunicarse de manera efectiva con él. Por ejemplo, en lugar de hacer suposiciones (probablemente erróneas) sobre puntos poco claros, recopile preguntas en una lista y envíe a su cliente la lista a intervalos regulares. Aún mejor: organizar una reunión para discutir los puntos. Si los requisitos son tan claros que la lista permanece vacía: no hay reunión (pero supongo que no). Si comienza a implementar suposiciones incorrectas en su software, tendrá mucho más esfuerzo para cambiar eso más adelante.
Doc Brown
3
@randomA: puede mantener a su cliente contento por un tiempo al no preguntar nada, y luego, cuando entregue la última cosa, hágalo muy infeliz, ya que resulta que perdió tanto los requisitos que puede tirar su programa y comenzar desde el principio (que el cliente no estará dispuesto a pagar). O lo hace un poco infeliz por algún tiempo pidiéndole lo suficiente para crear el programa correcto, pero muy feliz al final cuando el programa realmente hará lo que quiere y obtiene lo que ha pagado. Elige tu elección.
Doc Brown

Respuestas:

16

¿Se consideraría esto como malo, codificación de vaquero, antipatrón?

Respuesta corta: no. Hacer "ágilmente" correctamente no significa "no planificar", significa no analizar demasiado las cosas.

Una de las principales razones por las que se usa Agile es porque los clientes a menudo cambian los requisitos.

Esa es una declaración demasiado simplificadora. "Cambiar los requisitos" también se trata de cómo cambia la comprensión del equipo de los requisitos. Y se trata de cómo cambian las prioridades del cliente sobre el requisito cuando realmente ve algunas versiones del software.

De hecho, "ágil" funciona en mi humilde opinión exactamente en la situación que usted describe : el cliente tiene un buen conocimiento de sus requisitos generales, puede escribir un plan general a partir de él, llenar su cartera de pedidos con muchas "historias de usuarios", y ya tiene suficiente información para elegir la arquitectura correcta del sistema. Las breves iteraciones de una estrategia de desarrollo ágil ayudarán a hacer que los "requisitos vagos" sean más precisos, con muchos comentarios si todavía está yendo en la dirección correcta. También le dará una respuesta temprana sobre el esfuerzo real y los costos (que es algo que aún puede fallar en un enfoque en cascada, incluso si conoce cada detalle en detalle).

Doc Brown
fuente
3
Hacer "cascada" correctamente no significa "planear todo", significa no subanalizar las cosas.
Giorgio
1
@Giorgio: hacer "cascada" correctamente significa no aplicarlo cuando los requisitos son "un poco vagos" y "el software es lo suficientemente complejo como para que haya detalles, problemas que no reconocería hasta que realmente los enfrente" (cita del pregunta original).
Doc Brown
6

Usar ágil en esta situación sigue siendo una muy buena idea. Agile tiene muchos beneficios, uno de los cuales es la retroalimentación periódica del cliente y la capacidad de responder a los requisitos cambiantes como usted menciona.

Una de las principales razones por las que los proyectos en cascada son notorios por el fracaso es el problema 'casi terminado': las pruebas produjeron montones de errores al final, dejando un producto indescifrable y sin idea de si necesita otros dos días o dos años para solucionar los errores pendientes. Ágil elimina este riesgo por completo. Si un proyecto ágil se está ejecutando en exceso, aún puede entregar una versión funcional que:

A) Demuestra al cliente que realmente está allí a través de las demostraciones ("Todas estas historias están hechas, podemos hacer las últimas si lo desea") y un poco más de tiempo obtendrá exactamente lo que quiere.

B) Potencialmente es lo suficientemente bueno para que sean felices de todos modos y se liberen.

Para mí, eliminar este riesgo de fracaso total es una razón suficiente para que una empresa se mueva a un proceso de desarrollo ágil, la capacidad de construir un mejor software de lo planeado inicialmente es la guinda del pastel. Como se menciona en otras respuestas, esos requisitos "concretos" a menudo siguen siendo sorprendentemente maleables.

SpoonerNZ
fuente
No entiendo de qué manera A) resuelve el problema que mencionó al comienzo de su respuesta: ¿cómo sabe si las últimas historias tomarán unos días o dos años? Solo sabes realmente cuándo las haces, ¿no?
Giorgio
1
Tiene razón, pero la diferencia es que tiene un producto liberable en su estado actual, en lugar de una pieza de software defectuosa hecha al 90% que no se puede lanzar. También tiene evidencia empírica de cuánto tiempo le llevó entregar las funciones que son liberables, y sus estimaciones del trabajo restante que probablemente brinden más confianza que ninguna prueba de que algo que haya hecho realmente funcione.
SpoonerNZ
Depende: si todas las funciones planificadas son esenciales, entonces un producto con 90% de funciones no se puede usar / no se puede volver a liberar: solo se puede usar para dar una demostración de lo que ya está allí. En mi experiencia, agile no es preferible en todas las situaciones: hay proyectos para los que es más adecuado (requisitos cambiantes, características pequeñas, independientes e independientes) y proyectos para los que no lo es (requisitos estables, complejos y / o críticos para la misión) caracteristicas).
Giorgio
Estoy de acuerdo: la entrega insuficiente no es buena en ninguno de los casos, pero como parte interesada confiaría en el equipo que produce una versión completamente funcional de su software para jugar donde todo funciona pero faltan algunas características, o el equipo que le brinda un ¿Un montón de código fuente plagado de errores que teóricamente tiene todas sus características pero se bloquea y tiene un comportamiento inesperado? Sé en qué confiaría más.
SpoonerNZ
Por supuesto que confiaría en el primer equipo, pero no estoy de acuerdo en que al usar un método no ágil siempre terminas con "un montón de código fuente plagado de errores que teóricamente tiene todas tus características pero se bloquea y tiene un comportamiento inesperado" . Al menos, esta no ha sido mi experiencia hasta ahora.
Giorgio
3

Agile es ideal si necesita un ciclo de retroalimentación frecuente con el cliente. Esto puede deberse a que los requisitos cambian con frecuencia, pero también podría ser por otros motivos.

Por otro lado, Agile puede funcionar igualmente bien si los requisitos son completamente estables y el cliente espera solo una entrega de big bang, pero es posible que deba adaptar un poco las cosas para la cantidad de participación que el cliente espera tener durante el proyecto. Esto significa que el rol de Propietario del producto debe desempeñarse desde su propia organización y esa persona debe tener suficiente mandato del cliente para tomar decisiones.

Bart van Ingen Schenau
fuente
1
A menudo me pregunto si los clientes que no quieren involucrarse demasiado tienen una necesidad comercial real. A menudo he visto que esto sucede en proyectos donde una aplicación existente se 'traduce' a una nueva tecnología. Puede verificar el código si tiene preguntas, es lo que le están diciendo. Nadie está esperando la nueva versión.
user99561
@ user99561: tiene razón, pero en tales situaciones los requisitos en su mayoría no son vagos, son muy claros, siempre y cuando el nuevo programa se comporte exactamente como el anterior. En tal situación, no es necesario un enfoque "ágil". Un enfoque iterativo basado en la piedra angular (sin mucha interacción con el cliente) será suficiente.
Doc Brown
¿Claro como el cristal? Buena suerte para averiguar cuál es el comportamiento exacto y cuáles son las excepciones. La mayoría de las veces, incluso los empresarios no entienden lo que sucede en la aplicación. Mi consejo: huye tan rápido como puedas de estos proyectos. Porque sabe cuándo comienza el proyecto, pero no sabe cuándo se publicó el último error porque las aplicaciones se comportan de manera diferente.
user99561
0

Siempre puede dividir la versión grande en versiones más pequeñas (sprints) y pedirle comentarios a su cliente. De esta manera, está seguro de que está haciendo lo correcto y el cliente puede realizar un seguimiento de su progreso.

Si hay algo mal, puede ofrecer a su cliente la oportunidad de corregirlo antes, lo cual es muy bueno. Es mejor corregir sus errores lo antes posible, en lugar de mostrarle una mierda al final e intentar arreglarlo cuando ni siquiera sabe por dónde empezar.

Silviu Burcea
fuente
Acabo de agregar una edición para aclarar. Los clientes mostraron un problema con suficientes detalles y una clara lista de deseos y no quieren ser molestados aún más. Por lo tanto, suponga que no hay comentarios de los clientes hasta cerca del final, cuando puede hacer una demostración de un prototipo en funcionamiento.
InformadoA