Traduzione italiana del Manifesto for Agile Software Development

Nel febbraio del 2001, un gruppo di guru nello sviluppo software si incontrò, più o meno casualmente, per studiare nuove metodologie. A seguito di questo incontro fu redatto un manifesto per uno sviluppo agile del software

Principi del Manifesto Agile, fonte:  http://agilemanifesto.org/

1. La nostra più alta priorità è quella di soddisfare le richieste del Cliente, attraverso continui rilasci di versioni intermedie del software
2. Non bisogna temere le modifiche dei requisiti, anche se si è in una fase avanzata dello sviluppo, in quanto le metodologie agili si basano sul presupposto che i cambiamenti sono un vantaggio competitivo per il cliente.
3. Consegnare ogni due o tre settimane (max ogni due mesi) un software funzionante, con preferenza per scale temporali ridotte.
4. Il cliente e gli sviluppatori lavorano insieme per tutta la durata del progetto.
5. Occorre basare i progetti su individui motivati. Bisogna assicurargli un ambiente confortevole, un supporto e una fiducia adeguata.
6. La comunicazione diretta è il metodo più efficiente per trasmettere le informazioni all’interno del team.
7. Un software funzionante è la principale indicazione dello stato di avanzamento del progetto
8. I processi agili promuovono un’attività di sviluppo software sostenibile. Promotori, sviluppatori ed utenti devono essere in grado di garantire un passo costante a tempo indeterminato.
9. L'attenzione continua per l'eccellenza tecnica e il buon design esaltano l'agilità.
10. La Semplicita e’ essenziale.
11. Le migliori architetture, i migliori requisiti e progetti, nascono da team auto-organizzati.
12. Ad intervalli regolari, il team deve riflettere su come diventare più efficiente e adeguare il proprio comportamento in relazione all'obiettivo prefissato.

Una interessante Comunità Agile è all'indirizzo: http://www.agilealliance.org

L’ingegneria del software si occupa prevalentemente dei processi e delle metodologie finalizzate allo sviluppo del software. Oggi queste metodologie posso essere essenzialmente suddivise in:

• metodologie classiche. Sono fortemente orientate alle specifiche, in quanto propongono di analizzare un progetto nella sua totalità, dedicano moltissimo tempo all’analisi, cercano di descrivere anche tutte le future funzionalità. Conseguenza di ciò è che per molto tempo, queste metodologie, non producono risultati.
• metodologie agili. Sono fortemente orientate ai risultati, in quanto tendono a suddividere il progetto in piccole parti, in modo da poter disporre, nel minor tempo possibile, di alcune significative funzionalità, da ampliare e completare successivamente, mediante un iterativo processo di sviluppo. Inoltre propongono di coinvolgere, quando più è possibile il Cliente, in modo da avere un’immediata reattività alle sue richieste.

Le Metodologie Classiche suddividono lo sviluppo del progetto in quattro indipendenti fasi:

• Analisi
• Progettazione
• Implementazione
• Test.

Queste fasi vengono eseguite in un rigido ordine sequenziale. Tuttavia, può accadere che durante lo sviluppo si renda necessario il ritorno ad una fase precedente, per chiarire meglio alcuni aspetti del problema o perché si è reso necessario apportare modifiche. Essendo stato il progetto definito in modo rigido, potrebbe non essere semplice effettuare le necessarie modifiche.
Queste metodologie sono efficaci quando lo sviluppo del software è contenuto. Il software può essere definito in anticipo, perché basato sull'esperienze e non è soggetto a diventare rapidamente obsoleto.

Le Metodologie Agili prediligono la comunicazione real-time rispetto alla documentazione scritta. Non sono predittive, in quanto non cercano di prevedere come si evolverà il software, ma sono adattive in quanto cercano di capire quale sono le tecniche migliori per adattarsi all’evoluzione dei requisiti, al fine di ottenere la totale soddisfazione del cliente. Inoltre consentono di ridurre il rischio da errori, suddividendo il progetto in piccole funzionalità software, da sviluppare in limitate finestre temporali (tre o quattro settimane).
Questo iterativo processo di sviluppo deve essere realizzato in modo da produrre un progressivo incremento di funzionalità del software, fino a giungere alla completa realizzazione delle richieste del cliente. Ogni piccolo incremento, anche se non possiede sufficienti funzionalità, deve essere considerato completo e deve essere rilasciato. Inoltre deve comprendere pianificazione, analisi dei requisiti, implementazione, test e documentazione. Tuttavia queste  tecniche non possono essere applicate in tutti i progetti, ma solo nei casi in cui occorre seguire in tempo reale l’evoluzione, in quanto i requisiti cambiano di frequente.

Queste metodologie si chiamano agili perché consentono di rivedere le specifiche e di modificarle, sulla base di uno scambio continuo di informazioni con il cliente e i diversi protagonisti associati al processo di sviluppo. I valori fondamentali su cui si basano queste metodologie sono:

