Come si possono pianificare risorse e budget a lungo raggio quando si utilizza la metodologia Agile?

8

Agile non incoraggia un sacco di design all'avanguardia. Ciò è positivo dal punto di vista della gestione dei requisiti e dello sviluppo del software e consente al progetto di adattarsi alle mutevoli esigenze aziendali.

Tuttavia, come si fa una pianificazione a lungo termine delle risorse se non si sa veramente cosa si intende costruire quando si avvia? Oh, certo, hai un modello concettuale di ciò che costruirai, ma non hai dettagli quantificabili dai quali gettare quante risorse hai bisogno per completare il progetto, o quanto costerà.

Qualcuno ha qualche suggerimento su come andare sulla pianificazione a lungo raggio in un ambiente agile?

    
posta Erik Funkenbusch 27.12.2010 - 21:30
fonte

4 risposte

2

Ho semplicemente spinto la mia organizzazione a pilotare un approccio agile su uno dei nostri progetti. È stata una sfida per l'alta direzione perché hanno bisogno di un budget e di una tempistica previsti prima che possano persino finanziare un progetto (è una grande impresa).

Quindi, ho fatto quello che faccio sempre in quella situazione, faccio un'ipotesi plausibile. Ho esaminato l'ambito che stavamo assumendo che il progetto avrebbe comportato, indovinato il tempo di sviluppo di quegli articoli, aggiunto in un tempo aggiuntivo per analisti aziendali, amministratori di database, project manager, ecc., Aggiunto un po 'di padding e chiamato il budget stimato. Si noti che questo tipo di stima di "ordine approssimativo di grandezza" viene eseguita nella mia azienda prima di ogni progetto di cascata, quindi non era diverso.

Poi, quando abbiamo avviato il progetto agile, e abbiamo avuto la sensazione della nostra velocità, abbiamo proiettato il punto finale del progetto in base alla velocità e ai punti rimanenti della storia, e abbiamo scoperto che stiamo arrivando prima del mio originale stime di alto livello. Ma va bene (e ce lo aspettavamo).

Quindi immagino di generalizzare una risposta, dipende da cosa intendi per "lungo raggio" e quando hai bisogno di queste stime. Se ne hai bisogno prima dell'inizio del progetto, puoi usare il mio metodo. Se ne hai bisogno durante l'esecuzione di un progetto, puoi utilizzare il concetto di pianificazione del rilascio menzionato da Matthew Kubicina.

Inoltre, consiglio vivamente il piano di stima e pianificazione Agile di Mike Cohn che aiuta a risolvere questo genere di cose.

    
risposta data 28.12.2010 - 14:35
fonte
7

Agile ha un concetto di "Pianificazione della versione". L'intero team si riunisce per pianificare una prossima versione. Ho fatto fino a 2-3 mesi di anticipo. Questo di solito viene fatto dopo che il proprietario del prodotto ha determinato il "prodotto minimo vitale" e sanno esattamente cosa deve essere fatto per rilasciare il prodotto.

Il team può prendere le storie conosciute o la storia epica. Un'epopea è una grande storia o una caratteristica che non è stata ancora completamente definita. Forse qualcosa come "Consenti pagamenti internazionali". Perché questa storia o epopea è così generica, le stime saranno grandi e lo spiegheranno. Il team può fare qualcosa chiamato "t-shirt" e dare ad ogni epico un "piccolo", "medio" o "grande". Ciò fornisce al proprietario del prodotto un certo senso della dimensione delle storie nelle domande e consente al supervisore di fare alcune stime su quale sarà la data effettiva di rilascio.

La chiave è iniziare da dove e continuare a perfezionare i punti o le stime della storia man mano che maggiori informazioni sono conosciute.

Ecco un paio di link sulla pianificazione delle versioni:

risposta data 27.12.2010 - 21:55
fonte
0

Prova la metodologia Get Things Fatto di David Allen; Ho ricordato un passaggio del suo libro (il primo / principale su GTD) in cui dice qualcosa come "essere a lungo termine non significa avere molto tempo per iniziare a farlo".

GTD ti aiuta a pensare in termini attuabili, in modo da poter programmare le attività che puoi eseguire o programmare in un sistema tutto tuo. Questo è GTD in poche parole: link

GTD funziona sia per la vita che per il lavoro, e nel breve periodo fino al più lungo termine, purché continui a pensare nelle azioni e non solo alle cose che ti preoccupano e / o alla tua squadra. Se non hai molto tempo per leggere il libro, prendi l'audiolibro, ne vale davvero la pena.

Puoi anche provare Scrum (e persino combinare con GTD) ... fai una lista di funzionalità, box 'em in un mese di sviluppo e termina con una versione funzionante del prodotto.

Infine, ti consiglio di leggere Rework di Jason Fried, in cui parlano molto delle priorità e alcune nozioni di pianificazione del progetto informali che sono piuttosto utili.

    
risposta data 27.12.2010 - 21:49
fonte
0

In agile, questo è chiamato controlla e adatta. utilizza la cronologia come guida.

Devi conoscere la tua velocità prima di poter iniziare a formulare qualsiasi ipotesi su quanto velocemente puoi raggiungere l'obiettivo. In altre parole, esegui un paio di iterazioni per vedere quanto sei veloce e quindi usa queste informazioni per fare piani.

La risposta alla tua domanda è che devi prima raccogliere i dati prima di provare a fare una pianificazione a lungo termine.

    
risposta data 27.12.2010 - 22:41
fonte

Leggi altre domande sui tag