Nel corso di questi mesi abbiamo parlato dell’ALM in chiave Agile, evidenziando framework, approcci, best practice, strumenti e attività pratiche.

Inauguriamo, ora, una serie di post che hanno l’obiettivo di fornire una “soluzione tipo” per utilizzare Scrum e TFS (Team Foundation Server / Visual Studio Online) per la gestione di un progetto di media complessità. Prima di iniziare è, però, utile fare una precisazione: non si tratta di una soluzione “chiavi in mano” ma di un case-study che si può analizzare e che va adattato al proprio contesto. Inoltre la scelta di Scrum e TFS è dettata dalla volontà di abbracciare il framework Agile più diffuso e il miglior software di supporto all’ALM attualmente disponibile (fonte Gartner’s Magic Quadrant).

Scrum e TFS, ALM leader

Inoltre, anche se potrebbe sembrare ripetitivo, accenneremo ai fondamenti di entrambi, evitando al lettore di “saltare” sul web per cercare informazioni base relative.

Allora… cominciamo!!

Pt.1, ALM: Scrum + TFS ed oltre

La complessità del software ha raggiunto nell’ultimo decennio un livello tale da considerare oggi la sua produzione una delle attività più onerose e difficili da realizzare.

Riferendosi al framework Cynefin [post relativo], un sistema è definito “complesso” quando non può essere modellato secondo un approccio lineare (matematicamente secondo equazioni lineari) perché il funzionamento olistico è più della somma del funzionamento delle singole parti, dipendendo anche dalla sua evoluzione/storia.

Questo ragionamento si applica all’intero ciclo di vita del prodotto, richiedendo la definizione di una strategia complessiva e di tattiche specifiche che si applicano alle varie fasi di gestione della vita di un software, dalla progettazione allo sviluppo, fino ad arrivare alla sua dismissione: Application Lifecycle Management, appunto.

Volendo riportare una buona definizione di cos’è l’ALM (ne esistono diverse, con focus differenziato sui vari aspetti), possiamo affidarci a Wikipedia:

“Application Lifecycle Management (ALM) is a continuous processof managing the life of an application through governance, development and maintenance. ALM is themarriage of business management to software engineering made possible by tools that facilitate andi ntegrate requirements management, architecture, coding, testing, tracking, and release management.”

Ma qual è il “core” dell’ALM? Soddisfare le esigenze del cliente (stakeholder), fornendo gli strumenti e le pratiche utili a catturare i feedback e a riorganizzare le attività in funzione della loro priorità. E qui il connubio con l’Agile è assolutamente evidente e “naturale”.

Application Lifecycle Management

In particolare, tra le diverse metodologie e i diversi framework Agile adottati, Scrum si è imposto nell’ultimo decennio come riferimento per un approccio moderno alla gestione dello sviluppo del software.

Scrum Process

Il successo è dovuto ad un fattore principale: Scrum funziona ed è in grado di adattarsi a contesti fortemente eterogenei. Questo grazie al fatto che la metodologia creata da Ken Schwaber e Jeff Sutherland definisce una serie di ruoli, artefatti e momenti di riflessione/analisi, lasciando “libero” il Team di applicarli al proprio contesto. Attenzione: ciò non vuol dire che vige l’anarchia perché Scrum è difficile da implementare correttamente e va applicato nella sua interezza, altrimenti non si sta utilizzando Scrum! Quindi, niente “Scrum… but”! [si veda: Call it as you want, but don’t call it Scrum if it’s not!].
Possiamo descrivere, sinteticamente, l’applicazione dello Scrum process come segue:

Il {Product Owner (PO)}, dopo essersi confronta con gli stakeholder, definisce e priorizza le attività in quello che viene chiamato {Product Backlog}. A questo punto, lo {Scrum Master (SM)} riunisce il Team (compreso il PO) e, insieme ad esso, crea lo {Sprint Backlog} selezionando le attività da sviluppare nella successiva Iterazione {Sprint}. Prima di fare ciò, però, il Team ha definito il significato di “DONE”, ovvero quando una attività si può definire terminata (sviluppo, testing, documentazione, ecc..). Per ogni attività vengono definiti task unitari di lavoro, ne viene stimato il tempo di sviluppo in ore e, assolutamente fondamentale, i relativi criteri di accettazione.

Terminato lo {Sprint Planning}, lo Sprint (1sett. – 1mese) parte e i task individuati cominciano ad essere sviluppati. Giornalmente, prima di iniziare le attività, il Team tiene un meeting di 15minuti chiamato {Daily Scrum} in cui ci si confronta su cosa è stato fatto, cosa si farà nell’immediato e quali sono gli eventuali impedimenti.

Solo le attività che rispecchiano in pieno la definizione di “DONE” sono considerate terminate e, una volta raggiunta la fine dello Sprint, si procedete con uno {Sprint Review} in cui si mostra quanto realizzato al PO e agli stakeholder e uno {Sprint Retrospective} che consente al Team di analizzare la propria organizzazione al fine di migliorarla e migliorarsi.

La gestione di tutte le varie fasi può essere fatta senza l’ausilio di alcun supporto digitale, sfruttando, ad esempio, i classici post-it, ma ciò diventa poco pratico se si è in un contesto medio-grande con una struttura eventualmente delocalizzata in varie aree geografiche. Inoltre diventa difficile effettuare attività manuali di data-mining e associare le attività/task a quanto realmente sviluppato, per non parlare di tracciare agevolmente i feedback degli stakeholder e altre operazioni annesse.

Per questo, e non solo, uno strumento digitale di supporto all’ALM è sicuramente di estremo aiuto, soprattutto se flessibile ed integrato con le tecnologie di sviluppo stesse, esattamente come nel caso di TFS.

Team Foundation Server ecosystems

Evitando di entrare negli aspetti di gestione del codice, della relativa integrazione con le piattaforme di sviluppo Microsoft (.Net in primis) e degli strumenti di Continuous Integration, due elementi rendono TFS particolarmente attraente e flessibile: l’indipendenza dalla metodologia di gestione adottata e la sua estendibilità. Il primo elemento si ottiene grazie ai Process Template, ovvero un “pacchetto” che definisce gli elementi caratterizzanti la metodologia scelta (es per Scrum: workitem, bug, impediment, ecc.) e le loro caratteristiche. E’ possibile definire un Process Template custom e continuare a utilizzare, in accordo con esso, tutti gli strumenti di TFS, senza dover modificare praticamente nulla nella piattaforma di supporto. L’altro punto di forza, come detto, è l’estendibilità, che consente di estendere TFS ed interrogarlo direttamente dai propri servizi/strumenti, sfruttando, ad esempio, le Team Foundation Server OData API.

Il nostro viaggio è solo all’inizio, nel prossimo post vedremo come creare un nuovo Scrum Project in TFS e gestire il Product Backlog, in accordo con l’esecuzione dello Sprint Planning.