Pianificazione a lungo termine e agile?

Il mio team ha recentemente completato il processo di elaborazione di un piano di quasi un anno per il nostro lavoro. Abbiamo diviso il piano in tre fasi. Ogni fase includerà un paio di lanci.

Mi chiedo, da un punto di vista agile di te, è sbagliato? Penso che non sia una cattiva idea, perché non abbiamo trascorso troppo tempo a progettare nient'altro che i primi passi. È possibile per noi cambiare direzione. Allo stesso tempo è bello che non agiamo solo con un breve termine in vista.

Avere una visione di dove deve andare il progetto è una buona cosa ^TM .

Credere che sia esattamente ciò che accadrà non lo è.

"Nella preparazione alla battaglia ho sempre scoperto che i piani sono inutili, ma la pianificazione è indispensabile."

- Dwight D. Eisenhower

L'approccio adottato dalle metodologie Agile è quello di scomporre le cose in pezzi digeribili e ri-regolare la visione dopo che ogni pezzo è stato digerito.

Ciò significa che il tuo punto di arrivo tra un anno non sarà esattamente quello che pensi ora. Tuttavia, dovresti aver affrontato tutti gli elementi di alto valore presenti nel tuo elenco e aver coinvolto e soddisfatto le parti interessate man mano che avanzi.

OK, al management è stato presentato un mito da pianificare. Spero, per amor tuo, che non ti trattengano. Perché, vista invisibile, sono disposto a scommettere che la tua squadra non realizzerà nulla di simile a ciò che dice quel piano a lungo termine. In effetti, se raggiungi la media del settore, ti perderai di circa un fattore 2. E nella maggior parte delle organizzazioni una stima, una volta data, diventa il club con cui sono liberi di batterti quanto vogliono.

Probabilmente pensi che io sia solo cinico. Dopo tutto, hai appena comunicato tempi vaghi per insiemi di funzionalità non specificati che tutti sanno che potrebbero accadere molto più lentamente o più velocemente di quanto previsto, giusto? Ci dispiace, la maggior parte di ciò può essere vero, ma non è così che le persone tendono a sentire quei numeri. Hanno ascoltato delle date e una volta pronunciata tende ad essere più solida di quanto tu abbia detto. Inoltre, se esiste una catena di comunicazione, diventerà ancora più solida. E una volta che ai clienti esterni è stato promesso qualcosa dalle vendite in base a quello che hai detto, improvvisamente scoprirai che c'è molta meno flessibilità in quei numeri di quanto dovrebbe esserci. E ti garantisco che hai sottovalutato il tempo che ci vorrà.

Con questo ovvio punto di proposito, ti consiglierò di leggere la stima del software per imparare qualcosa su come la stima del software dovrebbe davvero essere fatta. Imparerai molto su ciò che hai fatto di sbagliato e su come fare meglio la prossima volta. (Nel processo imparerai perché sono così sicuro che hai sopravvalutato quello che farai.)

Detto questo, l'agile consiste principalmente nel ridurre il processo a ciò che è appropriato per una piccola squadra. Spesso un buon modo per ridurre il processo è cercare di ridurre la pianificazione a lungo termine su larga scala a favore della pianificazione di piccole cose a breve termine. Inoltre, tende ad essere più onesto, perché non sai cosa accadrà in futuro. Tuttavia, ciò spesso non si adatta alle più grandi esigenze aziendali e, quindi, indipendentemente dal fatto che tu ti dichiari agile, a volte devi stabilire piani più lunghi.

Detto questo, ti consiglio vivamente di scoprire un fatto chiave sulle date che hai comunicato, che purtroppo probabilmente torneranno come scadenze per morderti. E questo fatto è questo. Di cosa si preoccupano le persone, la data o il set di funzionalità? Ecco cosa intendo con questo. Spesso le organizzazioni hanno date specifiche che contano. Ad esempio, fai qualcosa per una conferenza o prima della corsa delle vacanze. In quel caso, ciò che conta è rilasciare qualcosa, e non tanto se quel qualcosa è completo. Altre volte esiste una serie di funzioni che devono essere rilasciate insieme e la completezza è più importante di quando succede esattamente. Se riesci a scoprire in quale situazione ti trovi, la tua squadra sarà in una posizione molto migliore per pianificare come gestire gli (quasi) inevitabili crunch che stanno arrivando.