1. Creatività. Privilegiare le persone e le loro interazioni, rispetto ai processi, al fine di ottenere da ciascun elemento del team il meglio delle loro potenzialità e nello stesso tempo liberare la loro creatività, slegandola dall’obbligo di seguire i processi. Il presupposto è che una persona che è felice di lavorare produrrà, in tempi contenuti, un software di qualità superiore rispetto a chi è obbligato a svolgere un’attività sgradita.
2. Collaborazione. Fondamentale è cercare di stabilire un rapporto di collaborazione con il cliente, in alternativa alla negoziazione del contratto, in quanto questa scelta garantisce il raggiungimento dei migliori risultati contrattuali possibili.
3. Comunicazione. Le metodologie auspicano un’intensa comunicazione fra chi sviluppa il software, il management e il cliente. 
4. Disponibilità. Non è fondamentale aderire alla pianificazione del progetto, ma essere disponibile a rispondere ai cambiamenti e a suggerire modifiche, piuttosto che aderire ad una predittività. Il fine è di migliorare il modo con cui il team deve rispondere ai cambiamenti.
5. Semplicità. I risultati devono risolvere un solo problema, ciò consente di favorire la concentrazione in un ambito ristretto.
6. Feedback. Il sistema deve essere costantemente verificato, in modo da garantire la consistenza.
7. Coraggio. Se si rileva che è necessario modificare ciò che è stato fatto in precedenza, occorre procedere senza timori al cambiamento, perché è fondamentale il raggiungimento degli obiettivi prefissati.
8. Funzionalità. E’ più importante la funzionalità del software e il rilascio di nuove versioni ad intervalli regolari, rispetto ad una completa specifica e documentazione del software. Ciò non significa rinuncia alla documentazione, ma deve essere ridotta al minimo indispensabile. In altri termini, prima occorre disporre di un software che funziona, poi sopperire alla mancanza di documentazione.

Conoscere in anticipo tutte le esigenze del cliente e tutti i requisiti che dovrebbe avere un prodotto software è certamente auspicabile, purtroppo in diversi casi ciò non è possibile, in quanto durante il periodo di sviluppo, le esigenze del cliente potrebbero cambiare,  inoltre durante la fase di progettazione potrebbero intervenire fattori che suggeriscono modifiche, ecc. Per questi motivi, spesso non è possibile utilizzare una metodologia predittiva, in quanto il processo di sviluppo è imprevedibile.

Le Metodologie Agili, quindi si basano su tecniche che tendono a rendere più semplice le modifiche al sistema, in quanto utilizzano un processo iterativo che comprende fasi di progettazione, sviluppo e test più brevi rispetto alle metodologie tradizionali. Inoltre sono metodologie che privilegino l’adattabilità alle modifiche, piuttosto che soddisfare in modo rigoroso le specifiche. In altri termini, fondamentale per questi metodi è l’adattabilità, l’iteratività e l’incrementalità.
Quindi le Metodologie Agili, piuttosto che soddisfare in modo rigoroso le specifiche, utilizzano tecniche che tendono a favorire l’adattabilità alle modifiche, l’iteratività e l’incrementalità, al fine di rendere più semplice le modifiche, mediante un processo iterativo che comprime le fasi di progettazione, sviluppo e test, rendendole più brevi rispetto alle metodologie tradizionali. Ciò consente di produrre versioni del software in tempi brevi, anche se con ridotte funzionalità.

Il termine Scrum (mischia) deriva dal rugby. Si basa sulla necessità di avere un team coeso, in cui tutti spingono nella medesima direzione, mediante un lavoro di gruppo, al fine di raggiungere la meta. Scrum comprende un insieme di semplici e agili regole al fine di aumentare la produttività nel Project Managment e di fornire, in tempo reale, informazioni affidabili sullo stato di sviluppo di un prodotto.

Una delle componenti più importanti del project management è senza alcun dubbio la comunicazione. Un secondo aspetto è l’attività di negoziazione e compromesso svolta dal Project Manager, attività che è direttamente associata alla complessità del progetto, in quanto comporta problemi dovuti ai cambi di specifiche, alla riduzione dei tempi di sviluppo, alle revisioni, alla riduzione del budget, al bilanciamento degli interessi contrastanti e delle aspettative di tutti gli attori.

Un terzo importante aspetto, nasce dalla constatazione che i requisiti di un progetto sono sempre destinati a modificarsi durante la fase di sviluppo, per questo motivo i requisiti costituiscono un punto di partenza inadeguato, per impostare un progetto. Quindi, in un’ottica di revisione della pianificazione delle attività, non è corretto partire da una perfetta definizione dei requisiti, ma è più intelligente considerare come vincoli primari dei progetti, i tempi, i costi e la possibilità di favorire la gestione dei cambiamenti dei requisiti. Ciò significa che occorre suddividere le funzionalità, in singoli componenti indipendenti, in modo da poter facilmente valutare costi, tempi e se si è in grado di completarli, procedendo con piccoli incrementi progressivi. In questo modo, diventa anche più semplice, suddividere le attività fra i diversi componenti di un Team di sviluppo.

Un ulteriore aspetto del project management è legato ai ruoli e agli stili comunicativi del Project Leader e del Project Manager. Il primo, oltre a fissare le mete, deve anche essere in grado di motivare il team, al fine di raggiungere gli obiettivi prefissati; mentre il secondo deve essere in grado di gestire i contratti, il budget e le comunicazioni.

