È sbagliato usare Agile quando i requisiti dei client non cambiano affatto?

Would this be considered as bad, cowboy coding, anti-pattern.

Risposta breve: no. Fare "agile" correttamente non significa "non pianificare", vuol dire non analizzare troppo le cose.

one of the major reasons why Agile is used is because clients often change the requirements.

Questa è una dichiarazione semplicissima. "I mutevoli requisiti" riguardano anche il modo in cui la comprensione del team dei requisiti cambia. E si tratta di come cambiano le priorità del cliente in merito al requisito quando vede effettivamente alcune versioni del software.

Infatti, "agile" funziona IMHO meglio esattamente nella situazione che descrivi - il cliente ha una buona conoscenza dei suoi requisiti generali, puoi scrivere un piano generale da esso, riempire il tuo arretrato con molte "user story" e hanno già abbastanza informazioni per scegliere l'architettura di sistema giusta. Le brevi iterazioni di una strategia di sviluppo agile aiuteranno quindi a rendere i "requisiti vaghi" più precisi, con un sacco di feedback se si sta andando nella giusta direzione. Vi fornirà anche un feedback tempestivo sullo sforzo reale e sui costi (che è qualcosa che potete ancora fallire in un approccio a cascata, anche se conoscete ogni singolo bit del fabbisogno in dettaglio).

L'utilizzo agile in questa situazione è ancora un'ottima idea. Ci sono molti vantaggi nell'agile, solo uno dei quali è il feedback regolare da parte del cliente e la capacità di rispondere ai mutevoli requisiti.

Uno dei motivi principali per cui i progetti a cascata sono noti per il fallimento è il problema "quasi fatto": testare i mucchietti di bug alla fine, lasciando un prodotto irrilevante e non sapere se sono necessari altri due o due anni per risolvere il problema bug in sospeso. Agile rimuove completamente questo rischio. Se un progetto agile è in esecuzione, è ancora possibile fornire una versione funzionante che:

A) Dimostra al cliente che sei quasi lì attraverso la demo ("Tutte queste storie sono fatte, possiamo fare gli ultimi se vuoi") e un po 'più di tempo otterrà esattamente quello che vogliono.

B) Potenzialmente è abbastanza buono per essere felici comunque e rilasciare.

Per me, rimuovere questo rischio di fallimento completo è una motivazione sufficiente per consentire a un'azienda di passare a un processo di sviluppo agile, la possibilità di creare software migliore di quanto inizialmente previsto è la ciliegina sulla torta. Come accennato in altre risposte, tali requisiti "concreti" sono spesso ancora sorprendentemente malleabili.

Agile è l'ideale se hai bisogno di un ciclo di feedback frequente con il cliente. Questo può essere dovuto al fatto che i requisiti cambiano frequentemente, ma potrebbe anche essere per altri motivi.

D'altra parte, Agile può funzionare egualmente bene se i requisiti sono completamente stabili e il cliente si aspetta solo una singola consegna big-bang, ma potrebbe essere necessario adattare un po 'le cose per la quantità di coinvolgimento che il cliente si aspetta di avere durante il progetto. Ciò significa che il ruolo del proprietario del prodotto deve essere compilato all'interno della propria organizzazione e che tale persona deve disporre di un mandato sufficiente da parte del cliente per prendere decisioni.

Puoi sempre dividere il grande rilascio in versioni più piccole (sprint) e chiedere al tuo cliente un feedback. In questo modo sei sicuro di fare la cosa giusta e il cliente può tenere traccia dei tuoi progressi.

Se c'è qualcosa che non va, puoi offrire al tuo cliente la possibilità di correggerti prima, il che è molto buono. È meglio correggere i propri errori il prima possibile, piuttosto che mostrargli una cazzata alla fine e provare a risolverli quando non sai nemmeno da dove cominciare.