Per il proprio processo di produzione, EIDOS utilizza strumenti e metodologie in grado di aggiungere valore ai Clienti e al team di sviluppo.
Il processo strategico Delivery ha la missione di progettare e continuamente perfezionare, anche con la diffusione di best practices, gli strumenti e le metodologie più idonei al raggiungimento di questo obiettivo.
Questo articolo descrive un’applicazione pratica della metodologia MSF e dello strumento Visual Studio Team System, tratta da un esempio reale di una soluzione sviluppata per un nostro Cliente del segmento Finance.
Prendiamo in esame uno specifico Requisito Cliente che ha come titolo “Dati Contratto”.
Il Requisito, categorizzato come scenario (Figura 1), viene inserito nel repository di VSTS e analizzato da un nostro Analista Funzionale. Successivamente vengono creati dal Solution Architect i relativi Requisiti di Prodotto.
Altri elementi collegati possono essere attività (di progettazione, interfaccia, sviluppo e test), rischi, richieste di modifica e altro.
Figura 1 - Sintesi logica del Requisito
Il Project Manager, supportato dal Solution Architect e dagli altri membri del team, utilizza Microsoft Project per pianificare e schedulare le attività necessarie al completamento del requisito.
In questo caso è stato scelto di organizzare la struttura delle attività in modo che tutte facciano capo al Requisito del Cliente. In altri casi viene creato un ulteriore livello gerarchico rappresentato dai Requisiti di Prodotto.
La sincronizzazione bidirezionale con Visual Studio Team System permette di pubblicare gli elementi di lavoro nel repository VSTS direttamente da Microsoft Project (Figura 2).
Figura 2 - Pianificazione del Requisito in Microsoft Project
Una volta pubblicati nel repository, gli elementi di lavoro possono essere visualizzati e gestiti dagli altri membri del team tramite Visual Studio, Microsoft Excel o un web browser.
In figura 3 è riportato il Requisito 551 (Dati Contratto) visualizzato da Visual Studio. Si possono notare gli elementi di lavoro collegati (in questo caso attività e requisiti di prodotto).
È possibile interrogare il repository tramite query definite a livello aziendale (e quindi valide per tutti i progetti EIDOS), a livello di progetto o a livello personale. Questo permette ai membri del team di esplorare il repository da punti di vista diversi: uno sviluppatore può ad esempio utilizzare la query “Mie Attività attive” per visualizzare tutti gli elementi di lavoro di tipo attività a lui assegnati e non ancora completati.
Figura 3 - Visualizzazione del requisito "Dati Contratto" da Visual Studio
Sfruttando l’integrazione tra le aree Source Control e Work item tracking di VSTS, gli sviluppatori possono collegare le modifiche effettuate al codice sorgente ai relativi elementi di lavoro al momento dell’operazione di check-in.
Il Project Manager può definire delle politiche di check-in più o meno restrittive incluse l’obbligatorietà per lo sviluppatore di associare i propri check-in ad almeno un elemento di lavoro.
Durante l’associazione è anche possibile effettuare un contestuale passaggio di stato per evidenziare che un particolare elemento di lavoro è stato risolto.
Successivamente è possibile navigare tra gli elementi di lavoro e le variazioni al codice sorgente e viceversa. In figura 4 si può ad esempio notare una serie di modifiche al codice sorgente collegate all’attività 486. Sfruttando la funzione di navigazione è possibile risalire ai file modificati ed alle righe di codice aggiunte, modificate o eliminate.
Figura 4 - Insiemi di modifica collegati ad un elemento di lavoro
Grazie alla forte integrazione tra aree funzionali e strumenti di accesso e ad una forte responsabilizzazione dei membri dei team di progetto, i dati contenuti nel repository risultano attendibili e aggiornati. Questo facilita enormemente il controllo del Valore prodotto.
In Figura 5 ad esempio viene controllato la stato di produzione del Valore relativo al requisito 551 (Dati Contratto) utilizzando un report fruibile via web. Il report evidenzia gli elementi di lavoro collegati al requisito raggruppati per tipologia affiancando un indicatore grafico che ne raffigura lo stato di avanzamento. Nel caso specifico si può notare che il requisito è stato completato ma non ancora testato.
Figura 5 - Controllo del Valore prodotto per il requisito 551
Questo articolo è tratto dal whitepaper “Strumenti e metodologie EIDOS per il Delivery”.
Per richiedere il whitepaper integrale, scrivete al Marketing EIDOS
eidos@eidos.biz