Le metodologie tradizionali, generalmente si basano su un vincolo primario: la definizione esatta dei requisiti, prima dell’inizio delle attività. Questi requisiti vengono espressi mediante una presunta dettagliata specifica. Purtroppo, durante questa fase si hanno pochi elementi per poter valutare le reali dimensioni delle attività da svolgere, per cui l’affidabilità delle stime, spesso risulta essere mediocre e superficiale. Una ulteriore complicazione è dovuta al fatto che il tutto presuppone una perfetta conoscenza dei requisiti, da cui dipendono le scelte progettuali, conoscenza che generalmente è presunta, ma quasi mai vera, il chè rende i progetti rigidi e poco flessibili a qualsiasi cambiamento.

Fra le metodologie di ultima generazione, SCRUM è quella che sta riscuotendo forti successi in tutto il mondo. E’ una metodologia Agile per la pianificazione e la gestione dei progetti, che utilizza un approccio adattivo, in quanto cerca di enfatizzare la non linearità dei progetti e mira ad una gestione del cambio delle specifiche, durante l’intero processo di sviluppo del software.

Scrum pone l’attenzione sull’esecuzione incrementale delle attività, da realizzare in tempi brevi e caratterizzate da grande coesione fra tutti i partecipanti al progetto. Fondamentale, in questo tipo di metodologia, è quindi la comunicazione che è resa agile durante tutte le fasi del progetto.

Uno dei presupposti di Scrum è che, nel corso di un progetto il cliente, per motivi diversi, può cambiare idea su ciò che desidera. Inoltre, gli imprevisti non possono essere facilmente gestisti con i metodi tradizionali.

Scrum adotta un approccio empirico, riconoscendo che un problema non può essere pienamente compreso o definito, per cui è meglio concentrarsi sulla capacità del Team di consegnare rapidamente release funzionanti, anche se non sono complete e di rispondere rapidamente alle esigenze emergenti. Scrum utilizza un metodo iterativo che si basa su un approccio incrementale, al fine di ottimizzare la prevedibilità e il controllo sui rischi.
L’approccio empirico su cui si basa Scrum, si fonda su tre principali elementi:

• Trasparenza, il cui fine è di garantire la visibilità dei risultati e la consapevolezza che lo sviluppo del progetto si evolve nella direzione auspicata.
• Ispezione, il cui fine è di garantire una forma di controllo, da attuare con una frequenza in grado di far emergere ciò che è in contraddizione o fuori dai limiti accettabili.
• Adattamento, il cui fine è di favorire l’introduzione di aggiustamenti o variazioni, che possono emergere durante le ispezioni o per adeguare lo sviluppo al sopraggiungere di nuove necessità.

Scrum prevede tre diversi tipi di incontri dedicati all’ispezione e all’adattamento:

• Daily Scrum, l’obiettivo dell’incontro è di poter controllare, con cadenza giornaliera, se i progressi verso l’obiettivo dello Sprint sono ragionevolmente adeguati. Durante questo meeting (che si svolge in piedi e dura al massimo 15 minuti), ogni membro del team deve essenzialmente rispondere a 3 domande: cosa ha fatto dopo l’ultimo meeting, cosa farà fino al successivo meeting, quali problemi ha dovuto affrontare. Una discussione di lavoro in piedi sollecita ad essere sintetici, trasmette la sensazione dell’urgenza, di un rapido disimpegno dei membri della discussione, per cui l’individuo tenderà a concentrarsi sugli aspetti importanti. Se questi incontri sono brevi, ma ricchi di contenuto, il team li percepirà come un valore e non cercherà di evitarli.
• Sprint Review e Planning Review, l’obiettivo dell’incontro è di ispezionare i progressi verso l’obiettivo di rilascio; il fine è di poter intervenire in anticipo per decidere se è opportuno introdurre adattamenti in grado di ottimizzare il valore del prossimo Sprint. Lo Sprint Review tipicamente comprende anche una demo per mostrare i risultati raggiunti.
• Sprint Retrospective, l’obiettivo dell’incontro è di esaminare i precedenti sprint al fine di determinare quali variazioni apportare, al fine di rendere il prossimo Sprint più produttivo.

Valutazioni e velocità di rilascio

Nelle metodologie Agili, i Team hanno molta autonomia, possono organizzarsi come meglio credono, in quanto sono importanti i risultati. Tuttavia occorre sottolineare che agile non è sinonimo di anarchia, in quanto i Team Agile, per conseguire i loro obiettivi, devono seguire processi rigorosamente definiti, si devono affidare prevalentemente alla collaborazione fra le persone piuttosto che alla rigida gestione dei documenti e dei dati.

In questa visione, lo Scrum Master deve contribuire a individuare la migliore soluzione, in termini organizzativi e di attribuzione dei compiti. Ciò significa che deve focalizzare l’attenzione sulla gestione delle relazioni e dei contesti, piuttosto che sugli aspetti tecnici, per questo motivo i suoi principali compiti sono quelli di rimuovere gli ostacoli organizzativi e di favorire la discussione fra i diversi membri del Team.

