Agile Life

Firefighter: Agile anti-pattern

firefighterGli sviluppatori amano sentirsi “importanti” e spesso si emozionano e si pavoneggiano quando sono insigniti del ruolo di firefighter, ovvero di pompieri chiamati a risolvere un’emergenza.

Ho letto, da più parti, che questa pratica è “supportata” da Scrum e dall’Agile in generale, a patto che sia attuata per un tempo limitato e che occupi solo una percentuale di tempo dell’iterazione.

Ebbene, tutto ciò è assolutamente falso! L’Agile non contempla minimamente la presenza di “firefighter” che, anzi, vanno in direzione opposta a quello che è il primo Valore dell’Agile Manifesto:

Gli individui e le interazioni più che i processi e gli strumenti

Tra l’altro, già il riferimento a tempistiche e percentuali, in modo così vincolante, dovrebbe far riflettere.

Un Team di Sviluppo (non solo Agile) è un’entità complessa, viva e con le proprie regole, su cui l’azienda ha investito ingenti risorse al fine di trasformarla in un ecosistema che produca Valore. Immaginare che qualcuno venga insignito del ruolo di “firefighter” mina il Team alle sue fondamenta, andando a creare membri di classe A e membri di classe B, creando fisiologiche frizioni interne e rendendo vano il lungo lavoro fatto per la sua costituzione e maturazione. A questo si aggiunge il fatto che tale approccio limita il know-how e la crescita ad un singolo componente del Team (o comunque ad un suo sottoinsieme), creando ulteriori disparità e demolendo l’idea stessa di Team cross-functional.

Inoltre, chi decide chi è un “firefighter”? Lo Scrum Master, il Team, il singolo Membro? Se il “firefighter” viene scelto, allora si passa ad un approccio command-and-control, all’antitesi dell’Agile, se invece viene (auto) nominato significa che il Team è ben lontano dal sentirsi tale.

Insomma, si evidenzia come questa pratica sia un vero e proprio Anti-Pattern che dà solo l’illusione di risolvere un problema nell’immediato, mentre crea grossi problemi in prospettiva, andando a degradare il Team e, di conseguenza, la sua capacità di creare Valore.

 

[FELICEPESCATORE.IT]

Asynchronous Non-solo Programming: code review

Nel post precedente abbiamo approfondito gli aspetti legati al Debito Tecnico e visti, brevemente, gli strumenti di analisi offerti da Visual Studio finalizzati al miglioramento della qualità del codice, omettendo volontariamente la funzionalità di Code Review che andremo qui ad esplorare.

Code Review consente ad un dev di chiedere, ad un altro membro del team, una revisione del proprio codice, andando ad estendere il concetto di Pair Programming o, estendendo lo scope, di Non-solo Programming.

Ma perché decidiamo di chiedere un audit del nostro codice? I motivi sono ovviamente diversi, e tra essi troviamo:

  • identificare codice scritto male o con potenziali (reali) bug;
  • condividere il know-how su quanto realizzato tra tutti i membri del Team;
  • condividere nuovo know-how semantico/sintattico;
  • ….

Nell’approccio Agile, XP in particolare, il Pair Programming è un sinonimo vero e proprio di lavoro a “4 mani”, prevedendo che 2 dev lavorino allo stesso calcolatore (a rotazione, master-slave, ecc..) al fine di ottenere quanto appena evidenziato. In realtà questo approccio “fisico” non sempre è apprezzato, in primis perché dipende molto dal rapporto interpersonale, soprattutto se la durata dell’attività si protrae per un periodo relativamente lungo. Inoltre, in progetti di medie/grandi dimensioni, è possibile che la review del codice sia demandata ad un gruppo di QA di supporto, che, chiaramente, ha un approccio totalmente differente (così come lo sono gli obiettivi) da quello dello sviluppo. Infine, il collega con cui vorremmo “condividere” il nostro codice potrebbe non essere disponibile nel momento in cui lo scriviamo.

In questi casi, ed altri, abbiamo bisogno di uno strumento che consenta di creare un Asynchronous Non-solo Programming, come la funzionalità di Code Review presente in Visual Studio (dalla versione 2012) grazie al supporto di TFS (sempre dalla versione 2012)/VSO con il relativo sistema di Work Item tracking e i due specifici Work Item: Code review request e Code review response.

Ma vediamo operativamente come utilizzare Code Review. Una volta completato il codice e ravvisata la necessità di una revisione, da Team Explorer di Visual Studio, selezioniamo “My Work” e da qui “Request Review”.

code review 1 code review 2

Start Code Review

code review 3

New Code Review

La finestra “New Code Review” (figura precedente) si presenta con quattro campi da compilare:

  • Name of one or more code reviewer, ovvero il Nome del Reviewer scelto da una drop list popolata con i nomi dei membri del team;
  • Code Review subject, l’Oggetto della richiesta di review;
  • Area Path, l’Area di riferimento;
  • Code Review Description, una breve descrizione della richiesta [opzionale].

più uno pre-compilato “Related Work Items” con i relativi Work Items di riferimento per il codice in essere, laddove ve ne siano.

Completato l’inserimento dei dati, non ci resta altro da fare che premere “Submit Request” e potremo verificare che la richiesta sia stata correttamente consegnata/assegnata verificandone la presenza nell’area “Code Reviews” sempre in “My Work”.

code review 4

Code Review Evidence

Ora la palla passa al nostro revisore che vedrà la richiesta nella propria “My Work”, potendone esplorare i dettagli. Inoltre, se ha configurato il relativo alert in TFS/VSO, sarà informato anche per email della richiesta stessa.

code review 5

Code Review viewed by Reviewer

Il revisore ha a disposizione una scheda (Code Review) con tutti i dettagli della richiesta e, nella parte inferiore, vengono evidenziati tutti i file modificati all’atto della richiesta. Selezionando i file è possibile sfruttare implicitamente gli strumenti di code compare per verificare le modifiche e aggiungere eventuali commenti.

code review 6

Code Compare and Comment

Una volta completata la revisione, il revisore chiude il task e il richiedente potrà vedere tutti i commenti/suggerimenti riportati.

code review 7

Code Review suggested info

Come abbiamo accennato, Code Review richiede il supporto diretto di TFS/VSO ed è quindi normale aspettarsi di poter consultare i Work Items annessi anche dalla relativa applicazione web.

code review 8

Code Review Response

E’ interessante evidenziare che, come best practice, è utile mettere in “shelve” il codice per il quale si richiede la review e, solo dopo la ricezione di quest’ultima ed aver apportato eventuali modifiche suggerite, procedere con il check-in.

Per fare ciò basta selezionare il tasto “Suspend” in “My Work”, mentre per riprendere basta seleziona “Switch”.

code review 9 code review 10

Suspend & Switch

Ridurre il Debito Tecnico un’Intenzionale con gli strumenti di Quality Management di Visual Studio

Abbiamo parlato più volte di Technical Debt all’interno dei nostri post, evidenziando come, se non gestito correttamente, possa portare in extremis alla necessità di riscrivere completamente un sistema software (Critical Mass of Software System: quando la qualità del software significa manutenibilità). Nel post “ALM, un approccio pratico alla gestione del Debito Tecnico” abbiamo anche visto come utilizzare una Clean Technical Debt Iteration (CTDi) tracciata in VSO/TFS per gestire e ridurre il debito tecnico accumulato.

E’ giunto ora il momento di vedere come essere proattivi, mettendo in campo quanto possibile per evitare la creazione del debito tecnico e ridurre gli interessi da pagare. Prima di vedere gli strumenti disponibili è utile soffermarci sulla terminologia, proponendo la tassonomia riportata nella figura seguente. 

technical debt taxonomy

Technical Debt Taxonomy

