Agile Project Management - LC90.99B. Team Scrum (gruppo di progetto)

Transcript

1 Che Cosa è SCRUM L interesse verso il project management Agile è unanimemente condiviso. Anche chi non è direttamente committed dovrà avvicinarsi alla nuova terminologia e la filosofia sottostante. Per apprendere la terminologia Agile conviene studiare SCRUM - il tool Agile più diffuso. Le definizioni e la terminologia che seguono sono condivise dai massimi guru della disciplina, come Mike Cohn, autore di Agile Estimating and Planning che ha ispirato questo elaborato a beneficio di coloro che intendono affrontare la certificazione Agile PMI-ACPsm. Scrum, forse il processo Agile più diffuso nello sviluppo software, sta diventando un "general-purpose project management framework utilizzabile anche in altri settori su progetti urgenti, complessi e innovativi. I progetti Scrum procedono con iterazioni dette sprint che durano da 2 a 4 settimane. Perciò, qualsiasi progetto complesso, innovativo e urgente può essere affrontato con un approccio Agile-SCRUM. Team Scrum (gruppo di progetto) Un Team Scrum composto solitamente da 5 a 9 persone, può raggiungere anche le centinaia di addetti e può essere anche di una sola persona. Con Scrum non ci sono più le figure tradizionali dello sviluppo software come: programmatori, designer, tester o architetti, ma tutti lavorano insieme per realizzare il lavoro promesso in ogni sprint, convinti di essere tutti sulla stessa barca. Il Product Owner rappresenta gli utenti, i clienti e altri soggetti coinvolti nel processo. Lo ScrumMaster è responsabile di garantire che il team utilizzi correttamente il processo eliminando eventuali ostacoli e proteggendo il team dalla pressione del Product Owner. Scrum, Il Product Backlog è la lista di lavori desiderati o di modifiche necessarie al prodotto. All inizio di ogni sprint, in una riunione di pianificazione, il product owner illustra i primi elementi del backlog al team, il quale decide quale lavoro eseguire durante lo sprint successivo, spostandolo dal product backlog allo sprint backlog che costituisce la lista dei task che il team promette di realizzare nel prossimo sprint. Ogni giorno tutto il team partecipa ad una riunione veloce detta Daily Sprint per contestualizzare il lavoro del giorno e mantenersi allineati. Alla fine di ogni sprint, il team espone ciò che ha realizzato in una sprint review meeting. Si tratta di una demo informale di ciò che è stato realizzato durante lo sprint. Non sono ammesse slide PowerPoint, la riunione non deve diventare un task né una distrazione dal processo. Sempre alla fine di ogni sprint il team esegue uno sprint retrospective per riflettere su come sta funzionando il processo Scrum e cosa cambiare per lavorare meglio. Il termine backlog viene utilizzato con due accezioni: Product backlog - lista di dispositivi (feature) che dovrà avere il prodotto. Sprint backlog - lista di task da eseguire in uno sprint. Mutuato dal Rugby, il termine SCRUM indica un gruppo di persone che si spinge per agguantare la palla lanciata dall arbitro. Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 1

