Lo sviluppo di software Agile può essere utilizzato in progetti definiti da un contratto?

Dai commenti dell'OP sembra che lui come me lavori per un negozio di consulenza, dove forniamo servizi di sviluppo per i nostri clienti ... Penso perché su questa cornice mentale che sta causando la sua confusione ... Quindi io sto per dichiarare un fatto ben noto ma mai dichiarato.

Agile non è compatibile con lo sviluppo del software definito da un contratto.

• I contratti devono essere duri, tu paghi X noi facciamo Y. vuoi X + M ci paghi Y + (M * N)
• I contratti DEVONO essere soddisfacenti, (IE non è aperto) altrimenti non sono contatti legali. (Quando è coinvolto un contatto, devi seguire un rigoroso processo di controllo delle modifiche.)

Molti negozi di consulenza affermano di Agile, stanno mentendo. Lo dicono solo perché Agile ha raggiunto lo stato di parola Buzz.

Agile funziona meglio per lo sviluppo interno in cui i programmatori sono a tempo pieno e si parla poco dei budget. Just Time Frames and Features.

Ti fermi quando l'azienda decide che non desidera fare altre iterazioni. Spero che ciò avvenga dopo che è stata consegnata una quantità significativa di valore, ma prima di arrivare troppo lontano nel regno dei rendimenti decrescenti.

Dovrebbe sempre essere guidato da "il business" qualunque cosa significhi nella tua circostanza. Potrebbe essere la gestione senior di un negozio di sviluppo software o gli sponsor aziendali in un ambiente di sviluppo interno. Decideranno quando il costo della prossima iterazione supererà il beneficio delle funzionalità che saranno disponibili nella successiva iterazione.

Mai, e questa è la sua bellezza.

Il progetto non è mai finito . Hai raggiunto un'altra versione, un'altra pietra miliare, ma finché il denaro scorre, c'è sempre un'altra caratteristica da aggiungere, un altro pezzo da migliorare, un altro bug da correggere. Il progetto morirà quando non sarà più necessario, ma non verrà mai completato. A differenza del modello Waterfall con requisito- > project- > product- > end, questo è un ciclo che può girare per sempre - purché tu venga pagato.

Non è una funzionalità aziendale citata di frequente di questa tecnologia, vero?

Qui c'è un equivoco: Agile non incoraggia i requisiti del progetto a cambiare. Permette invece il cambiamento senza sprecare lavoro o sacrificare importanti aree di sviluppo.

Ci sono quattro limiti fondamentali per qualsiasi progetto di ingegneria; portata, costo, tempo e qualità. La cascata presuppone che queste saranno statiche. Questa è un'ipotesi errata; uno o più di questi cambi SEMPRE. Scope creep, budget ridotto e altre "incognite sconosciute" interferiscono SEMPRE con un progetto, cambiando i vincoli. La cascata non lo anticipa, quindi quando accade, il progetto cambia in modi indesiderati; le caratteristiche importanti che non sono state ancora aggiunte vanno via, o sono fatte rapidamente, o il rilascio deve essere respinto, o costare palloncini mentre il PM getta denaro ai nuovi sviluppatori per far sì che tutto funzioni correttamente.

Agile, al contrario, consente ai vincoli di cambiare e in realtà lo prevede. Lo fa lavorando in piccoli pezzi utilizzabili, in base alle priorità del proprietario, e quindi i pezzi sono idealmente immediatamente utili al proprietario del progetto. Riduce così l'esposizione allo sconosciuto non facendo grandi piani in un lasso di tempo in cui le incognite sono grandi. Se la timeline cambia, i team possono essere aggiunti o le funzionalità meno importanti "de-scoped" e il sistema che il team ha già creato non viene modificato.

Fornisce inoltre stime migliori del tempo e dei costi necessari per produrre lo scopo dato alla qualità richiesta. Le persone sono notoriamente cattive nel valutare grandi lavori; ci vuole molta esperienza, e un calcolo molto più anticipato, per farlo correttamente. Al contrario, le persone sono generalmente dei buoni giudici su ciò che possono fare in un giorno o una settimana o due. Ciò produce rapidamente uno stato stazionario in cui è possibile estrapolare il tempo e il costo del lavoro da svolgere in base al ritmo storico, con una buona dose di precisione.

Per quanto riguarda la definizione degli endpoint, hai ragione; un progetto Agile può andare avanti all'infinito. Tuttavia, così può il tradizionale SLDC; il cliente torna spesso con più soldi e una lista dei desideri di aggiornamenti. La differenza è che non c'è una linea chiara tra "analisi", "progettazione", "sviluppo" e "manutenzione" quando si guarda al progetto nel suo complesso; tutto accade mattone per mattone, sprint a sprint. Se in qualsiasi momento il proprietario vuole chiamare il progetto "fatto", può, e avrà la somma totale di "mattoni" che ha pagato in un solido "muro"; potrebbe non essere il più alto o esteso rispetto a quanto inizialmente previsto, ma è saldamente installato, fa il lavoro e può essere aggiunto in un secondo momento con un minimo di abbattimento.

Finisce una volta che tutte le funzionalità sono state implementate e tutti i bug sono stati corretti.

Se la scadenza è fissa e anche i requisiti sono corretti. Quindi questo non sarà un problema. Ma se la scadenza è fissa, ma i requisiti stanno cambiando, allora c'è qualcosa che dovresti fare per portare a termine il progetto con successo.

Prezzo fisso parte 1, cosa c'è di così male?

Prezzo fisso parte 2, risolvilo con agile!

La grande premessa dietro lo sviluppo agile è che i requisiti sono in continua evoluzione, indipendentemente dalla metodologia utilizzata. Ora, naturalmente, è possibile creare un documento dei requisiti, creare un piano da eseguire su di esso e consegnarlo alla fine, e potrebbe sembrare che i requisiti non siano cambiati. Potrebbero non essere cambiati nel tuo piano, ma con le modifiche del mercato e la migliore comprensione del prodotto da parte tua e dei tuoi clienti, i requisiti in termini di ciò che il cliente desidera cambierà. Agile arriva e suggerisce un processo che non nasconde queste modifiche attraverso una pianificazione prefissata, ma invece costruisce rispondendo alle inevitabili modifiche nel processo.

Quando hai finito, passa da un programma fisso a quando il tuo prodotto si trova in un luogo in cui puoi fornire un valore commerciale sufficiente in cui il cliente può spedire e commercializzare il software nel suo stato attuale. Essere fatti è legato molto di più a quanto valore stai distribuendo invece di come hai aderito a un programma.