Come ottenere una buona panoramica di un backlog Agile?

0

Utilizziamo Visual Studio Team Services per ospitare il nostro codice in un repository Git e per gestire la nostra pianificazione Agile attraverso iterazioni (sprint), user story in un backlog, una taskboard per lo sprint corrente, ecc.

Funziona molto bene per pianificare ed eseguire lo sprint corrente e per rivedere quello precedente, ma trovo difficile avere una visione d'insieme. Mi piacerebbe vedere tutti gli sprint tracciati tra ora e il rilascio, guardare quali storie utente sono importanti in ognuno di questi sprint, ... salta su un livello e pianifica tutti gli sprint.

Dove si inserisce la metodologia Agile e gli strumenti VSO / TFS mi supportano oltre l'elenco di backlog di storie di utenti?

    
posta dumbledad 14.03.2016 - 16:06
fonte

2 risposte

6

I bit di questa domanda che non riguardano gli strumenti hanno una risposta soddisfacente in questa domanda che @MichaelT ha già indicato a.

Agile è contrario alla pianificazione eccessiva

Per quanto riguarda gli strumenti per supportare la pianificazione a lungo termine, tuttavia, il punto chiave è che Agile riconosce che le condizioni aziendali cambiano sempre e che i piani a lungo termine raramente arrivano alla fine senza cambiamenti significativi. La maggior parte delle organizzazioni è in sovrappeso e spreca enormi quantità di tempo a pianificare in modo dettagliato cosa succederà tra sei mesi, solo per rimpiazzare in tre mesi, e in cinque mesi, ecc.

Mantieni i piani a lungo termine di alto livello

Ovviamente devi fare una pianificazione a lungo termine in qualsiasi progetto significativo, ma la chiave è che, in ogni caso, dovresti ricalcolare i tuoi piani, dovresti mantenere i tuoi piani di alto livello. Non perdere tempo a fare stime inutili all'ora di quello che farai tra sei mesi. I manager amano farlo perché li fa sentire in controllo, ma è un'illusione. Sfortunatamente, molti strumenti tradizionali di gestione dei progetti ti portano a fare esattamente questo.

Caso ideale

Nel caso dell'idea con Agile, non hai una "scadenza". Hai una lista di cose che farai e rilascerai ogni sprint. Il software è "fatto" quando arrivi al punto in cui le parti interessate affermano di averlo fatto. Il tuo piano è il backlog. Questa è la lista delle cose che attualmente ti aspetti di fare nell'ordine in cui ti aspetti di farlo. Pianificare è solo scrivere storie e organizzarle nel tuo backlog. Non sono necessari strumenti aggiuntivi.

Caso realistico

Ovviamente, realisticamente, non stai lavorando in questa terra fantastica come normalmente i semi vogliono sapere quando sarà fatto. (O peggio, ti stanno dicendo quando deve essere fatto.) Realisticamente, alcuni risultati sprint sono inutili da rilasciare mentre altri sono vitali. Realisticamente, avrai altri team che hanno bisogno che alcune delle tue storie finiscano prima che le loro storie possano iniziare.

In questi casi, probabilmente dovrai creare un elenco di sprint futuri e storie di slot in ogni sprint, quindi hai un'idea approssimativa quando "finirai".

La chiave: è tutto che dovresti fare. Qualsiasi altra cosa è in fase di pianificazione.

Strumenti

Dato questo, i risultati della tua pianificazione sono solo un elenco di sprint, con un elenco puntato di storie per ogni sprint. Questo è tutto. Lo strumento che supporta elenchi puntati e tabelle funzionerà. Potresti usare Word. Potresti usare PowerPoint. Potresti usare Sharepoint. Potresti usare Mediawiki. (La mia squadra usa Confluence.) Potresti anche usare una lavagna con linee per sprint e note adesive. (Ho visto che team di successo nella mia azienda fanno esattamente questo.)

Basta non fare la pianificazione a cascata (e usare gli strumenti di pianificazione a cascata), etichettare gli "sprint" delle pietre miliari, avere una mischia giornaliera e far finta di fare Agile.

    
risposta data 14.03.2016 - 18:18
fonte
1

I'd like to see all the sprints laid out between now and release

Sembra che tu stia facendo scrum, nel qual caso rilasci (o puoi rilasciare) alla fine di ogni sprint. Se per rilascio , vuoi veramente dire che il progetto è stato completato, allora non dovresti guardare i tuoi sprint in questo modo.

Dovresti avere una roadmap dal proprietario del prodotto che è condivisa con tutti. Questo dovrebbe riguardare le caratteristiche di alto livello o la direzione del prodotto. Le uniche linee temporali incluse dovrebbero essere obiettivi generali per aiutare a identificare le priorità. L'essenza dell'agile è sapere che le cose cambieranno e che quelle linee temporali non sono reali.

Non dovresti guardare più avanti di uno sprint, dato che questo sprint potrebbe cambiare tutto. Probabilmente avrai un'idea del prossimo sprint, dal momento che saprai cosa è rimasto in cima al backlog. Non dovresti essere preoccupato di pianificare qualsiasi sprint oltre a quello.

    
risposta data 14.03.2016 - 22:19
fonte