Come Implementare la Metodologia Agile PDF

**Come implementare la Metodologia Agile** Implementare e consegnare un progetto con la metodologia Agile è come orchestrare un concerto: ogni elemento deve suonare al momento giusto, in armonia con gli altri. Non si tratta solo di seguire regole e processi, ma di adottare una mentalità, un modo d...

**Come implementare la Metodologia Agile** Implementare e consegnare un progetto con la metodologia Agile è come orchestrare un concerto: ogni elemento deve suonare al momento giusto, in armonia con gli altri. Non si tratta solo di seguire regole e processi, ma di adottare una mentalità, un modo di lavorare che valorizza la collaborazione, la flessibilità e la consegna continua di valore. In questo articolo ti guiderò passo dopo passo attraverso i principi fondamentali, le pratiche chiave e le sfide che potresti incontrare durante l'implementazione di Agile. **Capire Agile: Non Solo una Serie di Regole** Prima di addentrarci nella pratica, chiariamo una cosa: Agile non è un rigido schema di lavoro, ma un insieme di valori e principi. È descritto nel famoso Manifesto Agile, che si basa su quattro valori fondamentali: 1. Individui e interazioni più che processi e strumenti. 2. Software funzionante più che documentazione esaustiva. 3. Collaborazione con il cliente più che negoziazione dei contratti. 4. Rispondere al cambiamento più che seguire un piano. Attenzione però: questo non significa che processi, documentazione o piani siano inutili! Significa che, se dovessi scegliere tra rigidità e flessibilità, Agile punta sempre sulla seconda. Vediamo spesso, e vedrete spesso, come molti team usano le iterazioni, in particolare quelle di 2 settimane, perché l\'iterazione richiede una dimostrazione e una retrospettiva alla fine. Tuttavia, il team non ha bisogno di iterazioni per fare una retrospettiva. I membri del team possono decidere di fare una retrospettiva in questi momenti chiave: Quando il team completa una release o spedisce qualcosa. Non deve essere un incremento monumentale. Può essere qualsiasi release, non importa quanto piccola. Quando sono trascorse più di qualche settimana dalla precedente retrospettiva. Quando il team sembra bloccato e il lavoro completato non scorre nel team. Quando il team raggiunge qualsiasi altra Milestone di progetto. I team traggono vantaggio dall\'allocazione di tempo sufficiente per imparare, sia da una retrospettiva provvisoria che da una retrospettiva di fine progetto. I team devono imparare a conoscere il loro prodotto di lavoro e il processo di lavoro. Ad esempio, alcuni team hanno difficoltà a finire il lavoro. Quando i team pianificano abbastanza tempo, possono strutturare la loro retrospettiva per raccogliere dati, elaborarli e decidere cosa provare in seguito come esperimento. Innanzitutto, una retrospettiva non riguarda la colpa; la Retrospettiva è un momento in cui il team impara dal lavoro precedente e apporta piccoli miglioramenti. La Retrospettiva riguarda l\'analisi dei dati qualitativi (i sentimenti delle persone) e quantitativi (le misurazioni), quindi l\'utilizzo di tali dati per trovare le cause profonde, progettare contromisure e sviluppare piani d\'azione. Il team di progetto potrebbe ritrovarsi con molti elementi di azione per rimuovere gli impedimenti. Considerare di limitare il numero di elementi di azione alla capacità del team di affrontare il miglioramento nell\'iterazione o nel periodo di lavoro successivi. Cercare di migliorare troppe cose contemporaneamente e non finirne nessuna è molto peggio che pianificare di completare meno elementi e completarli con successo tutti. Quindi, quando il tempo lo consente, il team può lavorare sulla successiva opportunità di miglioramento nell\'elenco. Quando il team seleziona i miglioramenti, decidere come misurare i risultati. Vedrete allore che nel periodo di tempo successivo, dovrete misurare i risultati per convalidare il successo o il fallimento di ogni miglioramento. Un facilitatore del team li guida attraverso un\'attività per classificare l\'importanza di ogni elemento di miglioramento. Una volta che il team ha classificato gli elementi da migliorare, il team sceglie il numero appropriato su cui lavorare per l\'iterazione successiva (o aggiunge lavoro al flusso, se basato sul flusso). **Come Implementare Agile: Il Percorso Pratico** Implementare Agile richiede più di un semplice cambio di strumenti: è un cambiamento culturale. Come abbiamo visto precedentemente, riassumiamo come fare: **1. Forma il tuo team e crea una cultura Agile** Il cuore di Agile sono le persone. Per partire, è essenziale: - **Creare team multifunzionali**: unisci persone con competenze diverse, in modo che possano lavorare autonomamente per completare le attività. In un team Agile ideale, ci sono sviluppatori, tester, designer, esperti di business e magari anche un rappresentante del cliente. - **Stabilire ruoli chiave**: nella maggior parte delle implementazioni Agile, troverai tre ruoli principali: - **Product Owner**: il rappresentante del cliente. È responsabile di definire le priorità e assicurare che il team lavori sulle cose più importanti. - **Scrum Master (o Agile Coach)**: un facilitatore che rimuove ostacoli e aiuta il team a lavorare in modo efficiente. - **Team di sviluppo**: le persone che fanno il lavoro \"pratico\" per consegnare valore. La cultura Agile si basa su trasparenza, fiducia e collaborazione. E adesso sappiamo che è necessario crea un ambiente dove tutti si sentano liberi di condividere idee, fare domande e persino commettere errori (che, se gestiti bene, sono una fonte di apprendimento). **Preparazione del Backlog** Il Backlog è l\'elenco ordinato di tutto il lavoro, presentato in forma di storia, per un team. Non è necessario creare tutte le storie per l\'intero progetto prima che il lavoro inizi, solo quelle sufficienti per comprendere la prima versione a grandi linee e poi elementi sufficienti per l\'iterazione successiva. I product owner (o un product owner value team che include il product manager e tutti i product owner rilevanti per quell\'area del prodotto) potrebbero produrre una roadmap del prodotto per mostrare la sequenza prevista di risultati nel tempo. Il product owner ripianifica la roadmap in base a ciò che il team produce. **Rifinizione del Backlog** Nell\'agile basato sull\'iterazione, il product owner spesso lavora con il team per preparare alcune storie per l\'iterazione successiva durante una o più sessioni nel mezzo dell\'iterazione. Lo scopo di queste riunioni è di perfezionare abbastanza storie in modo che il team capisca cosa sono le storie e quanto sono grandi le storie in relazione tra loro. Non c\'è consenso su quanto dovrebbe durare la rifinitura. C\'è un continuum di: - Rifinitura just-in-time per agile basato sul flusso. Il team prende la carta successiva dalla colonna delle cose da fare e la discute; - Molti team agile basati sull\'iterazione usano una discussione di 1 ora a metà di un\'iterazione di 2 settimane. Qui i team selezionano una durata di iterazione che fornisca loro un feedback sufficientemente frequente; - Discussioni di rifinitura multiple per team Agile basati sull\'iterazione. I team possono usarle quando sono nuovi al prodotto, all\'area del prodotto o al dominio del problema. Considerate l\'utilizzo dell\'impact mapping per vedere come il prodotto si adatta insieme. In circostanze normali, il product owner guida questo lavoro. Un Servant Leader può facilitare qualsiasi riunione necessaria come un modo per servire il progetto. Le riunioni di perfezionamento consentono al product owner di presentare idee per le storie al team e al team di apprendere le potenziali sfide o problemi nelle storie. Se il product owner non è sicuro delle dipendenze, può chiedere al team di aumentare la funzionalità per comprenderne i rischi. Esistono molti modi in cui il product owner può condurre riunioni di preparazione del backlog e di perfezionamento, tra cui ad esempio: - Incoraggiare il team a lavorare come triadi di sviluppatore, tester, analista aziendale/product owner per discutere e scrivere la storia. - Presentare il concetto generale della storia al team. Il team discute e lo perfeziona in tutte le storie necessarie. - Collaborare con il team per trovare vari modi per esplorare e scrivere le storie insieme, assicurandosi che tutte le storie siano sufficientemente piccole da consentire al team di produrre un flusso costante di lavoro completato. Considerate di riuscire a completare una storia almeno una volta al giorno. I team hanno spesso l\'obiettivo di non dedicare più di 1 ora alla settimana a perfezionare le storie per il prossimo lotto di lavoro. I team vogliono massimizzare il tempo dedicato al lavoro anziché alla pianificazione. Se il team deve dedicare più di 1 ora alla settimana alla rifinitura delle storie, il product owner potrebbe essere troppo preparato o il team potrebbe non avere alcune competenze fondamentali necessarie per valutare e rifinire il lavoro. **Daily Standup** I team utilizzano gli standup per impegnarsi reciprocamente, scoprire problemi e garantire che il lavoro scorra senza intoppi nel team. Limita il tempo dello standup a non più di 15 minuti. Il team \"cammina\" sul Kanban o sulla bacheca delle attività in qualche modo e chiunque nel team può facilitare lo standup. In Agile basato sull\'iterazione, tutti rispondono alle seguenti domande in modalità round-robin: - Cosa ho completato dall\'ultimo standup? - Cosa ho intenzione di completare da ora al prossimo standup? - Quali sono i miei impedimenti (o rischi o problemi)? Domande come queste generano risposte che consentono al team di auto-organizzarsi e di responsabilizzarsi a vicenda per il completamento del lavoro a cui si sono impegnati il ​​giorno prima e durante l\'iterazione. L\'Agile basato sul flusso ha un approccio diverso agli standup, concentrandosi sulla produttività del team. Il team valuta la lavagna da destra a sinistra. Le domande sono: - Cosa dobbiamo fare per far progredire questo lavoro? - Qualcuno sta lavorando a qualcosa che non è sulla lavagna? - Cosa dobbiamo finire come team? - Ci sono colli di bottiglia o ostacoli al flusso di lavoro? Uno degli antipattern tipicamente osservati negli standup è che diventano riunioni di stato. I team che hanno tradizionalmente lavorato in un ambiente predittivo possono tendere a ricadere in questo antipattern poiché sono abituati a fornire uno stato. Un altro antipattern tipicamente osservato negli standup è che il team inizia a risolvere i problemi quando diventano evidenti. Gli standup servono per realizzare che ci sono problemi, non per risolverli. Aggiungi i problemi a un parcheggio, quindi crea un altro incontro, che potrebbe svolgersi subito dopo lo standup, e risolvi i problemi lì. I team gestiscono i propri standup. Quando sono gestiti bene, gli standup possono essere molto utili, a condizione che la natura del lavoro del team richieda un\'intensa collaborazione. Il mio consiglio è di allenarvi a prendere una decisione consapevole su quando il team ha bisogno, o può utilizzare efficacemente, gli Standup. Un altro consiglio che desidero darvi è di incoraggiare (o incoraggiarvi a farlo voi!) un membro del team a facilitare lo standup al posto di un project manager o di un leader, per assicurarti che non si trasformi in una riunione di stato, ma che venga invece utilizzata come un momento in cui il team può auto-organizzarsi e impegnarsi reciprocamente. **Dimostrazioni/Recensioni** Man mano che il team completa le funzionalità, solitamente sotto forma di user story, il team dimostra periodicamente il prodotto funzionante. Il product owner vede la dimostrazione e accetta o rifiuta le storie. Nell\'agile basato sull\'iterazione, il team dimostra tutti gli elementi di lavoro completati alla fine dell\'iterazione. Nell\'Agile, che è basato sul flusso, il team dimostra il lavoro completato quando è il momento di farlo, solitamente quando si sono accumulate sufficienti funzionalità in un set coerente. I team, incluso il product owner, hanno bisogno di feedback per decidere quanto presto chiedere feedback sul prodotto. Come linea guida generale, dimostra qualsiasi cosa il team abbia come prodotto funzionante almeno una volta ogni 2 settimane. Questa frequenza è sufficiente per la maggior parte dei team, così i membri del team possono ottenere feedback che impediscono loro di andare nella direzione sbagliata. È anche abbastanza frequente da consentire ai team di mantenere lo sviluppo del prodotto sufficientemente pulito per creare un prodotto completo tutte le volte che vogliono o hanno bisogno. Una parte fondamentale di ciò che rende agile un progetto è la consegna frequente di un prodotto funzionante. Un team che non dimostra o rilascia non può imparare abbastanza velocemente e probabilmente non sta adottando tecniche agili. Il team potrebbe aver bisogno di ulteriore coaching per consentire consegne frequenti. **Pianificazione per Agile basata sulle Iterazioni** La capacità di ogni team è diversa. La dimensione tipica della storia di ogni product owner è diversa. I team considerano la dimensione della loro storia in modo da non provare a impegnarsi in più storie di quante ne siano in grado di completare in un\'iterazione. Quando le persone non sono disponibili (ad esempio, per festività, ferie o qualsiasi cosa che impedisca alle persone di partecipare al set di lavoro successivo), il product owner capisce che il team ha una capacità ridotta. Il team non sarà in grado di completare la stessa quantità di lavoro completata nel periodo di tempo precedente. Quando i team hanno una capacità ridotta, pianificheranno solo il lavoro che soddisfa tale capacità. I team stimano cosa possono completare, che è una misura della capacità. I team non possono prevedere con il 100% di certezza cosa possono consegnare, poiché non possono conoscere l\'imprevisto. Quando i product owner riducono le storie e i team vedono i progressi sotto forma di un prodotto finito, i team apprendono cosa sono in grado di fare per il futuro. I team agili non pianificano solo una volta in un singolo blocco. Al contrario, i team agili pianificano un po\', realizzano, imparano e poi ripianificano un po\' di più, in un ciclo continuo. Pensate se e quando attirare l'attenzione del team sull'antipattern e aiutarlo a scoprire come migliorare i propri Standup. **Esecuzione di pratiche che aiutano i Team a creare Valore** Se il team non presta attenzione alla qualità, presto diventerà impossibile rilasciare qualsiasi cosa rapidamente. Le seguenti pratiche tecniche, molte delle quali provengono da eXtreme Programming (XP), possono aiutare il team a fornire alla massima velocità: - Integrazione continua. Eseguire l\'incorporazione frequente del lavoro nel tutto, indipendentemente dal prodotto, quindi eseguire nuovamente il test per determinare che l\'intero prodotto funzioni ancora come previsto. - Test a tutti i livelli. Utilizzare test a livello di sistema per informazioni end-to-end e test unitari per i componenti di base. Nel frattempo, capire se è necessario un test di integrazione e dove. I team trovano utile il test di fumo come primo sguardo per vedere se il prodotto di lavoro è buono. I team hanno scoperto che decidere quando eseguire test di regressione e quali li aiuta a mantenere la qualità del prodotto con buone prestazioni di build. I team Agile hanno una forte preferenza per i test automatizzati in modo da poter creare e mantenere uno slancio di consegna. - "Sviluppo basato sui test di accettazione" (ATDD). - In ATDD, l\'intero team si riunisce e discute i criteri di accettazione per un prodotto di lavoro. Quindi il team crea i test, che consentono al team di scrivere solo il codice e i test automatizzati necessari per soddisfare i criteri. Per i progetti non software, considera come testare il lavoro man mano che il team completa blocchi di valore. - "Sviluppo basato sui test" (TDD) e sviluppo basato sul comportamento (BDD). Scrivere test automatizzati prima di scrivere/creare il prodotto aiuta effettivamente le persone a progettare e a prevenire gli errori. Per i progetti non software, considera come \"testare\" i progetti del team. I progetti hardware e meccanici spesso utilizzano simulazioni per test intermedi dei loro progetti. - "Spike" (ricerca o esperimenti con limiti di tempo). I picchi sono utili per l\'apprendimento e possono essere utilizzati in circostanze quali: stima, definizione dei criteri di accettazione e comprensione del flusso dell\'azione di un utente attraverso il prodotto. I picchi sono utili quando il team ha bisogno di apprendere un elemento tecnico o funzionale critico. L'Agile per mette di scoprire, e di gestire, come le Iterazioni e gli Incrementi aiutino i Team a fornire un prodotto funzionante. Le iterazioni aiutano un team a creare una cadenza per la consegna e molti tipi di feedback. I team producono incrementi di valore per la consegna e il feedback. La prima parte di questa consegna è una dimostrazione. I team ricevono feedback su come il prodotto appare e funziona tramite una demo. I membri del team esaminano retrospettivamente per vedere come possono ispezionare e adattare il loro processo per avere successo. Le dimostrazioni o le revisioni sono una parte necessaria del flusso di progetto agile. Pianificate sempre la dimostrazione in modo appropriato per la cadenza di consegna del team. Un altro prezioso reminder che voglio condividere con voi è che gli approcci Agile sono nati dall\'esigenza di risolvere problemi associati ad alti tassi di cambiamento, incertezza e complessità nei progetti. Grazie a queste origini, contengono una varietà di strumenti e tecniche per gestire problemi che presentano problemi negli approcci predittivi. Per questo motivo i team dovrebbero fare demo spesso per ottenere feedback e mostrare i progressi. Incoraggiate anche voi il PMO e le altre parti interessate a guardare le demo in modo che le persone che decidono sul portfolio di progetti possano vedere i progressi effettivi.