Amending in Git

Nell’ultimo update di Visual Studio (Update 2 ora in RC) il supporto a Git continua ad evolversi, portando direttamente nella UI altre operazioni che erano appannaggio della Command Line. Debbo dire che una volta imparato Git la Command Line rimane sempre la vostra piu cara amica, perchè vi darà sempre pieno accesso a tutte le funzionalità, ma avere molte opzioni anche nella UI è comodo nell’ottica di integrare Git in team che vengono da un Source Control centralizzato e per i quali la command line potrebbe essere un esperienza Traumatica :) .

Una funzionalità molto interessante di Git va sotto il nome di “amending” e serve per modificare l’ultimo commit. Di base effettuando un commit con l’opzione –amend, invece di creare un nuovo commit, Git aggiunge i cambiamenti presenti nella staging area al commit precedente. I casi d’uso sono

*) Volete cambiare il messaggio dell’ultimo commit
*) Avete dimenticato di includere un file nell’ultimo commit
*) Dopo avere committato avete delle leggere modifiche da fare ad un file ma non volete creare un nuovo commit

ATTENZIONE: MAI e dico MAI fare un amend di un commit di cui si sia già effettuato il push su uno dei remote. In questo modo il vostro team si troverà a fronteggiare anomalie veramente fastidiose da risolvere.

Effettuare un amend dalla UI di Visual Studio è ora possibile, supponiamo di avere questa situazione, ho fatto un commit, ma dopo averlo fatto, mi rendo conto che avrei dovuto aggiungere anche un’altra modifica. A questo punto io posso fare la modifica mancante, supponiamo al file SqlStatements.cs. e poi andare nella finestra Changes.

2014-04-06_09-24-42

Come potete vedere nella figura sopra, nella finestra changes ho ancora il messaggio “Commit 0d3266b0 create locally” che rappresenta il commit precedente. Il file SqlStatement è correttamente segnato come modificato perché ho appunto fatto le modifiche che avrei voluto includere nel precedente commit. Ho inserito un nuovo commento chiamato “This is the right commit” e sarei quindi pronto per fare un altro commit. La situazione è chiaramente visibile anche da riga di comando

2014-04-06_09-25-21

Ora nel menu Actions, è presente una nuova voce di menu chiamata appunto “Amend” che vi permette di fare un commit in “rettifica”. Questo significa che le nuove modifiche (in questo caso il file SqlStatement.cs”) vengono aggiunte a quelle del commit precedente ed il commento viene sostituito. Al termine dell’amend questa è la situazione.

2014-04-06_09-25-29 

Da qui potete chiaramente vedere che il commit precedente è scomparso ed è stato sostituito da un nuovo commit che comprende tutte le modifiche di quello “amendato” più tutte quelle messe in amend. Come potete vedere il vecchio commit è scomparso, questo significa che la storia del vostro repository locale è stata “riscritta” e questa è la ragione per cui NON DOVETE MAI EFFETTUARE AMEND SU COMMIT DI CUI AVETE GIA’ FATTO PUSH, ALTRIMENTI RISCRIVETE LA STORIA PER TUTTI CAUSANDO NUMEROSI PROBLEMI.

Fortunatamente la UI di Visual Studio previene questo, quindi quando tentate di fare un amend di un commit di cui avete già fatto il push ottenete errore. Purtroppo il messaggio è poco significativo, ma per lo meno non correte il rischio di fare confusione.

2014-04-06_09-35-45

E’ anche possibile effettuare l’amend del solo messaggio di commento del commit. Il messaggio di commit è fondamentale e deve essere significativo, per cui se ci si rende conto che il messaggio non è stato messo correttamente è possibile cambiarlo. Per fare questo si può andare nella “Unsynced Commits”, da li verificare che l’ultimo commit sia ancora in Outgoing (ricordate vero che non potete fare amend di un commit di cui avete già fatto push? :) )

image

A questo punto fate doppio click su di lui per vederne il dettaglio, e da li se cambiate il Commit Message vi verrà abilitata la voce di menu “amend Message”. Chiaramente questo vale solamente per l’ultimo commit, ovvero non potete (dalla UI) cambiare il messaggio di commit di un altro commit tranne l’ultimo.