2 Rappresentazione Visuale Mike Cohn rappresenta l intero processo Scrum con il seguente grafico: Il grafico contiene gli elementi essenziali del processo Scrum. A sinistra vediamo la product backlog con le relative priorità stabilite dal product owner, ciò che si conosce alla data. All inizio di ogni sprint, il team stabilisce il lavoro da eseguire durante lo sprint, creando lo sprint backlog ossia la lista dei task dello sprint in corso con le rispettive stime delle durate. Ogni giorno, il team discute l avanzamento e gli ostacoli incontrati, nel Daily Scrum Meeting. Alla fine di ogni sprint, il team produce un potenziale rilascio di prodotto. Il Daily Scrum Meeting E una riunione giornaliera, alla stessa ora, di massimo 15 minuti per condividere il lavoro da eseguire durante il giorno con la discussione ridotta all essenziale: Daily Scrum. Ecco come sdrammatizza questo impegno giornaliero Mike Cohn: There is an old joke in which a chicken and a pig are talking and the chicken says, "Let's start a restaurant." The pig replies, "Good idea, but what should we call it?" "How about 'Ham and Eggs'" says the chicken. "No thanks," says the pig, "I'd be committed, you'd only be involved. The joke is meant to point out the difference between those who are committed on a project and those who are only involved. Solo chi è committed ha il diritto di parlare durante un Daily Scrum. Al Daily Scrum partecipano tutti i membri del team, lo ScrumMaster ed il Product Owner. Altre figure interessate possono partecipare solo se si limitano ad ascoltare. Aprire il Daily Scrum agli uditori è un modo molto efficace per informare gli altri stakeholder sullo stato del progetto. Deve essere chiaro che non si tratta di una riunione per risolvere problemi ed eventuali issue sollevate devono essere trattate offline dagli interessati dopo la riunione. Durante la riunione ogni partecipante risponde alle seguenti tre domande: 1. Cosa hai fatto ieri? 2. Cosa farai oggi? 3. Vedi ostacoli al lavoro da fare oggi? Concentrandosi su quello che ognuno ha fatto ieri e cosa farà oggi, il team raggiunge una notevole comprensione del lavoro fatto e di quello rimanente. Il Daily Scrum Meeting non è una riunione di revisione dove il manager raccoglie informazioni sulle attività in ritardo, invece, si tratta di un incontro dove i membri del team prendono impegni fra loro. Se uno si alza e dice oggi finisco la definizione del database, tutti sapranno che domani quel signore dirà se ha finito di definire il database o meno. In pratica, le persone prendono impegni di fronte a tutto il gruppo di lavoro. Se sorge un problema che impedisce di realizzare un attività, lo ScrumMaster ha la Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 2

3 responsabilità di risolverlo il prima possibile. Se lo ScrumMaster non è in grado di risolvere una issue tecnica, deve individuare chi lo potrà fare velocemente al posto suo. Le tre domande del Daily Scrum possono riguardare le singola persona oppure singole storie, se le persone hanno in carico più storie e non sono in grado di parlare di quelle non ancora in lavorazione. Questo è un dilemma di tutti i team Scrum: task o story? Bisogna essere precisi. Il Product Backlog Il Product Backlog è la lista delle cose da fare con una breve descrizione delle funzionalità desiderate. Non è necessario documentare in anticipo tutti i requisiti, ma il team ed il product owner iniziano a scrivere ciò che risulta più facile ed evidente al momento. Meglio che niente come primo sprint! Il backlog inizia a crescere man mano che l utente racconta altri dettagli (della sua story), aggiungendo: dispositivi, difetti da colmare, lavoro tecnico, conoscenze da acquisire, etc. Le User Stories sono l insieme di brevi descrizioni delle funzionalità desiderate raccontate dal punto di vista e prospettiva dell utente. Una volta costituito il product backlog di progetto, il product owner stabilisce le priorità da applicare durante lo sprint planning meeting. Il team valuta e determina quali componenti potrà realizzare nel successivo sprint e sposta i componenti prescelti dal product backlog allo sprint backlog, come illustrato nella figura precedente. Così come un work package della WBS (work breakdown structure) viene scomposto in una o più attività nel project management tradizionale, anche con Scrum una User Story inserita nel product backlog diventa uno o più task dello sprint backlog. Praticamene, il team parte dall elemento del product backlog con priorità più alta e si ferma all ultimo che ritiene di poter inserire in quello sprint. Può accadere che selezioni anche degli elementi con priorità più bassa, saltandone altri, se questi ultimi sono collegati a quelli con priorità più alta. Il Product Owner Il product owner è uno stakeholder chiave del progetto che deve saper trasmettere al team la visione di ciò che bisogna sviluppare: agisce sul product backlog e la lista delle funzionalità da realizzare. Questa figura deve avere chiaro le esigenze dell utente, la situazione del mercato, cosa fa la concorrenza, il trend futuro del tipo di applicazione che sta sviluppando. Sebbene il product owner stabilisca le priorità degli elementi del product backlog, il team decide, autonomamente, cosa realizzare in uno sprint. Il product owner non ha il potere di dire cosa deve fare il team, ma può influenzarlo, ovviamente. Il suo compito è motivare il team con propositi chiari. I membri del team sanno cosa sono in grado di fare e scelgono su quali user stories impegnarsi, partendo da quelle con priorità più alta. In cambio il product owner si impegna a non proporre nuovi requisiti su quelle stories durante lo sprint. Nuovi requisiti sono ammessi, anzi sono incoraggiate le richieste di modifiche, ma solo fuori dallo sprint in corso. Una volta che il team inizia uno sprint resta maniacalmente concentrato sul suo goal. Release Burndown charts In un progetto Scrum, il team traccia l avanzamento di un piano di rilascio aggiornando il relaese burndown chart alla fine di ogni sprint. L asse orizzontale del grafico indica gli sprint, l asse verticale il lavoro rimanente all inizio di ogni sprint. Il lavoro rimanente può essere espresso in qualsiasi unità di misura: story points, ideal days, team days e così via. Mike Cohn dichiara di preferire gli story points nel libro Agile Estimating and Planning. Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 3

