Step #10: rivedi, rifletti, ripeti.

Guida a Scrum in 10 facili step , lo Step #10: Rivedi, rifletti, ripeti.
Siamo davvero alla fine, la conclusione della nostra guida a Scrum in 10 semplici step.
Quindi ricapitolando abbiamo imparato a:

Step #1: Tieni in ordine il tuo Backlog di progetto
Step #2: Come fare la stima del tuo backlog di progetto
Step #3: Come pianificare lo Sprint – I requisiti
Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo
Step #6: Come implementare lo Sprint con Scrum
Step #7: Standup e… fai sentire la tua voce!
Step #8: Traccia i progressi con un diagramma quotidiano
Step #9: Consegna in tempo!

Ed arriviamo alla review finale del progetto, quella che mette il punto su quanto fatto fino a quel
momento ed apre la strada a nuovi e (si spera!) entusiasmanti progetti.

La review finale

Al termine dell’ultimo e fatidico Sprint organizza una riunione per una review completa del progetto.
Raduna l’intero team di sviluppo, invita tutti gli stakeholder-chiave rappresentanti del progetto lato cliente: più parti sono presenti, meglio è. Fate una review di quanto consegnato, una demo del software, sia che sia allo stadio completo, beta o ancora work in progress, la demo deve rappresentare lo state reale del software e tutte le feature effettivamente completate e funzionanti.
Lasciate che siano i membri del team a mostrare le parti della demo che li hanno visti attivamente coinvolti.
Per intenderci, gli scopi della review devono essere fondamentalmente 3:

– Consentire ai membri del team di mostrare i risultati ottenuti e dimostrare il proprio contributo al
progetto- Consentire agli stakeholders di prendere consapevolezza di cosa è stato fatto, dare un feedback
costruttivo e tempisticamente ancora utile prima della messa in pubblicazione

– Aiutare il team a restare focalizzati sulla deadline dello Sprint: a nessuno infatti piace arrivare a
un demo che non ha niente da mostrare. L’idea stessa della demo è uno sprone sufficiente,
normalmente ;).

La retrospettiva

Subito dopo -anche immediatamente dopo- la review, prevedete una riunione per la Sprint Retrospective: ovvero?
Riunitevi con tutto il team ed il Product Owner, ma questa volta senza gli stakeholder. L’obiettivo di questo particolare meeting sarà quello di riflettere su come sono andate le cose nel corso dello Sprint: è un’occasione per il team di discutere lo sprint e per considerare tutte le eventuali migliorie.

Tutti insieme, bisogna cercare di lavorare su:

– la review dell’ultimo burndown chart: com’è andata? Il tema è davvero riuscito a consegnare quanto previsto? Annotate le ore in eccesso rispetto alla pianificazione su un diagramma, in modo da avere una visione complessiva del rate di successo del team. Questo non per avere una misura di controllo e giudizio, ma per dare al team la possibilità di autovalutarsi e dare un valore reale ed oggettivo ai progressi raggiunti o mancati.

– la review della velocity: la velocity è data dal numero di punti stimati nel backlog originario in base al numero di elementi poi effettivamente completati negli sprint. Potranno essere annotati solo gli elementi completi al 100% e pronti alla delivery. Ancora una volta, tracciare visivamente la velocity in un diagramma grafico consente al team di realizzare a colpo d’occhio se si sta consegnando più o meno di quanto stimato.

– discutere cosa ha funzionato e può quindi essere ripreso nel progetto successivo

– discutere cosa avrebbe potuto funzionare meglio e quindi capire perché, per non ripeterlo nel progetto successivo.

– stabilire cosa verrà affrontato diversamente nel prossimo sprint.

Adottare, quindi, un generale atteggiamento di continuo learning process, sprint dopo sprint. Nei metodi tradizionali di gestione progetto, come ad esempio PRINCE2, prevedevano ugualmente questo concetto.

Ma il problema consisteva nel fatto che le persone -giunte a termine di progetto- non sempre ricordavano a sufficienza i vari step compiuti, specie se alla fine di un progetto su vasta scale, ed era quindi più difficile annotare ciò che era andato bene e ciò che non lo era per farne un vero learning process.

Altro fatto frequente, è che a fine progetto il team viene magari disperso e distribuito su progetti differenti, impedendo di fatto la trasmissione delle conoscenze ed esperienze acquisite. Nello sviluppo con Scrum invece, il processo di apprendimento è strutturato in piccoli pezzi nel corso del vivo del progetto, non solo al suo termine: è questo che consente in effetti di applicare quanto appreso/sperimentato nel ciclo precedente direttamente in quello successivo.

Ripeti

A questo punto il team è provvisto di tutte le informazioni necessarie sul prodotto, sulle sue performance e sugli eventuali impedimenti accorsi:

– come appariva il software dopo l’ultimo sprint
– feedback su quanto sviluppato fino a quel momento
– fino a che punto il team è stato in grado di consegnare quanto stabilito nella pianificazione dello
sprint
– la velocity del team e cosa è mediamente raggiungibile nella durata media di uno sprint
– cos’è andato bene
– cosa non è andato bene
– cosa verrà gestito diversamente di lì in avanti

Tutto ciò che rimane ora da fare: ripartire da capo, ma con il peso e vantaggio dell’esperienza maturata. Realisticamente, di solito servono 3 o 4 cicli di sprint perché il team prenda il giusto ritmo, impari ad apprendere dalle proprie esperienze e riesca a fissare in un termine medio il proprio grado di velocity su ogni sprint.
Di qui in avanti, non può che andare sempre meglio :): agile e scrum sono ottimi strumenti per aiutarvi a raggiungere meglio gli obiettivi di progetto, ma non sono nulla senza la vosrta costanza e tenacia nell’implementarli.

Quindi ci auguriamo che questa guida vi sia stata utile e …buon lavoro a tutti!

Interessati alle tecniche di sviluppo software con metodolgia agile e framewrok scrum? In Nextre Engineering possiamo aiutarvi ed accompagnarvi nella realizzazione del vostro progetto software, web o mobile application: contattateci per informazioni a contattaci@nextre.it