All’ALM summit è stato annunciato un nuovo sistema di tag per i work item di Team Foundation Service. Cosa significa? E’ molto facile

Ora posso aggiungere dei tag a delle attività, PBI, bug, etc.:

Semplicemente inserendo del testo:

Siccome è una colonna nel Work Item Type, si può filtrare:

Ecco qui!

Ovviamente si deve ricordare che è una prima release, e che il delivery model di Team Foundation Service è basato su Continuous Delivery, quindi possiamo aspettarci miglioramenti e nuove feature molto presto!

So che può suonare molto complesso ma questa è la nuova certificazione lanciata oggi all’ALM Summit, fatta appositamente per le tematiche di Application Lifecycle Management.

E’ composta di tre esami: il 70-496 (Administering Microsoft Visual Studio Team Foundation Server 2012) sarebbe il primo da affrontare, in quanto è quello più generico su Team Foundation Server e copre molto bene le basi per un’efficiente amministrazione della piattaforma.

Il secondo è il 70-497 (Software Testing with Visual Studio 2012), ed è focalizzato sulle capability di testing della piattaforma. Quindi coprirà cose come Test Manager, planning di test case e corretta gestione di essi, analisi dei risultati, ecc.

L’ultimo è – indovina un po’? – 70-498 (Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management), che copre ad esempio una definizione efficiente di SDLC end to end, per poi espanderlo a tutto l’ALM. Poi la Qualità, e le Operations.

Come per tutte le nuove certificazioni, una ricertificazione deve essere effettuata dopo due anni dal completamento.

“Mi hanno detto che Team Foundation Server 2012 gestisce percorsi piu lunghi di 260 caratteri. Come è possibile? Come lo gestisco?”

Domanda semplice, risposta semplice: se si deve lavorare su una specifica branch che va oltre i 260 caratteri (es.: $/Project/SubProject/Branch/…./WhatINeed, oltre 260 chars) lo si dovrà comunque mappare su un percorso più breve.

Quindi? Questo è stato un cambiamento necessario nei casi in cui la branching strategy è enorme, pervasiva, e magari ereditata da migrazioni di progetti esistenti. Impatta solo il server, non il client, quindi si è comunque soggetti al limite di Windows.

Di recente Microsoft ha rilasciato un nuovo progetto open source , per tutti quegli sviluppatori che non vogliono utilizzare Team Foundation Server ma sono obbligati – per diverse ragioni – invece di utilizzare Git.

Quindi abbiamo git-tf: un bridge per utilizzare Git come repository locale, da poter poi sincronizzare con Team Foundation Server.

Dopo aver impostato un repository locale (git init), consiglio di copiare I file di git-tf nella stessa cartella. Dopodiche si deve effettuare il binding al Server e al Team Project:

Una volta fatto questo si può iniziare ad aggiungere e modificare file. Come sample, ho aggiunto un file sul repository locale e ho eseguito il commit:

Manca solo il check-in

ed eccoci!

Questo è il primo passo verso il Distributed Version Control System da parte di Microsoft Manca ancora di qualche feature, ma dalla versione 2.0 (l’ultima) in poi è un modo fattibile per far utilizzare quello che si vuole all’interno del team.

Come sappiamo, in uno degli ultimi rilasci su Team Foundation Service – che lavora su sprint agili di tre settimane, e a breve nel Quarterly Update 1 di Team Foundation Server – è stata rilasciata una nuova feature: la Kanban Board.

Kanban è un processo basato sui confini imposti dai limiti di attività WIP (work in progress). Tutto è in una coda, con stati definiti (es. Development Ready, Test Ready, Release Ready, etc.), e le attività da svolgere sono gestiti in base alla capacity del team. Idealmente, questo è il miglior metodo per gestire della produzione ‘just in time’.

Ha una storia abbastanza interessante, essendo stata creata da un uomo giapponese studiando le abitudini dei supermercati statunitensi nello storage degli oggetti. Qualche dettaglio in più su Wikipedia.

Kanban obbliga il team ad affidarsi al suo autocontrollo, ricalibrando continuamente la loro coda basandosi sulla quantità di lavoro che possono svolgere. Utilizzandolo insieme a Scrum – ad esempio nella pianificazione degli sprint – rende lo sviluppo software come un orologio svizzero. Mia opinione, ovviamente

Come si integra questa metodologia con gli strumenti a nostra disposizione? La Kanban Board è il tool principale per adottare Kanban: visuale ed efficace.

Nel nostro caso – in cui abbiamo già la Backlog Board – non cambia le nostre abitudini, anzi, le complementa insieme alla board che abbiamo già! Ecco cosa intendo:

Questa è una Backlog Board di esempio: a sinistra vedo i miei PBI, con I task che li compongono ed il relativo status.

Questa è la corrispondente Kanban Board sullo stesso progetto:

Posso vedere solo i PBI, e non i work item corrispondenti. Inoltre, essendo l’unico membro di questo progetto ho inserito 1 come massimo carico WIP. Quindi vedo subito che sono sovraccarico.

Sono due tool complementari: la Backlog Board può essere utilizzata per capire ad un livello di dettaglio le attività, mentre invece la Kanban Board è un tool molto utile per una inspection a livello di progetto.

Anche quest’anno Microsoft mi ha premiato con il MVP Award, per il quarto anno consecutivo, su Visual Studio ALM.

Quindi c’è da aspettarsi un grande anno con molti contenuti su ALM, Visual Studio e Team Foundation Server.

E sono sempre molto felice di far parte della famiglia