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

12

Recentemente ho visto molti post che affermano che uno dei motivi principali per cui viene utilizzato Agile è perché i clienti cambiano spesso i requisiti.

Tuttavia, supponiamo che i client non cambino spesso i requisiti . In effetti, i clienti hanno requisiti fissi anche se potrebbero essere un po 'vaghi (ma nulla di irragionevolmente vago), ma utilizzo comunque Agile.

Il motivo per cui utilizzo Agile è perché il software è abbastanza complesso da contenere dettagli, problemi che non riconoscerei fino a quando non li avrò effettivamente affrontati. Potrei adottare un approccio di pianificazione pesante su larga scala come la cascata, ma poi ci vorrebbero alcuni mesi per finalizzare tutto il design di alto livello e le firme di codifica di basso livello. Tuttavia, esiste un progetto architettonico molto specifico e fisso per il sistema.

La mia domanda è: sarebbe considerato cattivo, codifica da cowboy, anti-pattern, ecc.? Dobbiamo utilizzare la cascata e pianificare il più possibile nei minimi dettagli prima di iniziare a programmare quando i requisiti sono stabili invece di questa mentalità "facciamolo" in Agile?

EDIT: Il punto principale qui è che: NON POSSIAMO dare la colpa ai clienti per i requisiti mutevoli. Supponiamo che i clienti ci abbiano segnalato un problema molto concreto, forniscici una lista dei desideri con dettagli molto ragionevoli e lasciaci in pace (cioè i clienti hanno le loro cose produttive da fare, non correggerli più. Dimostrali solo vicino al termina quando hai un prototipo funzionante minimo). Sarebbe sbagliato usare Agile in questo scenario?

agile development-process

— InformedA
fonte

2

@randomA: in realtà, IMHO non dovresti mai provare la cascata pura solo se vuoi creare un prodotto funzionante che richiede più di una settimana di sforzo.

— Doc Brown,

10

Per favore, dammi i tuoi clienti

— razethestray,

7

Darò 2 volte di più per i tuoi clienti rispetto a @razethestray

— Euforico

2

Se il tuo cliente non vuole "essere disturbato quotidianamente", impara a comunicare efficacemente con lui. Ad esempio, anziché fare ipotesi (probabilmente errate) su punti poco chiari, raccogliere le domande in un elenco e inviare l'elenco dei client a intervalli regolari. Ancora meglio: organizzare un incontro per discutere i punti. Se i requisiti sono così chiari che l'elenco rimane vuoto: nessuna riunione (ma suppongo che non lo farà). Se inizi a implementare ipotesi errate nel tuo software, avrai un enorme sforzo in più per cambiarlo in seguito.

— Doc Brown,

3

@randomA: puoi mantenere il tuo cliente felice per un po 'di tempo non chiedendo nulla, e poi, quando consegni l'ultima cosa, lo rendi molto infelice poiché si scopre che hai perso i requisiti così tanto che puoi buttare via il tuo programma e iniziare dall'inizio (che il cliente non sarà disposto a pagare). Oppure lo rendi un po 'infelice per un po' di tempo chiedendogli abbastanza nel mezzo per costruire il programma giusto, ma alla fine molto felice quando il programma farà effettivamente quello che vuole e ottiene quello per cui ha pagato. Scegli la tua scelta

— Doc Brown,

16

Questo sarebbe considerato cattivo, codifica da cowboy, anti-schema.

Risposta breve: no. Fare "agile" correttamente non significa "nessuna pianificazione", non significa sovraanalizzare le cose.

uno dei motivi principali per cui viene utilizzato Agile è perché i clienti cambiano spesso i requisiti.

Questa è un'affermazione semplicistica. "Modifica dei requisiti" riguarda anche il modo in cui la comprensione del team da parte dei requisiti cambia. Ed è su come cambiano le priorità del cliente in merito al requisito quando vede effettivamente alcune versioni del software.

In effetti, "agile" funziona meglio di IMHO 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 backlog con molte "storie utente" e hai già abbastanza informazioni per scegliere la giusta architettura di sistema. Le brevi iterazioni di una strategia di sviluppo agile aiuteranno quindi a rendere più precisi i "requisiti vaghi", con molti feedback se stai ancora andando nella giusta direzione. Ti darà anche un feedback tempestivo sullo sforzo reale e sui costi (che è qualcosa che puoi ancora fallire in un approccio a cascata, anche se conosci ogni singolo bit di dettaglio in dettaglio).

— Doc Brown
fonte

3

Fare correttamente "cascata" non significa "pianificare tutto", ma non sottoanalizzare le cose.

— Giorgio,

1

@Giorgio: fare correttamente "a cascata" significa non applicarlo quando i requisiti sono "un po 'vaghi" e "il software è abbastanza complesso che ci sono dettagli, problemi che non riconoscerei fino a quando non li affronterò" (cita dal domanda originale).

— Doc Brown,

6

Usare l'agile in questa situazione è ancora un'ottima idea. Ci sono molti vantaggi per l'agile, solo uno dei quali è il feedback regolare da parte del cliente e la capacità di rispondere alle mutevoli esigenze come menzionato.

