Primi passi con SCRUM - step2

Andando avanti con le mie letture da "iniziato" a SCRUM non poteva mancare la solita fase di raccolta informazioni di base.
Ecco quindi una serie di definizioni per i termini e i concetti più ricorrenti.

Partirei sicuramente dal manifesto AGILE che rappresenta in qualche modo la filosofia da abbracciare se si vuole intraprendere questo tipo di percorso:

Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

Con dieci anni di esperienza sulle spalle mi sento di poter dire che le voci a sinistra rappresentano la volontà di far riuscire un progetto e puntano più all'aspetto pratico della vicenda con le sue tante problematiche e sfaccettature, mentre le voci di destra puntano alla componente teorica e rigorosa del progetto (la componente per la quale il ponte sullo stretto di Messina non verrà mai costruito). Questo non vuol dire che io sia contro la gestione precisa e puntigliosa dei progetti, tuttavia invito tutti a riflettere.

Veniamo ora ai termini ricorrenti della metodologia SCRUM:

Attori coinvolti

• Il Product Owner (PO): tipicamente potrebbe essere una persona del marketing o comunque qualcuno a stretto contatto con il cliente finale in modo da avere bene in mente quali siano i desiderata e le esigenze reali.
• Lo Scrum Master (SM): tipicamente un Project Manager o un Team Leader che ha lo scopo di tenere unito e motivato il gruppo di lavoro facendo in modo di bloccare gli elementi di disturbo per il gruppo stesso e lavorando per risolvere e indirizzare al meglio i problemi bloccanti.
• Il Team di lavoro (TL): di fatto le persone che sviluppano il nostro software. SCRUM tende a non assegnare dei ruoli specifici (grafico, programmatore di back end o di front end...) bensì prevede che tutti i membri del gruppo cooperino e si auto-organizzino (chi fa cosa? come?) per completare il lavoro all'interno di un singolo sprint.

Gli artefatti principali (Documentazione)

• Product BackLog (PBL): rappresenta la lista delle caratteristiche e dei requisiti che il mio prodotto deve garantire. Tipicamente questa lista può essere fatta con degli use-case che descrivono gli scenari. Il PBL viene aggiornato dal PO che può decidere di aggiungere o eliminare requisiti in base alla sua evidenza di come evolve lo sviluppo e rispetto alla sua conoscenza del cliente finale. Il PO definisce di volta in volta le priorità rispetto alle varie attività presenti nella lista.
• Sprint BackLog (SBL): rappresenta la lista delle attività delle quali il team si occuperà all'interno di un determinato sprint. Generalmente si scelgono le attività a priorità maggiore così come definito dal PO nel PBL
• Release e Sprint Burndown Charts (RBC e SBC): Grafici che danno immediata evidenza di come le attività incluse rispettivamente nel Prodotto e nello Sprint diminuiscono all'aumentare del tempo (ovviamente se tutto procede come da pianificazione). In pratica in ascissa mettiamo il tempo o il numero di sprint previsti e in ordinata il numero di attività presenti nel Prodotto o nello sprint. Il risultato è un grafico con una curva decrescente come quello in figura:

In alternativa, invece di una curva, è possibile utilizzare un istogramma che ha il vantaggio di dare evidenza delle eventuali attività "extra" che potenzialmente si aggiungono al nostro progetto in corso d'opera (le attività vanno ad alimentare i valori negativi sull'asse delle ordinate):

[I grafici sono presi in prestito dal sito http://www.mountaingoatsoftware.com/scrum]

Gli incontri

• Sprint Planning Meeting (SPM): incontro che si svolge all'inizio di ogni sprint. Durante il primo di questi incontri viene definito il PBL che poi potrà subire variazione nel corso dei successivi incontri.
• Daily Scrum: incontro di circa 15 minuti da tenere preferibilmente a inizio giornata dove ciascun membro del team racconta molto rapidamente agli altri cosa ha fatto il giorno prima, cosa pensa di fare durante la giornata di lavoro che sta iniziando e espone le eventuali criticità o problemi bloccanti in cui è incappato.
• Sprint Review Meeting: incontro di chiusura di uno sprint all'interno del quale il gruppo presenta il risultato dello sprint. Tipicamente si può pensare come una demo ma sicuramente non una presentazione ufficiale. Il team non deve essere distratto da questo tipo di incontro che ha il solo scopo di mostrare rapidamente lo stato di avanzamento del lavoro.

Gli Sprint

Sono le fasi in cui viene svolto il lavoro. Tipicamente periodi di 2-4 settimane nei quali il team di lavoro si concentra sullo SBL che ha definito e lo SM evita che elementi esterni interferiscano nel lavoro del gruppo.
Scopo finale dello sprint è quello di ottenere una versione funzionante del prodotto che contenga le funzionalità scelte per lo SBL.

La task Board

Dato che SCRUM è una metodologia Agile e veloce si suggerisce di utilizzare una lavagna per attuare i concetti base del visual planning, ovvero armatevi di post-it e cominciate a scriverci sopra i requisiti e le attività, poi tracciate delle linee sulla lavagna e create la colonna degli use-case, la to-do list, la colonna delle attività chiuse e quelle da testare, le attività che compongono lo sprint e così via. Spostando di volta in volta i post-it da una colonna all'altra abbiamo immediata evidenza di come evolve il nostro progetto. In alternativa si può anche utilizzare un foglio excel appositamente strutturato o qualunque strumento con il quale vi trovate a vostro agio.
Gli elementi della task board che non devono mai mancare sono il PBL e il RBC.

Per il momento è tutto. Spero che i concetti siano chiari e comprensibili a tutti.