Quali sono alcune situazioni in cui Agile è inappropriato? [chiuso]

https://stackoverflow.com/questions/348611

20-08-2019
|

Domanda

Ho sentito e letto di Agile per anni. Possiedo un libro o due su di esso e mi piace l'idea.

Sono finalmente in una posizione in cui posso portare qualcosa del genere dove lavoro, ma ho serie preoccupazioni sul fatto che sia la strada da percorrere per noi:

Non esiste una dimensione minima per questo? Il grande design iniziale deve essere più efficiente per un progetto di tre o quattro settimane ... Giusto?
I nostri clienti di solito richiedono prezzi fissi. Devono sapere con cosa hanno a che fare, tranne in casi speciali in cui ci troviamo di fronte a un ovvio buco nero e anche allora le persone si sentono più a loro agio con un berretto. Quindi, come puoi fornire un preventivo se stai seguendo un processo tollerante alle continue modifiche ai requisiti?
Comprendo che Agile potrebbe fornire migliori probabilità di successo in progetti più complessi, ma non aumenterà i costi per il cliente? E ovviamente c'è il costo del fallimento da considerare - forse siamo tornati alla domanda sulla dimensione minima qui.
In che modo spiegheresti questo approccio contro-intuitivo ai clienti? Gli stakeholder non tecnici potrebbero non avere l'esperienza per avvolgere la testa attorno a qualsiasi cosa oltre Waterfall.
Anche per i progetti interni, ci sono budget. Cosa mi sto perdendo?
Sembra che ci sia un po 'di contraccolpo contro Agile ultimamente. Qualcos'altro inizierà presto a guadagnare trazione?

Nota: siamo un negozio di 5 sviluppatori con progetti che vanno da un giorno o due fino a diversi mesi. Non credo che ci sia una metodologia per dominarli tutti, ma sarebbe bello trovare qualcosa di abbastanza flessibile da poterlo adattare a tutti i nostri progetti.

Grazie mille!

Brian MacKay

Soluzione

Non credo che una metodologia possa dominarle tutte. Mi dispiace. Sono fermamente convinto di trovare il modello giusto per il progetto giusto. Ad esempio, come ti sentiresti se ti sottoponessi a un intervento chirurgico e sapessi che la macchina che ti teneva in vita è stata sviluppata in un rapido ciclo iterativo con poco design in anticipo.

Ma comunque, alla tua domanda. Sono un grande sostenitore degli approcci agili, di mantenere brevi le iterazioni, concentrarsi su ciò che l'utente desidera e non costruire la corazzata ma solo costruire esattamente ciò di cui hai bisogno. Direi che il 95% di tutti i progetti potrebbe usare approcci agili e, se non ci riescono, di solito è un problema culturale, non un problema di progetto.

Ora per quanto riguarda BDUF (Big Design up Front), abbiamo avuto un grande successo con un team di 20 persone su un progetto di 4 mesi, abbiamo preso il progetto suddiviso in 3 cicli di quattro settimane, all'inizio di ogni ciclo che abbiamo tutti si incontrano in una stanza e dicono ok ecco cosa dobbiamo costruire, ecco come lo costruiremo e abbiamo preso una decisione su come sarebbero state le nostre interfacce, quali dati avremmo avuto bisogno ecc ... Ma era solo una pugnalata , siamo quindi tornati ai nostri banchi e chiunque possedesse i vari pezzi ha cancellato i dettagli.

Sostanzialmente abbiamo fatto abbastanza BDUF in anticipo per avviare il team (e assicurarci di aver coperto tutti i requisiti aziendali). Chiamavamo queste sessioni Developer Days ed era un buon modo per far ripartire la squadra. Se hai i soldi per portare la squadra fuori dal sito, puoi metterli in una sala conferenze in un hotel, dar loro da mangiare un sacco di cianfrusaglie e guardare il flusso di succhi.

Altri suggerimenti

la soluzione semplice prevede 2 passaggi:

non stimare costi e programmi per progetti, stimare costi e programmi per caratteristiche
misura e registra informazioni sufficienti per calcolare i tuoi errori di velocità e stima