Esiste una verità difficilmente confutabile: per quanto vogliamo evitarlo, il nostro progetto avrà sempre un debito tecnico! Chiaramente, in questo caso, siamo nel campo dell’Unintentional Debt (Type 1), che è dettagliabile in due specifiche tipologie:

  • 1.A Naive Debt: questo debito deriva da cattive pratiche di sviluppo ed è quello su cui è possibile intervenire con maggior successo. Si pensi, ad esempio, ad un Team che non fa testing: un buon seminario su xUnit e l’utilizzo (eventuale e con parsimonia) del Gated check-in darà risultati lodevoli;
  • 1.B Unavoidable Debt: si tratta di debito ereditato su cui è difficile intervenire. Un esempio per tutti: una libreria sviluppata esternamente e utilizzabile solo as-is.

Dualmente all’Unintentional Debt è possibile identificare un “debito voluto” che indicheremo come Intentional Debt. Si tratta di una scelta dettata spesso da esigenze inderogabili e quasi sempre non tecniche, ad esempio: il Time-to-Market. Le afferenti tipologie di debito sono:

  • 2.A Short-term Debt, a sua volta diviso in:
    • 2.A.1 Identifiable significant shortcuts, ovvero il debito specificamente creato/accettato per raggiungere obiettivi strategici tramite tattiche di medio/breve termine. Si pensi alla necessità di procedere in parallelo sullo sviluppo e all’utilizzo temporaneo di fake library per realizzare una versione di supporto temporanea per il modulo che si sta realizzando, in attesa che quello definitivo sia ultimato;
    • 2.A.2 Identifiable tiny shortcuts, questo debito è assolutamente da evitare perché, nonostante sia creato per raggiungere uno specifico obiettivo di Program Level, ha degli altissimi costi di interesse, essendo sparso a macchia di leopardo. Esempi specifici sono: codice scritto frettolosamente, scarsa strutturazione del modello di dominio, ecc...
  • 2.B Long- term Debt, questo debito è legato ad obiettivi strategici di lungo/medio termine, supportati da una specifica visione. Rientra in questo ambito, ad esempio, la scelta voluta di creare una soluzione per uno specifico ambiente di erogazione anche se la relativa nuova versione è in fase di rilascio e potrebbe non essere correttamente supportata.

Nella tassonomia che abbiamo presentato, è presente anche il Non-Debt che non va interpretato come l’assenza di debito tecnico, piuttosto è da intendersi come classificazione di specifiche attività che avvengo durante il ciclo di delivery. Prendiamo la decisione di posticipare lo sviluppo di una Feature alla successiva release: questo non crea un “debito tecnico”, sia nel caso in cui la scelta è frutto di una discussione con il key-stakeholder, sia che lo sia unilateralmente (in tale scenario il prodotto manca di una funzionalità nel suo insieme ma non è stato aggiunto o creato debito tecnico afferente).

Proseguiamo rispondendo ora alla domanda fondamentale: quando e come pagare gli interessi associati al debito tecnico?

Qui il dualismo con il “debito finanziario” è decisamente più sfumato, perché non sempre è necessario pagare il debito tecnico: se si è in presenza di un software che sta per raggiungere la fine del suo naturale ciclo di adozione, non ha alcun senso investire su di esso e, quindi, pagare il debito tecnico accumulato.

Se, invece, ciò è necessario, è possibile adottare diverse tecniche: da quella citata all’inizio dell’articolo, e spiegata nel post specifico, piuttosto che il pagamento alla successiva iterazione con l’inserimento nell’Iteration Backlog dei Work Item relativi. Ogni azienda ed ogni Team hanno un approccio specifico, esattamente come ogni azienda gestisce in modo proprio il debito finanziario.

Come evidenziato, l’ambito 1.A è quello in cui è possibile intervenire in maniera più efficace. In particolare, Visual Studio 2013 mette a disposizione tutta una serie di strumenti pensati proprio per aumentare la qualità della propria soluzione:

  • Code Analysis, consente di verificare l’aderenza del codice alle regole e best practice selezionate;
  • Code Metrics, consente di analizzare il codice alla ricerca delle aree di maggior complessità e di difficile manutenzione;
  • Code Clone Analysis, consente di ricercare il codice clonato/simile, anche parziale, indipendentemente da alcuni aspetti caratterizzati (es: nome variabile). Molto utile per in caso di utilizzo intensivo di copia e incolla… ogni commento è superfluo, ovviamente!
  • CodeLens, introdotto con Visual Studio 2013, consente di visualizzare direttamente sul codice corrente informazioni relative (es: test superati, riferimenti diretti da/a, ecc…). Più che una funzionalità di analisi è da ritenersi una facility che aiuta a concentrarsi sul lavoro in corso ed evita errori dovuti a switch di finestre/ambienti;
  • xUnit Text, Visual Studio 2013 ha introdotto un nuovo sistema di gestione degli Unit Test che consente di selezionare il framework di testing più adatto alle proprie esigenze (tramite Adapter) ed utilizzarlo in modo nativo.

Ovviamente a queste funzionalità, utilizzabili direttamente da Visual Studio (2013), si aggiungono tutte quelle tipiche di un processo evoluto di ALM legate a VSO/TFS.

code analysis

Code Analysis

code metrics

Code Metrics

code clone analysis

Code Clone Analysis

codelens

CodeLens

Rimuovere Work Items dal Product Backlog e… da VSO

Dopo aver evidenziato più volte la necessità di gestire opportunamente il Product Backlog ed evitare di stimare troppi Work Itemper non sprecare risorse preziosi (waste), siamo pronti ad “accogliere il cambiamento” e rimuovere i Work Item che, con l’aumento di know-how sul progetto e la relativa evoluzione, si dimostrano inutili o non necessari.

Se tale operazione è relativamente banale con l’utilizzo di strumenti “fisici”, come post-it e flip-board, lo stesso non si può dire con VisualStudioOnline (o TFS), che non contempla una funzione diretta da Web Interface per la rimozione di uno o più Work Item. In linea di massima questo è un bene, perché l’operazione di eliminazione è definitiva ma, soprattutto, perché porta alla perdita di importanti informazioni per il Team: numero di Work Item errati, domini su cui intervenire per colmare lacune, ecc…

Andiamo a vedere una possibile strategia per tracciare queste informazioni e al contempo “liberare” il Backlog dai Work Item inutili, attraverso una soluzione estremamente semplice, soprattutto se applicata all’atto della creazione del Team Project.

Apriamo la sezione di amministrazione di VSO, spostiamoci nelle “Aree” e creiamo una struttura simile alla seguente:

remove work item 1

Area Settings

ValidateWorkItem sarà l’Area di riferimento per tutti i Work Item che intendiamo realmente realizzare, mentre _ReadyToDeletequella per i Work Item da scartare.

A questo punto, spostandoci nella sezione di gestione dei Team, creiamo un nuovo Team (nel caso in esempio: Working Team) associato al Team Project, facendo attenzione a non far creare un’Area di Default.

remove work item 2

New Team

Selezioniamo il nuovo Team e spostiamoci nuovamente nella sezione specifica delle Aree, andando ad associarlo all’area “ValidateWorkItem”.

remove work item 3

Associamo l'Administrator Team alla Root Area

Fatto questo, il nuovo Team avrà a disposizione una home page specifica omonima ma, soprattutto, un Product Backlog “epurato” dai Work Item che saranno associati all’Area _ReadyToDelete, visibili comunque al Team di Default.

remove work item 4

Work Item setted on _ReadyToDelete Area

Il nuovo Team creato può essere considerato come il Team di riferimento per le attività di sviluppo, mentre quello di Default andrà considerato come Team di Amministrazione a cui saranno visibili tutti i Work Item e, di conseguenza, associato alla Root Area (“SUAP” nell’esempio).