4 In questo burndown chart, il team ha avviato un progetto di 11 sprint da 2 settimane l uno con 200 story points. Il primo sprint è andato bene, lasciando 180 story points in coda. Nel secondo sprint il lavoro rimanente aumenta di nuovo. Forse è stato aggiunto altro lavoro o il team ha cambiato qualche stima. Dal terzo sprint in poi il progetto è andato bene. Il lavoro rimanente decresce regolarmente. Durane lo sprint 7 c è stato un rallentamento subito recuperato. Questo tipo di burndown chart funziona molto bene in molte situazioni e con molti team, però, ci possono essere delle complicazioni se il progetto riceve troppe richieste di modifiche. Il tipico burndown chart mostra la stima del lavoro rimanente sempre decrescente, ma nella realtà non è sempre così. Immaginiamo che il team pensava di ridurre il lavoro di 40 ore nel primo sprint ed invece lo ha ridotto solo di 10. Il team è stato più lento del previsto oppure è stato aggiunto altro lavoro? Bisogna chiarire queste situazioni per non perdere il controllo del progetto. Ecco un esempio: Il fenomeno delle richieste di modifiche può essere evidenziato, utilizzando anche il quadrante sotto l asse X. Nell esempio sopra vediamo un burndown chart con 175 story points iniziali, di cui 25 realizzati in sprint 1, scendendo a 150 story points a inizio sprint 2 e poi a 120 a inizio sprint 3. Come si vede dal grafico, la parte superiore delle barre si riduce del numero di story points realizzati ad ogni sprint. Però se viene aggiunto del lavoro, come a inizio sprint 4, il nuovo lavoro deve essere rappresentato sotto l asse X per evidenziare che sono intervenute delle richieste di modifiche e migliorare la lettura dell intero grafico. A inizio sprint 4, in realtà rimangono 135 story points, dove, però, 40 story points sono stati appena aggiunti e sono quelli sotto l asse X, mentre sopra rimangono i 95 story points come stimato inizialmente. Prima dell avvio di sprint 6 il product owner ha eliminato del lavoro. Anche le riduzioni di lavoro vengono rappresentate sotto l asse X come si vede da sprint 6. Questo approccio consente di veder decrescere il lavoro iniziale di sprint in sprint e di evidenziare le variazioni del carico di lavoro in corso d opera, creando qualche difficoltà nel predire la data di ultimazione del progetto. Lo ScrumMaster Lo ScrumMaster è responsabile del corretto utilizzo del processo Scrum da parte del team. E un allenatore (coach) che aiuta il team a dare il meglio. Spesso viene chiamato anche process owner in contrapposizione a product owner. Lo ScrumMaster aiuta il team a fornire la massima prestazione, rimuovendo eventuali ostacoli, moderando le riunioni e lavorando sul product owner affinché il product backlog sia sempre aggiornato e pronto per lo sprint successivo. Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 4

