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