Ask Me Anything n. 17/2

Ricorre l’appuntamento a microfono aperto.

Gli esperti della community GetLatestVersion sono a vostra disposizione proporre domande su qualunque tema attinente a Application Lifecycle Management, Ciclo di vita del Software e DevOps. Non ci sarà una scaletta od una impostazione predefinita, e le risposte possono essere anche supportate da demo immediate o approfondimenti provenienti da esperienze reali.

Biglietti su EventBrite (https://www.eventbrite.it/e/biglietti-getlatestversion-ask-me-anything-n-172-32974864708); se non riuscite a registrarvi, connettetevi comunque a https://meet.jit.si/GLV per incontrare i nostri ospiti.

0  

SecOps, DevSecOps, SecDevOps… la sicurezza al centro dell’azione di delivery

Per fortuna che esistono gli acronimi! Senza di essi che mondo sarebbe!! (ok, mi sono ispirato ad una famosa pubblicità nostrana :-))

Senza acronimi, però, il mondo dell’IT sembrerebbe in stallo perenne e alcuni temi portanti finirebbero pericolosamente nel dimenticatoio, sopraffatti dalla moda del momento.

In questo caso la domanda è banale: ma serve creare un nuovo acronimo per ricordarci ancora oggi che gli aspetti di Sicurezza devono essere al centro delle attenzioni dei team di delivery? Ovviamente, no! Ma forse può esserci d’aiuto per “rinfrescarci” la memoria.

Abbiamo più volte parlato di sicurezza, anche in relazione al mondo dell’IoT, raccontando come, ad esempio, AgileIoT ponga questo aspetto nei “ballons” fondamentali per la produzione di soluzioni massive di mercato. In ugual modo lo fano Disciplined Agile 2, SAFe e gli altri framework di scaling, per non parlare di Lean. Anche l’ISO ha formalizzato da tempo il proprio standard a riguardo, ovvero l’ISO 27001, che molte aziende si stanno quanto meno impegnando a “capire”.

secdevops

Sia che vogliate chiamarlo SecOps, DevSecOps, SecDevOps, o diversamente, resta il fatto che la Sicurezza è un vostro problema, e come tale dovete ponderare il vostro lavoro quotidiano in sua funzione. L’approccio che si cela dietro questi acronimi trova le fondamenta nel Threat modeling, dove si cerca, pragmaticamente, di identificare, enumerare e priorizzare gli ipotetici rischi ponendosi nei panni di colui che prova a violare i nostri sistemi.

Gli aspetti operativi di questo approccio si legano al value stream generale, specializzandosi in specifiche azioni da parte dei Devs e degli Ops. Un elemento da sottolineare è che applicando DevOps in tutta la sua potenzialità, ottenendo quindi un ambiente di delivery estremamente dinamico, si ha la necessità di rendere tale anche l’approccio alla sicurezza, concretizzando un “fast security approach” (the third way: learning), in modo da avere processi sempre aggiornati ed evitare l’accumulo di debito tecnico in tale area.

Diventa così evidente come ogni nuova iniziativa nasca di base con una serie di quesiti annessi:

  • Quali sono i dati che (andremo) si andrà a raccogliere?
  • Come verranno protetti i dati da attacchi interni ed esterni?
  • Qual è la sicurezza degli ambienti in cui le soluzioni vengono rese disponibili?
  • Che cosa si è imparato dall’esperienza e dalle release precedenti?
  • Quali sono le principali sfide incontrate?

Si tratta di tasselli estremamente importanti nell’impostazione generale del progetto, tanto da impattare, ad esempio, sulla Definition of Done e, di conseguenza, sull’effort complessivo (the first way: flow).

Se si va poi a guardare più da vicino le attività dei Developer, si evidenziano aspetti direttamente correlati alle attività di sviluppo in un’ottica di “secure engineering” (the first way: flow):

  • Implementare modelli adeguati di crittografia e di protezione dei dati;
  • Integrare scansioni di sicurezza automatizzati nei processi di sviluppo e condividerne rapidamente i risultati;
  • Coinvolgere gruppi di “hacking etico” per rafforzare la capacità di realizzare ed eseguire test di penetrazione sempre più efficaci;
  • Fare delle considerazioni sul possibile utilizzo malevole delle API pubbliche e registrarne gli abusi nei sistemi di monitoring;
  • Inserire nel codice strumenti di logging non-invasivo per tracciare adeguatamente i fault di sicurezza;
  • Essere costantemente aggiornati sulle nuove tipologie di attacchi e sulle tecniche di risposta e prevenzione;
  • Sperimentare e condividere successi e fallimenti.

