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

14

Di recente ho avuto una conversazione con un collega sviluppatore su Agile Software Development. Mentre capisco il principio, sembra che i requisiti in continua evoluzione creino il potenziale per il progetto di andare avanti per sempre. Ma, almeno dove lavoro, i progetti devono essere completati perché è un contratto.

Cioè, la prima iterazione potrebbe richiedere mesi, perché per alcuni progetti il cliente non può utilizzare un'applicazione incompleta. Per alcuni progetti, penso che devi prima definire finito, quindi puoi suddividerlo in iterazioni e perfezionare la tua definizione dopo ogni iterazione. Ma devi sempre avere questa definizione.

Se lo sviluppo di software Agile abbraccia requisiti in evoluzione, come fai a sapere dove finisce? Come si può prevedere un budget per un progetto quando il risultato finale è in continua evoluzione?

Lo sviluppo di software Agile riguarda più un processo agile che un prodotto agile?

agile

— Verax
fonte

termina quando devi effettivamente fornire qualcosa che funzioni, piuttosto che armeggiare. A quel punto devi iniziare a imporre struttura, pianificazione, fissare requisiti e scadenze e iniziare a lavorare piuttosto che a scherzare.

— jwenting

Ogni iterazione agile si traduce in un prodotto funzionante e consegnabile che il cliente può utilizzare e imparare di più. Questo continua fino a quando non sono soddisfatti, cosa che spesso accade prima del previsto. Ciò garantisce che il prodotto funzioni sempre e tiene conto del fatto che il software non è mai finito, ma si evolve per sempre o muore. Scegli un momento nel quale pensi che il prodotto sia abbastanza buono e fermati lì (per ora).

— Martin Wickman,

@Martin Wickman: lo capisco, ma "un prodotto consegnabile che il cliente può usare" è il problema qui. In tal caso, la prima iterazione potrebbe richiedere mesi, poiché per alcuni progetti il cliente non può utilizzare un'applicazione incompleta. Per alcuni progetti, penso che devi prima definire finito, quindi puoi suddividerlo in iterazioni e perfezionare la tua definizione dopo ogni iterazione. Ma DEVI SEMPRE avere questa definizione.

— Verax,

@Verax: il manifesto agile è stato creato per gestire i cambiamenti. Se il tuo progetto non ha cambiamenti, allora l'agile non fa per te. Fine della storia.

— Martin Wickman,

2

@Verax: dovresti chiarire la tua domanda e aggiungere più contesto ad essa. I tuoi commenti mostrano che c'è di più alla domanda. Ciò è evidente anche dal fatto che il voto conta sulla risposta e che la risposta accettata non è correlata al testo della domanda effettiva (e dice anche "dai commenti dei PO ...").

— Martin Wickman,

7

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 struttura mentale che sta causando la sua confusione ... Quindi vado a dichiarare un fatto ben noto ma mai dichiarato.

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

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

Molti negozi di consulenza sostengono di Agile, mentono. 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 di budget. Cornici e caratteristiche Just Time.

— Morons
fonte

Mentre apprendo di più su questo, sto arrivando alla stessa conclusione. La tua ultima frase sembra essere assolutamente corretta. Lavoravo per il governo e il mio cliente era l'agenzia per cui lavoravo, e i programmi dovevano essere mantenuti per anni e anni purché ci fossero impiegati che li usavano. Vedo agile lavorare lì. Ora sviluppo sistemi integrati. Il progetto termina quando la macchina funziona (tutto o niente). Se la macchina funziona parzialmente, non può essere venduta - progetto fallito.

— Verax,

2

In realtà un negozio di consulenza che stavo lavorando da un paio di anni fa aveva un articolo scritto da un agile aderente che descriveva come l'agile potesse essere inserito in un modello di servizio a prezzo fisso.

— McLottle,

2

Non sono d'accordo con questa risposta. Il motivo è che se si dispone di un contratto che non è a tempo indeterminato, significa che non si desidera gestire l'ambito-creep (cosa che accade quasi sempre). I contratti che sono abituati a vedere iniziano con: Paghi X, facciamo Y. Hanno quindi una clausola che afferma che qualsiasi modifica dell'ambito ha un prezzo aggiuntivo. Fintanto che inizi molto presto a notare il creep scope (che richiede risorse e tempo extra), i clienti precedenti possono reagire ai cambiamenti (ottenere approvazioni e budget dalla direzione superiore ecc.). Quindi il processo di gestione stesso diventa agile.