image

Buon lavoro “distribuito” Smile

Gian Maria Ricci

0  

Esportazione dei dati da VSO a on premise attiva fino al 20 Maggio

Se vi connettete al vostro VSO potrete ora notare una nuova tile dedicata all’esportazione dei dati.

image

Purtroppo le funzioni di esportazione, come detto precedentemente, saranno disponibili solamente per un periodo limitato di tempo, causa difficoltà tecniche nel tenere in piedi una opzione di migrazione permanente, a causa della differente velocità di aggiornamento delle versioni online e on-premise.

Cliccando sulla tile mostrata in figura verrete riportati ad una pagina MSDN che vi spiegherà passo passo come effettuare questa esportazione; operazione che richiede comunque di aprire un ticket al supporto tecnico per farvi abilitare le funzioni di esportazione.

Terminata questa fase, se volete esportare i vostri dati da VSO a un TFS on-premise, dovrete utilizzare l’integration platform o gli Integration Tools, oppure utilizzare git-tf per esportare il sorgente e copiare i Work Item con Excel se vi interessa una esportazione senza storia.

Gian Maria Ricci

0  

Il potere occulto del debito tecnico

Il concetto di Debito Tecnico (technical debt) è già emerso in diversi nostri post, in particolare in “ALM, un approccio pratico alla gestione del Debito Tecnico” dove abbiamo introdotto le iterazioni CBTi, ovvero le Clean Technical Debt Iteration, e la loro gestione tramite TFS.

Technical Debt

Il concetto che si cela dietro le CBTi è esplicitamente evidenziato in SAFe nella HIP iteration, che ha tre obiettivi primari:

  • Hardering
  • Innovation
  • Planning

Ma torniamo all’elemento centrale del post, riportando la definizione di “debito tecnico” presente su Wikipedia:

“[Technical Debt is] a neologistic metaphor referring to the eventual consequences of slapdash software architecture and hasty software development”

“[Il Debito Tecnico] è una metafora per indicare le eventuali conseguenze derivanti dalla frettolosa definizione di un’architettura software e da un altrettanto frettoloso sviluppo]

per completezza va ricordato che il termine “technical debt” è stato utilizzato per la prima volta da Ward Cunningham, parlando della complessità di far evolvere nel lungo periodo un sistema progettato tenendo conto solo dell’immediato (breve/brevissimo periodo)

Risulta ovvio che, se non trattato adeguatamente, il debito tecnico può portare a conseguenze molto forti, fino al fallimento del progetto stesso.

Nonostante ciò, bisogna, però, sempre vedere il bicchiere mezzo pieno! Infatti non esiste progetto che non abbia debito tecnico, e se pensiamo che il nostro progetto non ne sia affetto, probabilmente abbiamo una fiducia eccessiva in quel che stiamo realizzando e nelle nostre competenze, portandoci ad essere saccenti senza valutare correttamente il contesto (inspect-and-adapt) e generando, sicuramente, del lavoro con forti criticità o parzialmente inutile (waste).

Tale considerazione nasce dal fatto che il debito tecnico non è “banalmente” legato a codice scritto male o non testato ma dipende da fattori intrinsechi, legati al Team e al loro piano di azione.

