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

Sorgenti del .Net Framework in Visual Studio e oltre…

Avete mai avuto voglia di navigare facilmente nei sorgenti del .Net Framework senza usare diversi programmi o escamotage?

Per chi non lo sapesse, da qualche mese a questa parte è stato pubblicato il portale Reference Source che vi consente di navigare agevolmente all’interno dei sorgenti .Net Framework in maniera molto simile all’object browser di Visual Studio. La cosa interessante, è che è anche possibile scaricare i sorgenti in un pacchetto .zip e navigarlo all’interno di una soluzione.

Ma le novità non finiscono qui! Infatti tramite l’estensione Ref12 potete usare il tasto F12 per navigare direttamente da Visual Studio su Reference Source e visualizzare i sorgenti interessati. Bello, no?

E se volessi debuggare il mio codice e quello del .Net Framework? Beh, per quello potete seguire questo utile post che vi spiega come fare: Allow developers to step through .NET Framework sourcesA bocca aperta

 

Vi lascio con un video riepilogativo delle funzionalità esposte dal portale:

 

 

Enjoy it!

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 Item per 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 _ReadyToDelete quella 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.0Common7IDEReferenceAssembliesv2.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 (se siamo in presenza di una installazione on-premise o su una macchina in Cloud sotto il nostro controllo, ma non per VSO):

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

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 Backlog, Prodotto 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 sesso backlog in un Team Project e Configuration 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.

Ridatemi il Tachimetro!

Dopo aver partecipato allo splendido evento che risponde al nome di Better Software 2014, conclusosi ieri, eccoci a parlare nuovamente insieme di ALM e VisualStudioOnline.

Uno degli elementi che è emerso durante la 2gg di Firenze, è la necessità di ridurre il gap comunicazionale tra il management (Program e Portfolio) e gli assett operativi aziendali. In quest’ottica, è evidente che parlare, per esempio, ad un CEO o un CFO di Story Point, Sprint, Review, ecc.. ecc.. serve solo a confondere le idee e non ci aiuta ad avere un’organizzazione più dinamica, in grado di cogliere le opportunità emergenti e di soddisfare le aspettative degli stakeholder.

Il Management (Portfolio in particolare) si aspetta di avere delle metriche e di verificare se le nuove Iniziative messe in campo ne stando condizionando il trend in modo positivo. Fortunatamente, gli strumenti di BI che ci consentono di fare ciò sono decisamente maturi, ma spesso alla loro potenza si associa una complessità non irrilevante, sia di set-up, sia di gestione e sia di fruizione.

Se si ha bisogno di un quadro minimale, VisualStudioOnline/TFS ci viene incontro per un’analisi diretta dei dati contenuti nel Repository di progetto grazie alla funzionalità Chart, direttamente gestibile tramite la Web App generale dell’ambiente e attivabile da Work->Queries.

vso chart 1

VSO Query/Chart

Vediamo ora come utilizzare questa interessante funzionalità per mostrare l’evoluzione del progetto e l’andamento del lavoro al nostro management, in maniera più vicina alle loro esigenze.

Prima di tutto creiamo una nuova query di esempio, selezionando, in questo caso, tutti i work item presenti, indipendentemente dal tipo e dallo stato:

vso chart 2 simple chart query

Simple Chart Query

Salvata la nostra query (attenzione a selezionare il folder “Shared Queries”, altrimenti non sarà possibile effettuare il pin sulla home), passiamo alla funzionalità di definizione dei diagrammi (“chart”) e selezioniamo “New Chart”:

vso chart 3

New Chart

Sulla sinistra possiamo scegliere la tipologia di diagramma che vogliamo realizzare (Torta, Istogramma, Pivot, ecc..) mentre nell’area evidenziata in verde settiamo i parametri di riferimento per la generazione dello stesso:

vso chart 4

Scelta del tipo di Chart e settaggio delle informazioni

Una volta raggiunto il risultate desiderato, salvate il tutto.

A questo punto non ci resta che legare il diagramma alla home della nostro Team Project: attiviate il menu del diagramma che volete “pinnare” e scegliete “Pin to Homepage”