— Spoike,

Ciò non è incompatibile se il contratto riguarda il servizio (scrittura del codice) rispetto al prodotto (software finito). Agile consente di stimare cosa verrà fatto in base a quale budget, e se il requisito cambia, anche il budget deve cambiare. Vuoi un'altra funzionalità? Devi contrarre altre 500 ore-uomo. Il creep di funzionalità è anche il creep dei prezzi, completamente soddisfacente per gli sviluppatori, e se il cliente è disposto a pagare, chi siamo noi a chiederlo?

— SF.

2

Ci sono contratti agili , quindi ovviamente questa risposta è sbagliata per definizione.

— Martin Wickman,

20

Se ti stai concentrando sul fare (quello che ritieni sia) prima le cose più importanti, il progetto finirà quando:

Hai speso i soldi che hai preventivato.
Hai trascorso il tempo previsto.
Non vuoi più aggiungere o modificare nulla.
La prossima serie di cambiamenti con la massima priorità non vale quanto costerà.

— Dale Emery
fonte

5

1. Niente più soldi - Il cliente ha speso tutti i suoi soldi per un prodotto inutile incompleto. 2. Non più tempo - Il cliente ha ancora un prodotto inutile incompleto. 3. Niente da aggiungere - Sì, giusto! 4. Non ne vale la pena - Il cliente ha appena rinunciato al progetto. --- Cosa mi sto perdendo? Questo non ha senso per me.

— Verax,

7

Per 1 e 2: se fai prima le cose più importanti, poi quando finisci i soldi, avrai le cose più importanti che puoi ottenere per i soldi. Simile per tempo. Ammetto che 3 è raro. Per 4: l'arresto non significa necessariamente che il cliente abbia appena rinunciato. Potrebbe significare che hanno le cose più importanti che volevano da questo, e ora preferiscono fare altre cose con i loro soldi. Come decidi quando terminare altri progetti? Qualunque criterio tu usi ora è ancora disponibile su progetti agili.

— Dale Emery,

1

Dale, grazie per i tuoi pensieri. Penso che questo funzioni solo se il cliente paga individualmente ogni iterazione e valuta ogni iterazione come prodotto stesso. Non vedo come questo potrebbe funzionare bene per prodotti a costo fisso o prodotti che richiedono tutto o niente.

— Verax,

5

@Verax: non esiste un prodotto che richieda "tutto o niente". Ci sono sempre funzionalità che sono semplicemente "belle da avere" e bug che sono cosmetici piuttosto che funzionali. Un progetto a costo fisso è un successo se tutto ciò che rimane quando il denaro si esaurisce. I metodi agili cercano di massimizzare la probabilità di ciò.

— Michael Borgwardt,

1

Naturalmente c'è un costo per cambiare i requisiti. Se costruisci qualcosa in una iterazione, quindi cambi i requisiti per quella roba nella successiva, c'è un costo per quello. Agile riduce il costo. Non lo elimina. Se disponi di un budget, tieni presente il budget quando decidi se aggiungere una nuova funzionalità o modificarne una esistente, sapendo che stai sempre scambiando uno contro l'altro. Impari a stabilire le priorità e a ri-stabilire le priorità, e ne impari le conseguenze.

— Dale Emery,

14

Si interrompe quando l'attività decide che non desiderano più eseguire iterazioni. Si spera che ciò avvenga dopo che è stata consegnata una quantità significativa di valore, ma prima di arrivare troppo lontano nel regno dei rendimenti decrescenti.

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

— mcottle
fonte

5

Mai, e questa è la sua bellezza.

Il progetto non è mai finito . Hai raggiunto un'altra versione, un'altra pietra miliare, ma finché i soldi scorrono, c'è sempre un'altra funzione da aggiungere, un altro pezzo per migliorare, un altro bug da correggere. Il progetto morirà quando non sarà più necessario, ma non finirà mai. A differenza del modello Waterfall con requisito-> progetto-> prodotto-> fine, questo è un ciclo che può girare per sempre - purché vieni pagato.

