L'approccio Agile in 1000 parole

Le metodologie “Agili” oggi sono sinonimo di innovazione.
In 1000 parole e con molti riferimenti pratici, cerchiamo di rispondere alla domanda: “Cosa vuol dire essere Agili"?.

Concept.by, che spesso viene interpellata quando si opera in modo innovativo, opera da diversi anni utilizzando queste metodologie e può vantare già una discreta serie di casi di successo, alcuni dei quali presso grandi aziende, anche con gruppi di lavoro internazionali. Quindi abbiamo pensato di scrivere un articolo molto pratico (1000 parole), in grado di dare alcune informazioni fondamentali, come spunto di riflessione, in risposta alla domanda che più spesso ci viene rivolta su questo tema.
Per qualsiasi approfondimento vi invitiamo a contattarci.

 

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.

Vincoli in Agile

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.

 

Gruppo di lavoro 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”.

Esempio 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.

Sprint Agile
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”).

Agile 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 approccio Agile e 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.

  Agile Tradizionale
Soluzione Miglioramento continuo delle funzionalità Completamente prevedibile e definibile
Pianificazione Numerosi rilasci ravvicinati Definita a priori in ogni sua fase
Controllo Demandato al gruppo di lavoro Centralizzato su PM
Priorità risultati Soluzione Obiettivi
Gruppi di lavoro Stabili con grande autonomia Dinamici e con scarsa autonomia
Stile di gestione Leadership e collaborazione Controllo completo
Comunicazione Informale e continua Formale e pianificata
Ruolo Cliente Critico importante

 

Quando usare una metodologia Agile

L'approccio 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à (ricordiamo che “Devil is in details”) 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.

 

Diversi approcci Agili

Attualmente sono stati sviluppati diversi approcci Agili che si adattano in particolare allo sviluppo di applicazioni software ma che in realtà possono essere utilizzati in contesti diversi: Agile PM, Scrum, eXtreme Programming (XP), Kanban, …

Tuttavia è bene tenere presente che la metodologia Agile si basa su alcune best practices e strumenti sviluppati negli anni e può essere adattata alle diverse circostanze (progetti e clienti).

 



Richiesta informazioni


Ti informiamo che, per migliorare la tua esperienza di navigazione su questo sito, sono utilizzati cookie tecnici e cookie di terze parti e non cookie di profilazione.
Alla pagina privacy avere maggiori dettagli ai sensi dell'art. 13 del Codice della privacy.
Cliccando su 'Accetto' i cookie saranno attivati Accetto