Nel caso si voglia procedere con la soluzione più drastica, ovvero la completa cancellazione dei Work Item “inutili”, la succitata organizzazione è comunque d’aiuto perché circoscrivere l’Area di appartenenza (e di intervento) dei Work Item stessi.

github logoPer cancellare i Work Item possiamo utilizzare le API di VSO/TFS, sulla falsa riga del semplice programma dimostrativo scritto in C# e liberamente disponibile su GitHub: https://github.com/felicepescatore/TFSWorkItemDeleteSample.git

Le dll Microsoft.TeamFoundation.Client e Microsoft.TeamFoundation.WorkItemTracking.Client, necessarie al suo funzionamento, sono presenti nel vostro sistema al seguente path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0.

Attenzione: il programma cancella DEFINITIVAMENTE i Work Item, per cui va utilizzato con la massima attenzione.

Prima di potervi connettere da codice alla vostra istanza VSO, è necessario che abilitiate l’opzione “Alternate Credential & Password” direttamente da vostro profilo/Microsoft Account (lo trovate in alto a destra una volta loggati in VSO).

profile alternate credential

Alternative Auth Credential

In alternativa alla soluzione proposta, sempre per cancellare i Work Item è possibile ricorrere anche alla riga di comando:

witadmin destroywi /collection:CollectionURL /id:id [/noprompt]

 

[FELICEPESCATORE.IT]

Posted: 11 nov 2014 16:07 da felice.pescatore | con no comments
Inserito sotto: , ,
Product Backlog? Yes, but it can be more than one!

Il Product Backlog è la proiezione, ordinata e pesata, di quello che è il nostro Prodotto, o almeno di quanto, allo stato attuale, si conosce di esso.

In linea generale abbiamo un’associazione diretta tra Product BacklogProdotto e Agile Team, ovvero: per 1 Prodotto esiste 1 Product Backlog ed 1 Agile Team che ne prende in carico le attività. Si tratta, chiaramente, di uno scenario minimale che si complica notevolmente già solo ponendosi una semplice domanda: “Che cos’è per noi un Prodotto?”.

Facciamo un esempio molto semplice, tratto dall’ottimo libro Essential Scrum di Kenneth S. Rubin: se consideriamo Microsoft Office, possiamo etichettare come Prodotto l’intera Suite o una delle sue applicazione specifiche, per esempio Word:

product backlog office

Cos'è per noi il "Prodotto"?

Ebbene, la scelta di dove posizionarsi raramente è ben delineata dipendendo da una serie di elementi che afferiscono principalmente al Program Level (leggasi SAFe), in accordo con gli obiettivi strategici.

Ora, tralasciando la governance di questo aspetto, proviamo a vedere alcune strategie utili per gestire il nostro Product Backlog in base alla nostra definizione di “Prodotto” e a quanti Team sono associati ad esso. Chiaramente andiamo a scoprire anche come sfruttare adeguatamente VisualStudioOnline/TFS per accompagnare tali strategie.

Prima di procedere, utilizzando una stima della complessità dei progetti in linea con le T-Shirt Size, vediamo i possibili casi principali (sicuramente non esaustivi):

Size

Product Type

Team

S

Bassa Complessità

Uno/Generalista

M

Media Complessità

N/Generalisti

L

Alta Complessità

N/Generalisti e Specialisti

Size Case

Size S. In questo scenario possiamo adottare l’approccio più classico, in cui si ha un unico Product Backlog a cui afferisce un unico Agile Team. Come di consueto, il Product Backlog conterrà i Work Item più rilevanti e più dettagliati al Top.

size s

Size S

Guardando a VSO/TFS non è necessario fare particolari settaggi, essendo possibile utilizzare il Product Backlog e l’associazione dell’Agile Team al Team Project esattamente come viene creato scegliendo lo Scrum Process Template.

vso scrum process template

Scrum Process Template Items Tree

L’unica accortezza è quella di considerare le Feature (o Work Item a “grana grossa” se preferite) parte del Portfolio Backlog e le User Story/Bug/ecc… come elementi del (Product) Backlog legati alle Feature.

Size M. Questo scenario può essere suddiviso in due sub-scenari specifici:

  • M1: il nostro Prodotto è unico ed è associato a più Agile Team che lavorano sulle relative Feature;
  • M2: il nostro Prodotto è in realtà composto da più Prodotti specifici e ognuno di essi è associato uno specifico Product Backlog affidato ad un Agile Team;

size m1

Size M1

size m2

Size M2

Per quanto riguarda le relative configurazioni di VisualStudioOnline/TFS, sia per Size M1 che Size M2, vi rimando direttamente agli ottimi post di Gian Maria Ricci (Gestire Team Multipli con uno stesso backlog in un Team Project eConfiguration di un Team Project per più team con backlog multipli) in cui viene spiegato passo-passo come sfruttare le “Aree” di VSO/TFS per raggiungere la configurazione desiderata.

vso area configuration

VSO Area Configuration

Size L. E’ lo scenario più difficile, in cui abbiamo una serie di sotto Prodotti, ognuno dei quali può essere affidato a più di un Agile Team, sia generalista che specialista.

size l

Size L

Anche per quest’ultimo scenario, valgono i post di Gian Maria, che opportunamente combinati portano al risultato desiderato.

Prima di chiudere un breve cenno sullo Scaling, relativamente a SAFe. Il framework di Leffingwell, non contempla nessun Product Backlog, dal punto di vista letterale, bensì, ragionando in termini di Value Stream e ART, individua due Backlog differenti, posizionati in due livelli distinti:

  1. Program Backlog (Program Level): contiene tutto quanto necessario a rendere concreto l’Agile Release Train, in termini di iniziative e prodotti;
  2. Team Backlog (Team Level): è una segmentazione del relativo Program Backlog che contiene le attività di sviluppo associate allo specifico Agile Team.

program team backlog

SAFe Program e Team Backlog

Quanto proposto da SAFe rientra nel caso Size L, poiché il Program Backlog è un’entità complessa che può sicuramente essere composta da più Prodotti.

 

[FELICEPESCATORE.IT]

Scrum and TFS cookbook - pt.6,compendio: the Five Scrum Values

Ok, avevamo chiuso il precedente post dicendo che era l’ultimo della serie… ebbene non è così! Le nostre “ricette” sono preparate dalle persone, e le persone hanno bisogno di raggiungere il giusto affiatamento per ottenere il risultato sperato, o quanto meno per avvicinarsi ad esso.

D'altronde lo stesso manifesto Agile pone al primo posto, tra i propri valori, quello esplicitamente dedicato alle persone: “Gli individui e le interazioni più che i processi e gli strumenti” e Scrum, ovviamente, lo abbraccia pienamente (altrimenti non sarebbe Agile!), raffinandolo in 5 valori “derivati”: openness, courage, respect, focus e commitment.

 scrum 5 values

The 5 Scrum Values

Vediamoli questi valori in dettaglio, evidenziandoli per ogni componente dello Scrum Team (Scrum Master [SM], Product Owner [PO] e Development Team [DT]):

  • Focus. Lo SM è concentrato sulla rimozione degli impedimenti e sull’applicazione di Scrum all’interno del Team e nel contesto aziendale. Il PO è concentrato sull’ottenimento del massimo Valore per il prodotto in essere, organizzando opportunamente il Product Backlog. Il DT è focalizzato sullo sviluppo della soluzione in funzione della Definition of Done;
  • Coraggio (Courage). Lo SM deve avere coraggio per “proteggere” e “guidare” il Team, così come il PO per fidarsi delle attività in essere e dialogare con gli stakeholder. Il DT deve impegnarsi nella realizzazione dei Work Item, superando i propri limiti in un’ottica inspect-and-adapt;
  • Apertura (Openness). L’intero Team deve essere aperto ai cambiamenti, sia che provengano dall’interno che dall’esterno (stakeholder). In aggiunta, il DT deve guardare a nuove soluzioni, soprattutto tecniche, per ottimizzare la qualità di quanto realizzato;
  • Impegno (Commitment). Il DT sottoscrive il proprio impegno in ogni Sprint Planning, quando vengono decisi i Work Item da realizzare nella prossima iterazione. Lo SM ha un impegno costante nel far penetrare culturalmente Scrum nello specifico contesto. Il PO si impegna con gli stakeholder per ottenere costantemente (ad ogni Sprint) un incremento della soluzione disponibile, in ottica sempre di accrescimento del Valore complessivo;
  • Respect (Rispetto). Questo è il valore più difficile da conquistare, perché il rispetto si estende oltre i ruoli, toccando il personale. Il DT e lo SM devono rispettare le decisioni del PO, l’unico ad avere la parola finale su cosa realizzare. Dualmente il PO deve rispettare l’autonomia del DT sul come fare le cose e come raggiungere la DoD, così come deve rispettare lo SM nella propria attività di guida metodologica. Lo SM, dal proprio canto, deve essere un “leader servente” e non il techincal leader o il team leader vecchio stile command-and-control. Infine ogni singolo membro dello Scrum Team deve rispettare i propri colleghi nell’ottica della Prima Direttiva delle Retrospettive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Una cosa fondamentale è che i Valori appartengono a tutto il Team ed è sua responsabilità farli maturare ed applicare al proprio interno. Non esiste, insomma, un Value Scrum Master, ma la responsabilità è egualmente distribuita su tutti, sia per l’applicazione individuale che per quella complessiva.

Adesso è proprio tutto… 

 

[FELICEPESCATORE.IT]

Posted: 29 ott 2014 15:59 da felice.pescatore | con no comments
Inserito sotto: ,
Scrum and TFS cookbook - pt.5, Review and Retrospective

Per completare il nostro Sprint ci attendono due appuntamenti (cerimonie) fondamentali: lo Sprint Review e lo Sprint Retrospective.

sprint review meeting

Sprint Review and Sprint Retrospective meeting

Lo Sprint Review è dedicato alla presentazione del lavoro svolto, o meglio, dell’attuale stato del prodotto, comprendente tutto quanto sviluppato finora, integrato e testato. Ad esso partecipano praticamente tutti: gli stakeholder (interni ed esterni), loScrum Team al completo, uditori, ecc… Scrum prevede di effettuare lo Sprint Review alla fine di ogni sprint ma, in realtà, è sempre più frequente l’utilizzo del concetto di Minimum Viable Product (mvp), ovvero l’insieme minimo di funzionalità che rappresentano un incremento significativo dal punto di vista del cliente. Se applicato (cosa di frequente soprattutto quando lo sviluppo del prodotto coinvolge più Team) la cosa si traduce nell’avere uno Sprint Review interno minimale e uno Sprint Review più consistente ogni N-Sprint.

Durante lo Sprint Review vengono evidenziati eventuali problemi di sviluppo che si sono verificati e come evitarli in futuro. Tra essi, uno dei più frequenti, è il comportamento da adottare rispetto a User Story completate solo parzialmente.