Non è una caratteristica aziendale menzionata di frequente di questa tecnologia, vero?

— SF.
fonte

2

Nemmeno i progetti di Waterfall sono mai stati completati, ma è più probabile che vengano consegnati prenderli o lasciarli con importanti funzionalità mancanti, rendendo necessario un nuovo, costoso progetto.

— Michael Borgwardt,

4

C'è un malinteso qui: Agile non incoraggia i requisiti del progetto a cambiare. Permette invece di cambiare senza sprecare lavoro o sacrificare importanti aree di sviluppo.

Ci sono quattro vincoli fondamentali per qualsiasi progetto di ingegneria; portata, costo, tempo e qualità. Waterfall presume che questi saranno statici. Questa è un'ipotesi errata; uno o più di questi cambiano SEMPRE. Scorrimento di portata, budget ridotti e altre "incognite sconosciute" interferiscono SEMPRE con un progetto, modificando i vincoli. Waterfall non lo prevede, quindi quando succede, il progetto cambia in modo indesiderato; funzioni importanti che non sono ancora state aggiunte vanno via, o vengono fatte rapidamente, o il rilascio deve essere respinto o costa palloncini mentre il PM lancia denaro ai nuovi sviluppatori per entrare e aiutare a fare tutto nel modo giusto.

Agile, al contrario, consente ai vincoli di cambiare, e in realtà lo prevede. Lo fa facendo lavoro in piccoli pezzi utilizzabili, in base alle priorità del proprietario, e quindi i pezzi sono idealmente immediatamente utili al proprietario del progetto. Riduce quindi l'esposizione all'ignoto non elaborando grandi progetti in un lasso di tempo in cui gli incogniti sono grandi. Se la sequenza temporale cambia, i team possono essere aggiunti o le funzionalità meno importanti "rimosse dal campo di applicazione" e il sistema che il team ha già creato non viene influenzato.

Fornisce inoltre migliori stime del tempo e dei costi necessari per produrre l'ambito dato con la qualità richiesta. Le persone sono notoriamente cattive nella stima dei grandi lavori; ci vuole MOLTA esperienza e MOLTO più calcolo iniziale, per farlo correttamente. Al contrario, le persone sono generalmente buoni giudici di 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 CAN andare avanti per sempre. Tuttavia, così può fare il tradizionale SLDC; il cliente torna spesso con più soldi e una lista dei desideri di aggiornamenti. La differenza è che non esiste una linea chiara tra "analisi", "progettazione", "sviluppo" e "manutenzione" quando si guarda al progetto nel suo insieme; succede tutto mattone per mattone, sprint per sprint. Se in qualsiasi momento il proprietario desidera chiamare il progetto "completato", può farlo e avrà la somma totale dei "mattoni" per i quali ha pagato un solido "muro"; potrebbe non essere alto o estendersi per quanto pianificato inizialmente, ma è saldamente in atto, fa il lavoro e può essere aggiunto in un secondo momento con un minimo di abbattimento.

— Keiths
fonte

Mi dispiace ma "Permette invece di cambiare senza sprecare lavoro" è un errore omogeneo che viene utilizzato per convincere il management di quanto sia bello. Il refactoring e / o la riprogettazione del sistema per adattarsi a cambiamenti imprevisti non sono considerati sprechi di lavoro? Lo fa nel campo delle cascate, apparentemente non nel campo agile. Inoltre, se il cliente desiderava solo un lavoro che richiedesse 2 settimane per essere completato, non importa quale metodologia venga utilizzata, le persone possono fornire buone stime. Ciò che il cliente desidera davvero è quanto tempo prima che io abbia il prodotto completo, dove l'agile non è migliore di altri metodi di stima.

— Dunk,

1