Partendo dall’assunto che è possibile “gestire” un certo grado di debito tecnico, vediamo come classificare, spannometricamente, il debito stesso a seconda della gravità, dal grado più basso (e quindi più gestibile) a quello più alto e non più tollerabile:

  • Grade one: framework changes and evolution. Oggi, praticamente, nessun software viene scritto da zero, preferendo sempre l’adozione di un framework che fornisce quante più funzionalità cross-domain possibili. Ma ogni framework evolve (i più utilizzati evolvono anche con estrema rapidità) e per quanto sia garantita una retro-compatibilità, escluse ovviamente le nuove funzionalità, prima o poi arriverà il cosiddetto “breakdown time” in cui non sarà più possibile garantirla. Va da sé che per ovviare a tale problema e sfruttare a pieno le nuove caratteristiche bisogna adattare una corretta strategia di aggiornamento e dedicare tempo e risorse ad essa. In questo contesto è forse superfluo sottolineare come pratiche di “continuous integration”, supportate da test automatizzati, consento di approcciare al problema in modo sistematico e abbattere il debito tecnico relativo; 
  • Grade Two: lazy developers. Si tratta di una condizione particolare, dovuta spesso alla “pigrizia” (meno tipicamente all’incapacità) degli sviluppatori di gestire e far evolvere codice scritto da altri. Ogni sviluppatore è in grado (si spera!) di scrivere un sistema da zero, ma solo ottimi sviluppatori sono in grado di lavorare su quanto realizzato da altri. La pigrizia, però, non si evidenzia solo sulla propria attività, piuttosto diventa particolarmente evidente nel lavoro in Team quando è necessario “remare all’unisono” per raggiungere gli obiettivi e trasformarsi, idealmente, in un High Performance Team. Tale obiettivo è, infatti, difficile da raggiungere e richiede un impegno costante sotto la supervisione di un Coach esperto per evitare che le divergenze diventino ingestibili e la soluzione prodotta diventi debitoria;
  • Grade Three: pragmatic law. Nello sviluppo del software bisogna è necessario essere sempre pragmatici, riconoscendo che non c’è mai abbastanza tempo per sviluppare la soluzione perfetta. Bisogna riuscire a gestire correttamente il bilanciamento tra qualità, di quanto sviluppato, e tempo a disposizione, evitando di realizzare qualcosa di inutile che dovrà poi essere re-implementato. Un fattore particolarmente ostico è riuscire a comprendere la complessità (Story Point, Ideal Days) di quanto ci si approccia a realizzare, cercando di effettuare una stima attendibile: nel caso in cui la stima sia troppo distante dalla realtà e il commitment non è rinegoziabile, si cade quasi sempre nella tentazione di produrre codice di bassa qualità per rispettare i tempi, aumentando esponenzialmente il debito tecnico. Se sia accetta, quindi, la condizione che esiste sempre un certo livello di debito tecnico, non essendo possibile raggiungere la soluzione ottimale poiché vincolata da fattori reali (es: tempo), possiamo definire tale debito tecnico come “debito tecnico nobile”. Quindi, tanto meno si riesce a creare il giusto bilanciamento tra risultato atteso e risorse disponibili, tanto più ci si avvicina rapidamente al quarto ed ultimo grado del technical debt;

debito tecnico sottostima complessita

Aumento esponenziale del Debito Tecnico

  • Grade Four: cannot move forward. Arrivati a questo punto, il debito tecnico accumulato diventa evidente e non è più possibile ignorarlo perché il sistema realizzato è, con molta probabilità, affetta da diversi problemi (bug) su cui bisogna intervenire. Il catalizzatore? Gli stakeholder che notano ed evidenziano le lacune. Bisogna “pagare il debito accumulato” e fronteggiarne il costo (cost of servici the debt), esattamente come avviene con gli interessi della carta di credito, quando, per esempio, si va in rosso con il conto. La transizione tra il “terzo” ed il “quarto” grado può anche essere programmata, purché ci si appresti a pagare quanto prima il debito risultante. Si pensi, ad esempio, al nuovo software di contabilità per un’azienda che si trova a dover espletare alcuni obblighi normativi: se le funzionalità implementate sono sufficienti, allora si può decidere di rilasciare una prima release (deadline pressure) del software perché indispensabile. Si tenga conto che tale scelta è sempre rischiosa e il danno maggiore è spesso a carico del cliente, che accetta implicitamente una soluzione con funzionalità ridotte (ma non qualità ridotata!) rispetto a quella preventivata.

debito tecnico sottostima tempo

Deadline Pressure

Nonostante il quarto grado non dovrebbe mai essere raggiunto, paradossalmente, è quella che si raggiunge più facilmente. Questo perché non si è abituati ad un approccio Lean che consente di migliorarsi costantemente e, di conseguenza, migliorare il Team e quanto realizzato. Bisogna, ricordare, infine, che è sempre meglio ridurre il numero di features realizzate, garantendone sempre il livello di qualità stabilito in generale per la release che realizzare il doppio delle features rinunciando ad essa.