Parallelamente, gli Operation hanno in dote tutti quegli approcci e quelle tecniche che mirano a rendere sicuri gli ambienti di erogazione e raccogliere dati a riguardo (the second way: feedback):

  • Osservare cosa accade in seguito ai nuovi rilasci e come essi impattano sui livelli di sicurezza;
  • Assicurarsi che i software di base siano dotati degli ultimi aggiornamenti;
  • Validare costantemente le autorizzazioni d’accesso e proiettarle verso il livello minimo;
  • Assicurarsi che le diverse postazioni operative siano utilizzate solo da utenti autorizzati;
  • Settare strumenti di monitoraggio, attivi e passivi, che consentano di verificare lo stato di sicurezza in modo automatizzato e creare feedback rapidi sulla base delle informazioni ottenute;
  • Attuare scansioni di networking e tentativi di intrusione per validarne la robustezza;
  • Registrare qualsiasi anomalia e classificarla in funzione dei rischi;
  • Trasparenza e condivisione dello stato generale.

Come ripetiamo da tempo, realizzare oggi una soluzione IT ha un grado di complessità e di ingegnerizzazione completamente diverso da quello di soli cinque anni fa, per cui è necessario una nuova cultura e nuove competenze, permettendo così di sfruttare, inoltre, adeguatamente anche le nuove tecnologie a disposizione.

 

Stay tuned :-)

Build: I minuti sono tornati

Se avete attivato la nuova Home Page dell’account sul vostro Visual Studio Team Services, avrete sicuramente notato che il riepilogo dei minuti di build gratuiti è sparito. Il problema è che non solo è stato tolto dalla pagina iniziale, ma non era stato inserito in nessun’altra schermata.
Finalmente, però, abbiamo di nuovo la possibilità di visualizzare il contatore. Per farlo, bisogna andare sulle impostazioni dell’account, sotto Build and Release, Resource limits:

 Festeggiamo! I minuti sono tornati :)

Agile@School 2017 – I progetti

Sabato scorso, con i team definiti nell’incontro precedente, abbiamo parlato di analisi dei requisiti, partendo dalla customer journey che gli studenti hanno creato appositamente. Come mi aspettavo, quest’ultimo compito è risultato più arduo di quanto i ragazzi credessero. Non è infatti facile avere le idee chiare su quello che si vuole ottenere, anche se l’idea di fondo del progetto è apparentemente solida. Parlandone insieme e facendosi qualche domanda in più a mo’ di brainstorming, sono emerse tutte le normali lacune di chi non è abituato a pensare a veri progetti. 

Risultato? Non avevamo nemmeno una customer journey.
Come fare? Semplice, Gabriele ed io abbiamo seguito team per team, sia dando consigli sul “cosa fare” per chi era a corto di idee, sia discutendo la forma da seguire per ottenere risultati efficaci.
Come in ogni percorso, abbiamo perso un paio di ragazzi, i quali hanno preferito seguire un iter solitario. Parlo anche di queste persone perchè, nonostante la strada intrapresa, sono stati con noi, e ci hanno pure aiutato a costruire le board di cui parleremo a breve. Il tutto nello spirito di aiuto e condivisione. Ed è decisamente importante; un valore aggiunto non da poco. 
Possiamo dire di avere infine sei squadre, con altrettanti progetti:
Come si vede nella foto, il primo step è stato raccogliere una board. L’idea è quella di fare la story map, ovvero una bacheca in cui apporre post-it di colore differente, con la quale descrivere le funzionalità del software (o di altro, come l’utilizzo di hardware, il dialogo di bot, ecc.). Si tratta di un’implementazione molto semplice, se si conoscono già le funzionalità da offrire. Immaginate di avere una linea principale in cui rappresentare le feature principali ed almeno una secondaria in cui indicare le attività da implementare. Orizzontalmente le feature, e verticalmente il loro sviluppo. In verticale anche la profondità fino a cui arrivare, versione per versione. Ecco come appare:
La riga a matita, la quale esclude l’ultimo post-it blu, è la v1.0. Al di sotto di essa, la 2.0.
Dalla board ricaveremo le epiche e i PBI da aggiungere a Visual Studio Team Services, in modo da creare una rappresentazione virtuale della stessa. Utilizzeremo anche la funzionalità denominata swimlane, al fine di creare all’interno dello stesso spazio più board, una per ogni progetto/team. 
Da qui si inizierà con il vero sviluppo e con la riorganizzazione delle bacheche quando e laddove richiesto. I presupposti ci sono, le idee sono buone ed anche l’innovazione è presente nei pensieri dei ragazzi. Avremo, se tutto andrà come dovrebbe, un’automobile intelligente comandata da smartphone (Raspberry), un sistema di allarme domestico (Arduino), un paio di chatbot (senza intelligenza artificiale), una chat per la produttività dei team ed un progetto di riconoscimento facciale. Da rimanere a bocca aperta! Il problema è: “ce la faremo?”, proviamoci!
Stay tuned! 