Inoltre, fai sembrare una buona cosa che il proprietario possa chiamare fatto in qualsiasi momento e quello che hai finito è ciò che ottiene. IME, in genere il cliente vuole sapere che i suoi X dollari forniranno un certo set di funzionalità prima di buttare giù i soldi. Non vedo come un vantaggio il fatto che il cliente abbia speso un mucchio di soldi e abbia ottenuto solo la metà delle funzionalità che si aspettava. Ritengo che si tratti di un fallimento da parte delle società in via di sviluppo anche se potrebbero aver consegnato qualcosa che chiamano funzionante ....

— Dunk

2

Cosa accadrebbe se un cliente si contraesse per una casa ma i soldi finissero prima che il tetto fosse applicato? Il campo agile lo definirebbe comunque un successo. Nessun altro lo farebbe; in particolare il cliente.

— Dunk,

1

Per quanto riguarda la stima, il team stima cosa possono fare in uno sprint e questo è estrapolato per creare una sequenza temporale per l'intero progetto. Ancora una volta, aiuta a proteggere sia gli sviluppatori che il client. Puoi inserire tutto ciò che desideri in un contratto, incluso un importo e una data da non superare. È negoziabile. Agile aiuta ancora, mostrando entrambe le parti molto rapidamente se i vincoli sono fattibili. Due settimane dopo, se non sembra che sarà fatto in tempo per i soldi, le squadre possono essere aggiunte, le caratteristiche decodificate o il programma esteso.

— KeithS

1

E se avesse fatto lo stesso in un SLDC a cascata? O lo sviluppo si fermerebbe e il client potrebbe ottenere una base di codice con gravi lacune di funzionalità o anticipare una carenza di denaro / tempo, il programma rimanente verrebbe stipato nel tempo rimanente. Che sacrifica SEMPRE la qualità e alla fine di un progetto del genere il team di sviluppo è in crisi. Inoltre, si verificano molti sovraccarichi di costi perché una cascata tradizionale non produce un prodotto fino al completamento dello sviluppo; ciò limita la capacità del cliente di dire "non è quello che volevo".

— KeithS,

1

Termina quando tutte le funzionalità sono implementate e tutti i bug corretti.

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

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

Prezzo fisso parte 2, risolvilo con agile!

— CharithJ
fonte

È difficile sapere quando tutti i bug sono stati corretti.

— Martin Wickman,

Forse "quando vengono corretti tutti i bug noti che vale la pena correggere"?

— Dan Ray,

@CharithJ, i tuoi collegamenti sono interrotti. Sono ancora disponibili da qualche parte? Grazie.

— TwainJ,

1

Il grande presupposto alla base dello sviluppo agile è che i requisiti cambiano sempre, indipendentemente dalla metodologia utilizzata. Ora, ovviamente, potresti costruire un documento sui requisiti, costruire un piano per eseguirlo e consegnarlo alla fine, e potrebbe sembrare che i tuoi requisiti non siano cambiati. Potrebbero non essere cambiati nel tuo piano, ma con i cambiamenti del mercato e la migliore comprensione del prodotto da parte tua e dei tuoi clienti, cambieranno i requisiti in termini di ciò che il cliente desidera. Agile entra e suggerisce un processo che non nasconde questi cambiamenti attraverso una pianificazione fissa, ma crea invece una risposta agli inevitabili cambiamenti nel processo.

Al termine, ora si passa dal completamento di una pianificazione fissa a quando il prodotto si trova in un luogo in cui è possibile fornire un valore commerciale sufficiente in cui il cliente può spedire e commercializzare il software nel suo stato attuale. Il fatto è legato molto di più a quanto valore stai offrendo invece di come hai aderito a un programma.

— Brian Geihsler
fonte

1

I sostenitori agili sostengono erroneamente che nel mondo delle cascate gli sviluppatori scompaiono dopo la firma di un contratto e non vengono più ascoltati fino a quando un prodotto non esce dalla porta. Il modo in cui funziona nella vita reale è che ci sono un buon numero di checkpoint e molte recensioni con cui il cliente può essere coinvolto tanto quanto desidera. Se non gli piace la direzione o le decisioni, possono richiedere modifiche. Quando un prodotto viene consegnato, dovrebbe essere ciò che il cliente voleva nella misura in cui il cliente ha scelto di essere coinvolto. Agile non migliora questo aspetto per molti progetti.

— Dunk,