Controllo delle attività

Il controllo delle attività in Scrum dipende dalla velocità di rilascio e dalla dimensione del Backlog, cioè dall’elenco delle funzionalità da realizzare in base alle loro priorità, che generalmente vengono quantificate in Story Point, cioè in unità astratte che corrispondono a giorni ideali. La somma di questi valori determina la lunghezza del Backlog, mentre la velocità indica la quantità di Backlog che il Team è in grado di realizzare durante ogni singola iterazione, la cui durata è costante per definizione. Quindi, il tempo necessario per completare un progetto è dato dal rapporto fra il totale del Backlog e la Velocità ideale di rilascio, in cui sono costanti il tempo e il costo di ciascuna iterazione; mentre la differenza fra la velocità ideale e quella rilevata consente di ottenere un’indicatore per valutare il progredire del progetto, rispetto alle aspettative iniziali. Poiché il tempo e i costi sono vincoli fissi, possono variare solo le caratteristiche che devono essere rilasciate entro i termini previsti. Un efficiente e ben organizzato Team è quello che riesce ad operare alla velocità ideale, in quanto è in grado di fornire risultati prevedibili.

Start delle attività con Scrum

La quantità di lavoro preliminare che occorre svolgere per iniziare ad operare con Scrum, dipende ovviamente dalla dimensione del progetto e dal tipo di organizzazione aziendale. Tuttavia, dopo aver identificate le figure necessarie per realizzare il progetto è opportuno organizzare una riunione preliminare in cui vengono definiti i temi, lo scopo del progetto, il backlog di alto livello e i tempi grossolani richiesti dalla metodologia.

La prima fase di Scrum è denominata Sprint 0, il cui fine è di porre il Team nella condizione di iniziare le iterazioni necessarie per giungere, alla realizzazione del prodotto, nel minor tempo possibile. Durante questa fase vengono prevalentemente coinvolti i rispensabili del progetto, in quanto è necessario organizzare le diverse attività ed occorre effettuare una verifica economica, in quanto il valore del progetto, induce una maggiore consapevolezza nella scelta delle priorità, delle funzionalità e dei tempi di consegna.

Ovviamente, questa valutazione non potrà mai essere accurata, in quanto rappresenta un punto di inizio che sarà costantemente aggiornato dalla valutazione periodica dei Product Backlog Item, in quanto, la non corretta valutazione viene evidenziata dalla natura iterativa di Scrum, che consente di valutare gli effettivi avanzamenti durante i vari Sprint. Questo approccio consente sia di attenuare gli errori nelle valutazioni dei rischi, sia di evitare di perdere tempo nel cercare di realizzare presunte accurate valutazioni. Un ulteriore vantaggio offerto da Scrum, è che dopo qualche Sprint si è già in grado di valutare la fattibilità di un progetto e di comprendere quindi se, i requisiti richiesti, possono essere soddisfatti.

Un importante aspetto del project managment è espresso dal Project Vision, il cui obiettivo è di fornire all’intero Team, le informazioni necessarie per comprendere l’essenza del prodotto che si deve realizzare, tuttavia occorre evitare di produrre inutile documentazione, in quanto sono risorse che vengono inutilmente sprecate.

Un utile documento di Scrum è l’Initial Product Backlog, cioè una lista delle richieste e dei requisiti funzionali e non-funzionali del progetto, espressa in giorni ed ordinata per priorità, assegnata valutando le funzionalità in termini di ritorno dell’investimento. E’ questa una lista non-statica, nel senso che potrebbe cambiare con il trascorrere del tempo, anche perché il livello di dettaglio dipende dallo Spint in cui si è; quello in corso, ovviamente esprime il miglior livello di dettaglio possibile. Inoltre qualsiasi idea o requisito può essere aggiunto al Product Backlog, assegnandogli l’adeguata priorità. Questo approccio consente sia di stemperare gli eventuali attriti che potrebbero crearsi all’interno del Team, sia di sottoporre al confronto il valore della nuova idea, con quello del resto del progetto.

Quando il contenuto del Product Backlog è sufficiente per iniziare le attività, termina lo Sprint 0 e l’elenco del Product Backlog può anche essere trasformato in un documento dei requisiti del progetto.

I Ruoli e lo Scrum Team

Scrum consente di definire un processo che comprende un insieme di ruoli e di attività predefinite. Essenzialmente vi sono tre ruoli fondamentali (o Scrum Team): Product Owner, Scrum Master e Scrum Team. A questi occorre aggiungere gli Stakeholders.

