L'ambito fisso + termine fisso + contratto a prezzo fisso sarà mai realizzato per funzionare con "agile"?

Bene, ho lavorato principalmente in ambienti "agili" (anche se non usiamo il gergo), e ho fatto cose a costo fisso. Generalmente ciò che equivale a è più costoso, dal momento che nessuna azienda può permettersi di fare tutto gratuitamente, e le esigenze cambiano e si evolvono quando il cliente capisce più chiaramente ciò che desidera.

I requisiti iniziali per la parte a costo fisso devono essere eseguiti molto più attentamente di quanto non facciano in un tipico ambiente iterativo, rendendo il processo un po 'meno iterativo. La parte "più" del contratto può essere più iterativa, a condizione che abbiamo soddisfatto la quota di costi fissi in modo più o meno soddisfacente per il cliente.

Vorrei porre una contro-domanda:

L'ambito fisso + la scadenza fissa + il contratto a prezzo fisso possono mai essere fatti funzionare, periodo ?

Il "buon / veloce / a buon mercato - scegli due" dice non è solo uno sciocco scherzo ingegneristico. Ogni project manager degno di nota conosce il triangolo di gestione dei progetti :

Cistaidicendocheilcosto,l'ambitoeilprogrammasonostaticorretti.Ciònonlasciaspazioallamanovrabilitàoall'errore.Nessuno.Puoisceglieredivisualizzare"Qualità" come attributo, ma non è un attributo "reale", è più simile a un meta-attributo derivato dagli altri attributi (costo / ambito / pianificazione).

Il problema è che questo non succede mai nella realtà fintanto che il tuo progetto viene pianificato ed eseguito dagli umani.

• I requisiti e le specifiche non coprono mai ogni caso limite a meno che non siano stati redatti in modo immenso da architetti e designer qualificati, nel qual caso il progetto è già a metà; e anche allora c'è ancora la possibilità di errore.

• Si verificheranno costi imprevisti che porteranno a eccedenze di budget. Un abbonamento scaduto. Un produttore ha interrotto il supporto per un prodotto che stai utilizzando e devi trovarne uno nuovo. Un appaltatore orario ha aumentato il suo tasso sotto minaccia di partenza. Tutta la tua squadra ha scioperato, chiedendo un aumento del 10% e una settimana di ferie in più.

• Scadenziario degli orari. Emergono problemi imprevedibili; il componente grafico che hai utilizzato per 5 anni consecutivi non è compatibile con Windows 95, che il tuo client sta ancora utilizzando. Un bug oscuro in Windows a 64 bit causa seri problemi di interfaccia utente e trascorri quasi una settimana rintracciandoli e sviluppando una soluzione alternativa (questo in realtà mi è successo). Il tuo sviluppatore senior è stato investito da un autobus e tu devi reclutare e addestrare uno nuovo. La tua data di consegna stimata è sempre sbagliata. Sempre.

  Vedi legge di Hofstadter :

  Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

I metodi agili si concentrano sulla gestione del costo, della pianificazione e dell'ambito. La maggior parte delle volte, si tratta in particolare di destreggiarsi tra scope e talvolta schedule , motivo per cui si inizia con nebulose user story e revisioni di piani invece di versioni complete. Diverse metodologie utilizzano una terminologia diversa ma è la stessa premessa di base: rilasci frequenti e un ribilanciamento della pianificazione e dell'ambito di ogni versione.

Questo rende senza senso con un progetto che è (o pretende di essere) uno ambito fisso o programma fisso.

Se gli attributi del progetto uno (costo / ambito / programma) sono stati corretti, ti direi che potrebbe non essere adatto per le metodologie agili.

Se gli attributi del progetto due sono corretti, il tuo progetto sicuramente non è adatto per le metodologie agili.

Se gli attributi tutti e tre sono corretti, probabilmente il tuo progetto fallirà. Se viene effettivamente spedito, allora il programma originale è stato pesantemente ridimensionato, oppure il cliente è riuscito a illudersi pensando di aver effettivamente consegnato ciò che era stato promesso.

Se questo contratto è ancora sul tavolo, ti esorto a rifiutarlo. E se lo hai già accettato, che Dio abbia pietà della tua anima.

Adoro questa citazione:

"Scrum è ottimo sia per la variabile data-scope fissa, che per la" variabile-scope "(che cresce sempre) data-variabile. Se stai facendo fixed-date fixed-scope, ti consiglio waterfall o RUP, che ti compreranno qualche mese per cercare un nuovo lavoro. "    ~ Michael James

Certo, a patto che la barra della qualità sia tenuta molto bassa. Sono un credente nel vecchio triangolo di ferro del "tempo di consegna / qualità / prezzo" in cui puoi sceglierne due, ma poi l'altro galleggia. Sembra che tu abbia fissato il tempo di consegna e il prezzo (e anche le caratteristiche), quindi l'unica cosa che può dare è la qualità.

Detto questo, se stai utilizzando un grafico di burndown e hai gli elementi con la priorità più alta che vengono eseguiti per primi, potrebbe essere accettabile avere una manciata degli elementi più importanti fatti nel periodo di tempo specificato per l'importo monetario specificato. Per lo meno il tuo cliente vedrà che stai controllando il processo in qualche modo, con un deliverable alla fine di ogni iterazione e hanno la capacità di dire ciò che è più importante.

Altrimenti, penso che impegnarsi in un tempo prestabilito, in un set di caratteristiche e in un prezzo è sconsiderato e porterà a sforzi eroici con conseguente riduzione della qualità e codice meno gestibile. Agile non è una polvere magica delle fate.

Il prezzo fisso / la scadenza fissa / lo scopo fisso possono essere fatti almeno altrettanto bene che può essere a cascata.

In cascata, le stime del tempo sono imprecise ei dettagli finiscono per essere implementati in modo diverso rispetto alle specifiche originali. In altre parole, la deadline / scope non può essere conosciuta con esattezza.

In agile, puoi eseguire lo sprint zero per generare un backlog di storie utente e fare alcune stime. Quindi accetta di soddisfare le storie di valore per un prezzo fisso, entro una scadenza prefissata. Lo scopo è fissato in termini di storie di valore che intendi soddisfare e nessuna promessa fatta sulle storie degli utenti.

In altre parole, prometti di consegnare ciò che conta ed evitare di fare promesse su decisioni di design specifiche che non sono correlate alle entrate / risparmi / ecc. che il progetto dovrebbe consegnare.

Sono d'accordo con Bruce in una certa misura. Anche se non ho molta familiarità con waterfall o RUP, e quindi non posso commentare su questo.

Quello che ho letto di recente, e ho pensato che fosse davvero ben detto, è che anche in Agile trascuriamo la pianificazione. Una sessione di pianificazione approfondita una volta che l'iterazione è grande - non è essenziale - ma lo è anche la pianificazione per l'iterazione.

Lavoro nel settore dello spettacolo, dove le cose cambiano continuamente. Il team ha bisogno di un po 'di clemenza / flessibilità che permetta loro di "ripianificare" le storie a metà sprint per allinearsi con nuovi obiettivi o obiettivi rivisti.

Adoro l'idea di una pianificazione continua, poiché troppo spesso gli sviluppatori diranno al proprietario del prodotto di andare via quando stanno lavorando a storie a metà sprint. Questo è eccellente se il tuo team lavora su storie che sono ancora valide e il proprietario del tuo prodotto è solo una seccatura. Ma in alcuni casi le storie diventano ridondanti DURANTE lo sprint, ed è imperativo che il product owner lo riconosca, e affinchè il team si riallinea con gli obiettivi / le storie cambiate - non è di cosa si tratta agile?