Va bene avere un piano fintanto che lo consideri work-in-progress e non qualcosa di scritto in pietra.

La chiave qui è di rilasciare regolarmente (almeno mensilmente), raccogliere feedback reali dai tuoi utenti e aggiornare il tuo piano in base a quel feedback.

Ciò significa che il piano cambierà quando cambia l'ambito del progetto. Questa è una buona cosa , perché significa che i tuoi utenti hanno imparato di più su ciò che vogliono.

Supponendo project-managemente agileintendevi Scrum, questo non sarebbe il modo esatto di andare.

Nella Scrumprospettiva, se hai un piano annuale, dovresti avere almeno tutti gli Sprint quanti sono i mesi in un anno. Quindi, il tuo piano di un anno sta diventando più agile poiché è modificabile tra due Sprint.

A non Sprintpuò durare più di un mese, quando l' Teamimpegno si impegna a riportare Sprint Backlog Itemslo stato di Done.

Doneè una parola importante qui, e ognuno dei Scrum Teamdeve avere una definizione di fatto, cioè dove non c'è lavoro da fare. Quando a Sprint Backlog Itemè Fatto , ciò significa che l'analisi, l'architettura e la documentazione tecnica sono scritte e che la funzionalità è stata testata a fondo (unit test, test di integrazione, test funzionali ...).

Una volta Product Backlogche gli oggetti sono stati posizionati e gli articoli hanno la priorità con le caratteristiche meno importanti in basso, e quelli più importanti in cima, il Team (degli sviluppatori) determina quanto tempo dovrebbe Product Backlog Itemimpiegare lo sviluppo di ciascuno in base alla propria esperienza. È qui che puoi determinare che il progetto richiederà un anno intero di lavoro. Considera che solo ilProduct Ownerdeve dare la priorità agli Articoli in quanto è lui che è responsabile del ritorno sull'investimento, oppure sa qual è il più importante per l'utente finale. Inoltre, il Team valuterà il tempo necessario per sviluppare completamente una funzionalità, anche se potrebbero esserci pezzi di codice riutilizzabili qua e là che potrebbero soddisfare le esigenze di questa funzionalità, vale a dire, per evitare ulteriore complessità ed essere certi che un Articolo non debba prendere più a lungo di quanto richiesto dal Team. Il Product Backlog non deve necessariamente essere perfetto! La semplice enumerazione delle storie degli utenti che possiamo pensare al sistema da sviluppare è sufficiente in quella fase del processo.

È durante il periodo in Sprint Planning Meetingcui il Team si impegnerà su ciò che sarà sviluppato per il prossimo Sprint, creando così il Sprint Backlog. Il Sprint Backlogconsiste in un sottoinsieme basato sul fatto Product Backlog Itemsche si Teamimpegna alla fine dello Sprint. Considerando ad esempio un portafoglio ordini di 50 articoli e tutti i 50 articoli richiedono un anno da eseguire, il team potrebbe voler selezionare, diciamo 5 articoli dal portafoglio ordini, e creare lo Sprint portafoglio ordini con questi 5 articoli. Questi stessi 5 articoli possono essere espansi / esplosi in più altri oggetti quando richiesto, facendo sì che il Team possa forse cambiare idea dopo la revisione e impegnarsi a fare solo 4 articoli su 5 articoli precedentemente selezionati dal Product Backlog.

Una volta terminata la riunione di pianificazione di Sprint, che può durare non più di 8 ore per uno Sprint di un mese intero, all'interno del quale il team non si impegna solo a svolgere il lavoro per gli articoli selezionati, ma pianifica su come eseguirà il lavoro in modo che tutti nel Team sappiano esattamente cosa deve fare, Sprintdeve iniziare. È importante che il Team sia interfunzionale per il bene del progetto.

Detto questo, alla fine di ogni Sprint, che dura un mese nella situazione attuale, tutti gli Articoli che l' Teamimpegno a fare devono essere un pezzo consegnabile di caratteristiche completamente funzionali destinate agli Articoli selezionati dal Portafoglio prodotti. Deve essere consegnabile, ma non è obbligatorio che venga consegnato se non ha senso farlo secondo il Product Owner.

