Per anni lo sviluppo software ha previsto una fase iniziale piuttosto laboriosa che comprendeva la creazione di numerosi grafici colorati, denominati Gantt.

Questi grafici, ideati da Henry Gantt, risalgono al 1910 e vennero utilizzati durante la Prima Guerra Mondiale dal generale William Crozier, che all’epoca ricopriva il ruolo di “Chief of Ordnance for the US Army”.

Bene, chiunque abbia studiato tale guerra sa che l’efficienza organizzativa non è stata esattamente una caratteristica predominante del conflitto.

Viste queste premesse allora come mai tale artefatto della Prima Guerra Mondiale è riuscito a diventare uno strumento tanto utilizzato nel Project Management del XXI secolo?

La risposta è molto semplice: si tratta di uno strumento visivamente affascinante, tutto il lavoro infatti doveva essere riprodotto su un grande progetto e tutti potevano vederlo.

Seppur molto intrigante e suggestiva questa metodologia di pianificazione spesso al primo impatto con la realtà tende a mostrare i suoi difetti, e purtroppo i manager invece di rivedere il loro modo di pensare e la progettazione
preferiscono lasciare che il piano sembri funzionare, andando avanti per la loro strada.

Tale modo di fare spesso ha portato e continua a portare a fallimenti clamorosi: uno dei casi più eclatanti è il “Progetto Sentinel” dell’FBI, pianificato nel 2005 per una durata di 4 anni con un costo di 451 milioni
di dollari e che 5 anni dopo risultava essere sviluppato a metà, con un effort economico aggiuntivo di altri 350 milioni di dollari, ma potremmo citarne anche tanti altri.

Da qui la metodologia SCRUM, nata proprio per sopperire a queste situazioni.

Essa ha il vantaggio di rendere infatti la pianificazione di un progetto software più aderente alla realtà e si basa su come le persone lavorano realmente e non su come dicono di lavorare.

L’idea iniziale nasce dal lavoro di due professori di economia Giapponesi, Hirotaka Takeuchi e Nonaka Ikujiro, i quali avendo osservato i team di alcune delle più grandi compagnie di prodotti innovativi del mondo hanno rilevato come i più produttivi fossero quelli in cui i manager fungevano da “servant-leaders”, cioè delle figure con il compito di eliminare gli ostacoli incontrati dai team durante lo sviluppo del loro prodotto.

Jeff Sutherland in seguito nel 1995 ideò e standardizzo il modello, dando alla metodologia un nome che deriva dal medesimo termine del rugby, che indica il modo in cui una squadra lavora insieme per muovere
la palla lungo il campo: SCRUM

SCRUM fonda le sue radici nella filosofia orientale e più precisamente nel concetto denominato (in Giappone) Shu Ha Ri, che sostiene che una cosa (in generale, le arti marziali, in questo caso la metodologia) viene veramente appresa
solo esercitandosi e applicandola.

Tale Approccio richiede pratica e attenzione e una continua ricerca per raggiungere un livello superiore, livello in cui le cose semplicemente fluiscono ed accadono.

Filosofico si, ma molto chiaro: per poter padroneggiare la metodologia, fare innovazioni e migliorie al processo ed infine dimenticarsi delle regole e della “forma”, è necessario applicarsi e praticare.

COMPONENTI FONDAMENTALI

Le componenti fondamentali per poter applicare la metodologia Scrum sono le seguenti:

• Product Owner: è la persona che ha la visione completa di quello che bisognerà fare. E’ il responsabile dell’andamento del progetto.
• Team: le persone che concretamente svolgeranno il lavoro che hanno le conoscenze specifiche per poter affrontare le attività. Il team deve essere il più piccolo possibile, dalle 3 alle 9 persone per poter
  lavorare correttamente.
• Scrum Master: è la persona che spiegherà al resto del gruppo i dettagli della metodologia SCRUM e che aiuterà il team ad eliminare tutto ciò che potrebbe essere d’intralcio e rallentare il lavoro.
• Product Backlog: è una lista ad alto livello di attività da realizzare per portare la “vision” del Product Owner a compimento. In ogni momento il Product Backlog è l’unico e definitivo riassunto di tutte
  le attività che il team deve svolgere, in ordine di priorità.

Ogni attività riportata nel Product Backlog deve essere: completa di tutte le informazioni necessarie, piccola abbastanza da poter essere stimata, e deve essere possibile rilasciarla come entità completa per mostrarla al Product Owner.

Una attività non va mai stimata in ore ma in Story Points che possono essere rappresentati da una sequenza di Fibonacci, per valutarne la complessità.

• Sprint Planning: questa è la prima delle riunioni previste dalla metodologia: tutte le figure coinvolte pianificano lo Sprint.

Gli Sprint hanno sempre una lunghezza fissa (tipicamente due settimane), Il team seleziona dal Product Backlog una serie di attività che possono andare a ricoprire l’intera durata dello sprint (secondo le stime fatte precedentemente) e le
inserisce nella to-do list.

Dopo alcuni Sprint è possibile estrarre dei dati per valutare la velocità del gruppo di lavoro, parametro che lo Scrum Master e il team devono cercare di migliorare per gli sprint successivi.

• Daily Stand-Up: ogni giorno alla stessa ora e per non più di quindici minuti, Team e Scrum Master rispondono a turno a queste domande: Cosa ho fatto ieri? Cosa farò oggi? Quali impedimenti ho riscontrato nel raggiungere il mio obiettivo?

Grazie a questa routine ogni membro del gruppo conosce esattamente l’andamento dello Sprint e questo gli consente di apportare delle misure correttive.

• Sprint Review: è la riunione nella quale il team mostra il risultato ottenuto a fine Sprint. Il team deve mostrare solo i task che sposano completamente la definizione di Done, cioè qualcosa che è completamente
  finito, e che può essere rilasciato senza ulteriore lavoro.
• Sprint Retrospective: al termine dello Sprint Review, il Team e lo Scrum Master si riuniscono per discutere l’andamento dello Sprint, analizzando eventuali problematiche e definendo insieme una sola miglioria
  da portare nel successivo Sprint.

Tale metodologia è utilizzata ormai da tutte le più grandi aziende informatiche del mondo, e non solo, perché pur essendo nata come sistema per la gestione dello sviluppo di soluzioni software, Scrum viene oggi utilizzata per gli scopi più
disparati: dalla gestione dei flussi produttivi di prodotti di ogni genere ad ambiti educativi e di governo.

Per una volta quindi mettete da parte i soliti Gantt di progetto, adottate la metodologia SCRUM e fateci sapere il risultato!