Scrum - il framework agile applicabile

Scrum - il framework agile applicabile

Premessa

Lo studio strutturato dell'informatica prevede una fase che si può definire "meta processo", cioè la conoscenza di alcuni metodi utili a gestire il ciclo di sviluppo software. Come tanti paradigmi di questa scienza anche quelli riguardanti l'ingegneria del software sono soggetti a rapida evoluzione o rapida obsolescenza, spesso anche soggetti a "mode". Questi ultimi aspetti spesso rendono difficoltosa l'adozione di questi paradigmi a causa della loro rapida obsolescenza. La necessità (ampiamente dimostrata in letteratura) di adozione di un modello nello sviluppo software  impone un lavoro di ricerca e sperimentazione di queste metodologie per trovare quella che meglio si addice alle specifiche esigenze dettate dal dominio, dai linguaggi usati, dai macro-requisiti che si hanno. Metodologia che va approfondita e adattata.

Introduzione

Scrum è un framework per lo sviluppo di progetti complessi.

E' costituito da un insieme di metodologie recenti e best practices orientate alla gestione e di tutte le fasi necessarie alla realizzazione di progetti di qualunque tipo.

Può essere applicato nell'implementazione di qualunque settore con la produzione di beni o servizi, può essere applicato a piccoli team di 4 o 5 persone e a grandi community di 60 persone.

Principi base

- Controllo empirico sul progetto

- Auto-organizzazione

- Collaborazione

- Gestione delle priorità

- Time-boxing

- Sviluppo iterativo

Ruoli

I ruoli si suddividono in due macro categorie: Core (quelli obbligatori per la realizzazione del prodotto o del servizi) sono persone completamente dedicate al progetto.
Ruoli "Non Core" s(non obbligatori e possono includere membri del team che hanno interessi nel progetto).

Ruoli Core

"Product Owner" (committenti o esperti interni di prodotto). Il cliente fornisce al "Product Owner" i requisiti del prodotto mediante interviste. Il P.O., mediante consegne incrementali al cliente, integra il business di questo con la soluzione sviluppata. Il P.O. fornisce allo "Scrum Master" i requisiti di business in base alle priorità creando il "Prioritized Product Backlog" e definisce i "Criteri di Accettazione"

"Scrum Master" assicura allo scrum team un ambiente di lavoro ottimale al raggiungimento degli obiettivi.

"Scrum Team" crea i "Deliverable" del progetto e illustra l'incremento di prodotto al P.O. nel corso dello "Sprint Review Meeting".

Ruoli non Core

"Stakeholder"

"Scrum Guidance Body"

"Venditori"

"Chief Product Owner"

"Chief Scrum Master"

La comunicazione

Per la condivisione della conoscenza per allineare tutti i membri del team sulla metodologia si suggerisce di adottare questa guida:

scrumstudy-sbok-guide-3rd-edition-Italian

Altri elementi utili alla comunicazione:

Scrumboard

Sprint Burndown Chart

Devono essere condivisi e sempre disponibili.

In pratica

"Sprint" sono brevi periodi di tempo in cui una certa quantità di lavoro deve essere fatta.

"Prioritized Product Backlog" contiene una lista con le priorità dei requisiti di progetto e di business scritte come "User Stories", queste cominciano con lo "Spring Planning Meeting".

Le "User Stories" vengono analizzate e validate nello Sprint e sono un sistema di analisi molto efficace.

Un esempio di "User Stories" relativo ad un sito di e-commerce: gli attori (la componente che compie azioni) sono "i clienti" e il "manager del sito".

Un esempio di "User Stories" relativo ad ristorante: gli attori (la componente che compie azioni) sono "il cameriere", "lo chef", "il patron" nell'accezione di cliente, "il cassiere".

Ogni Sprint generalmente dura da una a massimo sei settimane. Gli Sprint coinvolgono il team e lo portano a produrre dei manufatti detti "deliverables".

Ogni giorno si fa un meeting breve, "Daily Standup Meeting" fortemente focalizzato su specifici aspetti, preferibilmente in piedi, per analizzare problemi e progressi.

Alla fine di ogni Sprint va fatto un "Sprint Review Meeting". In questo meeting il committente o gli esperti di prodotto interni ottengono una dimostrazione dei deliverables.

Il committente o gli esperti di prodotto interni sono chiamati ad accettare i deliverables solo se soddisfano i "Criteri di Accettazione" definiti in precedenza.

Il "Retrospect Spring Meeting" è l'incontro dei membri del team, a valle dello "Sprint Review Meeting", per migliorare il processo e le performance del gruppo di lavoro.

I vantaggi

- Il processo di sviluppo diviene "Customer centrico" con le esigenze del cliente sempre presenti e aggiornate grazie alla partecipazione attiva di clienti, stakeholders, product owner ecc.
- Vengono definiti dei ruoli indispensabili ad avere degli interlocutori adeguati e dotati di un "linguaggio" adatto a rendere comprensibili le interazioni fra le parti.
- Le demo negli "Sprint Review Meeting" danno la percezione del procedere del progetto ai Product Owner consentendo a questi di fornire un supporto critico e dinamico ottenendo quello che viene detto "Continuous Improvement".
- I "Daily Standup Meeting" spingono i problemi bloccanti ad essere comunicati quanto prima consentendo la fornitura di soluzioni prima che si incancriniscano.
- I ritmi degli Sprint vengono adattati al ritmo dei componenti del team. 
- Si ottiene forte motivazione grazie ai confronti frequenti dati dai "Daily Standup Meeting" e dai "Retrospect Sping Meeting"







Quest'opera è distribuita con Licenza Creative Commons Attribuzione 4.0 Internazionale (CC BY 4.0) - Condividi allo stesso modo