La qualità non è negoziabile, perché il conto prima o poi si paga!

TFS Update 2 is RTM (but Visual Studio Update 2 still RC) :)

Ok, come detto da Brian, nel suo blog, questa volta la situazione Update è un po piu confusa. Per TFS on-premise l’Update2 è RTM, ovvero è attualmente disponibile la versione definitiva, mentre per Visual Studio l’Update 2 è ancora in RC. I download li potete trovare a questi indirizzi

Per quanto riguarda TFS:

Per Visual Studio invece la lista dei download disponibili è la seguente:

Le ragioni  per cui per TFS l’aggiornamento è RTM mentre per le parti client è ancora in RC le potete leggere direttamente nel blog di Brian, ma gli aspetti interessanti sono le novità che sono state introdotte con questi aggiornamenti, di cui potete leggere una lista estesa nel blog di Visual Studio ALM.

Team Foundation Server 2013 Update 2 and Visual Studio 2013 Update 2 Release Candidate now available

Giusto per invitarvi a leggere il suddetto post, riporto qui la lista sintetica delle novità.

Testing Tools

Coded UI Testing for Windows Phone Applications

Export test artifacts

Manage test parameter data 
Grid view for Bulk Update Test Cases.

Cloud Load Testing integration with Application Insights.

Application Insights

Visual Studio Tools for Application Insights

Auto configuration of monitoring with Microsoft Monitoring  Agent and configuration files

Integration of Application Insights with Cloud Load Test

The Streaming Data page and Raw Event Stream for Dashboards 
Logging Integration with Search in Application Insights

City level reports from Usage

Team Foundation Server

The portfolio backlogs have performance improvements during web access navigation.

You can query on tags in Visual Studio and through web access.

You can apply tags to work items in Visual Studio.

You can apply permissions for who can add new tags.

You can edit tags in the Excel add-in for Team Foundation Server.

You can configure non-working days, and these are excluded from burndown charts.

Cumulative Flow Diagram start dates are configurable.

Lightweight charts can be pinned to project or team homepages.

You can customize the colors in lightweight charts.

The look and feel of the project and team homepage is updated.

Assume that you use Git hosted on TFS as source control system, you can access the deployed version of the solution by opening the iTrace file that is generated by the Microsoft Monitoring Agent, in Visual Studio Ultimate 2013.

Git tools have been updated to include an annotate view, reverting a commit, amending a commit, pushing to multiple remotes, and improved progress and cancellation ability for long running operations.

………..

Buon lavoro a tutti.

0  

Essere sempre Agile conviene sempre, utilizzare una Metodologia Agile… dipende!

Il Post precedente, in cui abbiamo evidenziato le profonde differenze tra un approccio Agile e il modello a Spirale, ci consente di rispondere ad una domanda a cui spesso, chi ha l’onere (e l’onore ;-) ) di dover gestire un progetto si trova a dover rispondere?

            “Conviene, per questo progetto, adottare un approccio Agile?”

Ebbene, chiariamo subito una cosa: la domanda è fondamentalmente sbagliata! Infatti la relativa risposta sarebbe sempre e soltanto “SI” perché l’approccio Agile migliora la collaborazione all’interno del Team e quella con l’esterno, puntando a creare il massimo Valore possibile per gli stakeholder. Ma tale aspetto (quindi i Valori e le Pratiche) possono essere sempre usati, anche senza una Metodologia Agile specifica.

La domanda corretta diventa quindi:

“Conviene, per questo progetto, adottare una Metodologia Agile o una Metodologia più Tradizionale, sia per la gestione che per lo sviluppo?”

waterfall-network

Waterfall vs Agile

e qui le cose si fanno decisamente interessanti, perché la risposta potrebbe riassumersi in un banale, ma assolutamente complicato: “dipende”. Ma “dipende” da cosa: dalla complessità del progetto, dalla preparazione del Team, dai tempi, dai costi, dall’incertezza tecnologica, dal contesto?