vso chart 5

Pin-to-Homepage

Se tutto è andato per il verso giusto, vi ritroverete una home page più “comunicativa” con il vostro cruscotto informativo bello in vista:

vso chart 6

VSO Home with Chart

Come visto, si tratta di uno strumento, entry level, semplice da attivare ed utilizzare, ma di estremo impatto comunicativo. Quando avrete bisogno, e vi assicuro che la domanda è proprio “quando” e non “se”, di uno strumento più raffinato in grado di fare analisi da più fonti e incrociare i dati per creare metriche di dettaglio, potrete pensare di dare uno sguardo a Power BI, nominato di recente da Forrester “Leader in Agile Business Intelligence”.

Chiudo con un OT, ringraziando gli organizzatori di Better Software per l’accoglienza e l’ottima qualità della manifestazione e, segnalandovi, le slide del mio intervento (http://www.slideshare.net/felicepescatore/agilescale-portfolio-level) se volete approfondire gli aspetti legati alla Gestione Olistica aziendale.

Quel vecchio avido di SQL Server

Oggi ho incontrato un problema abbastanza fastidioso configurando un build controller in TFS. L’errore era generato dall’impossibilità di attivare un servizio WCF nell’AT per mancanza di memoria RAM libera. Questo porta ad una regola generale da applicare se avete un TFS a singola istanza, dove SQL Server e AT condividono la stessa macchina.

Se seguite i dimensionamenti di MSDN, la configurazione singola macchina, con 4 GB di RAM ed un disco 10k è sufficiente per gruppi fino a 500 utenti. Se la vostra soluzione è virtualizzata, avete anche il vantaggio di poter dare più RAM e più CPU con poco sforzo e quindi la soluzione singola macchina, è comoda perché vi occupa solamente una licenza di Windows Server ed è di facile manutenzione.

La regola di base che dovete tenere in mente è che SQL Server tende a consumare tutta la memoria disponibile, lasciando poche risorse al resto. In questo caso l’occupazione di memoria di SQL era arrivata a 3 GB lasciando praticamente nulla disponibile al resto dei servizi. La regola doro quindi è quella di limitare l’uso di RAM di SQL Server, in modo da bilanciare l’uso delle risorse ed evitare questi problemi.

In questo specifico caso purtroppo era mancata la checklist, dato che come sempre avevo parlato di questo problema all’amministratore, ma poi con tutte le cose da fare entrambi ci siamo dimenticati fisicamente di farla, per cui purtroppo, come volevasi dimostrare, senza limitazione SQL Server ha occupato cosi tante risorse da compromettere il funzionamento degli altri servizi.

Ricordate sempre di monitorare le risorse usate dai vari componenti di TFS, cosi da prevenire errori di questo tipo.

Happy TFS.

Gian Maria.

2  

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… 

Quando faccio git push quali branch sto pushando?

Lavorando in command line in Git si potrebbe erroneamente pensare che facendo un

git push

Si effettui il push della sola branch che è in checkout, ma questo non è vero, dato che il reale comando per effettuare il push di una branch è

git push remotename branchname

Quindi se state nella branch XYZ ed avete un  unico remote chiamato origin dovete fare

git push origin XYZ

Il comportamento adottato da git se non specificate ne il remote ne la branch è determinato dalla impostazione push.default e come possiamo leggere dalla documentazione le possibilità sono.

nothing – do not push anything.

matching – push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.

upstream – push the current branch to its upstream branch.

tracking – deprecated synonym for upstream.

current – push the current branch to a branch of the same name.

Il default è matching, per cui facendo un git push state effettuando il push di tutte le vostre branch. Questa opzione probabilmente non è il miglior default che si possa avere, per questo in Git 2.0 il default verrà modificato in “Simple”, un ulteriore nuovo possibile valore per push.default:

simple – in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners. This mode has become the default in Git 2.0.

Fate quindi attenzione al modo che avete selezionato per evitare sorprese.

Gian Maria.

Scrum and TFS cookbook – pt.5, Review and Retrospective

Completato il nostro Sprint ci aspettano 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), lo Scrum 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 Continous 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à.

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