TFS + Scrum Master Tour
Facendo riferimento al post precedente, ecco un giro abbastanza completo su TFS e Scrum Master Workbench v2, su un progetto MSF for Agile 5.0 (il template di default di TFS 2010).
Il progetto demo è ThinkAhead.Pizza.MSF proprio per ricordare che il nostro fantomatico venditore di pizze ha un software scritto con MSF for Agile. L’idea è mostrare un giro abbastanza completo sul ciclo di vita di una User Story gestito da questi due strumenti.
Scrum Master Workbench si presenta con una grafica che ricorda le più classiche lavagne, ed è perfettamente integrato con TFS: alla partenza viene richiesto l’indirizzo dei servizi esposti da TFS e tutte le operazioni passano dai servizi in perfetto stile SOA.
Partendo dalla Task Board, si può creare una User Story (Calcolatore che sottrae): questa operazione invoca i servizi di TFS, esattamente come fa qualunque client per TFS (Team Explorer per primo) per aggiungere la User Story nel database dei Work Item del progetto.
Ripetuto il processo di creazione per una seconda User Story (calcolatore che moltiplica) si possono creare direttamente i Test Case dal pulsante “+” accandto alla User Story.
Abbiamo creato due Test Case, in fase di design per adesso; il primo assegnato a Andrea Provaglio che ha collaborato alla creazione dell’esempio e che collabora attivamente con noi nei progetti reali, il secondo assegnato a me.
I test case, in TFS verranno legati alla User Story relativa. Questa la visualizzazioene di Scrum Master Workbench.
Per vedere meglio l’interazione ci siamo spostati su Visual Studio Team Explorer e, analizzando i Test Case, abbiamo inserito due task molto semplici. Le prime due task nella figura seguente erano due test precedenti.
La creazione della classe è stata assegnata a me, mentre l’implementazione del metodo ad Andrea. Entrambe sono legate alla User Story numero 36 – Calcolatore che moltiplica
Tornando in Scrum Master Workbench è possibile recuperare le informazioni:
Visto che le due task sono state legate alla user story, appaiono come post-it accanto alla user story relativa e vengono segnate nella colonna Active e colorate di giallino. In alto invece possiamo notare una Task già chiusa di colore verde.
Lo sviluppatore, dall’elenco delle task della figura precedente, può vedere i lavori assegnati, oppure può prendere una task non assegnata a nessuno per iniziare il lavoro in perfetto stile Agile.
La prima task era destinata a me, quindi scrivo il codice seguente, in questo caso usando il metodo più classico: niente TTD o virtuosismi; aggiungo una classe al progetto Biz e la rendo pubblica.
Eseguo il check-in legando la task assegnata e indicando il suo completamento (vedremo i test e TTD più avanti):
La risoluzione della task fa si che in TFS la task passi allo stato di Completed in automatico. Posso verificare questo cambiamento anche in Scrum Master Workbench.
Adesso infatti la User Story 36 ha una task completata (Closed) e una aperta (Active) che Andrea dovrà implementare.
Andrea userà la metodologia TTD per implementare la classe. Partirà quindi dai Test Case da implementare visualizzandoli con Scrum Master Workbench oppure dal Team Explorer:
La descrizione delle Task, delle User Story e dei Test Case è volutamente breve per ragioni di spazio per questo post.
Andrea, inizia a creare il codice di test sfruttando il Test Framework di Visual Studio Ultimate:
Come si nota, l’intellisense di Visual Studio segnala che il metodo Multiply non è stato ancora implementato. Il test, come si nota, è stato Legato al WorkItem 37, che, come si può vedere dallo screenshot seguente è “Moltiplicare 3x2”: l’assegnazione è stata fatta in modo visuale dalla maschera delle proprietà.
Usando la funzionalità di Create Method Stub, Andrea ha creato il metodo, lo ha implementato e successivamente ha fatto check-in dopo varie prove sul Test.
Durante il check-in, è stato legato il Test Case in automatico
Visto che il Test Case è pronto per entrare in gioco nel progetto, dalla query “Test Case” del Team Explorer, Andreà marchera il test come “Ready”.
Lo Scrum Master Workbench visualizza esattamente la stessa informazione: il test case assegnato a me è ancora in Design, mentre il test implementato da Andrea è ready.
Facciamo girare il Test per verificare la sua funzionalità direttamnete da Test View.
Passato il test è il momento di fare un primo Check-in (si potrebbe fare uno Shelve per condividere il codice che ancora non abbiamo testato del tutto, ma visto che vogliamo tenere l’esempio semplice, passateci un check-in in questa fase).
Durante il check-in, è stata legata la task di implementazione del metodo di calcolatrice che giustamente viene marcata come Resolve.
Dovremmo ancora ripetere l’operazione di creazione del test e del relativo codice per l’altro Test Case, ma visto che i passi sono ripetitivi li omettiamo per semplicità.
Una volta terminato il codice dei due test case (corrispondendi alle due task nel nostro caso) possiamo marcare come Resolve, durante il check-in, anche la nostra User Story 36.
Il Scrum Master Workbench presenta la situazione finale: La user story è completata, e le due task interne sono state chiuse.
Andrea tiene regolarmente corsi di Agile Programming per le aziende più importanti nel panorama nazionale e internazionale ed è impegnato in numerose conferenze sull’argomento. Per chi non lo conosce, le informazioni sul suo profilo e sulle sue attività sono visibili sul suo sito www.andreaprovaglio.com.
Alla prossima
Rob