5 Questo ruolo viene ricoperto di solito da un project manager o un team leader, ma può essere ricoperto da chiunque sia in grado di proteggere il team di lavoro. Per protezione si intende non fargli subire le pressioni del product owner che li potrebbe sovraccaricare di lavoro. Il team va protetto dal product owner, ma anche dalla propria compiacenza. Il team potrebbe accontentarsi, ritenendosi soddisfatto, dei primi successi facili, per cui potrebbe smettere di cercare altre opportunità di miglioramento. Lo ScrumMaster deve prevenire questo rischio, da un lato, frenando la pressione del product owner quando il team è sovraccarico e dall altro chiedendogli più lavoro quando il team è meno impegnato. Il ruolo di ScrumMaster può apparire contraddittorio perché pur curando gli interessi del team, non ha nessuna autorità su di esso, invece ha molta autorità sui processi. In pratica non ha voce in capitolo sulle persone, ma può determinare come deve essere organizzato uno sprint. Lo ScrumMaster è simile ad un personal trainer che aiuta il team a seguire correttamente le regole Scrum, lo motiva ed evita che si lamenti saltando i passi più pesanti, sebbene abbia poca autorità. Lo ScrumMaster non ha autorità impositiva, ma ha il compito di ricordare al team gli obiettivi da raggiungere e come il team stesso ha promesso di raggiungerli. La poca autorità dello ScrumMaster è garantita dal comportamento del team di progetto. Uno ScrumMaster non può assegnare del lavoro ai membri del team, ma può decidere di modificare dei processi. Perciò con questa autorità limitata, lo ScrumMaster ha più difficoltà di un normale project manager. Il project manager tradizionale può dire fai questo, perché l ho deciso io, invece lo ScrumMaster si limita a verificare che vengano seguiti i processi Scrum. Secondo Mike Cohn un buon ScrumMaster deve avere questi sei attributi: 1. Responsabile 2. Umile 3. Collaborativo 4. Impegnato 5. Influente 6. Competente Il Team Scrum I gruppi di lavoro Scrum non comprendono i tradizionali ruoli di ingegneri del software come: programmatori, designer, tester o architetti. Ognuno lavora per completare, entro la fine dello sprint, il lavoro che ha preso in carico. In questo modo il team sviluppa un forte cameratismo ed il senso di essere sulla stessa barca. Di solito, il team Scrum è composto da 5 a 9 persone e invece di tendere a creare team numerosi, Scrum tende a creare team di team. Con la tecnica Scrum of Scrum ogni team partecipa con una sua persona alla riunione che coordina il lavoro di più team; riunioni analoghe al Daily Scrum Meeting, ma non necessariamente con la stessa frequenza giornaliera. Ecco come funziona la tecnica dello Scrum of Scrum, arrivando fino a 243 persone nel seguente esempio. Ogni cella della figura rappresenta 1 di 9 persone del team Scrum. Una persona di ogni team partecipa allo Scrum of Scrum per coordinare il lavoro sopra il suo team. Poi da questo team di 9 persone viene scelta un altra persona per partecipare allo Scrum of Scrum of Scrum. Sprint Backlog Lo sprint backlog è la lista dei task identificati dal team Scrum durante un sprint planning. Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 5

6 Nel corso dello sprint planning il gruppo di lavoro discute alcuni elementi del product backlog detti user stories per stabilire i task necessari al prossimo sprint e per stimarne le durate per realizzarli. I membri del team decidono gli elementi e le dimensioni del backlog, essendo gli unici ad impegnarsi a realizzare quelle attività. Lo sprint backlog, di solito, è una tabella tipo foglio excel, ma si può utilizzare anche software più sofisticato specifico dell ambiente Scrum o del mondo Agile in genere. Eccone un esempio: Durante lo sprint, i membri del team aggiornano lo sprint backlog man mano che assumono nuove informazioni o almeno una volta al giorno. Alcuni lo fanno nel Daily Scrum in collaborazione con lo ScrumMaster il quale ricalcola il lavoro rimanente e produce il burndown chart, come il seguente: Il team fa del suo meglio per inserire la giusta quantità di lavoro in ogni sprint. Nell esempio di burndown chart appare che il team inizialmente ha inserito troppo lavoro, circa 600 ore fino al 16/5/02. A quel punto, con il consenso del product owner, è stato rimosso del lavoro dallo sprint, portando alla diminuzione del lavoro rimanente tra il 16 ed il 17/5. Da allora in poi il team ha proceduto senza alcun impedimento fino alla fine. Sprint Planning Meeting Alla riunione di pianificazione dello sprint partecipano: il Product Owner, lo ScrumMaster e Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 6