Il Product Owner ha la responsabilità del prodotto dal punto di vista delle funzionalità. Il suo focus è il lato commerciale del prodotto e quindi del ritorno dell’investimento. E’ la persona che fornisce la visone del prodotto al Team, in quanto è colui che meglio conosce le specifiche del progetto; rappresenta tutti gli Stakeholders.
E’ il responsabile del Product Backlog e della consegna del progetto. In genere, rappresenta il committente, gestisce i conflitti sulle priorità con gli altri Stakeholders e l’elenco delle richieste di aggiunta o di modifica. Il suo compito è di garantire che il Team lavori con le informazioni giuste, decide le caratteristiche del prodotto, le date di consegna e la soddisfazione del cliente e degli altri Stakeholders. Inoltre, scrive le informazioni sui vari Product Backlog Item, definisce la loro priorità e li inserisce nel Product Backlog. Partecipa alle revisioni e alle pianificazioni mensili, ma non può modificare le priorità durante lo Sprint. Può essere un membro del Team, ma non può essere lo Scrum Master.

Scrum Master (project manager), non ha il compito di gestire il progetto ha il compito di coordinare il Team di sviluppo, di mediare le comunicazioni con il Product Owner, di gestire i processi associati al progetto, di definire con il committente le funzionalità del prodotto, di gestire gli allineamenti mensili e giornalieri. Inoltre prende le decisioni sulla riduzione o sull’incremento delle cose da fare che sono state concordate durante i diversi meeting.
Svolge un importante ruolo di mediazione, si preoccupa di risolvere gli imprevisti e di rimuovere tutti gli ostacoli quotidiani. Non è il leader del Team, ma lo protegge, affinchè possa concentrarsi con serenità, sulle attività necessarie per completare lo Sprint in corso. Quindi deve essere in grado di creare un gruppo unito, di far rispettare le regole e di far crescere le diverse persone che costituiscono il gruppo di lavoro. Infine dovrebbe essere in grado di individuare tutti gli strumenti necessari per migliorare le risorse, al fine di ridurre i tempi di consegna.

Scrum Team (gruppo di lavoro), è un gruppo interfunzionale che può variare da 5 a 9 persone. In genere comprende un analista, il responsabile della qualità, i progettisti, gli sviluppatori e un responsabile della documentazione. Sono quindi quelle figure professionali che svolgono l’effettivo lavoro (progettazione, sviluppo, test, ecc.). Nella pianificazione mensile lo Scream Team, valuta le cose da fare e si impegna a portarle a termine. Crea un elenco di Sprint Backlog e di Task (micro-attività della durata tra 4 e 16 ore) da effettuare per raggiungere gli obiettivi del mese. Durante il periodo di lavoro mensile si auto-organizza e tiene costantemente traccia dello stato di avanzamento dei task, rendendolo visibile a tutti. Infine, negli allineamenti giornalieri, segnala le criticità allo Scrum Manager, mentre nelle revisioni mensili presenta i risultati del proprio lavoro.

Stakeholders (o parti in causa), sono individui direttamente coinvolti nel progetto, in quanto i loro interessi sono direttamente o indirettamente influenzati o condizionati dal progetto. Questi individui esercitano una notevole influenza sugli obiettivi del progetto, determinano i requisiti, per cui è importante identificarli prima possibile, in modo da comprendere le loro idee e aspettative e nello stesso tempo di poterli poterli informare costantemente sullo stato di avanzamento del progetto. Tuttavia, gli Stakeolders possono effettuare richieste relative all’evoluzione e alla modifica del prodotto, oppure suggerire nuove priorità, ma le loro richieste non verranno prese in considerazione nell’immediato.

Quindi in Scrum, la figura del Project Manager autoritario, che si fa carico dell’intero progetto, che assegna, verifica e pianifica, è stato sostituito, da una gerarchia più flessibile, in cui tutte le parti in causa sono coinvolte, motivate e incoraggiate a risolvere i problemi, al fine di poter portare a termine le attività, in quanto questa metodologia, si adatta meglio alla dinamicità delle attuali organizzazioni del lavoro. Inoltre, alle metodologie tradizionali che richiedevano lunghe fasi di analisi, Scrum contrappone il rilascio periodico di funzionalità dell’applicazione, in modo da poter meglio controllare lo stato di avanzamento e risolvere tempestivamente le problematiche, ma soprattutto favorire il rispetto delle scadenze.

Per comprendere Scrum occorre conoscere come si evolve il suo Processo, ma soprattutto è indispensabile conoscere il significato e il senso di alcuni termini fondamentali.

Scrum è una metodologia agile iterativa e dinamica che consente di pianificare le diverse fasi del progetto, attraverso il planning e la stima del tempo necessario per produrre, ad ogni fine sprint, versioni parziali, ma funzionanti. La durata viene stabilita all’inizio del progetto e non può essere più cambiata, in quanto eventuali variazioni potrebbero rendere difficile calcolare la capacità del team di soddisfare agli impegni.

Quindi, l’obbiettivo del processo di Scrum è di fornire risultati con scadenza tipicamente mensili. Il processo inizia con le attività del Product Owner che crea i contenuti e le priorità, inserendoli nel Product Backlog. Ciò consente di disporre di una serie di elementi da poter analizzare e pianificare durante lo Sprint Planning Meeting.