È durante il periodo in Sprint Review Meetingcui Product Ownerè richiesto il richiamo che Teamdimostra ciò che è stato fatto durante lo Sprint, e dove deve dire perché non ha svolto, se applicabile, tutto il lavoro a cui si è impegnato. Il lavoro annullato viene quindi rimesso nel Product Backloge disponibile per il prossimo Sprint. Sicuramente questi Articoli annullati saranno inclusi nello Sprint successivo, salvo diversa indicazione da parte del Proprietario del Prodotto, nel caso in cui l'obiettivo fosse cambiato. Ma soprattutto, sebbene l'obiettivo di un sistema sia cambiato durante uno Sprint, non interromperlo a meno che non sia assolutamente necessario. Solo il Product Owner ha l'autorità di interrompere lo Sprint.

Una volta Sprint Review Meetingterminato, che dovrebbe durare non più di 4 ore per uno Sprint mensile (se ricordo bene), è tempo di arrivare al Sprint Retrospective Meeting. Il Sprint Retrospectiveè richiesto per il Teamsi verifichi in modo che esso può discutere, alla presenza del Maestro e Scrum Product Owner (opzionale) cosa è andato storto, come il team Scrum può migliorare le sue prestazioni, ecc e portare le regolazioni di conseguenza.

Quando la finestra temporale per il Sprint Retrospectiveè finita, allora Sprint Planning Meetingsi verifica il nuovo per pianificare il successivo Sprinte creare il nuovo Sprint Backlog.

