Premessa
Nel riordinare il materiale di MokaByte, in vista dell’imminente restyling del sito, ci stiamo soffermando, qua e là, in diversi articoli di molti anni fa. Ce ne sono alcuni che, a distanza di tanti anni, mantengono una loro validità.
Siamo andati a pescare un articolo uscito esattamente dieci anni fa che faceva parte di una serie sulla IT Governance. In quella pagina veniva affrontato il rapporto con le metodologie Agili che, nate nel decennio precedente, cominciavano ad affermarsi sul panorama IT italiano. È interessante notare come Scrum sia cambiato da allora, e come un certo tipo di approccio si sia modificato negli anni.
Ma, per quanto le cose siano decisamente cambiate in un decennio, capire da dove veniamo è un esercizio importante per percorrere i passi che ci aspettano nei prossimi anni. (n.d.r.).
Luglio 2011
Introduzione
Nel primo articolo di questa serie, abbiamo introdotto i principali modelli di IT Governance, soffermandoci sul framework COBIT nel secondo articolo. Questo mese analizzeremo una proposta di governance da applicare sui processi di sviluppo “agili” che utilizzano la metodologia Scrum.
Il modello proposto si chiama AGIT (AGIle software developmenT) e ha l’obiettivo di introdurre indicatori di governance per la misurazione di progetti software Scrum-based [AGIT].
Dopo una breve descrizione di Scrum, introdurremo gli indicatori AGIT che verranno poi mappati per la compliance con gli indicatori COBIT.
Scrum
Scrum è una metodologia agile di gestione dello sviluppo del software, ideata e sviluppata da Ken Schwaber e Mike Beedle. Scrum è un termine che deriva dal rugby e indica il “pacchetto di mischia”: è un’evidente metafora del team di sviluppo che deve lavorare insieme in modo coeso e “spingere” nella stessa direzione proprio come avviene per una squadra di rugby.
Gli elementi base di Scrum
Scrum prevede la suddivisione del progetto in iterazioni del progetto dette sprint.
A inizio progetto vengono definite le funzionalità da implementare raccolte, con le relative priorità, in un Product Backlog. Queste priorità vengono assegnate dal Product Owner che è il responsabile del prodotto; senza la sua autorizzazione non è possibile modificare le priorità del Product Backlog.
Prima dell’inizio di ogni sprint, il gruppo di lavoro (Scrum team) si riunisce con il responsabile del prodotto e insieme concordano gli elementi prioritari del Backlog che si dovranno implementare durante lo sprint. Ogni sprint ha una durata predefinita (dalle 2 alle 4 settimane) e, una volta decisi gli obiettivi, questi non possono essere cambiati (se non dagli sviluppatori stessi) sino alla fine dello sprint stesso.
Al termine di ogni sprint deve esserci il rilascio del prodotto software che deve essere un qualcosa di tangibile e utilizzabile dal cliente.
Durante lo sprint ogni giorno il team tiene un breve incontro di una quindicina di minuti chiamato Daily Scrum dove lo Scrum Master annota i task completati e quelli che rimangono e ogni sviluppatore racconta cosa ha fatto quel giorno e cosa dovrà fare il successivo.
I daily scrum si tengono sempre allo stesso posto e alla stessa e l’incontro è tenuto rigorosamente in piedi analogamente all’Xp Stand Up Meeting. Con lo Scrum si ha un ciclo di controllo fine e rigoroso che permette capire lo stato quotidiano di avanzamento dei lavori e di scoprire quanto prima eventuali problemi progetto.
L’organizzazione in Scrum
Da un punto di vista organizzativo Scrum prevede un Product Owner che come committente del lavoro definisce le cose da fare (Product Backlog) e le relative priorità con scadenza ad ogni iteration.
Lo Scrum Master è invece responsabile di gestire gli allineamenti giornalieri e ad ogni iteration tenendo quindi traccia dello stato di avanzamento dei lavori e della situazione dei Backlog.
A inizio di ogni iteration si definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo.
Lo Sprint Planning è diviso in due fasi: nella prima vengono identificate le user-story da completare e nella seconda il team definisce la progettazione tecnologica delle funzionalità concordate. Definito l’elenco dei task dell’iterazione (Sprint Backlog) da effettuare per raggiungere gli obiettivi del mese, il team segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri, e ad ogni sprint presenta i risultati ottenuti durante l’iterazione.
Lo Sprint Review fornisce un controllo sull’andamento del processo alla conclusione di ogni Sprint esplicitando cosa è andato bene o male (“What’s working well” / “What could work better”). Sulla base delle verifiche fatte possono essere fatti degli adattamenti (Inspect & Adapt). Alla conclusione dello Sprint, la squadra presenta l’incremento sul prodotto che potenzialmente potrebbe essere rilasciato.
Lo Sprint Retrospective è una riunione che permette allo Scrum Master e al team di identificare azioni correttive o modifiche utili per rendere il successivo sprint più produttivo.
Per comprendere la differenza fra i due tipi di “revisione”, possiamo dire che lo Sprint Review guarda a “che cosa” la squadra sta costruendo (il prodotto), mentre lo Sprint Retrospective guarda al “come” tutto ciò viene costruito (il processo).
Scrum: “cerimonie” e “artefatti”
Scrum prevede cinque “cerimonie”:
- daily meeting
- release planning
- sprint planning
- sprint review
- sprint retrospective
e fornisce quattro “artefatti” utili per la gestione e il monitoraggio delle performance del progetto:
- Product Backlog
- Product Burndown
- Sprint Backlog
- Sprint Burndown
I grafici di tipo burndown chart consentono di monitorare continuamente l’andamento del progresso del progetto: tale strumento grafico viene aggiornato quotidianamente e risulta quindi facile capire “a colpo d’occhio”, per ogni sprint, quanto lavoro è stato fatto e quanto ne rimane da completare.
È importante sottolineare come Scrum non entri in dettagli implementativi: Xp (eXtreme Programming) è la metodologia di sviluppo maggiormente utilizzata nella fase di implementazione dello Sprint.
Una governance per le metodologie agili
AGIT introduce ulteriori indicatori per Scrum senza violare i principi dell’Agile Software Development e permettendo una migliore governance dei progetti software Scrum-based.
Gli indicatori di governance ABIT sono mappabili con i tradizionale KPI di COBIT e forniscono un ulteriore contributo di chiarezza di governance dell’andamento dei lavori per quanto riguarda le risorse IT (applicazioni, informazioni, infrastruttura e persone), processi e requisiti di business.
Nell’immagine che segue si riportano i 14 indicatori AGIT.
Gli indicatori AGIT sono declinati rispetto alle quattro coordinate delle IT scorecards secondo i principi della Balanced Business Scorecard (BSC), introdotta da Robert Kaplan e David Norton negli anni Novanta.
Nella figura che segue si riportano gli indicatori AGIT declinati per ognuna delle quattro direttrici appena spiegate.
Vediamo ora il mapping e la compliance di AGIT rispetto a COBIT. Come visto nello scorso articolo, COBIT introduce, per ognuno dei 34 processi, indicatori sia di obiettivi (IT goal, process goal e activity goal) che le relative metriche di misura (key metrics) per definire e misurare le performance dell’IT.
Relazione tra indicatori AGIT e metriche COBIT
Nella tabella 2 che segue, si descrive la relazione tra gli indicatori AGIT e le metriche COBIT; questo in relazione ai seguenti processi COBIT:
PO – Plan and Organise – Pianificazione e Organizzazione
- PO7: Manage Human Resources – Gestire le risorse umane dell’IT
- PO8: Manage Quality – Gestire la qualità
- PO10: Manage Projects – Gestire i progetti
AI – Acquire and Implement – Acquisizione e implementazione
- AI1: Identify Automated Solutions – Identificare soluzioni informatiche
- AI2: Acquire and Maintain Application Software – Acquisire e manutenere il software applicativo
- AI6: Manage Changes – Gestire le modifiche
- AI7: Install and Accredit Solutions and Changes – Installare e certificare le soluzioni e le modifiche
DS- Delivery and Support – Erogazione e supporto
- DS5: Ensure Systems Security – Garantire la sicurezza dei sistemi
- DS10: Manage Problems – Gestire i problemi
Come si vede dalla tabella gli indicatori AGIT sono modellati per rispondere ai principali indicatori COBIT relativi alla pianificazione, acquisizione/implementazione e gestione del prodotto IT.
Nella figura 6 si riassume la relazione tra le fasi Scrum e la struttura dei 4 domini COBIT.
Conclusioni
In questo articolo abbiamo visto come è possibile applicare in modo agevole degli indicatori COBIT per ottenere utili e preziose informazioni di governance su progetti condotti in modalità agile con Scrum.