Il Team inizia le attività quotidiane, mediante la verifica nel Daily Scrum in cui la durata non deve superare i 15 minuti. Successivamente, inizia l’effettivo lavoro scegliendo le Tasks dal Sprint Backlog.
Al termine dello Sprint, che tipicamente ha durata mensile, il Team illustra i risultati delle attività svolte al Product Owner e agli Stakeholders (altri soggetti interessati). Il feedback ottenuto da questa attività, durante lo Sprint Review, si traduce in nuovi contenuti che vengono inseriti nel Product Backlog. Il Product Owner ridefinisce le priorità.

Questa attività consente quindi di discutere sui risultati ottenuti, al fine di apportare le variazioni necessarie prima di passare allo Spint successivo. Il Team, iterando attraverso gli Sprint, sviluppa un prodotto utile e funzionante, a cui nel tempo vengono aggiunte nuove funzionalità, nell’ottica del Working Increment. Il processo di Scrum può essere sintetizzato mediante la seguente rappresentazione grafica:

Il Product Backlog (cose da fare) è la principale lista delle funzionalità del prodotto, è ciò che occorre realizzare. E’ un elenco priorizzato di richieste di funzionalità desiderate per l’intero progetto. Per la stesura di questo elenco non è necessario scendere a livello di dettaglio e neppure che sia completo durante la fase iniziale. Il Product Backlog, contiene:

• i Product Backlog Items, cioè le descrizioni delle caratteristiche richieste dal prodotto
• le Wish-List Items (o lista dei desideri)

il tutto priorizato in base al valore che hanno per il business.
I Product Backlog Item (o più semplicemente Items), sono unità di lavoro sufficientemente piccole, da poter essere completate durante una Sprint Iteration. Gli Items, a loro volta, possono essere suddivisi in una o più Tasks.
Il Product Backlog è di proprietà del Product Owner, che lo crea e lo gestisce. Tuttavia, per definire le priorità nel Product Backlog, il Product Owner, deve avere il supporto del Team di Scrum, al fine di poter stimare, in modo corretto, caratteristi e costi dello sviluppo.
Il Product Backlog deve comprendere, sia le caratteristiche richieste dal cliente, sia i requisiti tecnici necessari per la costruzione del prodotto. Inoltre, gli items di più alta priorità nel Product Backlog, devono essere sufficientemente piccoli, in modo da poter essere facilmente valutati e testati; un ragionevole tempo di sviluppo per un item del Product Backlog è di 10 giorni.

Lo Sprint Backlog è una lista priorizzata di Tasks da completare durante il corrente Sprint. Le singole Tasks, generalmente devono essere definite in modo da poter essere eseguite in un tempo variabile fra 4 e 16 ore di lavoro. Questo alto livello di dettaglio consente al Team di conoscere esattamente cosa occorre fare, in modo che chiunque potenzialmente può scegliere un Task dalla lista. Le Tasks nello Sprint Backlog non sono mai assegnate, ma vengono sottoscritte dai membri del Team in base alla personale competenza e alle priorità indicate.
Lo Sprint Backlog è come se fosse un portafoglio di ordini, di proprietà del Team. Le stime e le valutazioni dello Sprint Backlog sono effettuate dal Team. E’ possibile usare un Task Board per visualizzare e modificare lo stato delle Task del corrente Sprint, in modo che possa assumere uno dei seguenti valori: To-do, In-progress e Done.

Lo Sprint è un periodo temporale, deciso dal Project Manager in accordo con il Team, che può variare da due a quattro settimane. Generalmente ha una durata di 30 giorni, in quanto rappresenta un tempo ragionevole per produrre qualcosa di significativo, anche se non definitivo, da sottoporre a verifica al fine di individuare eventuali criticità. Il tempo in Scrum è quindi suddiviso in cicli di lavoro, denominati Iterazioni, della durata di circa un mese.
Lo scopo di uno Sprint è quello di trasformare una lista del Product Backlog (insieme di requisiti prioritari), in un aumento di funzionalità del prodotto. Ciò significa che per ogni Sprint occorre anche definire lo Sprint Goal, cioè l’obiettivo.

Le attività dello Sprint, denominate Tasks e gli obiettivi, vengono definite all’inizio di ogni Sprint, durante la riunione di Sprint Planning. Durante questo meeting, il Product Owner informa il Team sugli Items nel Product Backlog che devono essere eseguiti. Il Team può quindi determinare quante risorse impegnare per eseguire il successivo Sprint. Durante lo Sprint, i requisiti vengono congelati, per cui non è possibile modificare lo Sprint Backlog.
Il Team può richiedere un supporto a fonti esterne, ma deve essere consapevole degli obiettivi e deve gestirsi in modo autonomo. Lo stato di avanzamento delle attività, può essere tracciato al termine di uno Sprint, mediante il grafico denominato Sprint Burndown.

Cumulative Sprint Backnlog