iniziare in piccolo e internamente, se possibile, per ottenere alcuni numeri di base. Se vuoi ancora realizzare un "grande design iniziale", fallo per le singole funzionalità. Questo aiuterà le tue stime iniziali a essere più accurate, e anche con quale granularità di "funzionalità" ti senti a tuo agio.

Nota: funzionerà solo se il cliente si impegna a fare la propria parte , in particolare per essere altamente disponibile agli sviluppatori (per rispondere a domande, scrivere storie e testare descrizioni, ecc.), e di non cambiare idea durante un'iterazione

buona fortuna con la tua transizione e facci sapere come va!

Di gran lunga la più grande controindicazione che ho visto è una mancata corrispondenza dei valori. La programmazione estrema si basa su rispetto, comunicazione, feedback, coraggio e semplicità. In un'organizzazione che si comporta in base a valori incompatibili, l'applicazione di XP causerà attrito e non comporterà alcun cambiamento duraturo (IME).

Dipende da chi chiedi e se credono nell'agile o meno ...

Per quanto riguarda questo:

Vorrei trovare una metodologia per dominarli tutti.

http://www.opaquelucidity.com/facepalm.jpg

I tuoi clienti sono tutti uguali? Hai già detto che le durate variano selvaggiamente ... Perché dovresti supporre che tutti i tipi di progetti diversi sarebbero adatti a una singola metodologia?

Cerca cosa fa fallire la pratica Agile ... Se ottieni 1-2 punti minori, troverai il modo di superarli. Altrimenti, stai cercando un fallimento. E una volta fallito, non avrai un'altra opportunità di provarlo. Anche se non è la pratica Agile che ha fallito ...

Inizia con progetti interni per avere un po 'di esperienza su come funziona il tuo processo agile e su come puoi stimare meglio quanto tempo ci vorrà. Quando ritieni di essere pronto ad affrontare un vero cliente, scegline uno di cui ti fidi molto e scegli un progetto ragionevolmente piccolo per cominciare. La chiave qui è che vuoi creare fiducia. Spiega cosa stai facendo e perché - vuoi fornire loro un software migliore che rifletta meglio le loro priorità prima - e mostra loro come hai avuto successo nei tuoi progetti interni. Mantieni le tue promesse - dato che credo nei metodi agili, non penso che questo sarà troppo difficile da fare.

Una volta che hai avuto successo (e stupito il cliente), ti chiederanno di usare il metodo su altri loro progetti. Una volta che hai un cliente felice puoi iniziare ad espanderti ad altri, usando il tuo primo cliente come riferimento. Molto presto scoprirai che le pratiche che stai utilizzando funzionano così bene che si insinuano nella tua "cascata". anche i processi. Alla fine, avrai bevuto abbastanza del kool-aid per essere come il resto di noi agilisti. : -)

Oh. E sì, ci sono progetti che non sono particolarmente suscettibili ai metodi agili. Cose come i sistemi critici per la vita, il controllo delle centrali nucleari, le industrie altamente regolamentate possono richiedere una progettazione e un processo più precisi di quanto lo consenta l'agile. La maggior parte di noi non lavora mai a questi progetti.

Scott Ambler è una buona autorità per una risposta su questo. Il suo articolo fa un buon lavoro nel mettere in evidenza alcune delle insidie ??del prezzo fisso, ma è sicuramente possibile. Alistair Cockburn concorda è anche possibile, ma sottolinea che alcuni dei vantaggi che ottieni dall'agile sono perso in contratti a prezzo fisso.

Un problema di base con "grande design iniziale". (BDUF) è il tempo impiegato nella progettazione di funzionalità che viene raramente, se non mai, utilizzato. Se devi avere un prodotto finito in meno di un mese, il problema deve essere davvero ben definito in anticipo.

Per quanto riguarda il costo del fallimento, questa è una preoccupazione molto legittima. Uno dei vantaggi di Agile è che eventuali guasti si verificano prima e con costi molto inferiori rispetto a quelli che verrebbero in un progetto secondo la metodologia a cascata. Essere in grado di imparare da quei fallimenti e ottenere un buon prodotto alla fine non è un risultato che la metodologia a cascata può offrire. Il governo federale ha un discreto numero di fallimenti di alto profilo nei progetti software che hanno seguito la metodologia a cascata e BDUF. Ho bloggato sul caso virtuale dell'FBI Errore nel progetto del file.