BugGuardian per ASP.NET Core

C’è un nuovo membro nella famiglia BugGuardian.
Un po’ di tempo fa ho rilasciato BugGuardian, una libreria che permette di create un work item di tipo Bug o Task sia su Visual Studio Team Services sia su Team Foundation Server, nel caso in cui la nostra applicazione sollevi un’eccezione non gestita. (Maggiori informazioni qui).
Dopo un po’, si sono aggiunte altre due librerie: BugGuardian.WebForms e BugGuardian.MVC. Come dice il nome, la prima è pensata per ASP.NET WebForms e l’altra per ASP.NET MVC, e servono per semplificare ulteriormente l’adozione della libreria a chi utilizza quelle piattaforme. Ma hanno un limite: funzionano solamente con ASP.NET tradizionale, su .Net Framework.
Oggi sono felice di annunciare che l’estensione BugGuardian.AspNetCore è finalmente disponibile.
BugGuardian.AspNetCore è stata sviluppata per supportare specificamente le webapp ASP.NET Core. Aggiunge un middleware all’applicazione che permette di intercettare automaticamente tutte le eccezioni non gestite.
E la cosa positiva è che supporta sia i progetti ASP.NET Core che utilizzano il full Framework sia quelli scritti con NetCore.
Potete trovare il codice sorgente (e tutte le informazioni sulla configurazione della libreria) su GitHub: https://github.com/n3wt0n/BugGuardian.AspNetCore
Il pacchetto è anche disponibile su NuGet: https://www.nuget.org/packages/DBTek.BugGuardian.AspNetCore
Happy Coding :)

DevOps è Cultura… ma cos’è la Cultura?

Tornando nei giorni scorsi da due importanti eventi, l’Agile Lean Conference Italia e Agile for Innovation, ho avuto tempo di riflettere in treno (complice il solito ritardo che stavolta ha superato gli 80 minuti) su una cosa: durante i miei interventi su DevOps mi soffermo sempre a sottolineare più volte come DevOps sia Cultura!

culture behaviour

Fin qui, nulla da recriminare a me stesso, ne sono profondamente convinto ed è un punto fermo di tutto il movimento che ruota, con cognizione di causa, intorno a questa filosofia nata (o meglio esplicitata) nel 2009 quando Patrick Debois da vita al DevOpsDays in Belgio e conia il termine stesso DevOps.

Al tempo, Debois è reduce da una consulenza per un’azienda governativa in cui il maggiore ostacolo incontrato è quello della completa assenza di comunicazione tra Dev e Ops, tanto da sentirsi frustrato nel non capire il perché di questa condizione paradossale.

Il problema era tutto nell’atteggiamento, o meglio ancora nei comportamenti che le due anime dell’IT avevano l’uno nei riguardi dell’altro: ogni gruppo si sentiva “superiore” e considerava l’altro una “zavorra” di cui non era possibile liberarsi e di conseguenza da relegare in un angolo.

Quindi, il come ci si pone rispetto ai nostri colleghi diretti, caratterizza la Cultura aziendale nel suo insieme, andando a connotare l’azienda stessa e la sua capacità di rispondere ai cambiamenti. La tematica è straordinariamente interessante, e per sintetizzarla possiamo prendere in prestito il concetto di Sfera di Influenza che l’amico Andrea Provaglio utilizza frequentemente per descrivere egregiamente la differenza tra Management e Leadership: ognuno di noi è leader almeno di sé stesso (ok, se non lo è i problemi sono diversi), per cui ognuno di noi ha una propria sfera di influenza che può assumere un volume più o meno ampio a secondo della capacità che abbiamo di influenzare gli altri.

I punti di intersezione delle diverse sfere di influenze rappresentano il contatto in cui i diversi gruppi aggregati (con il limite inferiore tendente a un componente) si confrontano partendo dalle proprie esperienze, anche diverse, che in qualche modo devono amalgamarsi per consentire al flusso generale delle attività di scorrere adeguatamente verso l’obiettivo di generare Valore. Se si riflette su questi aspetti, l’evidenza è straordinariamente ovvia: fino a che si resta nella nostra confort zone, siamo protetti, ci sentiamo sicuri e tutto fila per il meglio. Quando dobbiamo metterci in gioco, quest’area di sicurezza diventa instabile e i nostri comportamenti sono una risposta al cambiamento e al nuovo equilibrio da raggiungere.

Diventa così esplicito che la Cultura aziendale sia la capacità dell’organizzazione di accrescere la propria resilienza e rispondere adeguatamente ai cambiamenti radicali (kaikaku) che si affiancano a quelli graduali (kaizen), impliciti o e espliciti che siano.

Quando sentiamo delle affermazioni tipo: “questo approccio non si adatta alla nostra Cultura aziendale”, si evidenzia una implicita resistenza al cambiamento che sottolinea un nostro comportamento conservativo, dietro il quale si cela la non volontà di mettersi in gioco e impegnarsi a trovare un nuovo punto di equilibrio nell’orizzonte (landascape) organizzativo.

Volendo sintetizzare, possiamo affermare che:

la Cultura aziendale è l’insieme dei comportamenti che ogni membro dell’organizzazione ha nel confronto dei propri colleghi e nella risposta alla necessità di cambiamento proveniente da fattori esterni

e quindi:

per cambiare la Cultura organizzativa, potete e dovete cambiare i vostri Comportamenti

(e ciò si trasformerà nella nuova Cultura organizzativa)

Stay tuned J

Il movimento Agile sbarca al sud

2017 agile o day logo

L’Agile Community Campana, associazione nata lo scorso anno, è orgogliosa di annunciare che il 12 maggio 2017 ci sarà il primo Agile Open Day a Napoli, organizzato con la Facoltà di Ingegneria dell’università Federico II di Napoli e l’Italian Agile Movement.

È la prima volta che uno degli eventi afferenti al mondo Agile si tiene nelle regioni del Sud, nonostante la tematica sia estremamente importante, soprattutto per le aziende che fanno dell’IT uno dei propri fondamentali.

Esperti di tutta Italia saranno a Piazzale Tecchio a Napoli (sede della facoltà di Ingegneria) per raccontare esperienze concrete nel contesto italiano, utili a capire perché Agile, Lean, DevOps e gli altri approcci affini, abbiano un’importanza strategica nel contesto nazionale per qualsiasi azienda che voglia rispondere efficacemente alle perturbazioni del mercato.

Nessun dubbio quindi sull’opportunità di ascoltare e confrontarsi ai massimi livelli su queste tematiche, assaporando anche l’ospitalità che da sempre caratterizza i nostri territori.

L’invito è quello di iscrivervi subito all’evento tramite la pagina ufficiale: http://www.agilecommunitycampania.it/agile-open-day/ e, se avete storie da raccontare, inviare una vostra proposta di intervento che sarà valuta dall’apposita commissione che ha il compito di redigere l’agenda finale.

Sempre allo stesso indirizzo potete seguire l’evoluzione degli aspetti organizzativi e, in caso abbiate qualsiasi domanda, potete scriverci all’indirizzo email: info@agilecommunitycampania.it

Ci vediamo il 12 maggio a Napoli!