Durante il meeting relativo allo Sprint Planning, il Team di Scrum identifica e valuta le attività che devono essere completate durante il successivo Sprint. Il totale del lavoro che resta da completare è denominato Cumulative Backlog. Quando, durante il procedere dello Sprint, le diverse attività si completano, lo Scrum Master ricalcola il lavoro che deve essere fatto e lo Sprint Backlog diminuisce. Se al termine dello Sprint, il Cumulative Sprint Backnlog è zero, lo Sprint ha avuto successo.
Anche se durante lo Sprint, gli Items sono bloccati, lo Sprint Backlog potrebbe cambiare, in quanto durante lo sviluppo aumenta la comprensione sul prodotto, per cui potrebbe manifestarsi la necessità di dover svolgere ulteriori attività. Inoltre, durante lo sviluppo potrebbero anche emergere bug o anomalie che potrebbero richiedere ulteriori sviluppi. Tutto ciò potrebbe contribuire ad incrementare il tempo necessario per completare lo Sprint Backlog. In questi casi potrebbe essere utile considerare queste attività in modo separato, rispetto a quelle programate.
Il Product Owner, durante lo Sprint potrebbe collaborare con il Team, per aiutarlo a ridefinire l’obiettivo. Lo Scrum Master e il Team, per evitare di allungare lo Sprint, potrebbero decidere di effettuare modifiche contenute, se ritenute sufficienti.

Gli Artifacts in Scrum sono: il Product Backlog, lo Sprint Backlog, i Burndown Charts e gli Impediment Backlog.

In un precedente articolo relativo alla descrizione di come si evolve un processo in Scrum ho già descritto il Product Backlog e lo Sprint Backlog. Prima di completare l’argomento sugli Artifact in Scrum è fondamentale introdurre un uleriore concetto: la User Story (o semplicemente Story).

Le User Story descrivono ciò che deve essere realizzato in un progetto, sono una dichiarazione informale di requisiti, usate per descrivere aspetti funzionali e non funzionali; quindi non descrivono come verrà svolto il lavoro del Team di sviluppo. In genere sono formulate con una o più frasi di uso comune. Ogni User Story è di contenuto limitato, per cui può facilmente essere scritta su post-it. E’ un modo rapido per gestire le esigenze dei clienti, senza dover elaborare lunghi e formalizzati documenti. Il fine è quello di essere in grado di rispondere, in modo rapido, all’evoluzione delle esigenze del cliente.

La User Story non ha un formato standard, tuttavia generalmente comprende: un titolo, una breve storia (di solito un breve racconto che descrive le caratteristiche desiderate), uno screen (se è prevista una scheda di interfaccia) e una breve descrizione di come deve essere fatto il test. Un esempio di User Story è il seguente:

• Title: introduce una nuova foto in album
• Description: introdurre una nuova foto e successivamente, una seri di metadati; dopo aver introdotto i valori, ritornare alla pagina precedente.
• Screen: http://www.antoniosammartino.it/foto.html
• How to Test: caricare una foto e verificare I contenuti nel database.

I Burndown Charts
Il Burndown Chart consente di conoscere i progressi giornalieri, mentre il Product Burndown Chart mostra come mensilmente varia lo sprint.

Il Burndown Chart è utilizzato per mostrare nel tempo, il lavoro che occorre effettuare. Il lavoro è posto sull’asse Y, mentre il tempo sull’asse X. L’andamento del lavoro da effettuare potrebbe andare su e giù, ma tendenzialmente dovrebbe andare verso il basso.
Le attività da elaborare possono essere visualizzate nell’unità di misura che il Team preferisce: Story Points, Ideal Days, Team Days, ecc. In generale i Team di Scrum preferiscono usare come unità di misura lo Story Point, cioè un valore relativo non correlato con le ore, al fine di rappresentare la misura della complessità di un’attività, comparata con la durata necessaria per raggiungere un obiettivo.
Lo story point è comunque in grado di indicare, mediante una semplice relazione, quanto tempo è trascorso per completare uno Sprint. Per esempio, da uno Sprint dalla durata di 30 giorni, a cui ha partecipato un Team di 6 programmatori, che hanno consumato 200 Story Points, è possibile ricavare le ore lavorate nel seguente modo:

30 giorni x 8 ore= 240 ore x 6 developers = 1440 ore / 200 story point = 7 ore per Story Point.

La denominazione Story Points deriva dal fatto che questa unità di misua è spesso usata con le User Stories.

Impediment Backlog
Un impedimento in Scrum è un ostacolo che sta bloccando o rallentando il procedere delle attività del Team. Gli impedimenti vengono presentati e discussi nel Daily Scrum, se possono essere risolti velocemente, con l’aiuto di un collega oppure possono emergere alla fine dello Sprint, durante lo Sprint Retrospective, in quanto richiedono l’adozione di una serie di step specifici. In questi casi, gli Items vengono aggiunti nel Product Backlog.
L’Impediment Backlog, estende il concetto di rimozione degli ostacoli nei confronti del Team. Infatti, come il Product Owner è il proprietario del Product Backlog, lo Scrum Master è il proprietario dell’Impediment Backlog, nel senso che è sua responsabilità stabilire quando un impedimento deve essere aggiunto, quale è il livello della sua importanza e quando effettivamente può essere rimosso. Ciò consente al Team di avere la visibilità sugli impedimenti e dei progressi per giungere alla loro rimozione dalla lista. Durante il Daily Scrum i membri del Team comunicano gli ostacoli che hanno incontrato. Questi ostacoli vengono aggiunti all’Impediment Backlog.