Personalmente, suggerisco al Team di applicare due semplici regole:

  1. Una User Story non completata (o meglio, che non ha raggiunto lo stato di “Done”) non contribuisce al calcolo della Velocity;
  2. L’intera User Story, compresi i Task completati e non, vengono traslati nel nuovo Sprint.

 

    Un approccio alternativo al punto 2 è quello di “splittare” la User Story in UserStoryA e UserStoryB, la prima comprende i Task completati e la seconda quelli non completati. In questo modo la UserStoryA contribuisce anche alla Velocity dello Sprint attuale, mentre il resto va nello Sprint successivo.  Questo approccio ha lo svantaggio di dover ri-estimare anche la complessità delle due nuove User Story e, in generale, non è del tutto compliance con l’essenza di Scrum.

    Il primo supporto a questa fase da parte di TFS/VisualStudioOnline è chiaramente legato alla Continuous Integration (Pt.4, Sprint by Sprint) che consente di ottenere una soluzione completa e testata delle nuove funzionalità realizzate in modo automatizzato.  Lo strumento ALM di Microsoft ci viene incontro anche nell’attività di riallocare una User Story con tutti i relativi task in modo semplice e veloce: basta selezionare la User Story specifica e cambiare la sua “assegnazione”.

    tfs example 22

    User Story Iteration Assignment

    Se si desidera spostare solo i task non competi, la procedura è un po’ più complessa: TFS/VisualStudioOnline, in modo automatizzato, permette lo “share” di una User Story tra più Sprint (Iterazioni), quindi non è necessario effettuare la ri-stima per due User Story differenti. Vediamo come fare: prima di tutto bisogna creare una query che selezioni i task “undone”.

    tfs example 23

     Done / unDone Task query

    Dopodiché selezionate il risultato ottenuto (sia la User Story che i Task), cliccate con il tasto destro sulla selezione e scegliete “Move to Iteration”.

    tfs example 24

    Move to Iteration

    Una volta confermato il tutto avrete la User Story presente sia nell’iterazione corrente, con i relativi Task in Done state, e nell’iterazione successiva (o quella che avete indicato) con i Task non-in-Done-State.

    tfs example 25

    Shared User Story: Sprint Attuale

    tfs example 25

    Shared User Story split: Sprint Successivo

    Essendo la User Story in “share”, risulterà ancora aperta alla fine dello Sprint corrente e, automaticamente, non correrà al calcolo della Velocity.

    A valle delle operazioni di “aggiustamento”, lo Sprint Review si conclude con una serie di domande molto simili a quelle poste durate il Daily Scrum, di preparazione al prossimo Sprint Planning (Pt.3, go to the Sprint!):

    • What did you like the most ?
    • What did you not like?
    • What would you like to improve?

    Una volta terminata lo Sprint Review, lo Scrum Team (e solo esso) si riunisce per 2-3 ore per effettuare la Scrum Retrospective. Questo meeting è caratterizzato da una serie di Activity che consento di ispezionare l’applicazione di Scrum stesso e il comportamento del Team come tale, al fine di migliorare l’aspetto metodologico del lavoro. Spesso, come Activity, si utilizzano dei Retrospective Game come lo Starfish che consentono di raccogliere in modo chiaro e coinvolgente i vari aspetti che caratterizzano il Team.

    starfish retrospective

    Starfish game

    Da questo punto di vista, TFS/VisualStudioOnline non offre un grande supporto avendo, come detto, nella versione 2013 eliminato lo “Sprint Work Item”. L’opzione potrebbe essere quella di creare, a questo punto, un Work Item generico nella cui descrizione si inseriscono gli obiettivi (agenda) della retrospettiva e si allegano le foto dei vari artefatti realizzati.

    tfs example 26

    Retrospective Work Item

    Si tratta di un Work Item utile per aver traccia di quanto discusso nella retrospettiva, legandolo in modo diretto allo Sprint.

    Siamo giunti alla fine del nostro “cookbook”, un viaggio lungo 5 post in cui abbiamo visto alcune soluzioni pratiche che consentono a TFS/VisualStudioOnline di supportare in modo diretto l’utilizzo di Scrum all’interno della propria organizzazione.

    Sperando che il tutto vi abbia incuriosito e possa servirvi come start-point per le vostre esigenze, chiudo ricordandovi che sia TFS/VisualStudioOnline che Scrum vanno sempre calati nello specifico contesto di esercizio e che solo un loro utilizzo serio e disciplinato porta ad vero valore per le proprie attività.

    Posted: 25 set 2014 13:26 da felice.pescatore | con no comments
    Inserito sotto: , ,
    Scrum and TFS cookbook - pt.4, Sprint by Sprint

    In Scrum, il cuore pulsante e operativo delle attività di sviluppo è lo Sprint.

    dailyscrum

    A Sprint Activity: Daily Scrum

    Si tratta di un intervallo time-boxed, tipicamente di 1-4 settimane (mediamente 2settimane), all’interno del quale il Team concretizza lo Sprint Goal definito durante lo “Sprint Planning” e realizza le User Story, o, più in generale, i Work item inseriti nello Sprint Backlog.

    Lo Sprint raccoglie in se alcune delle cerimonie fondamentali di Scrum:

    • Daily Scrum: si tratta di uno stand-up meeting mattutino di una decina di minuti al massimo in cui tutti i membri del Team, a turno, illustrando cosa hanno realizzato (What have I done yesterday?), cosa si apprestano a fare (What will I do today?) e le eventuali difficoltà incontrante (What keeps me from doing my work?);
    • Sprint Review: si effettua alla chiusura dello Sprint. Il Product Owner mostra quanto realizzato agli stakeholder, al fine di validare in ultima analisi il tutto e raccogliere i feedback;
    • Sprint Retrospective: si effettua alla chiusura dello Sprint ed è dedicata al Team. Ha il compito fondamentale di ragionare sui processi adottati e sul loro miglioramento.

    Le ultime due cerimonie saranno oggetto del prossimo post di questa serie, mentre il Daily Scrum è implicitamente associato a quanto diremo nel prosieguo. Sempre in relazione allo Sprint, esiste un elemento che è fondamentale introdurre prima di proseguire: Definition of Done (DoD). Esattamente come per lo Sprint Goal, il Team (nella sua interezza) definisce cosa si intende per “DONE”, ovvero quando è possibile considerare un Work Item finito. Tale definizione evolve durante lo sviluppo del prodotto e può avere una prima formalizzazione associata ai primi Product Backlog Grooming o al primo Sprint. In pratica, si definisce una short list di attività da effettuare per ogni elemento del Backlog o per un suo insieme:

    • [MUST] Superamento dei Test di Accettazione (Acceptance Criteria);
    • [MUST] Definizione, esecuzione e superamento dei Test di Unità;
    • Test Code Coverage superiore ad una certa %;
    • Documentazione funzionale;
    • ….

    Tipicamente, per i Team che si sono imbarcati in Scrum da poco, è possibile limitarsi alle prime due attività, anche se si tratta di un’assunzione debole. Quello che invece è fondamentale evidenziare è che tanto più lunga è la lista delle attività annesse alla DoD, tanto più lungo sarà il tempo necessario per completare una User Story, incidendo, probabilmente, anche sulla sua complessità relativa (Story Point). In sintesi:

    la Velocity è inversamente proporzionale alla complessità della DoD

    La cosa interessante, più volte ripetuta, è che Scrum dice cosa fare ma non dice come farlo, lasciando la libertà al Team di auto organizzarsi e di scegliere le pratiche che più si ritengono opportune. In quest’ottica, per lo sviluppo vero e proprio, spesso i Team prendono “in prestito” le pratiche contemplate da eXtreme Programming (XP), il TDD e altro, in base alle proprie esigenze e alla propria maturità.

    TFS/VisualStudioOnline dispone di una serie di strumenti trasversali che consentono di svolgere le attività intrinseche ad uno Sprint. In primis la Sprint Board, di cui abbiamo già parlato nel post precedente, che consente di gestire agevolmente tutte le attività di organizzazione dei Work Item e dei Task.

    tfs example 20

    Sprint Board

    Il monitoraggio avviene attraverso una serie di strumenti visuali: lo Sprint Burndown Chart, il Release Burndown Chart, il Cumulative Flow, l’Histogram of Velocity, ecc. Ma, probabilmente, l’elemento più importante è la Dashboard, visionabile accedendo da Web e che presenta una sintesi dello stato del progetto, con Cruscotti e Tiles personalizzabili in grado di evidenziare aspetti specifici del progetto relativo. Per gli amanti dell’Agile si tratta di un vero e proprio Information Radiator Digitale in linea con la regola del 3+3: avere chiaro il quadro generale guardando la Board in 3secondi da 3metri.. forse qualche metro in meno :-).

    sprintburndown workitems 

    Sprint Burndown e Cumulative Flow

     

    tfs web access

    TFS Web Access / VSOnline Web App

    Tali strumenti visuali sono fondamentali per comunicare rapidamente con persone (es: manager o stakeholder) poco interessati agli aspetti di dettagli dello sviluppo ma focalizzati sul quadro complessivo. Il supporto dell’ambiente di BigM non si limita però a ciò, abbracciando un set di funzionalità legate alla verifica della Qualità del Codice (Code Quality), anche se, per inciso, sono strumenti integrati più nell’IDE Visual Studio (Premium e Ultimate) che in TFS/VisualStudioOnline. Tra essi troviamo:

    • Code Clone Detection, per la ricerca di codice duplicato;
    • Code Metrics, per misurare la complessità e la manutenibilità del codice;
    • Code Profiler, per analizzare l’utilizzo della memoria da parte del codice ed individuare colli di bottiglia nelle performance;
    • Static Code Analysis, per effettuare un check del codice basato su standard di riferimento (es: best practice per lo sviluppo .NET: i nomi dei metodi devono iniziare con la Maiuscola);
    • Unit Testing / Coded UI Tests /Code Coverage, supporto allo Unit Test (MSTest, xUnit o altri);
    • Fakes Framework, per la generazione automatizzata di Mocks e Stubs;

     

    Nonostante esistano strumenti ad-hoc per ognuna delle aree evidenziate, con funzionalità estreme, il grande vantaggio della soluzione Microsoft è la completa integrazione, consentendo così di produrre in modo efficiente codice di maggiore qualità rispettando i vincoli decisi con la DoD. In particolare, l’utilizzo delle batterie automatizzate per il Test e il settaggio dei Build Agent di TFS permettono di abbracciare in pieno la pratica della Continuous Integration (CI) che prevede un’integrazione completa e testata di quanto sviluppato sulla main-line di sviluppo. Gli strumenti forniti consento di impostare opportune policy (per esempio: inibire il check-in se non si superano i test di unità presenti nella solution) in modo da automatizzare il tutto.

    Sia le operazioni di Build che le attività di Testing sono gestibili tramite la Web App di TFS/VisualStudioOnline o direttamente da Visual Studio.

    A proposito di main-line: dalla versione 2013, TFS/VisualStudioOnline supporta pienamente sia il source control centralizzato proprietario (TFVC) che il distribuito GIT, consentendo di applicare le politiche di gestione del codice sorgente che più si adattano al proprio contesto.

    tfvc git

    TFVC & GIT

    Se si lavora in ottica Scrum e Continuous Integration (se non praticate quest’ultima vi consiglio vivamente di “incamminarvi” su questa strada), si può adottare una strategia di branch “Sprint-to-Branch” in cui si crea un nuovo branch ad ogni nuovo Sprint, legandoli direttamente tra loro.

    stretegia di branch

    Branch Strategy: Sprint-to-Branch

    Il prossimo post sarà dedicato allo Sprint Review e allo Sprint Retrospective, evidenziando come TFS/VisualStudioOnline sia di supporto alla loro esecuzione.

     

    [FELICEPESCATORE.IT]

    Posted: 18 set 2014 12:20 da felice.pescatore | con no comments
    Inserito sotto: , ,
    Scrum and TFS cookbook - pt.3, go to the Sprint!

    opo la creazione del Program Backlog e del Product Backlog, illustrate nel post precedente, siamo pronti a settare TFS/VisualStudioOnline per accompagnare il nostro Sprint: tuffiamoci nello Sprint Planning!

    sprint plagging

    Sprint Planning: let's start!

    Cos’è lo Sprint Planning? Si tratta della cerimonia Scrum a cui è demandata lo start-up di un nuovo Sprint, sotto il cappello di uno “Sprint Goal” che definisce l’obiettivo d’insieme dell’iterazione stessa. Il goal guida la scelta delle User Story (PBI) che andranno a formare lo Sprint Backlog e che devono trovarsi al top dello stack che rappresenta il Product Backlog, cosa che le assegna un’alta priorità relativa.

    Il numero di User Story da “inserire” nello Sprint hanno una relazione diretta con la Velocity raggiunta nello Sprint precedente dal Team, ottenuta sommando gli Story Point completati in funzione delle User Story completate. Nel caso in cui l’ultimo Sprint è stato interessato da eventi esterni che hanno inficiato il valore della Velocity, è possibile utilizzare una media storica come valore di riferimento.

    Ma come stimiamo gli Story Point associati ad una User Story? Come sempre, esistono diverse tecniche, ma vi suggerisco ilPlanning Poker basato sulla sequenza di Fibonacci “corretta” che, inoltre, contribuisce alla discussione sulla singola User Story al fine di condividerne il significato ed il dominio.

    planning-poker-fullfan

    Le carte per il Planning Poker

    L’attività di stima si svolge nel seguente modo:

    ogni membro del Team ha un proprio deck di carte con sopra la sequenza di Fibonacci “corretta” (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, 0,5, ?). Lo Scrum Master legge ad alta voce la User Story e chiede ad ogni membro del Team di stimare la relativa complessità scegliendo una carta dal mazzo e posizionandola con il dorso verso l’alto su una scrivania di supporto. Sempre su indicazione dello SM, tutti i membri del Team girano contemporaneamente le carte: a questo punto chi ha indicato il valore più basso e chi ha indicato quello più alto dispongono di 3minuti per motivare la scelta. L’operazione si ripete finché il Team non raggiunge un’opinione comune sulla complessità della User Story. Nel caso in cui il valore scelto sia di 40, 100, infinito, è opportuno che la User Story venga messa da parte ed analizzata con dovizia per essere divisa in User Story più semplici.

    Stimata la complessità della User Story, si passa alla definizione dei Task relativi che rappresentano l’unità minimale di lavoro stimata in ore. Il consiglio è quello di non effettuare una “stima verticale” (prima tutte le User Story e poi tutti i Task), ma seguire un approccio “orizzontale”: prendo una User Story dal Product Backlog, la stimo, definisco/stimo i relativi Task, passo alla successiva User Story. Questo per favorire una comprensione più di dettaglio della User Story corrente e di conseguenza del progetto, cosa che può essere sfruttata già nelle stime immediatamente successive.

    La cosa migliore è quella di effettuare tutta la fase relativa allo Sprint Planning usando un approccio diretto, ovvero tramite flip-board, post-it, deck-card, ecc, e solo successivamente riportare il tutto su TFS/VisualStudioOnline. Questo per essere assolutamente in grado di adattare la cerimonia alle proprie esigenze e non essere vincolati ai constraints dello strumento.

    Detto ciò, passiamo a TFS. Purtroppo l’ultima versione, compreso VisualStudioOnline, non dispone di “un’Area Sprint” o di uno “Sprint Work Item” per raccogliere lo “Sprint Goal” (congiuntamente ad alcuni altri elementi di Scrum), e, in attesa che vengano introdotti specifici elementi, possiamo associare lo Sprint Goal al nome dell’Iterazione, contando sul fatto che esso è tipicamente caratterizzato da una descrizione sintetica.

     tfs example 11

    Sprint Goal

    In alternativa è possibile, solo per TFS, creare un apposito Work Item o importare quello specifico esistente nella versione 2010.

    tfs example 12

    Sprint Work Item TFS 2010

    Fatto ciò, l’attività da fare è quella di associare i Work Item (User Story) dello Sprint Backlog appena definito allo Sprint corretto definito in TFS, selezionando ed impostando l’Iterazione (Iteration) di assegnazione.

    tfs example 13

    Assegnazione Iterazione

    Un’ulteriore utile aggiunta da fare è l’inserimento del “Peso” (Effort, ovvero Story Point) e del “Valore” (Business Value) per ogni User Story, valorizzando la sezione “Details” con quanto emerso durante il Planning Poker. Ciò sarà utile per gli strumenti di analisi.

    tfs example 14

    Effort e Priorità

    Non ci resta ora che assegnare la Priorità, in accordo con lo Sprint Backlog ed il Product Backlog: questa azione è “implicita” nel senso che si ottiene spostando con il mouse i Work Item nell’ordine (alias priorità) desiderato. Completati tutti i settaggi, selezionando lo specifico Sprint, TFS vi presenterà un summary simile a quello seguente:

    tfs example 15

    Sprint summary

    Una puntualizzazione: le uniche User Story ad essere state stimate sono quelle selezionate per lo Sprint in starting, mentre la stima di quelle rimanenti all’interno del Product Backlog è differita ai successivi Sprint Planning. Si tratta di una precisa scelta, legata alla teoria delle code (per approfondimenti, The Principles of Product Development Flow: Second Generation Lean Product Development - D. Reinertsen) in cui si dimostra l’inutilità di stimare completamente gli elementi di uno stack (alias Product Backlog), poiché la relativa conoscenza aumentare durante il progetto, alcuni di essi verranno eliminati ed altri introdotti.

    Ciò rende praticamente inutile la funzionalità di “Forecast” (previsione) attivabile nella visualizzazione dei PBI perché richiede l’assegnazione dei pesi a tutti i Work Item, cosa in netta contraddizione con quanto appena detto.

    tfs example 16

    TFS Forecast

    In sintesi: ignorate tale funzionalità, fa scena ma non serve a nulla.

    Quello che invece bisogna settare è la Capacity (capacità) del Team sullo Sprint, selezionando chi lavorerà sul progetto, in quale sub-area e per quante ore al giorno. In tal modo si indicano le ore totali che il Team dedicherà allo Sprint, suddivise, se ha senso, per area.

    tfs example 17

     Sprint "Capacity"

    Questo dato risulta utile per avere costantemente una stima di capacità/carico di lavoro, che però diventa evidente solo con l’ultimo degli step che descriviamo oggi: l’inserimento dei Task relativi alle User Story incluse nello Sprint.

    Selezioniamo “Board” e passiamo alla relativa visualizzazione:

    tfs example 18

    Sprint Board View

    Clicchiamo sul segno “+” adiacente la User Story e creiamo un nuovo Task, compilando i relativi dettagli:

    tfs example 19

    Nuovo Task

    Salviamo e, a questo punto, ci troveremo difronte a una Board contenente il nuovo Task con riportare le relative ore.

    tfs example 20

    Sprint Board

    Ovviamente i Task da creare sono quelli definiti nello Sprint Planning.

    La nostra finestra di stima della capacità del Team (alla destra dei Work Item nella visualizzazione Backlog dello Sprint) somiglierà alla figura seguente:

    tfs example 21

    Work

    Si conclude così la fase di “pre-settaggio” dello Sprint sulla base di quanto emerso durante lo Sprint Planning. Da sottolineare l’uso del termine “pre-settaggio” scelto per evidenziare che l’ambiente di lavoro relativo ad un Sprint è in continua evoluzione e questa è solo una fotografia del suo stato nella fase iniziale.

    Non ci resta che tuffarci nello Sprint vero e proprio, chiaramente nel prossimo post ;-)

    Alcuni approfondimenti:

     

    [FELICEPESCATORE.IT]

    Posted: 9 set 2014 15:32 da felice.pescatore | con no comments
    Inserito sotto: , ,
    Scrum and TFS cookbook - pt.2, Scrum + TFS, let’s start

    Dopo l’introduzione realizzata con il primo post della serie, siamo pronti a tuffarci nel lato operativo, creando un nuovo progetto e gestendo ingrediente fondamentale del nostro libro delle ricette: il Product Backlog. La sua governance spetta al Product Owner che sottopone costantemente i relativi Work Item al processo definito Product Backlog Groomingscrittura, stima, rifinimento e priorizzazione.

    product backlog grooming

    Product Backlog Grooming

    Come ben sanno coloro che usano Scrum, tale framework non contempla direttamente il Product Backlog Grooming,occupandosi esclusivamente della realizzazione dei relativi Work Item. Qui entriamo, in punta di piedi, nel campo dell’Agile Scaling (@Scale) che si occupa di estendere i valori, i principi e le pratiche Agili oltre il “solo” contesto dello sviluppo, abbracciando i vari aspetti aziendali. Chi segue i post che periodicamente pubblichiamo avrà sicuramente letto di DAD e SAFe, ma, volendo restare su Scrum, il Grooming può essere effettuato sfruttando CIF (Continuous Improvement Framework), creato da Scrum.org sotto la supervisione dallo stesso Ken Schwaber e pensato proprio per rafforzare la competitività dell’azienda al fine di massimizzare il proprio ROI (return on investment).

    cif framework

    CIF Framework

    Senza voler approfondire CIF e i relativi processi caratterizzanti, product development e continuous improvement, è importante evidenziare come il Product Backlog sia “condizionato”, praticamente, da tutte le funzioni aziendali: Product Management, Program Management e Development Management.

    Ma TFS 2013 come ci aiuta in tutto ciò? Ebbene, diamo un’occhiata alla segmentazione proposta da Microsoft per l’Agile Portfolio, relativamente allo Scrum Process Template:

    tfs scrum workitem

    TFS 213, Scrum Process Template Work Item

    TFS, di base, considera le attività di dev affidate a un solo Team (come detto vedremo in un apposito post della serie come “aggirare” questa limitazione), identificando due diversi Backlog: il Program Backlog (feature based) e il Product Backlog(Work Item based). Nella sola versione on-premise è possibile anche definire il Portfolio Backlog(Initiatives based), utile per descrivere Epic che tipicamente sono utilizzate a livello Portfolio (Management aziendale) per le decisioni strategiche.

    I tre diversi Backlog sono di proprietà/responsabilità di altrettante specifiche figure:

    • Portfolio Backlog, Portfolio Management;
    • Program Backlog, Product Management;
    • Product Backlog, Product Owner (che può essere coadiuvato da un Product Manager che cura gli aspetti di “esterni” del progetto, come quelli di business);

    Un attimo: dov’è finito lo Sprint Backlog? Tale Backlog viene implicitamente definito assegnando (sicuri?) un Work Item ad una specifica iterazione, sotto la supervisione, chiaramente, dello Scrum Master. L’assegnazione e la definizione dei relativi Task è, in perfetto stile Scrum, responsabilità del Team.

    Le Feature sono tipicamente espresse in modo generico (“il sistema deve disporre dell’autenticazione a 2-fasi”), i Work Itemsono prevalentemente costituiti dalle User Story (“Essendo un Utente voglio utilizzare il cellulare per ricevere il codice di autenticazione”) pesate in Story Point o Ideal Day, mentre i Task sono un’unità esplicita di lavoro (“realizzare la funzionalità di invio dell’SMS con codice di verifica”) espressa in ore e auto-assegnata da un singolo membro del Team.

    Discorso a parte per le Epic che, come lo stesso Portfolio Backlog, non verranno trattate essendo afferenti ad un dominio di discussione diverso.

    Andiamo ora a vedere come creare un nuovo progetto in VisualStudioOnline (se usate un’istallazione proprietaria di TFS la creazione del progetto avviene da Visual Studio), e creare un nuovo Product Backlog.

     

    Creazione di un nuovo progetto (Recent pojects & teams -> new)

    tfs example 1

    Create new project

    Cliccate su “new” e inserite le informazioni richieste, facendo attenzione a selezionare il corretto Process Template. A questo punto, VisualStudioOnline crea per noi una serie di elementi specifici per il nuovo progetto:

      • Un specifica Home Page;
      • Uno specifico Team;
      • Una serie di Iterazioni già attive relative alla prima release del nuovo sistema;
      • e … molto altro di cui parleremo in seguito.

    tfs example 2

    New Home Page

    tfs example 3

    New Team

    tfs example 4

    Iterations

    Impostare il timing relativo alla Release e agli Sprint

    Anche qui bisogna dire che, sebbene Scrum non preveda esplicitamente l’artefatto “Release”, è ormai pratica consolidata raggruppare una serie di Sprint sotto tale cappello. Questo per consentire una migliore gestione delle attività, soprattutto in ottica dei rilasci in produzione e della creazione di PSI (Potentially Shippable Increments) da mostrare agli stakeholder. Attenzione: TFS non setta automaticamente i tempi della Release in conformità con quelli settati per gli Sprint compresi in essa. Quindi dovete impostarli entrambi manualmente (prima o poi lo farà J)! Nell’inserimento, la soluzione Microsoft tiene comunque conto dell’intervallo scelto per lo Sprint precedente (es: 2 settimane) e vi suggerisce le date per i successivi. 

    tfs example 5 tfs example 6

    Sprint and Release timing 

    A questo punto avremo un Backlogs Tree simile al seguente: 

    tfs example 7

    Backlogs Tree

    Aggiungere le Feature e le User Story. Adottiamo un approccio top-down lineare

    Aggiungiamo una feature (Program Backlog)

    tfs example 8

    Aggiunta Feature

    Aggiungiamo le User Story (Product Backlog) avendo cura di settare la corretta relazione Padre-Figlio con la Feature inserita precedentemente

    tfs example 9

    Aggiunta User Story

    Alla fine si otterrà un risultato simile al seguente:

    tfs example 10

    Product Backlog Work Item

     

    Ora facciamo un attimo il punto della situazione: abbiamo creato il progetto, settato il timing, popolato il Program Backlog e il Product Backlog, cosa ci resta? La domanda è retorica perché la verità è che siamo solo all’inizio!

    Nonostante il passo successivo possa sembrare ovvio, ovvero la creazione del primo Sprint/Iteration Backlog con la scelta delle User Story, settando il campo “Iteration” per ogni singola User Story, e la definizione dei Task relativi, manca un tassello fondamentale e irrinunciabile per fare ciò: il Team!

    tfs example 11

    User Story Iteration Setting

    Se è vero che il Product Backlog è definito/gestito dal Product Owner (il Portfolio Backlog viene creato e manutenuto dai livelli aziendali più alti), come ripetuto più volte fino alla noia, la definizione dello Sprint/Iteration Backlog è appannaggio del Team… quindi, non barate! E non cadete nella trappola del pattern “command-and-control”, dove il “manager” definisce e a assegna i compiti.

    Come popolare lo Sprint/Iteration Backlog, scegliendo opportunamente le User Story e creare i Task relativi è l’argomento del prossimo post, insieme alla definizione del Team stesso all’interno di TFS e delle relative viste.

     

    [FELICEPESCATORE.IT]

    Posted: 9 set 2014 15:30 da felice.pescatore | con no comments
    Inserito sotto: , ,
    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: , ,
    Back to Value, Agile Portfolio Management

    Più volte abbiamo parlato del Portfolio (level), mostrando come gestire uno specifico Backlog con TFS2013 in modo da splittare le attività si più Team. Soffermiamoci ora sul Portfolio in se, rispondendo alla domanda "Come creo e gestisco efficacemente un Agile Portfolio?".

    Ebbene, la creazione e la gestione dell'Agile Portfolio per la produzione del software è un'attività complessa (cynefin – complex quadrand) quanto la creazione del software stesso. L'approccio Agile (e Lean) ha reso definitivamente chiaro che molta della complessità è legata alle interazioni che si creano tra le varie persone coinvolte nel processo di produzione, e ciò si riflette anche nella gestione del Portfolio di riferimento.

    In generale, il punto di partenza per la definizione di un Agile Portfolio è la Vision strategica aziendale, che contempla fattori come: trend di mercato a medio e lungo termine, obsolescenza tecnologica, opportunità di business, morfologia del mercato, ecc...

    Questi aspetti sono l'essenza di uno degli elementi portati dell'Agile Portfolio, il Portfolio Planning.

    agile portfolio

    La definizione del Portfolio Planning è la linfa costituente dei 4 pilastri (four pillar) dell'Agile Portfolio:

    • Value Management, definisce puntualmente cosa rappresenta il "Valore" nella Vision corrente, cosa che si concretizza nel Value Stream più volte richiamato in SAFe;
    • Work Management, sono le azioni di gestione messe in atto per portare a compimento le azioni di perseguimento del Value Stream, ad esempio l'Agile Release Train;
    • Capacity Management, condensa le azioni di gestione di tutto ciò che riguarda le risorse disponibili per il raggiungimento degli obiettivi, prima tra tutte le professionalità coinvolte, fondamentali negli ambiti di produzione complessi;
    • Financial Management, definisce gli espetti finanziari complessivi, legando le fasi al rispetto del budget e agli obiettivi di revenue che si vogliono perseguire.

    Ognuno dei quattro pilastri ingloba, in misura differente e con approccio differente, le attività di Risk Management che, chiaramente, assumono un significato diverso in base al contesto di riferimento.

    Infine, ma solo per descrizione non certo per importanza, troviamo il Portfolio Performance che trasforma la Vision in azioni concrete nell'ambito dello sviluppo e del posizionamento sul mercato. Un esempio: se la Vision è quella di "lanciare un treno" (ART launch) che abbatte costantemente il time-to-market, questo si traduce in una chiara impostazioni anche nelle attività di sviluppo che potrebbero, ad esempio, seguire una logica Lean.

    E' tutto? Assolutamente no! Abbiamo dimenticato uno degli aspetti più importanti e onnipresenti nel mondo Agile/Lean: il feedback che fluisce a tutti i livelli per riallineare costantemente il Portfolio con la situazione contingente o, dualmente, spingere affinché quest'ultima si avvicini maggiormente alla strategia inerente la Vision.


    Be SAFe!


    [FELICEPESCATORE.IT]

    Back to Value, draw the canvas!

    Dopo aver presentato il Product Canvas ed avere mostrato, brevemente, come integrarlo con gli strumenti comune in ambito ALM Microsoft, non ci resta che passare alla parte più interessante: dipingere la tela!

    SampleProductCanvas

    Un Product Canvas "popolato" (Roman Pichler)

    Il product Canvas è pensato per essere “esplorato” e “popolato” da sinistra verso destra e, quindi, la prima area che va riempita è quella relativa al “Target Group”, utilizzando l’approccio personas-oriented.

    ProductCanvasSteps

    Se si riflette un attimo su questa priorità, ci si rende conto che è assolutamente ovvia ed in linea con un approccio Agile/Lean alla creazione di soluzioni IT.

    Il secondo passo è quello di riempire la “Big Picture”, descrivendo le Features del prodotto attraverso tutti gli elementi che riteniamo idonei a rappresentarne la Vision. Ben vengano, quindi, user-story, StoryBoard, disegni della UI, ecc. Sono, invece, del tutto banditi elementi specifici dell’attività di implementazione: non troveremo mai: “creare le interfacce di accesso al db”.

    Infine, il terzo step, è quello di decide quale feature verrà sviluppata nella prossima iterazione di sviluppo, elencando le relative user-story ed evidenziando eventuali attività atte a esplorare specifiche soluzioni o a ridurre il rischio.

    Attenzione però a non interpretare questi step come sequenziali in senso stretto. Dopo la prima formalizzazione (sequenziale), l’intero Product Canvas va incontro a continue review e aggiornamenti, dovuti al know-how di dominio, continuamente aumentato man mano che si procede con il progetto.

    Ecco il punto: il Product Canvas è uno strumento di apprendimento che posa la sua essenza sul tanto amato pattern inspect-and-adapt.

    ProductCanvasAndLearning3

    Product Canvas come strumento di apprendimento (Roman Pichler)

     

    [FELICEPESCATORE.IT]

    Back to Value, dematerialisation

    Come accennato nel post precedente, Back to Value, vediamo ora di sfruttare gli strumenti che comunemente utilizziamo per ottenere una versione “digitale” ed integrata del Product Canvas.

    E’ utile fare una premessa: il Product Canvas dà il meglio di se in versione “materializzata”, quindi è opportuno che tutte le discussioni relativi (Inception Meeting, Iteration 0, ecc…) vengano effettuate con un bel Canvas fisico, con tutti gli strumenti tipici. La versione “dematerializzata” è utile per poter conservare in modo più efficace (non la semplice foto!) il lavoro prodotto e consentire di visualizzare i risultati ottenuti anche a stakeholder fisicamente non localizzati nella stessa struttura. Si tratta dello stesso approccio che suggerisco per la Kanban Board.

    Ma veniamo all’oggetto del post.

    Step 1

    Il primo passoè quello di creare/dotarsi di una versione digitale del Product Canvas, realizzato sfruttando PowerPoint, come quello mostrato nella figura seguente:

     ProductCanvasTemplate

    Product Canvas PPoint Template

    A questo punto, una volta fatte tutte le modifiche opportune, riempito il Canvas e aggiunti gli elementi di Story Board (consigliato), non resta che linkare direttamente il nostro elaborato direttamente a TFS in modo da condividerlo con gli stakeholder di progetto.

    Step 2

    Sempre in PowerPoint, selezionate “STORYBOARD” dalla Ribbon bar e poi attivate la voce “Storyboard Links”. Si aprirà una finestra simile alla seguente:

    productcanvas ppoint 1

    Linked Work Item

    Step 3

    Selezionate “Connect”, scegliete il server TFS di riferimento e il Team Project a cui volete associare il Product Canvas:

    productcanvas ppoint 2

    TFS Server & Team Project Selection

    Step 4

    Selezionate il WorkItem a cui collegare il Product Canvas (nell’esempio della figura seguente: “Product Canvas Definition”) e confermate l’operazione:

    productcanvas ppoint 3

    Scelta Work Item

    Step 5

    Il linking è avvenuto con successo e non vi resta che chiudere la schermata di riepilogo:

    productcanvas ppoint 4

    Ripeilogo

    Possiamo ora verificare se tutto è andato a buon fine, aprendo VisualStudio Online, selezionando il progetto e visualizzando i dettagli del Work Item “linkato”:

    productcanvas ppoint 5

     

    [FELICEPESCATORE.IT]

    Work Item & Product Canvas linked

    Il file deve chiaramente risiedere in una directory condivisa (eventualmente sharepoint) per poter essere accessibile da chiunque enon risiedere sul vostro disco privato.

    Bene, a questo punto abbiamo definito il MODELLO, abbiamo creato il TEMPLATE e collegato il tutto a TFS e ora… non ci resta che “disegnare la tela”. Lo faremo, però, nel prossimo post.

    Più Post Pagina seguente »