Tutti fattori validi (non esaustivi) che vanno opportunamente valutati e calibrati tra loro per effettuare la scelta giusta. In particolare, esistono una serie di framework che ci consentono di indirizzarci sulla strada giusta e, tra questi, vediamo uno dei più noti, ovvero Cynefin, che consente di individuare all’interno di quali casistiche di complessità ricade il sistema in analisi.

Partiamo dalle basi, ovvero dal modello che descrive il framework stesso (fig. successiva), definito sense-making dagli autori (Kurtz e Snowden, K&S):

cynefin framework

Cynefin framework

Il framework posiziona i sistemi in 4 quadranti idealmente ben distinti (anche se nella pratica i contorni sono decisamente più sfumati) e suggerisce i relativi pattern comportamentali:

  • Simple, i sistemi che ricadono in questo quadrante sono sostanzialmente contraddistinti da una chiara relazione causa-effetto, in cui l’aleatorietà è praticamente azzerata, e la soluzione è assolutamente evidente e non in discussione:

se butto un sasso da una finestra questo cadrà a terra”.

In questo quadrante è possibile decidere anticipatamente cosa fare, applicando, come suggerito, il pattern comportamentale sense-categorize-respond (valutare-classificare-agire). Lo sviluppo del progetto è affidato ad una catena di controllo (command-and-control) e a una serie di knowledge workers (KW) che applicano le proprie competenze in relazione a quanto deciso. Chiaramente la rete tra i KW è decisamente poco influente perché ad ognuno è demandato un compito ben specifico;

  • Complicated, i sistemi che ricadono in questo quadrante rispondono ancora ad una relazione del tipo causa-effetto, ma essa non è così evidente e non è univoca:
  • Complex, i sistemi in questo quadrante non possono più essere modellati 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. Un ottimo esempio di sistemi complessi sono i sistemi con rientranti (o feedback):

“se premo il pulsante di accensione del televisore, questo potrebbe accendersi a seconda del fatto che lo stesso sia o meno collegato alla rete elettrica”

In questo scenario, K&S suggeriscono di adottare il pattern sense-analyze-respond (valutare-analizzare-agire) che, parte sempre da una valutazione, ma poi si concentra sull’analisi del contesto che viene effettuata tramite l’approccio analitico di scomposizione del sistema in sotto-sistemi più semplici, basandosi sul fatto che il funzionamento d’insieme dei singoli componenti è equivalente a quello del sistema nel suo complesso (somma delle parti). I worker di tale sistema sono gli “Experts”, in grado di contestualizzare le proprie attività e relazionarsi con i propri colleghi per creare un Network che rende meno rigido (anche se non lo elimina) l’approccio command-and-control

 Un esempio concreto della sua applicazione: la catena di montaggio;

“lo stesso motore ha un rendimento diverso in base a come è stato utilizzato”

In questo caso l’approccio da seguire è quello di “metterci le mani dentro”, ovvero probe-sense-respond (sondo-valuto-agisco), anche sapendo che potrei perturbare il sistema stessa (principio di indeterminazione di Heisenberg).

In questo caso il Network tra i worker diventa fondamentale e il pattern comportamentale diventa inspect-and-adapt, diminuendo anche l’importanza degli Expert a favore di worker più orizzontali in grado di spingersi oltre e rispondere nel modo migliore relativo al contesto;

  • Chaotic, i sistemi di questo quadrante non rispondo più a nessuna legge deterministica o, se lo fanno, ciò avviene per una frazione limitata di tempo che non ha valenza sul piano complessivo. Siamo in presenza di una elevata incertezza in cui ogni tipo di valutazione (sense) o di indagine (probe) non è di alcun aiuto. Ogni approccio di gestione di questi sistemi è destinati, nella stragrande maggioranza dei casi, ad essere fallimentari, e se proprio bisogna intervenire, l’unico pattern perseguibile è act-sense-response, in pratica si opera sul sistema a “naso”, si valuta il risultato e si agisce di conseguenza (agisco-valuto-rispondo). Ogni piccola perturbazione porta ad un effetto potenzialmente devastante e, la stessa azione ripetuta più volte, porta ad effetti diversi. Si è in presenza del cosiddetto effetto farfalla:

“il battito delle ali di una farfalla in Brasile può scatenare un tornado in Texas”

Sia il Network che la Gerarchia hanno ben poco significato.

Caratterizzati i quattro quadranti, vediamo come Cynefin ci indirizza verso una possibile metodologia di sviluppo:

  • Se siamo in presenza di sistemi Semplici o Complicati, possiamo ricorrere a metodologie tradizionali, perché il dominio di riferimento è noto e la variabilità è estremamente bassa. Ad esempio, per i sistemi Complicati, si può pensare di utilizzare il modello a Spirale, ma non è da escludere lo stesso Waterfall;
  • Se siamo in presenza di sistemi Complessi, le metodologie Agili sono la soluzione ideale;
  • Se siamo in presenza del Caos la scelta migliore è, probabilmente, quella di abortire il progetto!

Esistono chiaramente situazioni border-line dove l’esperienza e la maturità aziendale rappresenta l’elemento di scelta definitivo: ad esempio se il sistema è al confine tra Complicato e Complesso e la mia azienda utilizza già abbondantemente metodologie Agile, la scelta ricadrà quasi sicuramente su quest’ultime. Il caso duale vale un po’ meno perché l’entropia del sistema è più facile che aumenti piuttosto che diminuisca.

Prima di concludere, per completezza, bisogna evidenziare che Cynefin contempla anche un quinto quadrato, definito Disorder, in cui ci si trova quando non si riesce a inquadrare correttamente il sistema. Cosa fare in questi casi? Affidarsi alla propria esperienza!

Application Insights

Oramai sono passati un po di giorni dall’ultimo update di Visual Studio Online e vorrei porre l’accento su una nuova interessante funzionalità introdotta nel prodotto.

Oltre alle normali funzionaltà, è ora presente la possibilità di inviare i log dei propri applicativi su Application Insights, per poter poi utilizzare la sintassi di Apache Lucene per poter cercare nei log.  Naturalmente sono supportati i framework di logging piu comuni, come log4net per cui è disponibile un appender qui.

http://www.nuget.org/packages/Microsoft.ApplicationInsights.Log4NetAppender/

Buon logging.

Gian Maria.

0  

Personalizzare l’editor di Visual Studio

Se non vi piacciono i colori dell’editor di Visual Studio e non vi va di perdere tempo nei settaggi nella scelta di tutti i colori, potete come me scegliere uno degli schemi già pronti all’uso da questo sito: StudioStyles. Qui potete trovare oltre 2000 schemi da importare direttamente all’interno del vostro Visual Studio oppure potete scegliere di creare con pochi passi uno schema personalizzato.

Se scegliamo la prima opzione, una volta scaricato il file .vssettings basterà importarlo all’interno di Visual Studio nella voce Tools –> Import & Export Settings e poi seguite il wizard che consente di

- fare un backup dell’attuale profilo (consigliato);

- importazione lo schema scaricato dal sito.

Se una volta importato lo schema vi siete accorti che non vi piace e volete tornare ai settaggi precedenti, basterà o re-importare lo schema di cui avete il backup, oppure, se non avete mai fatto modifiche all’aspetto grafico dell’editor, potete direttamente fare un reset dalla schermata di importazione:

image

Keep Calm and Use Visual Studio! Hot smile

Gestire Team Multipli con uno stesso backlog in un Team Project

Precedenti post della serie

Organizzare I Team Project del proprio TFS
Configurazione di Un Team Project per piu Teams con Backlog Multipli.

In questo post verrà mostrato come configurare un Team Project per avere più team multipli che lavorano su uno stesso Backlog, situazione molto comune nei team agili. In questo caso bisogna utilizzare un semplice “trucco” affinché TFS possa gestire Sprint Backlog distinti. La configurazione è molto simile a quella mostrata precedentemente per la configurazione di un Team Project con Backlog Distinti. Vediamo quindi come si configura il tutto.

