Come rappresentare un progetto agile per le persone focalizzate sulla cascata [chiuso]

Al nostro team è stato chiesto di rappresentare i nostri sforzi di sviluppo in un piano di progetto. Nessuno è scontento del nostro lavoro o mette in discussione la nostra capacità di fornire, stiamo solo partecipando a una richiesta di bestiame IT per i piani di progetto. Il problema è che siamo un team agile e non abbiamo pensato al nostro lavoro in termini di un piano di progetto formale.

Sebbene abbiamo un'idea generale di ciò su cui stiamo lavorando, non siamo sicuri al 100% fino a quando non pianificheremo un'iterazione. Fino ad ora il nostro team ha operato in gran parte nel vuoto e non è stato richiesto di presentare la nostra metodologia o metrica a soggetti esterni. Seguiamo la maggior parte delle pratiche sposate nella programmazione estrema .

Teniamo riunioni di pianificazione trimestrali per avere un'idea generale delle storie su cui lavoreremo per un quarto. Detto questo, le nostre storie sono documentate su schede 3x5 e sono stimate solo all'inizio dell'iterazione in cui verranno lavorate. Dopo la stima documentiamo la storia in Team Foundation Sever . Durante un'iterazione, alleghiamo il codice delle storie e le segnaliamo come completate una volta terminate. Da questi dati siamo in grado di generare grafici di burn down e velocità. Soprattutto, conosciamo la nostra velocità media per un'iterazione che ci impedisce di mordere più di quanto possiamo masticare.

Non sto cercando di modificare il modo in cui facciamo lo sviluppo, ma voglio presentare le nostre attività di sviluppo in un rapporto che capirà solo chi ha familiarità con la cascata. In Che aspetto ha un piano di progetto agile , Kent McDonald fa un buon lavoro nel delineare le differenze tra i piani di progetto agili e quelli a cascata. Specifica le differenze tra i proiettili di consumo:

• Un piano di progetto agile si basa sulle funzionalità
• Un piano di progetto Agile è organizzato in iterazioni
• Un piano di progetto Agile ha diversi livelli di dettaglio a seconda del periodo di tempo
• Un piano di progetto Agile è di proprietà del team

Essere in grado di spiegare le differenze è grandioso, ma come presentare al meglio i dati?

Mostra loro il manifesto agile a metà corsa .

Ti dice sicuramente di cosa tratta il sistema Agile confrontandolo con i metodi a cascata :

Individui e interazioni su processi e strumenti
e disponiamo di processi e strumenti obbligatori per controllare il modo in cui tali individui (preferiamo il termine "risorse") interagiscono

Software funzionante su documentazione completa
purché tale software sia ampiamente documentato

La collaborazione con i clienti per la negoziazione di contratti
entro i limiti di contratti rigorosi, ovviamente, e soggetta a rigoroso controllo delle modifiche

Rispondere al cambiamento seguendo un piano a condizione che sia in atto un piano
dettagliato per rispondere al cambiamento ed è seguito esattamente

Ho dovuto farlo una volta. Il team voleva fare Agile, il cliente voleva (e comprendeva Agile), una terza parte esterna (chiamarli "Revisori"), voleva vedere i rapporti su Waterfall.

Un motivo importante per cui potremmo mentire era perché alla terza parte non importava davvero, volevano solo selezionare le caselle. Se il cliente era contento e il team era contento, i "revisori" difficilmente sarebbero tornati indietro e avrebbero esaminato i rapporti che avevamo loro fornito, prima di spuntare le caselle finali.

Non farlo se la terza parte conta e REALMENTE si preoccupa che stai usando la cascata . Se i revisori dei conti sanno che sei agile e che non hanno aggiornato i loro documenti per supportarti, allora puoi mentire.

cosa fai? Bugia , ma bugia bianca.

• Sostituire le funzionalità, come requisito "Must have Feature".
• Il tuo lavoro è in Iterazioni, le iterazioni generalmente durano più di X settimane, un piano a cascata ama vedere le cose in genere in Settimane, quindi nessun grosso problema. È possibile etichettare la fine di ogni iterazione come pietra miliare. Le pietre miliari sono la cascata. Le iterazioni tendono ad avere un tema (o un'epopea associata) in modo da poter attaccare il tema / titolo epico sulla pietra miliare (ad es. 21/11 Have GUI complete.)
• Calcola la tua velocità (dai grafici di burn down / up) e calcola quanto tempo rappresenta un Story Point, in media, (almeno alla tua velocità attuale), questo ti darà durate delle attività. Spesso quelli imprecisi e selvaggi, ma saranno significativi in ​​una certa misura.
• Il tuo piano ha diversi livelli di dettaglio a seconda del periodo di tempo, sostanzialmente lo stesso per la cascata. Possibilmente diverso un piano a cascata ha dettagli diversi a seconda del pubblico.

• Un piano Agile è di proprietà del Team. Un piano a cascata è di proprietà del Project Manager. È evidente che tu abbia già un Project Manager e probabilmente stanno facendo questa traduzione . Dovrebbero prendere possesso di questo documento tradotto e proteggere la squadra dal flack che potrebbe piovere su di loro a causa sua. È compito di un project manager Agile o Waterfall proteggere il team dalle distrazioni che impediranno loro di lavorare.

• Sicuramente non sai davvero cosa stai facendo nella prossima iterazione, ma sai più o meno cosa stai facendo. Hai un'idea, e ancora più ruvida l'Iterazione dopo. (Ho sentito questo chiamato Radar Iterazione). Mentire e dire che lo fai. e quando ti menti tra i denti sulla carta della storia che non è sul tuo radar di iterazione, e mettila da qualche parte. Spero che tu non debba inviare troppi aggiornamenti sul piano del progetto, o noteranno che non hai fatto ciò che hai detto che farai.

Fondamentalmente questo è un dolore. La traduzione sarà di molte ore di lavoro. Se devi farlo molto, automatizzalo.

La prima domanda da porsi è cosa vuole veramente l'azienda? Alcune aziende sono perfettamente felici di vedere gli sprint agili rappresentati / suddivisi in un diagramma di Gantt. Potrebbe non avere senso per chiunque comprenda effettivamente gli sprint e possa cambiare regolarmente, ma è familiare alle persone che lo richiedono. Quindi insieme al diagramma di Gantt, presenta il burndown, ecc.

Abbiamo vissuto qualcosa di simile e alla fine (se Agile sta funzionando) si venderà da solo (in caso contrario, perché lo stai facendo?). Le persone iniziano a capire lo "sforzo" e che una certa squadra è in grado di "bruciare" 40 punti di sforzo in uno sprint di 2 settimane e in realtà sono abbastanza bravi a stimare quei punti di sforzo. Una volta che ne vedranno i benefici, venderanno il processo al resto dell'azienda per te. Ma il punto principale è che non puoi mai, mai forzarlo su qualcuno mentre reagiranno.