¿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 razones principales por las que se utiliza Agile es porque los clientes a menudo cambian los requisitos.

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

La razón por la que empleo 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 llevarí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: ¿Sería esto considerado como malo, codificación de vaqueros, antipatrón, etc.? ¿Debemos emplear cascada y planear todo lo 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. Supongamos que los clientes nos indicaron un problema muy concreto, nos dan una lista de deseos con detalles muy razonables y nos dejan solos (es decir, los clientes tienen sus propias cosas productivas que hacer, no los molesten más. Termine cuando tenga un prototipo mínimo de trabajo). ¿Sería incorrecto utilizar Agile en este escenario?

    
pregunta InformedA 16.07.2014 - 08:27

4 respuestas

16
  

Se consideraría esto como incorrecto, codificación de vaquero, antipatrón.

Respuesta corta: no. Hacer "ágil" correctamente no significa "no planear", significa no analizar demasiado las cosas.

  

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

Esa es una declaración que simplifica demasiado. "Requisitos cambiantes" también trata sobre cómo cambia el entendimiento del equipo de los requisitos. Y se trata de cómo cambian las prioridades del cliente sobre el requisito cuando él realmente ve algunas versiones del software.

De hecho, "ágil" funciona en mi MEJOR exactamente en la situación que describe : el cliente tiene un buen conocimiento de sus requisitos generales, puede escribir un plan general a partir de él, llenar su backlog con muchas "historias de usuario", y ya tienen suficiente información para elegir la arquitectura de sistema correcta. 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 va en la dirección correcta. También le proporcionará comentarios tempranos sobre el esfuerzo real y los costos (que es algo que aún puede fallar en un enfoque de cascada, incluso si conoce cada uno de los requisitos en detalle).

    
respondido por el Doc Brown 16.07.2014 - 08:50
6

El uso ágil en esta situación sigue siendo una muy buena idea. Agile tiene muchos beneficios, solo uno de los cuales es la retroalimentación regular del cliente y la capacidad de responder a los requisitos cambiantes que menciona.

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

A) Le demuestra al cliente que en realidad está casi allí a través de la demostración ("Todas estas historias están listas, podemos hacer las últimas si así lo desea") y un poco más de tiempo obtendrá exactamente lo que quieren.

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

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

    
respondido por el SpoonerNZ 16.07.2014 - 14:02
3

Agile es ideal si necesita un bucle 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 otra parte, Agile puede funcionar igual de bien si los requisitos son completamente estables y el cliente espera solo una entrega única, pero es posible que deba adaptarse un poco a la cantidad de participación que el cliente espera. tener durante el proyecto. Esto significa que el rol de Propietario del producto debe se debe completar desde su propia organización y esa persona debe tener el mandato suficiente del cliente para tomar decisiones.

    
respondido por el Bart van Ingen Schenau 16.07.2014 - 08:48
0

Siempre puede dividir el lanzamiento grande en lanzamientos más pequeños (sprints) y pedir 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 tus errores lo antes posible, en lugar de mostrarle una mierda al final e intentar corregirlo cuando ni siquiera sabes por dónde empezar.

    
respondido por el Silviu Burcea 16.07.2014 - 08:53

Lea otras preguntas en las etiquetas