Felice Pescatore, Agile Community Campania

DevOps, Agile e Lean: non è più concesso ignorarli

DevOps è diventato ormai il killer-approach per la delivery di soluzioni che siano in grado di avere un basso time-to-market e ottimizzare l’intero value stream aziendale annesso.

Devo ammettere che da sempre considero DevOps la naturale estensione dell’Agile, con una positiva contaminazione dei principi Lean (che ricordo sono derivati dal mondo manifatturiero), cosa che mi porta ad amare poco il termine “DevOps” in sé perché, almeno lessicalmente, sembra limitare il tutto ai Developer ed agli Operation oltre che all’ambito IT.

solution s curve

Detto questo, è importante evidenziare che DevOps non “appartiene” solo al mondo dell’IT, bensì è un approccio che spinge a far propri i 3 principi portanti: Flow, Feedback e Learning (così come sono oggi riformulati rispetto alla prima enunciazione), per un’azione efficace nella creazione di Servizi e Prodotti negli ambiti più diversi. A tal proposito segnalo l’interessante approfondimento degli amici di AgileReloaded: L’orizzonte allargato di Agile.

Resta comunque indubbio che l’IT è la culla di DevOps, trasformando gradualmente le azioni annesse allo sviluppo di soluzioni complesse da attività “artigianali” ad attività più “ingegneristiche”, con precisi elementi di riferimento. Ciò fa si che le aziende percepiscano sempre più il proprio IT per quello che deve essere: un Asset strategico al servizio del Business e non un Centro di Costo.

E le parole sono estremamente importanti: parlare di “divisione IT” porta ad immaginare un Silos a sé stante con regole proprie e ben identificabili. Ciò è quanto di più semplicistico si possa immaginare perché l’IT è estremamente pervasivo e condiziona, restandone a sua volta condizionato, tutte le aree aziendali.

La centralità di DevOps, anche se non del tutto maturata nel nostro contesto nazionale, è confermata da un’indagine di IDC che oggi ne vede l’adozione in oltre il 70% delle principali aziende mondiali (con livelli diversi e penetrazione diversa) e stima il superamento della soglia dell’80% entro il 2019.

Ma questa penetrazione così profonda, quali sfide comporta?

Anche qui dobbiamo avere una visione olistica del contesto poiché molte aziende che provano a sperimentare DevOps su un progetto pilota o un’area di riferimento, si accorgono rapidamente che è necessario coinvolgere tutte le diverse funzioni aziendali, per cui lo Scaling diventa inevitabile e anche estremamente veloce.

Ma torniamo alla nostra precedente domanda, andando ad evidenziare le sfide primarie che ogni azienda incontra nell’adozione concreta di DevOps e, quindi, nel profondo percorso di trasformazione e cambiamento Culturale:

  • Sponsorship aziendale: adottare DevOps significa investire e avere pazienza nell’ottenere risultati tangibili localizzati a breve termine, ma complessivamente visibili nel medio termine. L’investimento è sia in termini finanziari che in termini di impegno delle Persone (vi prego… non usate il termine “risorse” per indicarle!), per cui solo se è uno dei massimi dirigenti aziendali (CxO) a supportarla, l’adozione potrà avere il sostegno necessario e raggiungere risultati lusinghieri;
  • Abbandonare le rigide strutture di controllo del passato: una Cultura volta al continuo miglioramento, basata su applicazioni empiriche, mal si lega con una organizzazione aziendale basata sul pattern command-and-control, in cui è difficile cambiare. I manager devono imparare a delegare, mentre le linee più operative ad avere coraggio, cercando di rendere la struttura più flessibile ma soprattutto focalizzata sul value stream;
  • Il Core know-how deve essere in azienda: considerare l’IT un “centro di costo” ha portato negli anni ad abusare dell’outsourcing, perdendo conoscenza, controllo e capacità di gestire le nuove sfide di mercato. Questa tendenza deve trasformarsi in un’outsourcing bilanciato in cui gli elementi chiave, per rispondere efficacemente e prontamente al Business, sono all’interno e ci si appoggia ad un’outsourcing controllato per gli elementi corollari (abbiamo parlato abbondantemente di questo aspetto nella serie DevOps and Outsourcing: OutOps);
  • Ridurre la resistenza al cambiamento: DevOps è Cultura, e una trasformazione aziendale nella sua direzione comporta nuovi modelli organizzativi, nuovi ruoli e un diverso approccio alle prospettive di carriera. Questi aspetti spingono ad aumentare la resistenza al cambiamento per restare nella propria “confort zone” e ridurre al minimo la necessità di rimettersi in discussione. È compito dell’organizzazione fare chiarezza su questi aspetti e creare le opportunità a sostegno dei desideri intersechi (leggasi Management 3.0) ed estrinsechi di ogni singolo collaboratore;
  • Fail Fast o meglio… Learn Fast: il fallimento è una componente poco desiderata ma fortemente presente, e a volte indispensabile, nel mondo dei sistemi complessi. Il mantra non deve essere: “non fallire mai…” ma “fallire il meno possibile e quando accade far tesoro del fallimento stesso”. In pratica ogni fallimento diventa un tassello nel cambiamento e nell’ottimizzazione complessiva… chiaramente questo non vuol dire fallire sempre!
  • Mai applicare qualcosa “out-of-the-book”: DevOps è un cambiamento culturale da ricamare nel proprio contesto e come tale necessita di essere capito profondamente nelle sue varie sfaccettature. Non basta comprare un libro e leggere qualche blog per iniziare la propria trasformazione: il rischio di fallimento è estremamente elevato! Meglio affidarsi al supporto di professionisti che accompagnano l’organizzazione a muovere i primi passi e ad individuare gli elementi focali che consentono affacciarsi al mondo DevOps con maggiore fiducia e minori incertezze.

Se tutto questo vi spaventa o vi fa tornare nel “vostro mondo” fatevi una domanda: possiamo permetterci di non cambiare quando tutto sta evolvendo ad un ritmo frenetico ed inarrestabile?

In fondo bisogna lasciare andare il passato per essere padroni del futuro.

Stay tuned J

Agile@School 2017 – Primo incontro

Il progetto Agile@School è ufficialmente ricominciato. E rispetto all’anno scorso, con una marcia in più, vista la grande partecipazione. Quasi una ventina di persone, tante idee e progetti, tanti team e quindi, cambiamento di metodologia. 

L’anno scorso abbiamo introdotto il concetto di Scrum ed i relativi principi e pratiche. Questa volta abbiamo pensato, proprio per la natura distribuita dei partecipanti, di passare a Kanban. Senza entrare troppo nel dettaglio metodologico, avremo:
– Alcuni micro team, che chiameremo “task force”, prendendo spunto da un termine usato (in modo diverso in realtà) da Mauro Servienti nelle sue slide sul suo lavoro in Particular
– Una Kanban board
– La definizione delle personas
– La definizione della customer journey e di una Story Map
– Alcune cerimonie utili all’allineamento delle persone nel complesso
Le task force
Come detto in precedenza, il termine è stato preso da un’interessantissima sessione di Mauro Servienti, in cui si racconta la sua esperienza sul suo posto di lavoro, una realtà molto distribuita, anche geograficamente, che necessita di una gestione ben studiata. Nelle slide si parla di task force per indicare un elenco di “volontari” che si uniscono per risolvere un problema (o una issue). Ogni task force effettua un meeting per capire come e cosa fare al fine di portare l’elemento dal backlog fino alla completa implementazione e, ovviamente, inizia a lavorare per portare a compimento l’implementazione stessa. Il tutto seguendo un ciclo di vita (lifecycle) che dura quanto serve a portare a termine il tutto. 
In Agile@School avremo quindi sei task force, sei gruppi di due o tre persone che prenderanno in carico le implementazioni e le relative analisi. Nel nostro caso avremo una task force per progetto, ed ogni progetto sarà una tesina differente da preparare entro i prossimi tre mesi.
La Kanban board
Vedendo l’insieme dei ragazzi come un grande team di circa venti persone, abbiamo deciso di organizzare la nostra Kanban board non solo con le colonne che identificano il processo di ogni elemento, bensì aggiungendo swimlane, ovvero linee orizzontali che distinguono ogni prima release di ogni progetto, e quindi, task force:
Sulla foto indicata ci sono tutti i termini propri di Visual Studio Team Service, e sono stati tutti descritti ai ragazzi. Abbiamo quindi un glossario comune, in modo da potersi esprimere con un linguaggio comune. Anche questo dà valore aggiunto.
Le personas
Ogni membro delle task force ha compilato una scheda appositamente preparata, per dare indicazioni interessanti su interessi, obbiettivi ed informazioni generali. Perché scrivere di sé? Perché conoscersi è il primo passo verso la costruzione di una fiducia reciproca e di trasparenza, necessarie per avere team solidi e produttivi. La scheda delle personas proposta, molto semplice, è la seguente:
Perché “ruolo nel team”? Perché volevamo capire anche l’interesse dei ragazzi. Si tratta di una forzatura, è vero, ma è interessante osservare come i partecipanti si vedono all’interno di una squadra. Alla fine, adattare la scheda porterà ad avere ancora più informazioni utili.
La customer journey
Al termine del percorso introduttivo, dopo aver condiviso il glossario e le idee sul progetto, abbiamo assegnato un lavoro importante ai ragazzi. Fare la customer journey del progetto che hanno in testa. Il compito non è semplice, poiché sarà necessario identificare le problematiche e i requisiti funzionali richiesti per l’applicazione. Ogni task force dovrà creare il “viaggio” dell’utilizzatore, con tanto di cambiamento di umore nei vari momenti e con l’indicazione dei punti più critici e di quelli che danno valore aggiunto.
Unitamente alla customer journey, nel prossimo incontro, andremo a creare la story map di ogni progetto, che utilizzeremo per aggiungere le attività sulla board. Da lì, inizieremo a sviluppare e a gestire ogni task force.
Le cerimonie
Abbiamo identificato un paio di cerimonie ereditate da Scrum, al fine di rendere l’esperienza dei partecipanti interessante anche a livello di rapporti interpersonali ed inter-task force. Il nostro obbiettivo è quello di fare una review dei progetti, per portare quell che in gergo chiamiamo Awareness (consapevolezza), in modo da rendere chiaro a tutti chi sta facendo cosa e come sta affrontando le problematiche. Il fine è quello di condividere anche l’esperienza ottenuta dalla risoluzione delle anomalie e degli impedimenti. Infine, una retrospettiva, per migliorare il processo incontro dopo incontro. A parte queste due, non serviranno “daily meeting” o altri momenti di incontro.
Per tutto il resto, il progetto rimane simile a quello dell’anno scorso. Utilizzeremo Slack, Visual Studio Team Services, e lasceremo la libertà ai ragazzi nella scelta degli strumenti di sviluppo. Saremo Gabriele ed io, anche se, come già indicato in un post precedente, vorremmo seriamente far partire il progetto in altre realtà, per chiunque fosse interessato, professori compresi!
Vedremo come proseguirà.
Come sempre,
Stay Tuned! 