La prima differenza è nella gestione delle aree, di base quello che viene fatto è creare un’area di base (in questo esempio chiamata Common) e procedere poi alla creazione dei due Team specificando però di non creare automaticamente un’area associata. Una volta creati si procederà alla creazione manuale di un’area distinta per ogni come sottoarea della Common. Per entrambi i team l’area base verrà configurata come sorgente del Backlog.

image

In questo modo entrambi i team vedranno nel backlog tutti gli elementi facenti parte dell’area Common e delle sue aree figlie, ottenendo quindi il risultato voluto: Avere un unico Backlog per più team distinti.

Quando si tratta invece di andare a configurare le iterazioni la situazione è leggermente differente. Durante uno sprint planning o in generale durante la pianificazione della prossima iterazione, si deve decidere quali elementi del Backlog faranno parte dell’iterazione, ma molto spesso si vuole anche assegnare questi PBI ad un team oppure ad un altro. In generale possiamo avere due casi

Caso 1: Lo sprint Backlog è comune tra i due team. Questo significa che quando si è raggiunto un accordo sui PBI da risolvere nella successiva iterazione, entrambi i team iniziano a lavorare sullo stesso set di PBI. Questo caso è piuttosto anomalo, perché di fatto è come lavorare con un unico Team. In questo caso si può tranquillamente creare l’albero delle iterazioni con gli sprint e usare la stessa configurazione per entrambi i team.

Caso 2: Ogni team ha il suo Sprint Backlog. Questa è la soluzione più standard, in questo modo ogni team ha il suo insieme di PBI su cui lavorare nella prossima iterazione. In questo caso è necessario in TFS procedere alla creazione di un albero distinto di iterazioni per ogni team, come mostrato in figura.

image

Qui viene rappresentata la configurazione per i TeamA, ma si può notare come è presente anche un albero di iterazioni chiamato CommonB i cui figli sono sprint con lo stesso nome e le stesse date, per il TeamB. Il Team B avrà chiaramente flaggati gli sprint figli di CommonB.

In questo modo, quando si effettua la pianificazione, si può aprire in due pagine distinte del browser la gestione del Backlog di entrambi i team.

image

Le due visioni sono sovrapposte nella figura sopra e si può facilmente notare come entrambi i team vedono esattamente lo stesso Backlog. Ora supponiamo che il TeamA si prenda carico della UserStory 1 ed il TeamB si prenda carico della User Story 2. Per fare questo ogni team trascina la User Story che vuole assegnarsi nello sprint corrente (Sprint 3) con il classico Drag And Drop.

Sebbene visivamente l’operazione per entrambi i team sia identica, il link Sprint 3 che è rappresentato nelle due visualizzazioni non è lo stesso. Per il Team A è CommonA/Sprint3 mentre per il TeamB è CommonB/Sprint3. In questo modo cliccando sul link ed andando a visualizzare il proprio Sprint Backlog ogni team vede solamente i PBI di cui si è fatto carico.

SNAGHTML3e064b

Come si può vedere dalla figura sopra, ogni Team vede le proprie User Story nel proprio Sprint Backlog.

Gian Maria

Comments Off  

Pubblicare automaticamente un pacchetto NuGet durante una build di TFS

In MSDN online è stato pubblicato ieri un mio articolo sul come personalizzare il nuovo Workflow della build di TFS tramite script powershell. L’articolo è disponibile qui e tratta il versioning automatico e la pubblicazione automatica di un pacchetto nuget durante la build.

Buona lettura.

Gian Maria.

Comments Off  

La fine del Early Adopter di Visual Studio Online non è la fine del mondo

In questi giorni Microsoft ha confermato che il programma Early Adopter di Visual Studio Online terminerà il 7 maggio. I benefici Early Adopter consentivano agli utenti che si erano registrati su VSO nella fase di lancio della piattaforma di poter usufruire di tutti i servizi della stessa gratuitamente. Il termine di tale opzione era previsto inizialmente per il 13 marzo ma era stato successivamente posticipato per una serie di problemi che hanno ritardato la disponibilità delle modalità di migrazione.

Gli utenti di VSO che preferissero optare per una soluzione on-premises piuttosto che per la versione a cloud a pagamento riceveranno infatti da Microsoft tutto il dovuto supporto per l’esportazione dei dati da VSO e l’importazione degli stessi sul proprio TFS.