Le metodologie che utilizzerai saranno determinate tanto dall'adattamento con il tuo team quanto dal tipo di software che stai costruendo e dai tuoi clienti. tvanfosson ha ragione sui progetti che non sono adatti a metodi agili. Concordo con Kent Beck sull'idea di mancata corrispondenza dei valori. Alcune organizzazioni non sono pronte per Agile da una prospettiva culturale, indipendentemente dai suoi meriti e dal successo altrove.

Lasciami rispondere punto per punto alle tue preoccupazioni:

Non esiste una dimensione minima per questo? Il grande design davanti deve essere di più efficiente per tre o quattro settimane progetto ... giusto?

Non sono sicuro di cosa ti faccia pensare che disegnare rettangoli su carta debba essere più veloce del codice di refactoring.

Comunque, anche se lo fosse, la domanda se BDUF ripaghi sarebbe molto più una funzione di quanto apprendimento ci si aspetta durante il progetto che di dimensioni del progetto. Più ci si può aspettare di apprendere qualcosa sulla progettazione, i requisiti, ecc. Durante l'implementazione del sistema, più si spreca la progettazione iniziale.

Devo ancora incontrare un progetto in cui non ho imparato cose significative durante l'implementazione del sistema.

I nostri clienti richiedono solitamente fissi prezzi. Devono sapere cosa sono trattare, tranne in casi speciali dove siamo contro un ovvio buco nero e anche allora lo sono le persone più comodo con un berretto. Così come puoi fornire un preventivo se lo sei seguire un processo tollerante delle modifiche ai requisiti in corso?

Accetta solo le modifiche ai requisiti che non cambiano lo sforzo totale. Cioè, quando arrivano nuovi requisiti, eliminano quelli meno importanti. Lascia che il cliente decida in modo da ottenere il massimo profitto.

Non otterrai tutti i vantaggi di Agile in questo modo, ma è buono quanto il prezzo fisso può ottenere, per quanto ne so.

Comprendo che Agile potrebbe fornire maggiori probabilità di successo in progetti più complessi, ma non aumenterà i costi per il cliente?

Stai suggerendo che i progetti gestiti in modo Agile siano più costosi dei progetti tradizionali? In realtà ci sono aziende là fuori che hanno sperimentato il contrario, fino a una riduzione dei costi del 50%.

E ovviamente c'è il costo del fallimento da considerare - forse siamo tornati alla domanda sulla dimensione minima qui.

Il costo del fallimento diminuisce con un progetto Agile, a causa del feedback iniziale. Puoi notare un errore, e quindi decidere di annullare il progetto, molto prima.

In che modo spiegheresti questo approccio contro-intuitivo ai clienti? Gli stakeholder non tecnici potrebbero non avere l'esperienza per avvolgere la testa attorno a Waterfall.

Perché paga lo sviluppo di software Agile?

Anche per i progetti interni, ci sono budget. Cosa mi sto perdendo?

Non lo so. Agile funziona bene con i budget: implementa le funzionalità con la massima priorità fino a quando il budget non viene esaurito. Hai il sistema più prezioso che avrebbe potuto essere implementato per quei soldi.

Sembra che ci sia un po 'di contraccolpo contro Agile ultimamente. Qualcos'altro inizierà presto a guadagnare trazione?

Fin dall'inizio c'è stata una reazione contraria. E man mano che sta diventando più popolare (ed è!), È naturale vedere anche più contraccolpi.

Lean Software Development sta guadagnando molta trazione. Non è in concorrenza con lo sviluppo Agile, ma piuttosto complementare, però. Le comunità in realtà sono abbastanza sovrapposte.

Per quanto riguarda la "metodologia" per domarli tutti " - dai un'occhiata al "Crystal" di Alistair Cockburn famiglia di processi agili. Sostiene (abbastanza con competenza) che ogni progetto ha bisogno del proprio processo e che anche il processo di un progetto deve cambiare nel corso del progetto. E fornisce un framework leggero per lo sviluppo del processo.

Come Scrum, mentre ci penso. Scrum in realtà non ti dice molto su come eseguire il tuo progetto, ma molto di più su come scoprire cosa funziona e

