Agile Life

agosto 2014 - Post

Scrum and TFS: cookbook

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 tfs market adoptions 2013

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

alm process

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

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.

 

tfs-archi

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’indipendenzadalla 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.

 

[FELICEPESCATORE.IT]

Posted: 26 ago 2014 13:21 da felice.pescatore | con no comments
Inserito sotto: , ,
Welcome SAFe 3.0

Il 25 luglio scorso Dean Leffingwell ha ufficialmente annuncia il rilascio della versione 3.0 dello Scaled Agile Framework.

Le novità sono davvero tante e, praticamente, l’intera impostazione viene fortemente rivista, sia negli elementi che nell’infrastruttura stessa, il tutto in ottica di rendere disponibile alle organizzazioni uno strumento che consenta di focalizzarsi sul Value Delivery, migliorando il coordinamento delle attività annesse a Value Stream particolarmente ampi.

Da una veloce occhiata della Big Picture si nota propria la strutturale riorganizzazione della nuova versione rispetto alla precedente (2.5):

safe 3.0

SAFe 3.0

safe

SAFe 2.5

Si evidenzia subito come il Program Level ed il Team Level si stiano sempre più avvicinando, quasi a fondersi tra di loro, con l’esplicito obiettivo di disegnare un’organizzazione più orizzontale e più efficiente.

Dalla Big Picture 3.0 si nota, anche, un Portfolio Level molto più definito, che abbraccia una o più ART per le Epiche di Business e quelle Architetturali, e che evidenzia una maggiore attenzione a quegli aspetti decisionali strategici che influenzano in maniera diretta tutta l’attività di creazione dei Value Stream.

Volendo fare una panoramica delle innovazioni più rilevanti, troviamo inoltre:

  • Esplicito inserimento dell’approccio Kanban (Portfolio Kanban Systems) per la gestione degli elementi del Portfolio Backlog;
  • Un esplicito focus sulla figura del Lean Agile Leader, con evidenza delle criticità, delle responsabilità e delle competenze annesse;
  • Una diretta dipendenza tra le decisioni strategiche (portfolio Backlog e Value Stream) e il budget disponibile, che non si limita alla semplice contabilità ma viene esteso ad ogni aspetto, come, per esempio, l’innovazione. SAFe 3.0 definisce il Lean-Agile Budgeting come strumento annesso;
  • Enfasi sul ruolo di Coordinamento dei vari Agile Release Train avviati a livello Portfolio per il raggiungimento degli obiettivi di Valore programmati;
  • Particolare attenzione all’aspetto del Delivery (Program Level) con l’introduzione del Release Object e dell’approccio delDelivery on Demand;
  • Code Quality esteso esplicitamente alle pratiche più comuni: Test-FirstContinuous Integration e, forse meno scontata, Agile Architetture.

Questo è solo un estratto di quanto presentato con il nuovo framework e di quanto vedremo in diversi post successivi.

 

[FELICEPESCATORE.IT]

Posted: 7 ago 2014 14:58 da felice.pescatore | con no comments
Inserito sotto: , ,