Lean, Agile e DevOps… go Back!

Preparando una serie di slide per i prossimi eventi, mi sono reso conto che il mondo dello sviluppo IT si sta letteralmente “popolando” di metodologie, pratiche e “buzzword” non sempre distinguibili e ben inquadrabili.

Tutto ciò rende estremamente difficile capire quale approccio convenga adottare per il contesto specifico e in cosa le varie opzioni si differenziano tra di loro, soprattutto se si decide di imbarcarsi nel pericoloso fai-da-te senza una chiara visione e strategia degli obiettivi di cambiamento che si vogliono raggiungere.

Lungi dal voler essere esaustivo, vediamo di inquadrare a grana grossa come relazionare tra loro i tre approcci che oggi sono adottati maggiormente nel mondo dell’IT per la gestione dell’Application Lifecycle Management: Lean, Agile e DevOps. Per fare ciò ci baseremo sulla figura seguente:

lean agile devops

Lean & Agile & DevOps

Come si vede, alla base di tutto vi è Lean. Questo perché Lean è orientato all’ottimizzazione olistica dei processi e, nel caso di uno specifico prodotto, alla sua ottimizzazione end-to-end. Sui valori e sui principi Lean troviamo l’approccio DevOps, orientato al Deployment, ovvero alla consegna del prodotto (o soluzione che sia) al cliente. Nel ciclo DevOps, infine troviamo approcci e metodologie specifiche, a partire da Agile, nelle sue varie incarnazioni, fino alle pratiche di Customer Delivery e di Solution Delivery.

Tutte e tre gli approcci sono quindi indispensabili per ottimizzare l’intero flusso di creazione del Valore, perché nessuno di essi, individualmente, copre tutte le fasi annessi:

  • Lean, è alla base di Agile e di tutte le pratiche moderne di creazione di Valore e ottimizzazione del flusso di lavoro
    • Lean Startup e Running Lean si focalizzano sulla validazione applicata dell’idea di business e sulla verifica della sostenibilità economica delle iniziative annesse:
    • Lean Change consente di approcciare al Change Management in chiave di micro-esperimento basati sul fallimento come strumento di apprendimento.
  • DevOps, è focalizzato sulla creazione di una Cultura del Delivery in funzione del business piuttosto che una focalizzata sui dettagli tecnici
    • Continuous Integration, Continuous Delivery e Continuous Deploy sono le fondamenta per creare una solida Agile Deployment Pipeline.
  • Agile, è lo strumento principe per lavorare in chiave adattativo, velocizzando i feedback loop grazie a soluzioni incrementali e funzionanti
    • Scrum ed XP sono le metodologie Agile più utilizzate, con Scrum orientato alla gestione del progetto ed XP all’implementazione.

In abbinamento a Lean, troviamo i framework di Agile@Scaling, Discipline Agile Delivery e Scaled Agile Framework in primis, pensati per offrire un set di strumenti consistenti che consentano di gestire prodotti di media e grande complessità, multi progetto e multi team.

Per maggiori dettagli sulle differenze primarie tra Agile e Lean, vi rimando a questo precedente post Lean e Agile, similitudini e differenze.

 

Per tutto il resto ci vediamo domani, 5-febbraio-2016, al DevOps@Works di Roma J

DevOps@Work (#DOAW16), manca solo una settimana

Il 5 di febbraio si terrà il DevOps@Work a Roma (#DOAW16) grazie all’impegno di  GetLatestVersion.it e DomusDotNet. 
Si tratta di una giornata dedicata interamente all’universo DevOps. Due track, tanti speaker di valore nazionale ed internazionale per mostrare lo stato dell’arte della metodologia DevOps.
l’agenda è la seguente:
Come potete notare, gli argomenti saranno tanti, e questa volta riuscirò a parlare di due punti cardine del processo di Continuous Integration su database. Infatti, il ciclo di integrazione continua si basa su: Sviluppo ed invio dei changeset al source control, build automatizzata del database, unit testing e poi eventuale applicazione dei cambiamenti sull’ambiente dedicato al continuo miglioramento (quello utile a mostrare i cambiamenti tra una release e l’altra).
Con le due sessioni proposte, andremo ad approfondire l’integrazione di tool di terze parti e SQL Server Management Studio. Con la prima, capiremo come inviare i changeset al nostro source control manager, come gestire anche i dati statici, come filtrare ed escludere informazioni sul source control manager ed infine come associare item di backlog.
Con la seconda andremo invece a scrivere e ad eseguire test unitari sulle nostre stored procedure, in modo da evitare regressioni e da supportare lo sviluppo evolutivo in ottica di qualità.
A lungo i miei sforzi si sono concentrati su questo argomento, perciò, vedere che l’argomento diventa sempre più importante e richiesto (anche per requisiti di business) mi rende sempre più fiero.
Spero di trovarvi, come sempre, numerosi all’evento!
Mi piacerebbe scambiare due chiacchiere insieme.
Correte ad iscrivervi!

Cancellare Work Item in VSTS

Una delle prime domande che mi sono sempre state fatte in questi anni dagli utenti che iniziano ad usare TFS ed iniziano a “Giocare” con il sistema è: Come posso cancellare un Work Item? 

Questa domanda è sicuramente una delle più fatte, perchè di base, fino alle ultimissme versioni, l’unico modo di cancellare un Work Item era tramite riga di comando (witadmin destroywi). La ragione di questo è abbastanza normale, TFS è un sistema di tracciatura dati che deve garantire l’accountabilty, per cui in realtà non cancellerete mai un Work Item, ma ad esempio lo mettere in stato “Done” oppure per un bug in stato “Chiuso” con reason “duplicato” etc etc.

Purtroppo però esistono situazioni in cui realmente si vuole andare a rimuovere completamente un Work Item, non lasciando traccia nel sistema. Dato che la riga di comando è abbastanza poco user friendly, e soprattutto può solamente essere utilizzata da chi ha sufficienti diritti per cancellare un Work Item, sempre si più si è sentita la necessità di poter cancellare un Work Item direttamente dalla UI Web.

image_thumb[2]

 

Una volta cancellato un Work Item, il sistema avverte che in realtà non è stato realmente cancellato, ma per ora parcheggiato nel Recycle Bin.

image_thumb[5]

Il link al Recycle Bin campeggia anche in bella vista nella schermata dei WORK ITEMS.

image_thumb[8]

Nel recycle bin avete la possibilità di ripristinare il Work Item (1) cosi come la possibilità di cancellarlo definitivamente (2)

image_thumb[11]

Nel caso di Restore l’accountability è garantita, perchè l’operazione di Delete e Restore sono correttamente incluse nella storia del Work Item.

image_thumb[14]

In caso selezionate il Delete dal cestino sarete avvertiti che l’operazione non è reversibile, in questo caso il Work Item, con tutta la sua storia è persa per sempre.

image_thumb[17]

Come ultima nota, se dovete cancellare più Work Item contemporaneamente, potete o selezionare tutti i Work Item che volete cancellare e poi facendo click con il tasto Destro scegliere Delete, oppure direttamente effettuare dal backlog un Drag And Drop sull’icona del cestino.

image_thumb[21]

Questa funzionalità per ora è disponibile solamente in VSTS e non in TFS on-premises.

Gian Maria Ricci.

Nuovo deploy di VSTS

Potete leggere online tutte le nuove funzionalità disponibili su Visual Studio Team Services rilasciate il 25 gennaio.

Dopo poco dall’introduzione del concetto di Dashboard è ora possibile scrivere nuovi widget come estensioni di VSTS. Molte altre novità sono sempre state rilasciate nell’ambito delle dashboard, tra cui la possibilità di fare auto-refresh delle dashboard stesse (utile nel caso vogliate mettere qualche dashboard sempre visibile su un monitor).

Ci sono moltissime altre modifiche, ma una delle più interessanti è la possibilità di effettuare ricerche contemporaneamente sul codice Git e TFVC, dato che ora vi è la possibilità di avere entrambi i source control su un unico Team Project.

Come sempre non mi stancherò di ripeterlo, una delle ragioni per usare VSTS è la possibilità di rimanere sempre aggiornato con continue novità senza dovere spendere un solo millisecondo ad amministrare server installati on-premises.

Happy VSTS.

Gian Maria.

Product Centric approach

Il mondo dell’ALM, nelle sue varie declinazioni, è complesso e articolato, abbracciando una serie estremamente ampia ed eterogenea di fattori ed obiettivi.

Qualsiasi sia la definizione o specializzazione adottata, è fondamentale, però, evidenziare che il focus è relativo al Prodotto (o Soluzione), dall’Inception alla sua Dismissione (from Inception to Retirement), cosa ben diversa dal focus sullo specifico Progetto.

Questo aspetto è fondamentale perché un Prodotto è di per sé allineato a strategie o iniziative di business da cui si aspetta un risultato quantificabile in termini economici e a cui dovrebbero essere anche annessi eventuali bonus di produttività.

Il Progetto (o i Progetti), diversamente, rappresenta l’aspetto operativo annesso al Prodotto, ovvero l’insieme delle azioni concrete da mettere in campo per la sua realizzazione e la sua gestione in esercizio.

product vs project

Product vs Project Scope

Si tratta di una differenza estremamente importante, tanto che i framework di Scaling dell’Agile, così come Lean e DevOps, ne tengono conto in modo esplicito, ricordando che il software è solo una parte del Prodotto. Infatti, una volta che il nostro software è pronto, esso va: messo in produzione, gestito, manutenuto, aggiornato ed infine ritirato.

Se si parte dal Program Level, dando per assodate le scelte strategiche di Portfolio, tutto ciò non può prescindere da una stretta sinergia tra Business, Developer ed Operation, proprio i tre pilastri funzionari alla base di DevOps.

Proprio le ultime evoluzioni dei principali framework @Scale, SAFe e DAD in primis, contemplano in modo diretto DevOps come parte fondate della creazione di nuovi Prodotti. Questo, proprio per enfatizzare la necessità di focalizzarsi sul “Product Lifecycle” e non soltanto sul “Software Development Lifecycle”, evitando di ritrovarsi con progetti che non siano direttamente riconducibili ad un Prodotto, ovvero ad una iniziativa di business.

In generale abbiamo un Prodotto quando sono ben identificabili:

  • Motivazioni;
  • Obiettivi e Goal Misurabili;
  • Big Picture;
  • Assunzioni e vincoli;
  • Feature di alto livello;
  • Confini applicative di alto livello;
  • Milestone di riferimento;
  • Budget di riferimento;
  • Progetti afferenti, con relativi Product Owner e Team annesso.

In funzione di tali caratterizzazioni è possibile individuare una serie di semplici regole che possono essere di aiuto per identificare se la nostra attività sposa l’approccio product-centric e non è un progetto fine a sé stesso:

  • Il Product Owner è immediatamente identificabile, in sostanza il nostro Prodotto deve essere sotto la governance di un Product Owner che abbia una dipendenza stretta con il successo del prodotto stesso;
  • Esiste una specifica iniziativa di ALM, in cui sono identificabili le relazioni, funzionali e organizzative, finalizzate alla realizzazione del Prodotto.
  • Esiste una BigPicture che consente di verificare l’allineamento costante tra le feature che ci si appresta a sviluppare e gli obiettivi generali di business;
  • L’azione di DevOps deve essere in line con la responsabilità from Inception to Retirement.

Se il vostro attuale progetto non è collocabile nella sfera di uno specifico Prodotto è bene chiedersi per chi lo stiamo realizzando e se sia il caso di continuare effettivamente ad investire su di esso.

VSTS e Trello: Lean management

La gestione dei progetti IT in chiave Lean è diventata una strada praticamente obbligatoria per gestire in modo efficace (e si spera anche efficiente) i progetti di classe “enterprise”.

VSTS e TFS, insieme all’intero ecosistema Visual Studio, offrono un ricco set di tool e funzionalità per gestire digitalmente gli aspetti tipici di questo approccio, dall’ormai indispensabile Kanban Board alle User Story Card (PBI).

Ma, come la stessa Microsoft afferma ormai da tempo, il mondo è fatto da tante soluzioni indipendenti a cui gli utenti sono fortemente legati e che utilizzano con esterna soddisfazione. Per questo l’apertura che la casa di Redmond sta attuando è totale, consentendo di integrare il proprio strumento di ALM con i tool più utilizzati del mondo Lean e Agile, soprattutto con quelli che possono vantare una più ampia platea di utilizzatori.

Da questo punto di vista è interessante mostrare come VSTS sia in grado di “comunicare” con Trello, un servizio di project management particolarmente apprezzato per la sua leggerezza e velocità.

trello vsts 0

Trello

Trello è una sorta di “bacheca virtuale” da condividere con altri membri del team (ma anche con gli amici, se lo si usa, ad esempio, gestire l’organizzazione di un evento) in cui organizzare i propri progetti. Esistono video su youtube che mostrano come usare Trello per cucinare, gestendo gli ingredienti e le fasi di preparazione e cottura J.

Dalla mia esperienza diretta devo ammettere che Trello è uno strumento veramente flessibile e molto apprezzato dai manager che non vogliono spendere troppo tempo nell’apprendimento di tool complessi come VSTS.

Per colmare questo gap, VSTS offre l’interessante funzione di Service Hooks che consente di collegare il nostro amato strumento cloud con Trello.

Il tutto è molto semplice.

Selezionate “Manage Project” delle opzioni relative al Team Project corrente:

trello vsts 1

Settings

scegliete poi la voce “Service Hooks” e premete sull’icona di “add”:

trello vsts 2

Service Hooks

A questo punto si aprirà una lista di tool con cui è possibile integrarsi, selezionate ovviamente Trello:

trello vsts 3

Trello

Come è possibile notare, l’integrazione si basa su una una serie di eventi che scatenano l’inserimento di una Card o di una Lista (una colonna) in Trello.

Gli step successivi di configurazione sono estremamente semplici, compresa la generazione e l’inserimento del token di autenticazione per accedere a Trello che potete richiedere con il link “Get it now” autorizzando l’accesso.

 

trello vsts 4

“Get it now” per ottenere il token di autenticazione di Trello

Inoltre, nelle opzioni avanzate (presenti sotto l’area di settings) potete decidere il nome che VSTS darà alla Card (o alla Lista) e la relativa descrizione, sfruttando specifici placeholder che estraggono le informazioni dal vostro PBI:

trello vsts 6

Card Name e Card Description

Completata la configurazione il gioco è fatto.

Nel caso in esempio ho legato la creazione di una Card all’inserimento di un nuovo PBI:

trello vsts 7

From VSTS to Trello

In questo modo i manager potranno continuare, se lo vogliono, ad utilizzare Trello e voi ad utilizzare il vostro amato VSTS senza dover passa le informazioni manualmente da un’applicazione all’altra.

 

Reduce the waste!

Il 2016 è l’anno di DevOps!

Un altro anno è già terminato ed uno nuovo è ormai iniziato. Frase fatta, vero. Ma questo 2016 porta grandi novità, soprattutto negli eventi che noi di GetLatestVersion.it seguiremo, fin dai primi mesi. Questo sembra essere l’anno di DevOps, un termine ormai utilizzato talmente tanto da essere applicato spesso a sproposito (chiaritevi le idee qui, grazie a Felice Pescatore).

Cosa avremo? Di certo, un febbraio ricco di sessioni.
Partiamo il 5 di febbraio, con il DevOps@Work a Roma (#DOAW16) 
GetLatestVersion.it e DomusDotNet organizza una giornata dedicata interamente all’universo DevOps. Due track, tanti speaker di valore nazionale ed internazionale per mostrare lo stato dell’arte della metodologia DevOps.
Potete scaricare la locandina qui. Tuttavia, l’agenda è la seguente:
Il 26 febbraio, con DevOps@Work a Napoli
DotNetCampania, in collaborazione con Microsoft Italia, organizza per il prossimo 26 Febbraio una giornata di formazione interamente dedicata al mondo DevOps. Scopriremo insieme ai più famosi esperti italiani sull’argomento, che cos’è DevOps e quale valore aggiunto può dare al ciclo di vita delle nostre applicazioni.


Con un taglio estremamente pratico, vedremo concretamente come la combinazione tra tool e metodologie possano trasformare l’IT in una vero e proprio centro di supporto al Business, automatizzando al massimo la catena di Valore che parte dalla concezione del prodotto e si completa con la sua messa in erogazione.


Per registrarvi all’evento di Napoli, seguite questo link. Mentre per Roma, qui.
Inoltre, noi di GetLatestVersion.it vi porteremo una sorpresa a Roma. Già qualcosa è trapelato su twitter (@agileiotdotorg).
Vi aspettiamo numerosi!
Stay Tuned! 

Progetto Agile@School – Introduzione

Sabato scorso ho presentato il progetto Agile@School alla scuola superiore in cui ho studiato per la maturità: l’ITSOS di Fornovo di Taro.

L’istituto, da sempre all’avanguardia per tutto quello che riguarda il mondo dell’informatica, ha anche una materia, tecnologia, per la quale il progetto proposto diventa ancora più importante.
Infatti, i professori che seguono la suddetta materia, affrontano durante l’anno la teoria sulle metodologie di sviluppo e di gestione dei progetti.
Idea
Dopo un paio di anni di riflessioni su come poter aiutare la scuola ad avvicinarsi al mondo del lavoro, nasce Agile@School (mi sono preso una licenza, non credo esista già questo nome), frutto dell’esperienza in campo Agile che mi sono fatto nel tempo, anche con gli utlimi anni da “gestore” di un team. Il progetto ha l’intento di applicare i “giochi” a cui l’Agile si appresta per far conoscere agli studenti la vera essenza del teamwork, unitamente al valore aggiunto che la produzione di software di qualità darà loro ed alla scuola, non solo in termini di progetto aggiuntivo, ma anche di preparazione di argomentazioni da presentare all’esame.

La scuola si presenta molto bene:
L’aula che si vede nelle foto è una sala multimediale, colorata in stile Google, con round table e sedie mobili. Il tutto si può definire già pronto ad accogliere alcune delle cerimonie distintive della metodologia.
Le basi ci sono, anche se dovremo lavorare sodo per applicare i cambiamenti ai pattern e per adattare i tempi alle regole che si dovranno seguire.
L’idea quindi è quella di prendere una decina di ragazzi, tra classi quarte e quinte, per sviluppare un semplice progetto, almeno in prima battuta, al fine di fare rodaggio degli iter e per fare formazione non solo degli alunni, ma anche dei docenti stessi.
Idea generale
La big picture è:

- Scelta di un progetto semplice, tipo “Gestione dell’inventario dei dispositivi informatici scolastici“, oppure “Gestione delle anagrafiche degli studenti e dei *palmares* degli alunni del passato“. 
- Scelta di due team da 6/7 persone l’uno (es. 2 di quarda e 2 di quinta)
- Scelta delle specializzazioni e dei team di test (probabilmente i ragazzi di quarta)
- Scelta dei ruoli (A parte il sottoscritto, farò il coach, avremo un Product Owner, nella persona di un professore, ed uno scrum master, come facilitatore, probabilmente un ragazzo che mi aiuterà nel progetto)
- Comprensione degli skill professionali e delle attitudini dei membri del team
- Creazione delle milestone di progetto
- Creazione e popolamento del backlog
- Iterazioni e cerimonie
- Rilasci continui
Una volta che questa idea è consolidata e ben provata nel tempo, il passo successivo prevede l’integrazione di uno sviluppo non solo software, ma sistemistico, ed anche, ambiziosamente, IoT.
Pensiamo infatti ad uno scenario Internet of Things, nel quale uno smart device è implementato come progetto scolastico; nulla vieta di poter adattare ed estendere le metodologie agili su di esso (ricordo @agileiotdotorg ).
Feedback
Il feedback degli studenti è stato inaspettato, devo ammetterlo. Alla fine delle mie semplici slide, che ho cercato di tenere ad un livello alto per non tediare troppo i ragazzi, abbiamo fatto una dimostrazione di un daily meeting, con tanto di finto caffè. Cinque ragazzi in cerchio, con un bicchiere immaginario in mano, che parlano tra loro e che rispondono alle fatidiche tre domande. Hanno parlato del loro progetto in essere ed in base all’ultimo giorno passato in laboratorio.
Da coach ho fatto notare loro i problemi, come ad esempio:
- Grafica implementata durante l’implementazione di un bug (perdita di focus)
- Conoscenza di un solo sviluppatore vs progetto chiaro per tutti
- Problemi di collaborazione mancante (chi fa troppo vs chi non aiuta molto).
Alla fine del meeting fac-simile già si respirava aria di valore aggiunto. La dimostrazione di quanto metodo può essere messo anche nelle piccole cose è stata veramente efficace, anche per gli addetti ai lavori. Sia i docenti che i tecnici di laboratorio, infatti, hanno appoggiato appieno l’idea. La scuola non è così lontana dal mondo del lavoro come sembra. E i ragazzi sono interessati.
Strumenti e soluzioni
Come procederemo ora? Come prima cosa, faremo una giornata all’insegna dell’agile, in particolar modo dell’approfondimento dei termini, che dovranno diventare comuni a tutti. In secondo luogo, inizieremo a popolare il backlog di prodotto e decideremo come disegnare le iterazioni e le cerimonie. Utilizzeremo Visual Studio Online, sfrutteremo DreamSpark, così utile per le scuole, e molto probabilmente, scriveremo addirittura .net!
Cosa consiglierò? Lean? Scrum? DaD? Credo proprio che applicheremo un pattern custom, dedicato a questo strano tipo di iterazione. Infatti, non esiste la giornata di lavoro, e quindi l’iterazione può essere applicata solo alle ore di laboratorio, con l’aggiunta delle ore al di fuori dell’orario scolastico. Sarà veramente stimolante reagire a questa realtà.
Ed ora, si comincia, e vi terrò aggiornati.. Questa è solo l’introduzione.
Stay tuned! 

The Three Way for DevOps

Il nostro viaggio nel mondo DevOps enfatizza costantemente l’importanza di considerare l’intera Line of Business (LOB), se non l’intera azienda, al servizio della realizzazione di un Prodotto o Soluzione che si voglia.

Abbiamo visto come spesso sia difficile arrivare a elementi di sintesi condivisi, essendo DevOps stesso in continua evoluzione e cambiamento, a partire dai principi basilari già evidenzianti in “The Ownership Revolution”: Focus Aziendale, Lean, Integrazione, Condivisione, Monitoraggio, Miglioramento continuo.

Ma come possiamo tracciare il percorso seguire per raggiungere i massimi benefici di una completa integrazione aziendale, andando a motivare anche l’effort necessario al grande cambiamento Culturale annesso a DevOps?

Ebbene, Gene Kim ci propone i “The Three Way”, un set di principi basilari, di cui i precedenti possono essere considerati una specializzazione, utili a guidare l’azienda nella propria e specifica trasformazione:

  • The First Way: System Thinking;
  • The Second Way: Amplify Feedback Loops;
  • The Third Way: Culture of Continual Experimentation and Learning.

The First Way” enfatizza la necessità di concentrarsi sull’intera LOB, e quindi su un’ottimizzazione complessiva del Value Stream, cosa che non passa necessariamente per l’ottimizzazione di un silos o dipartimento specifico. Ancora una volta si evidenzia come l’obiettivo sia quello di ottimizzare l’intero processo di creazione di una soluzione: dalla sua idea alla sua messa in esercizio.

way first way

La cosa interessante è che i singoli Work Center, i centri focali delle attività, non possono essere ottimizzati oltre il livello attuale se ciò va a scapito del processo globale, ovvero se sia ha un degrado della Value Chain. La logica è quella “pull” di Lean: sono i Work Center a valle a dichiararsi pronti a prendere in carico una nuova attività, per cui è inutile che due Work Center adiacenti viaggino a velocità disallineate, perché si andrebbe a creare un inutile sovrabbondanza di attività in Ready-to-Pull.

Outcomes: la “prima via” responsabilizza i Work Center nella gestione dei difetti, sia di processo che di lavorazione, senza la presunzione che il problema verrà risolto da qualcun altro in qualche modo. Inoltre, come evidenziato, porta all’ottimizzazione complessiva del Value Stream, attraverso una comprensione sempre più profonda dei processi ed evitando di sprecare risorse nell’ottimizzazione delle singole stazioni senza tener conto del disegno complessivo.

The Second Way” pone l’accento sulla necessità di creare loop di feedback efficaci ed estremamente rapidi.

way second way

Per migliorare i propri processi è indispensabile che i feedback arrivino velocemente e che l’origine sia la più significativa possibile, andando a coinvolgere tutti gli attori interessati dal Value Stream.

Outcomes: la “seconda via” porta a rispondere più adeguatamente alle esigenze dei clienti, esterni o interni che siano, riducendo e velocizzando i feedback in modo da aumentare la conoscenza complessiva sugli obiettivi da raggiungere e su cosa è realmente importante focalizzarsi.

The Third Way” si concentra sulla necessità di creare una Cultura aziendale in grado di sperimentare continuamente, considerando il fallimento alla base dell’apprendimento e dell’abbattimento dei rischi, e focalizzata sulla pratica e sulla ripetizione, ritenendole indispensabile per padroneggiare le attività.

way third way

Si tratta di un approccio fondamentale, che consente di esplorare anche le cosiddette “danger zone” proprio perché il fallimento non viene visto come un qualcosa di cui vergognarsi, e quindi da evitare a tutti i costi, anche a discapito di interventi che porterebbero a miglioramenti significativi.

Outcomes: la “terza via” porta a benefici rilevanti che vanno dalla migliore ripartizione del lavoro, a incentivi basati sull’assunzione dei rischi, fino all’approccio di introdurre volontariamente piccoli difetti (ricordate: siamo in regime di micro-esperimenti) per testare la resistenza dell’intero processo.

Personalizzazione del process template finalmente su VSTS

Una delle limitazioni più “sentite” della versione “online” di TFS, meglio conosciuta come Visual Studio Online, ora Visual Studio Team Services era l’impossibilità di personalizzare il process template. Finalmente con il deploy del 10 Dicembre questa limitazione lentamente inizia a sparire.

Finalmente è ora possibile in Visual Studio Team Services personalizzare parzialmente il Process Template

Perché dico lentamente? Perché in realtà non si ha ancora la completa personalizzazione del Process Template, come si ha invece per la versione On Premises e la ragione è questa: dato che è Microsoft che si occupa degli aggiornamenti, non può permettersi di verificare se gli aggiornamenti al Process Template sono compatibili con le vostre personalizzazioni, e quindi la struttura di estendibilità di VSTS è stata completamente cambiata. Non è quindi supportata la modalità standard con la quale si poteva scaricare i file XML di definizione, cambiarli e poi ri-uploadarli, perchè questo permetterebbe di personalizzare praticamente tutto.

Vediamo quindi che funzionalità di estensione sono presenti ora in VSTS.

Process Template Ereditati

Nella pagina di amministrazione della Project Collection potete vedere infatti tutti i process template disponibili ed il numero di Team Project che lo usano.

image

 

Questi template sono quelli Base forniti da Microsoft e non possono essere cambiati. Quello che si può fare è creare dei Process template ereditati dove verranno in realtà effettuate le personalizzazioni. Il primo passo per creare le proprie personalizzazioni è quello di creare un nuovo processo ereditato

image

 

image

In questo modo si è creato il proprio processo che eredita da quello Agile. La documentazione ufficiale dettagliata si può trovare qui https://msdn.microsoft.com/en-us/Library/vs/alm/Work/import-process/import-process.

L’ereditarietà dei processi garantisce che nessuno possa modificare i processi base, che sono gestiti da Microsoft, semplificando le operazioni di upgrade.

Appena il vostro nuovo processo ereditato è stato creato vi viene offerta la possibilità di creare un nuovo Team Project basato sul processo ereditato oppure di cambiare un Team Project esistente per usare il nuovo template. Attenzione che in questo secondo caso potete cambiare un Team Project che è basato sul processo master da cui siete partiti. Non è infatti ad esempio possibile portare un Team Project da SCRUM a Agile o CMMI o viceversa.

image

Infatti come si può vedere dalla figura successiva, solamente i Team Project basati sul template Agile sono disponibili per essere migrati al nuovo progetto.

Per ora non è possibile migrare un Team Project da un processo ad un altro (es da Scrum ad Agile), ma solamente tra processi ereditati.

image

In questo modo quando Microsoft deve aggiornare uno dei Process Template base, può farlo senza problemi, perché tutte le modifiche vengono in realtà effettuate su di un processo che “eredita” le caratteristiche di quello base e su di lui imposta le personalizzazioni.

personalizzazione web based

A questo punto potete andare ad effettuare le personalizzazioni del template direttamente tramite l’interfaccia web senza dovere editare manualmente file XML.

Per la personalizzazione dei template di VSTS non è più necessario l’editing manuale di file XML, ma tutte le operazioni vengono fatte dall’interfaccia web.

Cliccando su uno dei process template ereditati, si può procedere alla personalizzazione.

image

Cliccando nella Work Item Types posso ad esempio andare ad aggiungere un nuovo campo al Work Item di tipo Bug, supponiamo di volere aggiungere un campo che permetta di identificare il cliente che ha segnalato il bug.

image

Potete chiaramente sia aggiungere un Field esistente (perché magari presente su un altro Process Template ereditato) sia crearne uno nuovo.

image

Per ora non è possibile aggiungere l’intero set delle regole che sono normalmente disponibili per i campi dei Work Item. Le regole sono limitate al valore di default e obbligatorietà del campo. Il posizionamento nell’interfaccia invece viene semplicemente fatto con drag and drop andando a posizionare il campo dove si preferisce.

image

La gestione dei campi è ora radicalmente semplificata, è possibile infatti avere anche la lista di tutti i field, e sapere esattamente da quali Work Item questi field sono referenziati.

image

Infine è possibile anche gestire la sicurezza di questo Process Template ereditato, stabilendo chiaramente chi può modificarlo, cancellarlo o creare ulteriori processi ereditati.

image

Il vostro nuovo campo è ora disponibile ai vostri utenti.

image

Conclusioni

Con questo primo deploy, inizia a cadere una delle più sentite limitazioni di VSTS rispetto alla versione on premises, ovvero la possibilità di adattare il process template alle proprie esigenze. Sicuramente in futuro le possibilità di espansione verranno aumentate e come sempre vi consiglio di seguire il nostro blog per rimanere sempre aggiornati. :)

Buone feste a tutti.

Comments Off