Non userei necessariamente agile per un progetto in cui tutto è noto in anticipo. Agile funziona bene quando il cambiamento è altamente probabile. Nel caso in cui il cambiamento non sia verosimile, si può usare il processo predittivo o a cascata per gestire un simile progetto.

Seguono le risposte a domande particolari: Non esiste una dimensione minima per questo? Da un punto di vista pratico, Agile è indipendente dalle dimensioni. Detto questo, più un progetto è grande, più si verificherà un cambiamento. Se un progetto è piccolo, allora tutto è conoscibile e il cambiamento è improbabile.

Il grande design in primo piano deve essere più efficiente per un progetto di tre o quattro settimane ... Giusto? Il design semplice ed evoluto guidato da TDD è sempre più efficace. Dovresti avere appena fatto abbastanza architettura per sapere dove cadono i pezzi principali. Non usare l'architettura per indovinare cosa stai per fare, cattura solo ciò che è conoscibile. Lascia che il design semplice ed evoluto ti permetta di evolvere il tuo design dettagliato mentre costruisci l'applicazione.

I nostri clienti di solito richiedono prezzi fissi. Devono sapere con cosa hanno a che fare, tranne in casi speciali in cui ci troviamo di fronte a un ovvio buco nero e anche allora le persone si sentono più a loro agio con un berretto. Quindi, come puoi fornire un preventivo se stai seguendo un processo tollerante alle continue modifiche ai requisiti? All'inizio è richiesta una certa istruzione. Dovresti stabilire un portafoglio ordini di prodotti, chiedere al proprietario del prodotto di stabilire delle priorità e quindi fare una stima iniziale del lavoro. Ciò ha richiesto al proprietario del prodotto di stabilire una linea di demarcazione nel portafoglio ordini per l'offerta fissa. Quindi si dimensiona la squadra e la durata per soddisfare il preventivo. Il contratto stabilisce quindi che verrà utilizzata la capacità fissa della squadra per la fascia oraria stabilita. Ciò manterrà il proprietario del prodotto concentrato sulla fascia oraria e sul budget quando effettuerà chiamate prioritarie sul backlog.

Comprendo che Agile potrebbe fornire migliori probabilità di successo in progetti più complessi, ma non aumenterà i costi per il cliente? Un progetto di successo è sempre più economico di un progetto fallito.

In che modo spiegheresti questo approccio contro-intuitivo ai clienti? Gli stakeholder non tecnici potrebbero non avere l'esperienza per avvolgere la testa attorno a Waterfall. L'istruzione (ovvero il campo di addestramento agile) e la visita di squadre agili di successo aiuteranno enormemente. Quindi avvia la squadra. Il lavoro li renderà impegnati e i risultati li venderanno.

Anche per i progetti interni, ci sono budget. Cosa mi sto perdendo? Ultimamente sembra che ci sia stato un contraccolpo contro Agile. Qualcos'altro inizierà presto a guadagnare trazione? L'unico contraccolpo di cui sono a conoscenza è progetti agili che non usano efficacemente le pratiche ingegneristiche (vale a dire, solo SCRUM). Un team che utilizza SCRUM e XP effectivley farà molto bene alla consegna e ad un ritmo sostenibile.

Suggerirei contro Agile nello sviluppo di un nuovo sistema di controllo del traffico aereo.

Imho:

Agile o no, dovresti progettare ciò che è noto prima dell'implementazione - prima di "solo provare cose". Suddividi ricorsivamente le cose in compiti gestibili, quindi progetta ciò che è noto, che si tratti di dettagli chiacchieroni o semplicemente concetti generali. Cose come l'interfaccia utente e i requisiti aziendali di tutti i giorni non sono quasi mai messi in pietra prima dello sviluppo, mentre potrebbero essere le funzionalità di simulazione dei velivoli.

Un modo per provare a " vendere " agile per i clienti è concedere loro due opzioni: 1. Cascata, dove non è possibile annullare fino a quando noi (gli sviluppatori) raggiungiamo la fine dell'accordo. 2. Agile, dove ricevi aggiornamenti settimanali sullo stato, dimostrazioni pratiche man mano che diventano disponibili e il diritto di interrompere il servizio ogni 2 settimane (nel caso in cui non ti piaccia il nostro lavoro).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow