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.

Update pre-natalizi

Potete leggere online le novità di Visual Studio Online relative all’update del 2 dicembre. Di tutte le novità, probabilmente la piu interessante è che, installando la versione del client di Release Manager Update 4, è ora possibile connettere Release Management al proprio account VSO per effettuare il deploy su azure.

Come sempre il deploy non è rilasciato per tutti gli utenti contemporaneamente, ma il rollout avverrà durante la settimana, per cui se non vedere le nuove funzionalità attive nel vostro account, è solamente questione di pazientare un poco.

Happy VSO.

0  

Perché non posso cancellare un Test Plan con TFS2013 Update 3

Se avete aggiornato TFS 2013 con update 3 o successivi ed usate Microsoft Test Manager, probabilmente vi sarete accorti che non più possibile cancellare un Test Plan da MTM.

image

La ragione è da ricercarsi nella modifica introdotta con Update 3, che trasforma i Test Plan in Work Item veri e propri.

image

In TFS non è possibile cancellare fisicamente un Work Item a meno di non ricorrere alla linea di comando, usando il comando witadmin con l’opzione destroywi.

Questo comportamento è voluto, perché TFS deve mantenere la storia di ogni Work Item e non deve essere possibile effettuarne la cancellazione fisica in modo facile. Si pensi ad un bug, anche se il bug è stato riconosciuto come duplicato e deve essere rimosso dalla lista di bug attivi, deve essere chiuso con reason “duplicato” invece di essere cancellato. Questo perché posso essere interessato ad avere report che mi dicano quanti bug sono in stato chiuso con reason duplicato per avere delle statistiche.

Per questa ragione, ora che i Test Plan sono dei Work Item veri e propri, la loro cancellazione deve essere effettuata con il comando

witadmin destroywi

cosi come per qualsiasi altro Work Item del sistema.

Gian Maria.

0  

VS 2015–Novità sul debugging

Nel recente evento Connect() di Microsoft è stato rilasciato in preview Visual Studio 2015. Questa nuova versione di Visual Studio introduce tante novità per noi sviluppatori, tra cui quelle legate al debugging. Questo post ha l’intento di mostrarvi come sfruttare al meglio queste nuove feature.

Partiamo dalla prima novità: l’interfaccia grafica. Infatti, in Visual Studio 2015, quando creiamo un nuovo punto di interruzione (o passiamo sopra uno già esistente), compare un menù contestuale con 2 icone che ci consentono o di aprire il menù delle impostazioni del debugger o abilitare/disabilitare il punto di interruzione (figura 1).

 

image

Figura 1

Nel caso in cui selezioniamo il pulsante delle impostazioni, viene aperta una finestra nell’editor che ci mostra 2 cose: conditions e actions (figura 2).

Le conditions ci consentono di stabilire in base ad una o più condizioni quando l’esecuzione del codice si deve fermare in corrispondenza del punto di interruzione (figura 2). Le tipologie di condizioni che possiamo applicare ad un punto di interruzione sono 3:

  • Conditional Expression, che consente di verificare una condizione su una variabile, proprietà o oggetto nel codice;
  • Hit Count, che consente di indicare il numero di volte che il codice in corrispondenza del breakpoint deve essere eseguito prima che Visual Studio fermi l’esecuzione
  • Filter, che aiuta a debuggare codice che viene eseguito in parallelo (ad esempio è possibile specificare l’id o il nome del thread).

 

image

Figura 2

Le actions invece consentono (per il momento!) di stampare un messaggio nella finestra di Output con la possibilità di inserire sia il valore di variabili presenti nel contesto tramite le parentesi graffe, che di poter utilizzare delle variabili preimpostate precedute dal carattere $ (dollaro). In tale contesto, è anche possibile impostare se l’esecuzione del codice si deve fermare oppure no (Continue execution).

 

image

Figura 3

 

Alcune novità ci sono anche nel menù contestuale associato al punto di interruzione, infatti adesso contiene solo i collegamenti ad alcune opzioni essenziali come in figura 4 (visto che le altre sono state spostate nella piccola popup della figura 1):

 

image

Figura 4

Una delle grandi novità di Visual Studio 2015 è la possibilità di eseguire le lambda expression nell’Immediate window o nella Watch window. Questa è una feature che è stata richiesta tantissimo e che farà felice tanti sviluppatori. Nella seguente figura (5), si può vedere un esempio di utilizzo:

 

image

Figura 5

 

Ultima novità di questo post sono i performance tips: si tratta di informazioni visualizzate durante il debugging che mostrano il tempo di esecuzione e il tempo di CPU legato all’istruzione eseguita (figura 6). E’ inoltre possibile accedere alle opzioni per questi ultimi cliccando su di essi (figura 7).

 

image

Figura 6

image

Figura 7

 

Non vi resta che scaricare la preview di Visual Studio 2015 da qui e iniziarla ad usare!

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

Slides sulle due sessioni di SQL Sat Parma

Le slide delle due sessioni tenute al SQL Saturday di Parma sono disponibili in italiano ed inglese su SlideShare.

Ormai sono proprio orientato all’application lifecycle management, anche se andrebbe definita come database lifecycle management (DLM), essendo praticamente solo su SQL Server.
La prima sessione, “Mettere i database sotto source control“, è scaricabile qui.
In essa abbiamo descritto genericamente i concetti di team work e di ALM/DLM, per poi capire le differenze tra codice e database.
Alla fine abbiamo fatto le dimostrazioni dell’utilizzo dei tool forniti, sia da Microsoft con Visual Studio e SQL Server Data Tools, sia da terze parti, come Red-Gate ed ApexSQL.
La seconda, “Unit testing su database“, è scaricabile qui.
In questa sessione abbiamo affrontato i concetti dello unit testing, sempre riferito al database, ma con un occhio rivolto sempre a quanto si farebbe con il codice puro.
Abbiamo mostrato come utilizzare i vari tool di testing come Red-Gate SQL Test e Visual Studio Unit test projects per poi finire con una dimostrazione diretta di unit test con TSQLUnit.
Inoltre ho creato un set di script dimostrativo sull’utilizzo di TSQLUnit, usando solo T-SQL.
Spero di trovare il tempo per scrivere un’interfaccia per SSMS in modo da semplificare la scrittura di test di unità con TSQLUnit.

Con l’anno nuovo spero di rilasciare anche due articoli che andranno ad estendere il mio precedente sulla Continuous Integration su SQL Server.

Stay Tuned! 

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.