SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

---

Vorrei cominciare enunciando i diversi “perché” potresti, o dovresti,  decidere di utilizzare SCRUM per gestire i progetti nella tua azienda.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

 

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

   

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

   

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening

Pronti, partenza…..via!

Scrum è una metodologia agile che pone il focus sull’esecuzione incrementale del lavoro (release), in tempi brevi, caratterizzati da grossa coesione e spirito di iniziativa del team.

In fase analitica utilizza linee di comunicazione molto corte e, in fase di sviluppo, tempi decisionali molto brevi al fine di non dover dedicare troppo tempo allo sviluppo di documentazione analitica e reinvestire quel tempo nello sviluppo effettivo del prodotto.

Esistono tre ruoli/figure fondamentali:

• Product owner, colui che è responsabile del prodotto (solitamente il committente)
• ScrumMaster, colui che governa il processo di produzione (project manager)
• Team, gli sviluppatori che eseguono il lavoro

Le features del prodotto solitamente vengono tutte raccolte dallo ScrumMaster a seguito di interviste effettuate con il committente, gli utenti finali, gli stessi membri del team. Questa lista di funzionalità è chiamata “product backlog“.

Il secondo step è di decidere, con il product owner, quali funzionalità enteranno nelle diverse release (deliverable) ; la lista di funzionalità a capo di una release viene chiamata “release backlog“.

A questo punto entra in gioco il team che con lo ScrumMaster assegna priorità alle singole feature della release ed effettua la stima dei tempi per ciascuna.

Finalmente, in funzione del tempo in cui si vogliono suddividere gli sprint (solitamente da 2 giorni sino a 30 giorni), si scelgono le singole features e si raggruppano, appunto, in sprint.

Le singole attività vengono assegnate ai membri del team e finalmente si parte con lo sviluppo.

 La scorsa settimana abbiamo deciso di utilizzare tale tecnica per un cambio importante di release del nostro framework applicativo che ci supporta nello sviluppo delle soluzioni. L’ultimo intervento innovativo al progetto era stato fatto più di un anno fà e le segnalazioni di anomalie, bug, revisioni o migliorie erano piuttosto corpose.

Io, in quanto product owner, e il mio collega Massimiliano, ScrumMaster, abbiamo fatto la cernita di tutte le possibili features (product backlog) che potevano essere implementate.

E’ stata fatta una prima scrematura (legge 80/20 di Pareto, ricordate?) che ci ha portati ad avere una lista di features più importanti da sviluppare (release backlog).

A quel punto lo ScrumMaster e il team, hanno prioritizzato tali attività e suddiviso in sprint (che per noi era di 2 giorni), terminando con l’assegnazione dei compiti alle singole persone.

A quel punto è stato il momento del via!

Quali i risultati? Beh, oggi ho parlato con Massimiliano per avere un feedback in merito.

Cosa ha funzionato:

• I tempi sono stati rispettati tranne piccole varianze
• Praticamente tutte le feature sono state implementate
• Il lavoro del team a stretto contatto, su tematiche comuni, ha permesso la nascita di buone idee/suggerimenti
• La condivisione e la comunicazione attiva ha permesso di creare persone di backup su alcune aree di codice sino ad allora conosciute solo da singoli

Cosa non ha funzionato:

• Non tutte le persone che inizialmente erano state scelte per far parte dello “sprint team” hanno potuto partecipare attivamente, cause incombenze e urgenze lavorative

In generale comunque possiamo ritenerci soddisfatti.

Il prossimo sprint lo faremo probabilmente il prossimo mese, e lavorare molto di più sulla qualità dei processi che utilizziamo per produrre soluzioni.

ByeBye

Comprimiamo lo schedule

Lo so, le frasi “comprimiamo lo schedule” o “accorciamo i tempi di consegna” vi fanno venire i brividi; soprattutto negli ultimi tempi sembra essere diventata la frase più in voga e più nominata da clienti o commmittenti di progetto.

Anche da noi in Diesys capita spesso di fare improvvise accelerazioni e questa settimana, per esempio, ha visto impegnato una parte del team nel cercare di comprimere i tempi di rilascio di una deliverable di progetto.
Stiamo infatti sviluppando un’applicazione di trouble ticketing (TicketIT), inizialmente nata per uso interno, che però ci è stata chiesta a inizio settimana in visione da un cliente.

L’applicazione essendo nata per solo uso interno, navigava tranquilla con un rank low-priority, in mari calmi e poco increspati; l’interesse del cliente però ci ha dato lo spunto per metterci alla prova e soprattuto ha imposto una deadline (scade oggi) per la creazione di una demo funzionante.

Vediamo la teoria; quando si parla di compressione dello schedule tornano alla mente studi approfonditi sul PMBOK o letture “agili” fatte qua e là.
Il PMBOK terza edizione [1],  nomina due tecniche precise di compressione: crashing e fast tracking; mentre l’agile software developmente ce ne regala un’altra: lo sprint.

Crashing

Un tipo specifico di tecnica di compressione della schedulazione del progetto eseguita mediante la diminuzione della durata della schedulazione di progetto dopo l’analisi di un certo numero di alternative allo scopo di determinare come ottenere la massima compressione della durata della schedulazione al minor costo aggiuntivo. I sistemi adottati più comunemente per la compressione dei tempi di una schedulazione prevedono la riduzione delle durate delle attività schedulate e l’aumento delle risorse assegnate alle attività schedulate.   [1]

Fast Tracking

Tecnica specifica di compressione della schedulazione del progetto che consente di modificare la logica del reticolo per sovrapporre le fasi che verrebbero in genere svolte in sequenza, come la fase di progettazione e quella di costruzione, o per eseguire in parallelo le attività schedulate. [1]

Sprint

Le metodologie agili invece definiscono uno sprint come una normale iterazione di 2/4 settimane che porta allo sviluppo di una parte perfettamente funzionante di prodotto, poi rilasciata al cliente

Vantaggi e  Svantaggi

Tutte e tre le tecniche hanno ovviamente pregi e difetti.
Il crashing, spesso osteggiato da molti, può portare invece che a riduzioni, ad aumenti di tempi: pensate infatti ad un’attività mediamente complessa, in carico ad uno specifico membro del team, che poi verrà suddivisa su due o più persone. Ci dovrà essere un tempo minimo di passaggio di consegne e una inziale forte dipendenza delle risorse aggiunte dalla risorsa originale.

Il fast tracking da questo punto di vista sembrerebbe essere meno “scomodo”: le risorse aggiunte lavorano su attività diverse.
Aumentano però i rischi complessivi: dobbiamo eseguire parallelamente attività nate per essere svolte in sequenza.

Infine lo sprint è strettamente legato alle metodologie agili e quindi il team deve conoscere ed essere disciplinato nell’eseguire iterazioni che concorrono allo sviluppo di blocchi funzionanti di codice.

Il nostro approccio

In questi giorni abbiamo cercato di mettere insieme le tre tecniche dedicando quattro differenti risorse al progetto.
In primo luogo abbiamo diviso gli interventi in aree funzionali e assegnato ad ogni area una priorità (plan/feature backlog).
Ad ogni risorsa è stata assegnata un’area funzionale e la responsibilità di portare a compimento le specifiche funzionalità (task/backlog).
Tali risorse di fatto stavano mettendo in pratica la tecnica di fast-tracking.
Per ridurre i rischi derivanti dall’esecuzione di differenti attività in parallelo, abbiamo identificato un coordinatore (scrum master?) che funge da collante nel team.
Il coordinatore ha poi di fatto svolto indirettamente anche funzioni di crashing (o di pair-programming) perché spesso si è trovato a sviluppare parti di codice inerenti la stessa attività con altri team di progetto.

Il risultato effettivo finale lo attendiamo nel primo pomeriggio.
Un prima considerazione che può essere tratta riguarda il team che mette in pratica tali tecniche: è necessario che tutti i membri condividano l’obiettivo finale, siano motivati, pronti a mettersi in gioco e soprattutto che abbiano una buona competenza tecnica.

Fortunatamente il mio team ha dimostrato in pieno tali competenze….e voi là fuori, avete fatto esperienze simili?

---

I marchi citati sono dei rispettivi proprietari.

[1] PMBOK Third Edition  – Project Management Institute