Lo Scrum Master esamina la lista degli impedimenti e determina quale è di più alta priorità e si assume la responsabilità di rimuoverli, soprattutto se non svolgono anche attività di sviluppo. Tuttavia, anche i membri del Team possono assumersi l’onere di rimuovere gli ostacoli dall’Impediment backlog, specialmente se sono di alta priorità perché bloccano lo Sprint. Il membro del Team che ha identificato l’impedimento ha la responsabilità di stabilire quando l’ostacolo è stato effettivamente rimosso.
L’Impediment Backlog è molto semplice da implementare, ma molto potente se applicato in modo corretto, in quanto consente al Team di concentrarsi su specifici impedimenti, piuttosto che lasciarsi travolgere dagli ostacoli.

Lo Sprint Planning, ha l’obiettivo di identificare i possibili Backlog da completare e di definire sia le funzionalità, sia le mansioni. Durante questo meeting lo Scrum Master, il Product Owner e il Team si riuniscono per determinare su quali funzionalità del prodotto il team dovrà lavorare. Il Product Owner identifica le funzionalità, mentre il Team fornisce una stima dei tempi, al fine di determinare la fattibilità. Durante lo Sprint Planning vengono decisi i Product Backlog da realizzare, successivamente nessuno li può modificare. Tuttavia se lo Sprint non può essere portato a termine, lo Scrum Master può interromperlo ed organizzare un nuovo Sprint Planning. Lo Sprint può anche essere interrotto se le condizioni esterne cambiano in modo sostanziale o se il Team è disturbato da elementi esterni. Infine, se il Team ritiene di non riuscire a completare i Product Backlog pianificati, può contrattare con il Product Owner al fine di richiedere la rimozione di alcuni elementi.

Lo Sprint Review consente, alla fine di ogni Sprint, di effettuare un controllo sull’andamento del progetto. Il meeting, della durata max di un’ora, inizia con un membro del Team che illustra l'obiettivo dello Sprint, l’incremento di funzianalità del prodotto e comunica gli eventuali problemi che si sono verificati durante lo Sprint. I partecipanti al meeting, dopo aver ricevuto le necessarie informazioni, possono suggerire come procedere, formulare eventuali richieste di miglioramento o aggiungere nuove funzionalità, partendo dall’osservazione concreta del prodotto. Durante questa fase il Team può contribuire a prendere le decisioni, in quanto conosce i punti deboli e di forza del prodotto.
Anche gli Stakeholder possono richiedere funzionalità non previste o che non rispettano le specifiche e quindi sollecitare una nuova pianificazione.
Il Product Owner, dopo aver ascoltato le richieste, riorganizza le priorità per il prossimo Sprint. Infine, al termine della riunione, lo Scrum Master fissa la data e scegli le persone che dovranno partecipare alla prossima riunione.

Lo Sprint Retrospective è il meeting finale dello sprint. Consente allo Scrum Master e al Team, di identificare cosa occorre cambiare per rendere più produttivo il successivo Sprint. Quindi, mentre lo Sprint Rewiew è incentrata sul prodotto, guarda a “cosa” il Team sta costruendo, mentre lo Sprint Retrospective focalizza l’attenzione sul processo, guarda a “come” viene costruito il prodotto, cioè come il Team lavora, il livello di competenze, gli strumenti che vengono utilizzati, per cui tutto ciò che appare essere interessante diventa argomento di discussione. A questo meeting partecipano il Product Owner, lo Scrum Master e il Team. Questo meeting è molto importante, in quanto consente al Team di migliorare con il trascorrere del tempo.

Daily Scrum Meeting. Questa riunione, della durata max di 15 minuti, generalmente si svolge la mattina, prima dell’inizio delle attività, in modo da consentire ai diversi componenti del team di soffermarsi su ciò che hanno fatto nel giorno precedente, di comunicare cosa intendono fare oggi e di aggiornare sull’avanzamento delle attività e sui problemi incontrati, in modo da consentire allo Scrum Master di prenderne nota, al fine di rimuovere gli ostacoli. Chi per qualche motivo non può essere presente, deve comunque comunicare il suo stato di avanzamento lavoro. Tutti possono partecipare a questa riunione, ma solo chi è direttamente coinvolto nel progetto può parlare. Questa breve riunione è molto importante, in quanto consente di evidenziare subito i problemi e di condividerli, inoltre consente di rimuovere le incomprensioni e di chiarire costantemente gli obiettivi da raggiungere. La riunione viene tenuta in piedi, al fine di favorire l’attenzione.
I membri del Team devono essere rapidi nell’esposizione, parla una sola persona per volta, non si devono fare domande, non si discute e non si divaga, in quanto l’obiettivo della riunione è quello di comunicare. Se un membro del Team segnala qualcosa di interessante o se richiede l’assistenza di altri, occorre fornire una risposta immediata, ma la discussione deve continuare in una sede diversa.Il responsabile della riunione è lo Scrum Master. In estrema sintesi questo meeting ha l’obiettivo di rispondere a tre domande: cosa ho fatto ieri, cosa farò oggi, quali ostacoli ho incontrato.