In che modo Agile evita lo stallo del progetto quando è quasi completato (la sindrome del 90 percento)?

Agile si occupa di ciò non facendo affatto quell'ultimo 10%. Facciamo prima il lavoro (prezioso) più importante, quindi a tempo debito hai percorso il tuo primo 90%, è estremamente probabile che l'ultimo 10% sia bello avere cose che non valgono l'investimento da sviluppare quell'ultimo piccolo pezzettino Tendiamo a variare scope su un progetto Agile, non sulla pianificazione.

Alistair Cockburn ha un buon articolo qui che parla di questo con l'analogia di fare i bagagli una casa per lo spostamento.

In sostanza, penso che il problema che stai descrivendo sia quando chiedi al team di segnalare "quale percentuale completa" sono e poi usa una formula per aggregarla in un valore percentuale totale del progetto complessivo.

Uno degli aspetti più importanti della gestione agile del progetto è il concetto secondo cui lo stato di completezza di un deliverable è binario. Per rubare un Yodaismo: è fatto o non fatto . Non c'è niente come parzialmente fatto.

Questo porta a un paio di altri concetti importanti e prima di tutto è ciò che fatto significa. Sono parziale rispetto allo standard 'done like dinner', cioè la cena viene considerata conclusa solo quando è effettivamente pronta per essere consumata. L'altra cosa importante qui è che avendo piccoli deliverable indipendenti, ottieni una precisione molto migliore su quali progressi sono stati fatti.

Una volta che hai questo posto, diventa possibile parlare di percentuale completa per uno sforzo più grande. Se disponi di 10 deliverable che hanno approssimativamente le stesse dimensioni (in termini di sforzo) e ne hai 5 fatti , puoi dire che sei completato al 50%. Ancora più importante, puoi prendere i dati relativi al tempo necessario per eseguire queste 5 cose e che tipo di variazioni hai visto e utilizzare nei modelli predittivi per prevedere quando il resto del lavoro sarà completato.

Agile si occupa in modo estremamente semplice: non ha "pianificazione".

Come ho descritto in questa risposta ; 90/90 si verifica quando stai cercando di costruire il tuo programma basato su "percorso felice", solo per scoprire all'ultimo momento tutti gli altri casi limite, che devono essere implementati.

In un ambiente agile e corretto, brevi iterazioni e piccoli blocchi di funzionalità, con l'attenzione sul fatto che il software sia sempre nello stato "rilasciabile", consentono di evitare questo tipo di pianificazione. Ma rende molto più difficile pianificare quando le grandi funzionalità saranno correttamente terminate.

Semplicemente detto, le metodologie agili cercano di evitare ciò non basandosi sulla "completezza" del progetto in base a quanto tempo è stato fatto. Basi su quali funzioni sono già implementate.

Facile: non chiedere mai progressi su un'attività come percentuale.

La cascata si basa sul presupposto che tu sappia in anticipo cosa devi fare, in modo da poter misurare fino a dove ti trovi. In Agile non sai tutto in anticipo. Imparerai le cose lungo il percorso, le specifiche cambieranno ei requisiti saranno chiariti, aggiunti o scartati in base al ciclo di feedback.

Dato che non sai quale percorso intraprendere, è ovviamente impossibile dire per quanto tempo sei in arrivo.

Ci sono due modi possibili per comprendere questa domanda:

1. 90 funzioni su 100 sono state completate. Ma prima hai fatto le funzioni semplici e le restanti 10 impiegheranno altrettanto tempo dei 90 precedenti.
2. Tutte le tue funzionalità sono "completate al 90%". Ma prima hai fatto le parti facili delle funzionalità e il restante "10%" impiegherà il tempo richiesto dal precedente "90%".

In entrambi i casi hai stimato lo sforzo molto male. Nel peggiore dei casi non hai nulla di funzionale da mostrare per i tuoi sforzi.

Scrum risolve questo problema:

1. non sta facendo lunghi mesi e credendo che sia accurato. Quello che hai in Scrum sono dei burn-down che ti permettono di stimare quanto a lungo potrebbe prendere. Ma Scrum è estremamente aperto sul fatto che questa sia una supposizione al meglio.
2. prendere una funzione alla volta e completarla fino al punto in cui hai una versione consegnabile. Forzando ogni articolo da lavorare, finito, testato, levigato e cerato si elimina la tendenza a stimare solo il percorso felice e procrastinare sul "Sì, prima della spedizione dovremo gestire alcuni casi speciali, ma in sostanza è fatto! " parti.
3. priorità per le funzionalità in base al valore aggiunto al prodotto. In questo modo, quando finisci il tempo / i soldi hai il prodotto più prezioso che potresti aver costruito in quel momento.
4. mantenendo le iterazioni brevi. Alla fine di ogni iterazione hai la possibilità di cambiare rotta, continuare a sviluppare, abbandonare il progetto con una quantità minima di sforzi inutili, riadattare le tue aspettative per quando è fatto nel senso tradizionale.