Uno dei motivi principali per cui i progetti a cascata sono noti per il fallimento è il problema "quasi compiuto": testare pile di bug prodotte alla fine, lasciando un prodotto inattaccabile e senza idea se occorrono altri due giorni o due anni per correggere i bug in sospeso. Agile rimuove completamente questo rischio. Se un progetto agile funziona in modo eccessivo, è comunque possibile fornire una versione funzionante che:

A) Dimostra al cliente che in realtà ci sei quasi tramite le demo ("Tutte queste storie sono fatte, possiamo fare le ultime se vuoi") e ancora un po 'di tempo otterrà esattamente quello che vogliono.

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

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

— SpoonerNZ
fonte

Non capisco in che modo A) risolva il problema che hai citato all'inizio della tua risposta: come fai a sapere se le ultime storie impiegheranno qualche giorno o due anni? Sai davvero solo quando li fai davvero, vero?

— Giorgio,

1

Hai ragione, ma la differenza è che hai un prodotto rilasciabile nel suo stato attuale, piuttosto che un software difettoso fatto al 90% che non può essere rilasciato. Hai anche prove empiriche di quanto tempo hai impiegato per fornire le funzionalità che sono rilasciabili e delle tue stime del lavoro rimanente che probabilmente forniranno maggiore sicurezza che nessuna prova del fatto che qualcosa che hai fatto effettivamente funziona.

— SpoonerNZ

Dipende: se tutte le funzionalità pianificate sono essenziali, un prodotto con funzionalità al 90% è inutilizzabile / non rilasciabile: può essere utilizzato solo per fornire una demo di ciò che è già lì. Nella mia esperienza, l'agile non è preferibile in tutte le situazioni: ci sono progetti per i quali l'agile è più adatto (requisiti che cambiano, caratteristiche piccole, indipendenti e indipendenti) e progetti per i quali non lo è (requisiti stabili, complessi e / o mission-critical Caratteristiche).

— Giorgio,

Sono d'accordo - la sotto-consegna non è buona in entrambi i casi, ma come stakeholder ti fideresti del team che produce una versione completamente funzionante del tuo software per giocare dove tutto funziona ma mancano alcune funzionalità, o il team che ti dà un bug crivellato pila di codice sorgente che teoricamente ha tutte le tue funzionalità ma si blocca un sacco e ha un sacco di comportamenti inaspettati? So di cosa mi fiderei di più.

— SpoonerNZ,

Ovviamente mi fiderei del primo team, ma non sono d'accordo sul fatto che usando un metodo non agile si finisce sempre con "un mucchio di codici sorgente crivellato di bug che teoricamente ha tutte le tue caratteristiche ma si arresta in modo anomalo e ha un comportamento inaspettato" . Almeno, questa non è stata la mia esperienza fino ad ora.

— Giorgio,

3

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

D'altra parte, Agile può funzionare altrettanto bene se i requisiti sono completamente stabili e il cliente si aspetta una sola consegna big bang, ma potresti dover adattare un po 'le cose alla quantità di coinvolgimento che il cliente si aspetta di avere durante progetto. Ciò significa che il ruolo di Product Owner deve essere ricoperto all'interno della propria organizzazione e che tale persona deve avere un mandato sufficiente da parte del cliente per prendere decisioni.

— Bart van Ingen Schenau
fonte

1

Mi chiedo spesso se i clienti che non vogliono essere troppo coinvolti abbiano un reale bisogno commerciale. Ho visto spesso ciò accadere in progetti in cui un'applicazione esistente viene "tradotta" in una nuova tecnologia. Puoi controllare il codice se hai domande su cosa ti stanno dicendo. Nessuno sta aspettando il remake.

— user99561,

@ user99561: hai ragione, ma in tali situazioni i requisiti non sono per lo più vaghi, sono cristallini - purché il nuovo programma si comporti esattamente come quello precedente. In una situazione del genere un approccio "agile" non è effettivamente necessario. Sarà infatti sufficiente un approccio iterativo basato su pietre miliari (senza molta interazione con il cliente).

— Doc Brown,

Cristallino? Buona fortuna a capire qual è il comportamento esatto e quali sono le eccezioni. Il più delle volte anche gli uomini d'affari non capiscono cosa succede nell'applicazione. Il mio consiglio: scappare il più velocemente possibile da questi progetti. Perché sai quando inizia il progetto, ma non sai quando l'ultimo bug pubblicato perché le applicazioni si comportano in modo diverso verranno risolti.

— user99561,

0

Puoi sempre dividere la versione più grande in versioni più piccole (sprint) e chiedere feedback al tuo cliente. 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 tuoi errori il prima possibile, piuttosto che mostrargli una cazzata alla fine e provare a risolverlo quando non sai nemmeno da dove cominciare.

— Silviu Burcea
fonte

Ho appena aggiunto una modifica per chiarire. I clienti hanno mostrato un problema con dettagli sufficienti e una chiara lista dei desideri e non vogliono essere ulteriormente turbati. Quindi supponi, nessun feedback del cliente fino alla fine quando puoi provare un prototipo funzionante.

— Informato il