Ricorda, Teamè responsabile di mantenere Daily Scrumuna riunione stand-up di 15 minuti in cui ogni membro del team risponde alle tre domande (non in quell'ordine particolare):

1. Che cosa hai fatto dall'ultimo Scrum quotidiano?
2. Cosa pensi di fare fino al prossimo Scrum quotidiano?
3. Quali sono i problemi o gli impedimenti che hai riscontrato dall'ultimo Scrum quotidiano?

Non Scrum Masterè obbligato a essere presente, ma è tenuto ad assicurare che il Team si riunisca al Daily Scrum e che i Membri rispondano correttamente alle tre domande.

Lo Scrum Master è responsabile del rispetto delle Scrum Rules da parte degli altri membri dello Scrum Team (Scrum Master, Product Owner e Team).

Alla fine, seguendo queste semplici regole, il tuo team di sviluppo diventerà agile. L'agilità è la capacità di recuperare qualsiasi cambiamento il più rapidamente possibile per il Team, ovvero alla fine di ogni Sprint, dove può essere a conoscenza delle modifiche apportate dal Product Owner al Product Backlog. In caso di disastro totale e completo cambio di orientamento, il massimo perso che l'azienda deve assorbire è un mese di sviluppo, il che è abbastanza trascurabile, considerando che ci sono circa solo 20 giorni lavorativi in ​​un mese.

Per ulteriori informazioni dettagliate su Scrum e lo sviluppo di software Agile, consultare Scrum.org e la relativa Guida di Scrum .

Bene, questa è piuttosto una risposta! Spero che questo ti aiuti almeno nella gestione del tuo progetto.

EDIT # 1

Mentre prevedi di eseguire tre o quattro fasi, come lo chiami, è più probabile che il tuo Team perda l'attenzione dal punto di vista obiettivo primario. Se dopo solo il primo trimestre dimostrerai ciò che il tuo Team ha fatto, potrebbero esserci alcune importanti modifiche da apportare che richiedono importanti riprogettazioni e ripensamenti sull'architettura del tuo software, riprendendolo forse per oltre 20 giorni di lavoro persi. Il principio di agilità è quello di essere in grado di tenere il passo con i cambiamenti non appena si verificano, o appena è possibile entro un ragionevole lasso di tempo, ovvero, per Scrum, la casella temporale di uno Sprint.

1. Penso che dovresti avere quanti più lanci puoi. L'unico feedback / metrica reale per i progressi nello sviluppo del software è il codice distribuito in produzione. Quindi, qualunque sia il processo che usi, più spesso distribuisci dal vivo, più agile ottieni. Vale a dire, ricevi feedback reali da utenti reali prima e sei in grado di adattarti prima.

2. Anche se non dovresti fare Big Design Up Front , penso che sia bello pensare al quadro generale ogni volta che stai per regolare e riempire il backlog, sia per Scrum (per il prossimo sprint) sia per Kanban / flow (quando c'è spazio nel limite WIP). Se consideri l'intero (prodotto, servizio, ecc.), È più facile considerare quali elementi di lavoro ti daranno più valore in seguito.

3. Tieni presente che il quadro generale cambia. Ogni volta che si considera l'arretrato, la regolazione delle priorità ecc., Si considerano anche le modifiche al quadro generale. Le cose cambiano nel tempo, comprese le esigenze di clienti specifici e persino interi mercati. Il tuo quadro generale dovrebbe riflettere questo in modo che le tue priorità possano essere allineate con la realtà ogni volta che riempi l'arretrato, e non solo all'inizio quando fai il piano.

Insomma, penso che diventi più agile più controlli e ti adatti.

La pianificazione di immagini di grandi dimensioni non richiede così tanto tempo ed è fondamentale che i grandi progetti abbiano in mente l'immagine generale quando si definiscono gli sprint, altrimenti le scorciatoie prese in uno sprint potrebbero creare problemi in seguito.

Dovresti:

1. Avere un piano generale (preferibilmente senza scadenze allegate), che si evolverà man mano che procedi.

2. Quando si definisce uno sprint, ci si assicura che lo sprint sia coerente con il quadro generale. Questo non significa sempre che cambi la tua idea di ciò che è desiderato per lo sprint. A volte scoprirai, quando definirai uno sprint, che il tuo quadro generale dovrebbe essere regolato. In un modo o nell'altro il piano generale e lo sprint dovrebbero essere coerenti tra loro andando nello sprint.

3. Il piano generale deve essere modificato man mano che procedi. Imparerai le cose mentre lavori. Sorgeranno nuove opportunità, emergeranno punti di conflitto nel piano. Puoi regolare il piano generale al volo, mentre procedi. Ma quasi sempre dovresti rivederlo tra gli sprint - per incorporare le lezioni dell'ultimo sprint e assicurarti che il prossimo sprint sia in armonia con il quadro generale.

Penso che sia meglio se l'arretrato e il grande piano di progetto sono strutture separate. Il grande proprietario del progetto mantiene il piano generale in un formato gerarchico per mantenere il contesto, quindi è possibile estrarre funzionalità / attività per alimentare il backlog, che a sua volta alimenterà lo sprint successivo.

Il backlog, a differenza del piano generale, può essere aggiunto da altri membri del team. Spetta al principale proprietario del progetto assicurarsi che gli elementi del backlog e il piano di immagine generale rimangano in armonia - a volte regolando l'elemento di backlog e talvolta il piano di immagine grande.

Questo metodo mantiene il potere di agilità e il potere di allineare tutti gli elementi del progetto nel miglior modo possibile in un determinato momento attraverso una pianificazione generale.

Jim

Aggiungerò qui la forma abbreviata del mio rant anti-Agile.

Agile può essere molto distruttivo per grandi progetti, specialmente quando si costruiscono librerie e framework che saranno alla base dello sviluppo futuro. Una preoccupazione molto importante nelle prime fasi è "il mio design supporterà le funzionalità che dobbiamo offrire nel prossimo anno?". La maggior parte delle strategie Agili non consente questo tipo di lungimiranza e quindi vengono creati punti di fallimento del progetto.

Sono un po 'dolorante su questo punto perché sono stato solo bruciato da questo me stesso. Stiamo riscrivendo alcune delle nostre librerie principali. Le prime fasi sono state fatte e hanno raggiunto gli obiettivi per i loro sprint. È tutto molto agile. Quindi, sono stato coinvolto per aggiungere alcune funzionalità di caricamento dinamico. Tuttavia, sono stato bloccato per circa sei settimane perché ciò che è stato scritto prima presupponeva che non ci sarebbe mai stato un caricamento dinamico, ho perso molto tempo a riscrivere e lavorare su ciò che era già lì. La parte peggiore è che il caricamento dinamico era nelle specifiche all'inizio; se il lavoro iniziale avesse tenuto conto di tutti i requisiti futuri e fatto il "grande lavoro di progettazione in anticipo" che le pratiche agili considerano male, avrei potuto implementare la mia funzione in pochi giorni.

La lezione è, usa l'agile per le piccole cose che sei disposto a buttare via. A volte può essere fantastico. Tuttavia, non è l'unico vero modo di sviluppo software. Quando si scrive un codice di base ad alto rischio o che avrà una lunga durata, fare il grande progetto.