7 l intero team di progetto. Il product owner descrive i dispositivi con priorità più alta al team. Il team pone domande per comprendere meglio le user stories del product backlog e disporre di sprint backlog più dettagliati. Il product owner non descrive tutti gli argomenti nel product backlog; un buon metodo è prepararsi a parlare di almeno due sprint. In uno sprint planning meeting devono emergere due fatti: il proposito (goal) dello sprint il backlog dello sprint. Lo sprint goal, scritto in collaborazione tra team e product owner, deve essere breve di una o due frasi su ciò che il team pianifica di realizzare durante lo sprint. Lo sprint goal viene utilizzato per informare gli stakeholder, fuori dallo sprint, che desiderano sapere cosa sta realizzando quel team, ma non hanno bisogno di sentire tutti i dettagli. Il successo dello sprint viene verificato durante lo Sprint Review Meeting, rispetto allo sprint goal e non agli argomenti del product backlog. Lo sprint backlog è l altro output della pianificazione dello sprint. Sprint Retrospective Un team può sempre migliorare. Anche se il team è efficiente perché sfrutta tutte le opportunità per migliorare, il team, alla fine di ogni sprint, impiega del tempo per riflettere su come sta andando il progetto e come potrebbe migliorare. Questo momento si chiama Sprint retrospective ed è l ultimo evento di uno sprint. Viene indetta una riunione della durata di un ora circa, di solito, subito dopo lo sprint review. Vi partecipano i soliti: ScrumMaster, Product Owner e intero team di progetto. Il modo più semplice di condurre questa riunione è la così detta start-stop continue meeting dove ogni partecipante è chiamato a indicare cosa avvierebbe, cosa fermerebbe e cosa continuerebbe. Lo ScrumMaster modera la riunione chiedendo ad ognuno di esprimere la propria idea. Una volta raccolte abbastanza idee vengono messe ai voti per decidere su quali idee concentrarsi durante il prossimo sprint. Si tratta di una tecnica di bainstorming. A fine sprint, la successiva riunione retrospettiva rivede gli argomenti della precedente retrospettiva. Sprint Review Meeting Alla fine di ogni sprint, il team presenta ciò che ha realizzato in una sprint review meeting. Si tratta di una demo molto informale delle funzionalità realizzate durante lo sprint, appena concluso. Non sono ammesse slide PowerPoint, né sono ammesse più di due ore per preparare la riunione, perché non deve diventare un task né una distrazione dal processo, ma deve essere solo il risultato naturale dello sprint. I partecipanti sono i soliti: Product Owner, ScrumMaster e intero Team dello Scrum; più manager, clienti e sviluppatori di altri progetti come uditori. Durante la riunione viene rivisto il progetto rispetto ai propositi fissati nello Sprint Planning Meeting. Idealmente il team deve aver completato ogni argomento del product backlog trasferito nello sprint, ma è più importante il proposito complessivo dello sprint. Task Board Si tratta di un tabellone sul quale esporre lo stato di ogni task delle stories del backlog e le eventuali aggiunte, spostamenti, modifiche, etc. I membri del team in qualsiasi momento sono liberi di modificare il tabellone per rappresentare la situazione di un componente da quell istante in poi. Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 7

8 Questo è un tipico esempio di task board. Ogni riga rappresenta una user story che è l unità di lavoro suggerita per il product backlog. Durante lo sprint planning meeting il team decide cosa realizzare durante lo sprint successivo. Ogni product backlog si compone di più sprint backlog item che in pratica sono i task- attività, rappresentati da una scheda collocata sul tabellone. Ogni scheda (task) nasce nella colonna To do e viene spostata nelle altre colonne man mano che viene lavorata. Le colonne tipiche del task board sono: Story - la descrizione di alto livello di cosa si deve fare To do - le schede di dettaglio delle attività da realizzare Work in Process - le schede in lavorazione To verify - schede che rappresentano momenti di test dipendenti da altri task Done - mucchio di schede lavorate da rimuovere a fine sprint. Questo lavoro è stato possibile grazie al materiale pubblicato da Mike Cohn sul suo sito, oltre alla presentazione: che ho ripreso e messo a vostra disposizione su Se questo lavoro ti è piaciuto, raccontalo ad un amico che sta pensando alla certificazione Agile e non sa a chi rivolersi. PASSAPAROLA Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm di Vito Madaio pag. 8