Skip to content
ScrumItalia.org

Diventa SCRUM MASTER con la certificazione completa in lingua italiana

Primary Navigation Menu
Menu
  • Certificazioni
  • Online Training
  • Newsletter
  • Blog
  • Risorse
    • SCRUM
    • AGILE
    • Kaizen
    • Six Sigma
    • Project Management

Pensare AGILE – breve introduzione nella metodologia

In: AGILE, SCRUM
Tagged: Burndown chart, daily scrum, Product Backlog, Scrum Events, Scrum Master, Scrum Team
Agile vs Waterfall

Pensare “Agile”

Pensare Agile – La metodologia Agile è fortemente focalizzata sul prodotto da realizzare piuttosto che sul processo per realizzarla e considera le variabili “Qualità”, “Tempo” e “Costi” non negoziabili spostando la flessibilità verso le Funzionalità del prodotto.

Agile vs Waterfall

Detto così sembra essere contraddittorio ma in realtà l’obiettivo è quello di realizzare un prodotto che soddisfa il cliente per le sue caratteristiche essenziali e non in tutte le funzionalità.

Il gruppo di lavoro

Siccome bisogna essere agili, il gruppo di lavoro deve essere piccolo (5/10 membri) e i suoi componenti devono essere competenti, autonomi e focalizzati sul progetto (quindi la qualità e la disponibilità delle persone coinvolte deve essere elevata).
Membri essenziali del team sono (le terminologie variano tra le metodologie):

  • Project Manager (in Scrum, Scrum Master) ha un ruolo di coordinamento e il suo obiettivo fondamentale e mettere in condizione il Team di Sviluppo di operare a pieno regime
  • Business Analyst ha il compito di tradurre i requisiti di Business in funzionalità del prodotto e passare queste allo sviluppo
  • Business Ambassador (in Scrum, Product Owner) ha il compito di definire insieme al Business Analyst i dettagli del prodotto fornendo la visione di dettaglio dal lato del Business
  • Team di Sviluppo è il gruppo di lavoro che fisicamente realizza il prodotto.

Attorno a questo gruppo possono operare anche altre figure.

Team Agile

Le specifiche del prodotto

Nella metodologia Agile, la realizzazione del prodotto è lo scopo primario, quindi tutte le attività che non sono focalizzate su questo obiettivo vengono ridotte al minimo.
Qualcuno interpreta questo principio come “progetto senza documentazione”: niente di più lontano dal vero. Nei progetti Agili si documenta il prodotto in ogni sua vista ma lo si fa usando un approccio molto pragmatico. I requisiti sono descritti in “Stories” che raccontano in linguaggio non formale cosa deve fare il prodotto e i criteri di verifica. Le “Stories” sono raccolte in “Epic” e vengono elencate nel “Product Backlog”.

Epic/User stories


Dalle “Stories”, che vengono discusse e approfondite in incontri plenari, si generano i “Task” che sono assegnati al team di sviluppo.

La realizzazione del prodotto

Il prodotto non viene realizzato con un unico processo ma attraverso una serie di cicli di rifinitura (detti “Sprint”) che da un lato aggiungono nuove funzioni, dall’altro raffinano quelle esistenti.

Scrum framework


Gli Sprint hanno durata prefissata (2/4 settimane) e hanno un elenco di Task da realizzare che vengono raccolti dal Project Manager in base alla priorità indicate dal Business Analyst e dal Business Ambassador (“Sprint plan”, “Sprint Backlog”).
Il Team di Sviluppo sviluppa le funzionalità del prodotto realizzando i Task presenti nello Sprint Backlog senza un piano preciso ma in base alla effettiva disponibilità e capacità dei suoi membri, garantendo quindi una occupazione a pieno regime .

Il processo di sviluppo

Ogni giorno il team di sviluppo si allinea (“Daily meeting”) e condivide il piano di lavoro ed evidenziando eventuali criticità (“Impediments”)
Ogni Task parte con stato “To do” e passa in “Doing” per poi finire in “Done” dopo averlo verificato sulla base dei criteri di accettazione indicati. L’effetto che si ottiene è quello dello svuotamento della lista dei Task che può essere controllato con una lavagna che conta i Task da risolvere all’interno dello sprint (“Burndown chart”).

Burndown chart


Finita la durata dello Sprint le funzionalità vengono presentate (“Demo”) al Business Analyst e al Business Ambassador che verifica cosa è stato effettivamente prodotto. Quindi si fa una review dello Sprint: si vede lo stato di risoluzione dei Task, si valuta la effettiva capacità, si discute dei problemi incontrati e si prepara lo Sprint successivo.
In base al piano dei rilasci (un Rilascio può contenere le funzioni di diversi Sprint) e all’effettivo stato dello sviluppo, si rilasciano le funzionalità per un UAT esterno al team.

Confronto tra metodologia Agile e Waterfall (approccio tradizionale)

Non esiste un modo migliore per gestire i progetti, entrambi gli approcci sono validi e consolidati negli anni, tuttavia può essere utile una tabella comparativa che permette anche di capire quando è conveniente usare un approccio o un altro.

 AgileTradizionale
SoluzioneMiglioramento continuo delle funzionalitàCompletamente prevedibile e definibile
PianificazioneNumerosi rilasci ravvicinatiDefinita a priori in ogni sua fase
ControlloDemandato al gruppo di lavoroCentralizzato su PM
Priorità risultatiSoluzioneObiettivi
Gruppi di lavoroStabili con grande autonomiaDinamici e con scarsa autonomia
Stile di gestioneLeadership e collaborazioneControllo completo
ComunicazioneInformale e continuaFormale e pianificata
Ruolo ClienteCriticoimportante

Quando usare una metodologia Agile

Pensare Agile garantisce flessibilità al cambiamento ma questa caratteristica ha dei costi che il Business deve avere sempre presente:

  • E’ indispensabile che vi sia una stretta e continua collaborazione tra Business e Team di Sviluppo in quanto la definizione dei dettagli delle funzionalità avviene in modo altamente destrutturato per garantire velocità e risparmio di tempo.
  • Può accadere che le funzionalità a più bassa priorità non vengano realizzate perché le risorse non erano sufficienti. Ecco perché la gestione delle priorità assume una importanza fondamentale come il ruolo e le capacità del Business Analyst.

L’esperienza del Project Manager può fare la differenza tra un progetto di successo o meno e il pensare Agile è il metodo che permette l’ottimizzazione delle performance del team

2020-02-04
Previous Post: SCRUM Team – i 3 ruoli presenti all’interno della squadra
Next Post: Regole SCRUM – le 12 regole di base

Vuoi diventare un Scrum Master certificato ?

Prova il nostro test gratuito

Categories

  • AGILE (4)
  • Certificazioni (1)
  • English (8)
  • Kanban (1)
  • Project Management (2)
  • SCRUM (7)

Tags

Agile planning agile principles Burndown chart Cross fertilization CSM SCRUMALLIANCE daily scrum daily standup Development Team Increment Items Kanban dashboard PMI-ACP Product Backlog Product Owner project management PSM SCRUM.ORG Scrum Scrum Basic Rules Scrum Events Scrum Master Scrum Rules Scrum Team Self-transcendence Sprint Sprint Backlog Sprint goal Sprint Planning Sprint Retrospective Sprint Review story point
  • Home
  • Certificazioni
  • Online Training
  • Blog
  • Risorse
  • Newsletter
  • About
  • Privacy Policy

Certificazioni

Home

Stay in touch

Designed using Dispatch Premium. Powered by WordPress.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok