DevOps and Outsourcing: OutOps [pt.1]

Con questo post iniziamo una mini-serie di articoli (presumibilmente 3) dedicati ad esplorare una tematica sempre più comune: DevOps e il mondo outsourcing.
Senza alcuna pretesa di dare una “ricetta pronta all’uso”, vedremo gli aspetti cruciali annessi alle situazioni in cui lo sviluppo viene esternalizzato e come possiamo adottare DevOps in questi ambiti, parlando di alcune strategie di successo.

DevOps and Outsourcing: OutOps

Come ci sforziamo da tempo di evidenziare, DevOps è prima di tutto un approccio culturale, così come sintetizzato dalla definizione seguente:

 Culturale in cui l’intera Line of Business si assume la responsabilità della creazione di Valore per il cliente.

Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme, andando a standardizzare e padroneggiare i processi attraverso la ripetitività e la pratica [cit. FP]

Tutto interessante, di valore e dai forti riflessi applicativi pratici, ma…. come sempre, purtroppo, esistono situazioni in cui tale livello di integrazione tra “Dev” e “Ops” non è concretamente realizzabile per il semplice fatto che l’azienda ha adottato una strategia di outsourcing (totale o predominante) delle attività di sviluppo.

In pratica, i “Dev” non ci sono proprio!

Quindi si potrebbe, a primo acchito, essere tentati nell’affermare che: “DevOps non è applicabile nei contesti fortemente caratterizzati dall’outsourcing”.

dev wall out ops mini 

Se questa affermazione d’impeto ha dei fondamentati (di cui discuteremo a breve), la realtà, fortunatamente, non è nera o bianca, ma esistono diverse possibilità per applicare DevOps con successo anche in questi contesti, proprio perché si tratta prima di tutto della capacità di cooperare perseguendo un obiettivo comune.

Infatti, è come se la parte di “Dev” diventasse un “artefatto” da incastrare nel proprio processo di delivery, gestendo sempre l’ottimizzazione del flusso complessivo delle attività, in contrapposizione alla logica dell’ottimizzazione locale tipica degli approcci tradizionali.

Per indicare questo scenario, andremo a coniare uno specifico acronimo: OutOps (Outsourcing & Operations).

Va specificato che si potrebbe avere anche il caso duale, ovvero “Dev” interno e “Ops” esterno, dando vita a un ipotetico DevOut (Development & Outsourcing). Questo caso è però molto più raro nella realtà, perché tipicamente la governance della infrastruttura è quasi sempre interna alle diverse aziende, indipendente dal fatto che l’hardware sia in-house, gestito da terze parti o in cloud. Infine, il caso di Out-Out, in cui tutto è in outsourcing, ci porta nel dominio del Software-as-a-Service: l’azienda compra la soluzione sotto forma di servizio, svincolandosi da tutti gli oneri realizzativi. Tale scenario è chiaramente poco attinente al discorso che si sta facendo.

I diversi scenari sono rappresentati dal seguente DevOps Outsourcing quadrant, in relazione all’outsourcing di “Dev” e “Ops”.

 

devops quadrant

DevOps Outsourcing quadrant

Nel prosieguo faremo riferimento al contesto specifico di OutOps.

Be C.A.L.M.S and Stay Agile

Prima di parlare delle possibili strategie di adozione di DevOps in realtà ousourced-orinted, è bene fare alcuni richiami a quelli che sono gli elementi fondanti di questo approccio.

DevOps si basa su cinque pillar (pilastri) fondamentali: Comunicazione, Integrazione, Collaborazione, Automazione e Misurazione, ognuno dei quali deve essere presente all’interno della propria azione di delivery per poter operare in chiave di Continuous Improvement.

 

devops pillar

DevOps Pillar

Si tratta di un ecosistema complessivo che può assumere diverse sfaccettature e va opportunamente bilanciato al fine di ottimizzare l’intero flusso di delivery in funzione degli obietti di business, in chiara logica Lean.

Proprio per attuare questo bilanciamento, all’interno del proprio DevOps journey, è possibile sfruttare il meta-framework operativo C.A.L.M.S., creato da Damon Edwards e Jez Humble, il cui nome è formato dalle diverse leve a disposizione per raggiungere tale obiettivo:

  • Culture – gestire il cambiamento focalizzandosi sulla collaborazione e la comunicazione
    • Hearts & Minds, Embrace Change;
  • Automation – rimuovere le azioni manuali lungo la catena del valore
    • Continuous Integration, Continuous Delivery/Deployment, Infrastructure-as-a-code;
  • Lean – utilizzare i principi Lean per velocizzare, standardizzare e rendere efficienti le attività
    • Customer Value focus, Small batch size;
  • Metrics – misurare qualsiasi cosa, utilizzando i risultati per rifinire costantemente le attività
    • Measure Everything, Show the improvement;
  • Sharing, condividere le esperienze di successo e di fallimento per una crescita diffusa
    • Open Information Sharing, Collaboration. 

Il livello di ciascuno di questi 5 elementi vi permette di avere una istantanea dell’azione di Change Management in chiave DevOps, evidenziando punti di forza e debolezza e portando ad individuare opportune strategie di miglioramento.

Nel contesto specifico di OutOps è chiaro che alcune leve sono più aggredibili di altre, in particolare: Automation, Lean e Metrics. Questo non vuol dire che le altre siano assenti, ma che assumono delle forme meno libere, e più vincolate da aspetti relazionali spesso regolamentati da specifici contratti o accordi formali.

 

Questo primo post termina qui. Nel prossimo vedremo le strategie di OutOps e i relativi vantaggi operativi.

 

Stay tuned :-)

Agile@School, si ricomincia!

Agile@School è un progetto nato l’anno scorso, per ora seguito solo dal sottoscritto e da pochi altri amici che mi hanno aiutato nello svolgimento delle attività. Tuttavia, seppure l’anno scorso fosse stato totalmente sperimentale, credo che possa diventare sempre più interessante, soprattutto se condiviso con chi vorrebbe partecipare.

Ad oggi non abbiamo nemmeno un sito che descriva di cosa si tratta, anche perchè non abbiamo ancora definito un reale contesto ed un insieme di step da seguire. Ed è proprio per questo che scrivo il post. Oltre a descrivere ed aggiungere dettagli su qualcosa che può diventare importante, sono qui a chiederVi disponibilità di partecipazione, ovunque vi troviate sul territorio nazionale. Ma andiamo per passo.
Cos’è Agile@School?
Si tratta di un’idea che si pone come obbiettivo quello di portare le metodologie Agili (a scelta di chi segue il progetto stesso in accordo con la scuola) all’interno di istituti di scuola superiore o di media inferiore (anche questo a scelta) al fine di gestire progetti scolastici, quali ad esempio tesine di esame, progetti paralleli, sviluppo di idee utili all’istituto stesso, e via discorrendo.
Ok, ma cosa si deve fare?
Seppure l’organizzazione sia in mano a chi si prende l’onere (e l’onore) di seguire il progetto, l’esperienza che ho avuto l’anno scorso mi permette di dare un paio di dritte:
– crearsi una board (con Trello, ad esempio)
– trovare un aiutante per le volte in cui ci si riuinisce con la scuola
– creare un team con una chat collaborativa (con Slack, ad esempio)
– concordare con i professori un referente a scuola
– prepararsi una sessioncina di 4/5 slide da presentare agli studenti, sessione semplice ed accattivante, non tediosa e già formativa (quello viene dopo)
– organizzare un primo incontro illustrativo per selezionare il team da seguire (il numero degli studenti è selezionato dai docenti stessi)
– cercare di seguire un team di massimo 7/8 persone, ma se la scuola ne offre di più, provare a fare due team, aumentando gli aiutanti (consiglio di partire con uno)
– organizzare con i prof. le date e le periodicità di incontro per seguire con il metodo scelto (Scrum, Kanban, ecc..) da coach
– istruire il vostro aiutante come un facilitatore, tipo uno ScrumMaster, per seguire insieme la “cosa” da esterni
– selezionare i ruoli nel team e determinare l’area di lavoro comune
– postare ogni incontro sul vostro blog (più social FB, Twitter, LinkedIn, ecc.)
Chi può aiutare?
Chiunque abbia voglia di impararsi le basi dell’agile (meglio se ha già esperienza) e soprattutto chi è già nel mondo del lavoro, il che aiuta davvero a capire come comportarsi. 
C’è una community?
L’unica community che, ad oggi, segue questa cosa, è GetLatestVersion.it, con la quale stiamo provando a promuovere questo progetto dal nord al sud Italia.
Periodo?
Questo è il periodo migliore per partire. L’inizio dell’anno. Ma possiamo intanto parlarne insieme in una call di pochi minuti per ulteriori delucidazioni.
Futuro?
Nel futuro penseremo a come accentrare le informazioni per realizzare un vero e proprio progetto con relativo Sito (e anche qui vedremo se usare strumenti comuni o meno). Una volta che avremo poi almeno un paio di realtà in più, faremo il nostro team su chat collaborativa (probabilmente Slack).

Contatti?
Alessandro Alpi (Io), Gabriele Etta (il mio aiutante), tutta la community di GetLatestVersion.it

Vi aspetto, in questo progetto credo davvero tanto, visto anche il successo dell’anno scorso!

Stay tuned! :)

AgileIoT Funnel: le metodologie

Concludiamo il nostro viaggio attraverso l’AgileIoT Funnel, arrivando alla punta dell’iceberg. Dopo aver parlato della filosofia, dei principi e delle pratiche, esploriamo ora le due metodologie attualmente basate su di esse: Duttile e Fiotto.

agileiot funnel methodologies

Prima di proseguire, è fondamentale evidenziare che le struttura di AgileIoT consente di adottarne gli aspetti portanti senza essere legati alle specifiche metodologie. Questo aspetto è fondamentale poiché essi sono sempre validi al di la del processo, che va sempre adattato e contestualizzato.

Ma torniamo alle metodologie.

Duttile è il framework di processo principale, riassumibile dal Poster seguente:

duttile poster 097 mini

Duttile Poster

Duttile definisce un processo ricco ed articolato per la produzione di soluzioni legate al mondo dell’Internet of Things, orientato al Valore e alle soluzioni End-to-End. In particolare, la creazione di una specifica soluzione passa attraverso tre fasi ben delineate:

  • Prototype Phase: è la prima fase del processo. Viene definita la Vision, effettuata la fase di Prototipazione Veloce e creato il Product Backlog attraverso una fase di planning specifica;
  • Engineering Phase: è la fase in cui la soluzione viene Ingegnerizzata e Sviluppata. Si tratta, intuitivamente, della fase più corposa e più complessa dell’intero processo;
  • Workout Phase: è l’ultima fase focalizzata sul Delivery in esercizio, sul Supporto e sul Miglioramento Continuo.

La complessità intrinseca affida un ruolo fondamentale alla Solution Definiton of Done (sDoD), chiarendo in modo esplicito quando i seguenti Goal, contemplati da Duttile, possono ritenersi raggiunti.

Dualmente, chi preferisce un approccio in chiave Lean, può optare per Fiotto, che si sviluppa in chiave “Continuous Value” e “Continuous Deployment” per la realizzazione di soluzioni IoT secondo l’AgileIoT Manifesto.

fiotto poster sample

Fiotto Poster

Utilizzando gli elementi costituenti identificati in Duttile, Fiotto sfrutta il WorkPivot per passare dall’evidenza delle attività afferenti l’intero AgileIoT Team (verticali) a quelle del singolo Signal Temporary Team (orizzontali).

Questa trasformazione avviene visivamente grazie all’introduzione del D-ARCH (Do it for… Achieve Rapidly Customer Hopes), in cui le attività (Slot) sono identificate in funzione della loro specificità (Hardware, Firmware e Cloud – asse verticale) associate, contemporaneamente, all’ST2 (asse orizzontale) e al relativo Work in Progress limit (WIP-limit / WIP-l). Si vanno quindi ad enfatizzare le attività dei sub-team, specializzati sul singolo Signal, così come previsto dal Framework, supportando in modo visuale il Flashback per il riallineamento giornaliero.

Si conclude così il nostro viaggio attraverso l’AgileIoT Funnel, ma non alla scoperta di AgileIoT.

Stay tuned J

Nuovo Ask Me Anything con il team di GetLatestVersion il 31 gennaio.

Il 31 Gennaio 2017 GetLatestVersion organizza un nuovo AMA (Ask Me Anything) online. Per chi non lo sapesse l’AMA è un appuntamento in cui chiunque può partecipare e chiedere quello che si vuole sull’argomento in discussione ed il team di GLV cercherà :) di rispondere.

L’argomento come sempre è ALM su piattaforma TFS/VSTS, metodologie Agili e DevOps.

Potete registrarvi a questo indirizzo http://bit.ly/2hPgjgc

Vi aspettiamo.

Il Team di GetLatestVersion

AgileIoT Funnel: le pratiche

Quanto illustrato fin ora dell’AgileIoT Funnel, ovvero la filosofia ed i principi, pone le basi per un’azione efficace nella realizzazione di soluzioni dell’internet of things di mercato.

Ma per guidare in modo diretto tale attività vanno utilizzate e fatte proprie le Pratiche fondamentali di AgileIoT:

agileiot funnel practices 

Nello specifico si evidenziano 5 pratiche:

  • Fast Prototyping, che ha lo scopo di validare la sostenibilità generale della soluzione. Sostenibilità che passa attraverso 8 bobble- aspects, rappresentanti i principali aspetti annessi ad una soluzione IoT: Energy, Hardware, Code, Data Flow, Cloud, Security, Delivery e Legal. 
  • Make-Measure-Learn, che spinge a sperimentare rapidamente le diverse ipotesi e le diverse assunzioni:
    • Make: creo un prototipo per testare le ipotesi annesse alla Vision e per iniziare a consolidare il team di riferimento;
    • Measure: analizzo il prototipo in funzione dei Goal e delle relative metriche. Inoltre verifico se l’organizzazione aziendale ed il team sono a proprio agio per la realizzazione della soluzione;
    • Learn: attuo le opportune modifiche in funzione dei risultati.
  • Flashback, porta il team a confrontarsi sull’avanzamento dello sviluppo, creando un’azione di allineamento rapido specifica per il mondo dell’IoT in cui è l’osservatore ad andare direttamente al desk su viene presentato l’attuale manufatto in lavorazione e ponendo un numero limitato di domande temporalmente vincolate;
  • Continuous Improvement, che spinge a ridurre al minimo gli interventi sugli aspetti hardware della soluzione, azione estremamente costosa e lunga. L’approccio è quello di intervenire sul firmware, sui servizi e sul cloud in modo da poter costantemente migliorare la soluzione complessiva e intervenire con workaround in caso di problemi dei dispositivi fisici;
  • Continuous Integration, spinge a integrare costantemente ed il prima possibile tutte le differenti anime della soluzione, in modo da rilevare quanto prima i difetti ed i problemi esistenti ed intervenire rapidamente per risolverli. Si tratta di un’azione fondamentale per ridurre i costi associati a mal funzionamenti o riposte inattese dal sistema.

Queste pratiche operative consentono di attivare l’azione complessiva del team in funzione di quelli che sono gli obiettivi di collaborazione e condivisione degli obiettivi, fondamentali per il successo di ogni iniziativa.

Stay tuned J

AgileIoT Funnel: i principi

A legare il mondo delle pratiche (cosa fare) con la filosofia (visione) alla base di AgileIoT troviamo i Principi, ovvero un insieme di fattori che hanno l’ambizione di Ispirare il modo in cui viene approcciata la realizzazione di una soluzione IoT.

agileiot funnel principles

Nello specifico, AgileIoT individua 4 principi fondamentali:

  • Non si tratta di software, hardware o servizi: è l’insieme che va realizzato bene! Questo principio spinge il team cross-skill e cross-functional a lavorare a stretto contatto, coordinandosi costantemente e andando ad operare in chiave incrementale in modo da far emergere il prima possibile i problemi e risolverli nel modo più efficace dato il contesto specifico;
  • Pensare meno e agire prima! Lo sviluppo di una soluzione IoT passa attraverso l’utilizzo di tecnologie abilitanti che consentono di sperimentare rapidamente, e a basso costo relativo, le diverse ipotesi che si presentano durante l’intero ciclo di ALM (o PLM che si voglia). È quindi possibile ridurre al minimo la fase di “progettazione a tavolino” per focalizzarsi sulla “costruzione a tavolino” grazie ai diversi EVK disponibili sul mercato.
  • Semplice è meglio!  Più si è in grado di rendere semplice la propria soluzione, più si può essere confidenti che la stessa abbia la complessità minima necessaria e quindi possa evolvere in modo efficace e sostenibile. “Semplice” va inteso come “comprensibile” e “manutenibile”, obiettivo che si raggiungere utilizzando in modo preferenziale approcci standard e strumenti consolidati.
  • Se non puoi ricordarlo, non puoi migliorarlo! L’utilizzo di strumenti di Visual Management è fondamentale per poter avere prontezza dello stato di avanzamento complessivo della realizzazione della soluzione. Il più classico degli strumenti in quest’ottica è la Kanban Board.

Come si evidenzia, i principi non danno delle indicazioni operative, cosa demandato alle pratiche, ma comincia ad inserire quei tasselli che vanno a consolidare in contesto pratico di operatività dell’AgileIoT Team.

 

Sta tuned >J

AgileIoT Funnel: la filosofia

Continuiamo il nostro viaggio alla scoperta di AgileIoT attraverso i vari livelli dell’AgileIoT Funnel (visto nel post precedente), partendo da quello più profondo e condizionante, ovvero la filosofia.

agileiot funnel philosophy

La filosofia di AgileIoT nasce da una considerazione estremamente attuale: la contaminazione delle soluzioni IT con elementi che vanno oltre la sfera del software. Questo aspetto interessa praticamente tutte le aree applicative moderne, ognuna con le proprie peculiarità e regole proprie, esplicite e implicite.

Così, la realizzazione di una specifica soluzione deve confrontarsi quantomeno con aspetti legati all’Hardware, che possono contare su processi maggiormente collaudati e predittivi, al Software, dove la complessità e il cambiamento sono all’ordine del giorno, e al mondo del Cloud e dei Big Data, con le proprie regole e i propri elementi di rischio.

Quello che si riscontra nella pratica è che, tipicamente, la realizzazione di una soluzione così composta avviene in modo settoriale, ovvero si tende a creare appositi team che in parallelo ed in modo indipendente sviluppano le varie componenti per poi sincronizzarsi in un determinato momento e dare il via alle successive fasi di integrazione e test.

Si tratta di un approccio che sposa la logica della Big Bang Integration e che soffre di diversi problemi critici:

  • l’efficienza dello sviluppo è fortemente penalizzata, poiché i diversi team non comunicano costantemente tra loro e non condividono il know-how e la crescita complessiva;
  • i problemi vengono alla luce solo in una fase avanzata di realizzazione della soluzione, con costi di fix elevati, soprattutto per le componenti meno dinamiche (come l’hardware);
  • la soluzione finale spesso contiene un compromesso qualitativo a ribasso, dettato dalla necessità di consegnare la soluzione in tempo e basato su workaround (tipicamente software) laddove i vari componenti non si integrino perfettamente. 

Ecco perché AgileIoT si fonda su una specifica filosofia pensata per visualizzare una Visione Condivisa.

In particolare essa si rifà alla Bottega Rinascimentale, la cellula in cui veniva fatto tutto quanto necessario alla realizzazione di una nuova opera: dalla progettazione alla commercializzazione, passando per la formazione e la produzione.

bottega rinascimentale dipinto

Bottega Rinascimentale

Di pari passo, quindi, i membri di un AgileIoT team sono spinti a comportarsi come gli artigiani rinascimentali, lavorando costantemente insieme al fine di trovare il modo migliore per produrre quanto atteso dal cliente, consolidando le interazioni e producendo soluzioni funzionanti di qualità, in assoluta sintonia con i 4 Valori portanti dell’Agile.

Un modo olistico di affrontare le sfide sottese alla realizzazione di soluzioni complesse, a cominciare da quella annessa al cambiamento Culturale ed Organizzativo che è imprescindibile per le odierne attese dei Mercati di riferimento.

 

 

Stay tuned J

Aggiunta di un tipo di Work Item in VSTS

Precedenti post sulla personalizzazione Work Item in TFS

1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 – Customizzare il process template, regole per i campi aggiuntivi dei WI
5 – Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni

Post su personalizzazione VSTS

1 – Personalizzare il process template in VSTS
2 – Process template Ereditati in VSTS
3 – Aggiungere ad un Work Item un campo esistente in un altro template
4 – Creazione di un campo custom
5 – Modificare gli stati di un Work Item

Sicuramente la personalizzazione più interessante che può essere fatta su un Process Template è aggiungere un nuovo tipo di Work Item. In ogni team infatti esiste la necessità di tracciare informazioni concettualmente non mappabili su uno dei tipi di Work Item Tradizionali. Ad esempio potreste voler tracciare le sessioni di Event Storming da fare con il cliente e poterle schedulare. In questo caso un normale PBI nel process template SCRUM potrebbe fare al caso vostro, ma sicuramente avere un Work Item personalizzato permette di tracciare l’informazione in maniera più corretta. Per chi fa SCRUM infatti può essere interessante creare un Work Item Type per ogni tipologia di attività che sia pianificabile nello sprint.

Come possibile esempio mostrerò una personalizzazione fatta sul process template dell’account VSTS di GetLatestVersion, creata per per supportare un processo particolare, la pubblicazione di video-pillole sull’argomento ALM.

Di base con il processo SCRUM , sarebbe possibile utilizzare i PBI per rappresentare i Video che vogliamo realizzare ed utilizzare le features per categorizzare i video, ma è in qualche modo una forzatura. Sicuramente il poter creare dei Work Item personalizzati permettono di rappresentare in maniera più personalizzata e corretta queste iniziativa.

Navigando nella sezione dei Work Item Types nella pagina di personalizzazione del Process Template, si può notare il link che permette la creazione di un nuovo Work Item Type.

image

Per cominciare inizio creando un Work Item chiamato Video Pill, che deve rappresentare un video di massimo 7 minuti che focalizzerà l’attenzione su un punto ben preciso. Come si può vedere dalla figura sottostante è sufficiente dare un nome, una descrizione ed un colore ed il nuovo Work Item è creato.

image 

Alla pressione del bottone “Create” viene creato il nuovo Work Item che appare immediatamente nella lista a sinistra.

image

A questo punto la prima modifica che solitamente viene effettuata è quella di decidere se e dove questo nuovo Work Item apparirà nei backlog, ovvero nella pianificazione agile (Portfolio Management).

image

Di base si deve quindi decidere a che livello del backlog verrà visualizzato il nostro Work Item Type, oppure decidere di non farlo apparire per nulla. Nel caso della pillola video si è deciso per il livello del PBI, ovvero, banalmente, una User Story. In questo modo è possibile dare una “categoria” all’informazione. Tutti i Work Item a livello Task sono attività dello sprint / iterazione figlie di un elemento del backlog, mentre i livelli superiori (features ed epics) sono contenitori più generali per gestire il Portfolio Management.

Per quanto riguarda le opzioni di Overview è possibile modificare la descrizione, sia distruggere il tipo di Work Item, opzione che non è chiaramente possibile per i Work Item base del processo. Anche in questo caso si può vedere come il sistema previene operazioni (come la cancellazione di tipi già presenti) che possono andare ad inficiare un eventuale aggiornamento del Process Template.

image

Ricordate che cancellare un Work Item Type custom provocherà la cancellazione di tutti i Work Item creati sulla base di quel tipo, cosi come tutti i dati storici, ed è quindi una operazione che deve essere ponderata con molta attenzione.

Dopo avere selezionato la posizione del Backlog è consigliabile andare ad editare gli stati disponibili, in questo caso si è scelto di utilizzare gli stessi stati del PBI. Questo non è strettamente necessario, ma dato che il nuovo tipo di Work Item condivide lo stesso livello di Backlog, il processo sarà molto più chiaro se la nostra Video Pill contiene gli stessi stati dei Work Item Type che sono presenti allo stesso livello.

image

Anche in questo caso è interessante vedere le differenze che vi sono tra i menù contestuali presenti nella lista di stati di un PBI (1) e quelli presenti nella lista di stati del nostro nuovo Work Item (2).

image

Mentre per il PBI le uniche opzioni che possiamo avere per gli stati base sono View e Hide, nel nostro nuovo Work Item tutti gli stati possono essere sia Editati che Rimossi. Mentre, come visto nell’articolo precedente, non è possibile rimuovere uno stato per uno dei Work Item base, per quelli personalizzati non esiste nessuna limitazione e si possono aggiungere e rimuovere tutti gli stati che si preferisce.

A questo punto non rimane altro da fare che andare a inserire nel Work Item Type i campi desiderati e modificare il layout in modo che sia aderente alle nostre necessità.

Anche in questo caso si può notare come con veramente pochi click sia stato possibile andare ad aggiungere una nuova tipologia di informazione nel nostro account VSTS, adattandolo alle specifiche esigenze del team e senza il rischio di complicare le procedure di update.

Gian Maria.

WorkItems History: la mia prima estensione per VSTS e TFS

Sono davvero felice ed orgoglioso di condividere la prima versione della mia primissima Estensione per Visual Studio Team Services e Team Foundation Server: WorkItems History.
Cos’è
WorkItems History è un’estensione che aggiunge un hub “History” alla sezione Work di VSTS/TFS e permette di visualizzare la cronologia dei work item modificati e/o aggiunti al backlog del progetto.
Perchè
Lavorare in team non è sempre una cos semplice, specialmente quando c’è bisogno di tenere tutte le cose “sotto controllo”. Con questa estensione, possiamo avere un po’ più di controllo almeno su quello che sta accadendo al nostro lavoro.
Altre info
Ho deciso di rilasciare questa estensione come Software Open Source.
Potete dare un’occhiata alla sua pagina di (https://github.com/n3wt0n/WorkItemsHistory) e, se volete, potete contribuire attivamente al progetto. Fate riferimento alle Contribution guidelines ed al Code of Conduct per maggiori dettagli a riguardo.
Utilizzo, supporto e Feedback
Questa estensione è pubblicamente disponibile attraverso il VS Marketplace, a questo link: https://marketplace.visualstudio.com/items?itemName=DB.WorkItemsHistory
Potete trovare  ulteriori informazioni sull’utilizzo e l’installazione di WorkItems History sul repo GitHub.

Nel caso in cui doveste trovare un bug o un comportamento inaspettato dell’estensione, fatemelo sapere attraverso la pagina Issues su GitHub e cercherò di risolverlo prima possibile!
Attendo i vostri feedback :)

AgileIoT, The Funnel

AgileIoT è prima di tutto una filosofia, basata sull’agile manifesto, che si trasforma in un approccio pratico attraverso i relativi principi, pratiche e metodologie.

Questa impostazione si concretizza nell’AgileIoT Funnel che ne descrive in modo sintetico gli aspetti portanti evidenziando gli Ambiti relativi e i diversi Elementi caratterizzanti:

agileiot funnel

 Troviamo quindi:

  • Filosofia, pensata per visualizzare una visione condivisa;
    • La Bottega Rinascimentale, la cellula in cui veniva fatto quanto necessario alla realizzazione di una nuova opera: dalla progettazione alla commercializzazione, passando per la formazione e la produzione. I membri del team sono spinti a comportarsi come gli artigiani rinascimentali.
  • Principi, pensati per ispirare le azioni delle persone:
    • Non si tratta di software, hardware o servizi: è l’insieme che va realizzato bene!
    • Pensare meno e agire prima!
    • Semplice è meglio!
    • Se non puoi ricordarlo, non puoi migliorarlo!
  • Pratiche, pensate per guidare le azioni delle persone:
    • Fast Prototyping;
    • Make-Measure-Learn;
    • Flashback;
    • Continuous Improvement;
    • Continuous Integration.
  • Metodologie, pensate per adattare il tutto a differenti contesti:
    • Duttile Framework;
    • Fiotto;
    • … il vostro approccio!

Grazie al Funnel è quindi possibile approfondire la struttura a supporto dell’adozione di Agile nel mondo dell’IoT e decidere come e cosa utlizzare in funzione dello specifico contesto.

 

Stay tuned J