Nuovo deploy per VSTS

Con la solita cadenza tri-settimanale ecco le release notes del nuovo sprint rilasciato su VSTS. La nuova funzionalità su cui mi voglio soffermare è il cambio di licenza / uso per i build agent. Tradizionalmente infatti VSTS permetteva di usare un agent on premise gratuitamente, e per ogni agent in più era necessario pagare un abbonamento mensile.

Con il nuovo update la situazione è cambiata, nella parte di amministrazione del vostro account è ora presente un menu dedicato alle Build and Release dove potete vedere le Resource Limits.

image

Di base avete solamente una free pipeline, il cui significato è discusso in questo articolo. Senza entrare nel dettaglio il concetto è che potete installare quanti agent volete, ma se avete una sola pipeline attiva, solamente una build o una release attiva possono coesistere contemporaneamente. Questo significa che anche se avete agent liberi, se una build è in corso le altre verranno accodate.

Questa situazione è molto più desiderabile rispetto alla gestione classica, perché in questo modo voi potete deployare quanti agent volete, senza doverli ogni volta attivare o disattivare, e lasciare che sia il sistema a gestire il throttling. Se vi rendete conto che una sola pipeline non vi basta, potete acquistarne altre, ma nel frattempo potete installare agent su linux, windows, mac senza dovere impazzire.

Gian Maria.