L'ambito fisso + la scadenza fissa + il contratto a prezzo fisso possono mai essere fatti funzionare con "agile"?

Alcuni progetti che eseguiamo internamente sono Scrum, pur essendo "riparati tutto" al cliente. Stiamo riscontrando un successo misto da parte nostra (al cliente piace la visibilità del grafico di burndown). I tipi di progetti che lavoriamo possono essere eseguiti con successo usando i metodi agili?

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 è il costo-plus, dal momento che nessuna azienda può permettersi di fare tutto gratuitamente e i requisiti cambiano e si evolvono man mano che il cliente capisce più chiaramente ciò che desidera.

I requisiti iniziali per la parte di costo fisso devono essere eseguiti con molta più attenzione di quanto non siano 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 porzione di costo fisso più o meno soddisfacente per il cliente.

Vorrei porre una contro-domanda:

È possibile far funzionare l'ambito fisso + scadenza fissa + contratto a prezzo fisso, periodo ?

Il detto "buono / veloce / economico - scegli due" non è solo uno scherzo ingegnoso sciocco. Ogni responsabile di progetto degno di nota conosce il triangolo di gestione del progetto :

Ci stai dicendo che i costi, l'ambito e la pianificazione sono tutti fissi. Ciò non lascia spazio a manovrabilità o errore. Nessuno . Puoi scegliere di visualizzare "Qualità" come un attributo, ma non è un attributo "reale", è più simile a un meta-attributo derivato dagli altri attributi (costo / ambito / programma).

Il problema è che ciò non accade mai nella realtà finché il tuo progetto viene pianificato ed eseguito dagli umani.

• I requisiti e le specifiche non coprono mai tutti i casi limite a meno che non siano stati elaborati con dettagli immensi da architetti e designer qualificati, nel qual caso il progetto è già a metà lavoro; e anche allora c'è ancora la possibilità di errore.

• Verranno visualizzati costi imprevisti che comportano sovraccarichi 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 minacciato di partenza. Tutta la tua squadra ha appena scioperato, chiedendo un aumento del 10% e una settimana in più di vacanza.

• Gli orari scorrono. Si manifestano problemi imprevedibili; quel componente grafico che stai usando da 5 anni consecutivi non è compatibile con Windows 95, che il tuo client sta ancora usando. Un oscuro bug in Windows a 64 bit provoca gravi problemi all'interfaccia utente e passi quasi una settimana a rintracciarlo e sviluppare una soluzione alternativa (questo in realtà è successo a me). Il tuo sviluppatore senior è stato investito da un autobus e devi andare a reclutare e addestrarne uno nuovo. La data di consegna stimata è sempre errata. Sempre.

  Vedi la legge di Hofstadter :

  Legge di Hofstadter: ci vuole sempre più tempo del previsto, anche quando si tiene conto della Legge di Hofstadter.

I metodi agili si basano sulla manipolazione di costi, pianificazione e ambito. Il più delle volte, si tratta in particolare di destreggiarsi tra l' ambito e talvolta il programma , motivo per cui si inizia con storie utente nebulose e si pianificano le revisioni anziché le versioni complete. Metodologie diverse usano una terminologia diversa ma è sempre la stessa premessa di base: rilasci frequenti e un riequilibrio del programma e dell'ambito con ogni rilascio.

Questo rende alcun senso con un progetto che è (o dichiara di essere) sia portata fissa o orario fisso.

Se un attributo del progetto (costo / ambito / programma) fosse corretto, ti direi che potrebbe non essere adatto a metodologie agili.

Se vengono fissati due attributi del progetto, il progetto non è sicuramente adatto a metodologie agili.

Se tutti e tre gli attributi sono corretti, probabilmente il tuo progetto fallirà. Se effettivamente viene spedito, allora il programma originale è stato enormemente confuso, o il cliente è riuscito a illudersi nel pensare che tu abbia effettivamente consegnato ciò che era stato promesso.

Se questo contratto è ancora sul tavolo, ti esorto a rifiutarlo. E se l'hai già accettato, possa Dio avere pietà della tua anima.

Adoro questa citazione:

“Scrum è ottimo sia per ambito variabile a data fissa, sia per data variabile" a portata fissa "(che cresce sempre). Se stai facendo un ambito fisso a data fissa, raccomando a cascata o RUP, che ti comprerà qualche mese per cercare un nuovo lavoro. ”~ Michael James

Certo, fintanto che la barra della qualità è notevolmente ridotta. Sono un sostenitore del vecchio triangolo di ferro di "tempi di consegna / qualità / prezzo" dove puoi sceglierne due, ma poi l'altro galleggia. Sembra che tu abbia fissato i tempi 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 prima gli articoli con la priorità più alta, potrebbe essere accettabile fare una manciata degli articoli più importanti nel periodo di tempo specificato per l'importo monetario specificato. Per lo meno il tuo cliente vedrà che stai controllando un po 'il processo, con un deliverable alla fine di ogni iterazione e hanno la capacità di dire ciò che è più importante.

Altrimenti, ritengo che impegnarsi in un tempo prestabilito, set di funzionalità e prezzo sia insensato e porterà a sforzi eroici con conseguente qualità inferiore e codice meno gestibile. Agile non è polvere magica fata.

Il prezzo fisso / la scadenza fissa / l'ambito fisso possono essere fatti tanto agili quanto in cascata.

A cascata, le stime del tempo sono imprecise e i dettagli finiscono per essere implementati in modo diverso rispetto alle specifiche originali. In altre parole, la scadenza / ambito di applicazione non può essere conosciuta esattamente in anticipo.

In agile, puoi fare uno sprint zero per generare un backlog di user story e fare delle stime. Quindi accetta di soddisfare le storie di valore a un prezzo fisso, entro una scadenza fissa. L'ambito è fissato in termini di storie di valore che intendi soddisfare e non vengono fatte promesse sulle storie degli utenti.

In altre parole, prometti di consegnare ciò che conta ed eviti di fare promesse su decisioni di progettazione specifiche non correlate a entrate / risparmi / ecc. che il progetto dovrebbe consegnare.

Sono d'accordo con Bruce fino a un certo punto. Anche se non ho troppa familiarità con la cascata o RUP, e quindi non posso commentarlo.

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

Lavoro nel settore dello spettacolo, dove le cose cambiano costantemente. Il team ha bisogno di un certo grado di clemenza / flessibilità che consentirà loro di "riprogrammare" le storie a metà sprint al fine di 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 un fastidio. Ma in alcuni casi le storie diventano ridondanti DURANTE lo sprint, ed è indispensabile che il proprietario del prodotto lo rilevi e che il team si riallini con obiettivi / storie cambiati - non è questo ciò che è agile?