In questo post non vorrei però parlare di migrazione, ma approfittare invece per capire un po’ meglio quali saranno le opzioni gratuite offerte dalla piattaforma per gli Early Adopter dopo tale data, che poi altro non sono se non quelle già garantite a un qualunque utente che si iscriva oggi su VSO.

Il piano entry level disponibile su Visual Studio Online è il Basic ed è su questo che saranno convertiti tutti gli attuali Early Adopter a meno di non sottoscrivere un piano a pagamento. Il piano consente di utilizzare il servizio cloud di Microsoft per gestire i propri progetti sia dal punto di vista del codice che delle attività, con la possibilità di condividere i progetti in team fino a 5 persone senza costi aggiuntivi.

Ciò vuol dire un repository di codice sorgente con tutte le caratteristiche di TFS che ben conosciamo e con la possibilità di utilizzare sia lo storico Team Foundation Version Control (TFVC) centralizzato che Git, un sistema di Version Control distribuito (DVCS). Ma vuole anche dire poter sfruttare VSO per la gestione dei requisiti e delle attività di sviluppo, potendo optare tanto per un approccio tradizionale (usando il Process Template MSF for CMMI Process Improvement 2013) quanto per uno Agile (scegliendo il template generico MSF for Agile Software Development 2013 o quello Microsoft Visual Studio Scrum 2013 specifico per Scrum di cui una la peculiare terminologia).

Il piano prevede inoltre fino a 60 minuti mensili di Build e 15.000 minuti di Load Testing.

La possibilità di lavorare in team su un progetto condiviso su VSO è ancora più interessante se analizziamo meglio la limitazione delle 5 persone gratuite. La limitazione è infatti relativa alla possibilità di aggiungere fino a 5 utenti in possesso a loro volta di un piano Basic. Non vi è invece alcuna limitazione relativa agli utenti in possesso di un abbonamento MSDN ed è quindi possibile, da un piano Basic, gestire un progetto con anche più di 5 membri a patto che quelli eccedenti siano tutti in possesso di un abbonamento MSDN.

Per verificare quale sia la situazione del nostro piano possiamo cliccare sul tab Users a partire dalla Home page del nostro account.

All’interno del tab è riassunta la situazione relativa alle licenze di tutti gli utenti accreditati sul nostro account di VSO. Nel nostro esempio l’account prevede l’accesso per 6 utenti in possesso del piano Early Adopter. In questo caso alla data di scadenza del 7 maggio gli utenti saranno migrati sul piano Basic e questo poterebbe l’account a sforare il limite di 5 account Basic gratuiti.

È quindi necessario acquistare licenze aggiuntive per gli utenti oltre il quinto, oppure specificare che uno o più utenti sono in possesso di un abbonamento MSDN e non vanno quindi conteggiati nel novero di quelli Basic. Per farlo selezioniamo l’utente e clicchiamo sul tasto Edit.

Possiamo ora scegliere il tipo di licenza impostando ad esempio Eligible MSDN Subscriber e cliccando su Save. In tal modo comunichiamo a VSO che l’utente selezionato gode, a parer nostro, dei privilegi riservati agli utenti in possesso di un abbonamento MSDN.

La nostra indicazione viene registrata e sarà confermata al successivo login dell’utente su Visual Studio Online.

Quando ciò avviene il cruscotto degli utenti riporta l’indicazione corretta sulla licenza in uso. È possibile anche anticipare il momento in cui i piani Early Adopter saranno convertiti in Basic, impostando per uno o più utenti il piano Basic con la stessa procedura appena descritta. Gli utenti con licenza Basic vanno ovviamente a riempire i 5 spazi gratuiti a disposizione.

I vantaggi degli utenti in possesso di un abbonamento MSDN non si esauriscono nel fatto di poter partecipare a progetti su account Basic senza consumare gli slot gratuiti previsti. Tali utenti infatti non sono soggetti alle limitazioni previste per gli utenti Basic a livello di Team Rooms, Features, Test, Feedback, ecc.

Happy coding!