The Dark Side of .NET Programming

Il blog di Michele Aponte
posts - 212, comments - 145, trackbacks - 16

ALM Day: Paolo Ruffini e Davide Vernole in ‘Scrum e metodologie agili’.

Davide e Paolo si pongono l’obiettivo di spiegarci le possibilità di adozione di metodologie agili nei nostri progetti, con tutti i problemi e i benefici del caso.

Si parte dal cliente, da cui acquisiamo requisiti, funzionalità e aspettative temporali, nonchè costi. Poi c’è il team di sviluppo, che mette in campo tecnologia, skill, agilità e Mood. C’è poi il project management con budget, gestione risorse, tracciabilità. Questo è l’ecosistema, l’ambiente in cui stiamo lavorando.

Adottare una metodologia agile ha i seguenti vantaggi:

  • migliorare reattività, qualità e tracciabilità
  • normalizzare team e approccio progettuale

Quale metodologia adottare? Dipende dall’attitudine e dalla situazione attuale. Sicuramente deve soddisfare le nostre necessità e non sceglierla per moda…

Quando facciamo un progetto la variabile umane è quella più determinante nei risultati ottenuti, a parità di metodologie. Di solito ci troviamo di fronte alla sindrome dello studente: si parte con calma, si arriva in ufficio con calma…poi ci si avvicina alla scadenza e lì cominciamo a buggare continuamente perchè il livello di stress si alza vertiginosamente. Quindi una consegna lunga può portare a problemi dovuti a questa sindrome.

Una soluzione può essere SCRUM: è un framework interattivo che permette la gestione di lavori complessi. Ne esiste un template, anzi tre, per TFS. Un processo SCRUM è incentrato sul cosa c’è ancora da fare. Il product Owner decide le funzionalità da realizzare, lo SCRUM Master è il responsabile dell’adozione della metodologia nel team e funge da interlocutore tra il product Owner e il team.

Si parte dalla preparazione: user story, vision, productbacklog (elenco di tutte le funzionalità attese ordinate per priorità dal product owner), piano di rilascio iniziale, identificazione degli SPONSOR, composizione del team e logistica. Si parte dal product backlog smarcate con le prime SPRINT: ci si riunisce (per 8 ore) e si fissa la durata della prima scadenza (sprint) che dovrebbe essere di 15 giorni, max 30. Nel prima parte del meeting ci si dice COSA si aspetta il cliente. nella seconda il team decide COME farle. Il ciclo è giornaliero: ci si incontra tutti i giorni (daily meeting) e si fa il punto della situazione, se ci sono problemi tutto il team lo sa, tutto il team sa a che punto siamo. Si rilascia la prima versione e si fa uno SPRINT REVIEW seguito da uno SPRINT RETROSPECTIVE spiegando cosa ha funzionato e cosa no in modo da correggere il tiro per lo sprint successivo. A questo punto si ricomincia! La cosa importante è che rilasciando funzionalità stiamo dando valore al CLIENTE!

A questo punto scadenze brevi annullano l’effetto della sindrome dello studente e il livello di stress del team rimane costante.

Come si fa ad adottare in un’azienda che non sia una startup? Si parte da un piccolo team che adatta la metodologia alle proprie necessità. Dopodichè gli altri team adottano la versione modificata della metodologia: chiamiamola contaminazione dei team!

TFS ci offre integrazione con vari prodotti della famiglia office, il che aiuta le figure non tecniche a seguire la metodologia: project ed excel ad esempio.

Non dimentichiamo che dobbiamo gestire i costi dell’adozione della metodologia, per restare nei budget e concorrenziali sul mercato. Grazie alle metriche di valutazione e la reportistica di TFS possiamo fare un’analisi delle tempistiche e dei costi sui progetti precedenti e riuscire a stimare i nuovi tempi.

Abbiamo un po’ sforato i tempi…ma ne è valsa la pena!

Print | posted on martedì 3 novembre 2009 23:53 |

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET