How to share an Azure DevOps Artifact feed with the entire organization

Azure Feeds used to be scoped to an organization. However, to enable public feeds and to become more consistent with the rest of Azure DevOps, feeds created through the new create feed UI are now project-scoped.

The only way to create an org-scoped Azure Artifact Feed is through API calls and it’s not reccomended.

If we want to share a feed with an entire organization this is what we need to do.

Tutorial

  1. We open the Azure Artifact module on the left of the portal
  2. We select the feed that we want to share
  3. We click on the gear icon to open the settings related to the feed.
Azure DevOps Artifact feed section with numbered steps to achieve the result of the tutorial.

Azure DevOps Artifact Feed

From here we need to select a View of the feed that we want to share and select the appropriate visibility level. These are the necessary steps:

  1. We select the View tab from the settings page;
  2. Then we select the View that we want to share (Local in this example);
  3. We click the Edit button;
  4. We select the org name (miferrac in this example) to share the feed with the entire org.
Steps to share the Local view of an Azure Artifact Feed.

Edit view

And that’s it!

TL; DR

We learned how to share an Azure DevOps Artifact Feed with the entire org.

Reference

Secure and share packages – MS Doc

Agile@School – Anno quinto, ep. 5

Ed eccoci alla seconda lezione completamente online! L’impatto è stato molto meno forte; la volta scorsa abbiamo avuto un po’ di tensione causata dalla mancanza di esperienza, mentre stavolta la lezione è filata via senza intoppi (tolto qualche problema tecnico iniziale, prontamente risolto dal gentilissimo personale della scuola). È un buon segno. Nonostante tutto, è possibile (addirittura auspicabile?) una forma di educazione online, che nulla ha da invidiare alle classiche lezioni frontali, eccetto il rapporto umano, ovviamente.

Comunque, venendo ai temi della lezione, anche questa volta lo scopo è stato quello di “far parlare” i ragazzi: è piuttosto evidente che la maggior parte di loro non è abituata a interagire più del necessario (per carità, alla loro età…), però una delle cose che vorremmo gli restasse da questa esperienza è proprio quella di imparare i comportamenti tipici del team. In un ambiente lavorativo, dove la comunicazione e il lavoro di squadra sono centrali, infatti, possono fare la differenza.

Pier-Paolo ha iniziato la lezione riprendendo le fila di quella precedente e ha cercato di far comprendere meglio agli studenti la differenza fra un approccio waterfall (a cascata) e uno ad iterazioni, tipico invece dello sviluppo agile, che in questo periodo è addirittura indicato nei decreti ministeriali. Quello che si è notato è la tendenza da parte dei ragazzi di procedere in un modo un po’ “tutto o niente”, poco organizzato nel tempo, per quanto riguarda le implementazioni; in ambito lavorativo ciò non consente di portare un reale valore tangibile al cliente. Infatti, non gli viene fornita una versione coerente del lavorato e non gli si da visibilità dei progressi nel software fino a fine sviluppo. I ragazzi dovrebbero cominciare a lavorare più a “storie”, realizzando parti del loro software, magari piccole, ma funzionanti e “visibili” findai primi momenti (agile e iterazioni).

Le impressioni positive che già avevamo rilevato sono poi state confermate: la modalità totalmente online con cui si svolge la lezione è vincente. Anche questa volta il professore ha chiesto di mostrare l’avanzamento dei progetti ed è evidente che i ragazzi si stiano abituando al backlog e alla creazione e presa in carico dei task. Manca ancora il poter vedere i progetti funzionanti, ma siamo confidenti nelle prossime lezioni.

La lezione è terminata con una breve dimostrazione dell’integrazione fra le push su GitHub e Azure DevOps (impostate la volta precedente). La prossima settimana vedremo se tutto questo avrà portato i voluti risultati. Speriamo anche di poter iniziare a parlare di branching style, ma questo è un argomento ostico anche per i lavoratori, quindi non sarà semplice.

Bene, continuiamo così nonostante le difficoltà che ci stanno mettendo a dura prova. Alla prossima lezione!

PMI Disciplined Agile: Disciplined Agile Enterprise (pt.6)

Riprendiamo il nostro viaggio attraverso Disciplined Agile, andando ad esplorare l’anello più olistico del toolkit, ovvero: Disciplined Agile Enterprise (DAE).

da f1

Con i process blade di livello DAE, DA supporta lo sviluppo di una organizzazione in grado di abbracciare una Cultura Agile a tutti i livelli, adottando strumenti che le permettono di rispondere rapidamente ai cambiamenti del mercato.  È utile sottolineare, ulteriormente, che le diverse aree di DA vanno intese in senso evolutivo: i benefici tangibili e continuativi si ottengono se esse si sviluppano partendo dal centro (DAD) verso l’esterno (DAE) e non scegliendo solo quello che ci è “comodo”.

Una DAE, in particolare, affronta le sfide di mercato grazie ad una cultura che favorisce il l’apprendimento e l’evoluzione continua, in modo da adattarsi costantemente alle mutevoli esigenze del mercato di riferimento, spesso di tipo VUCA (Volatilità, Incertezza, Complessità e Ambiguità). In questo contesto, DAE si fonda su tre considerazioni primarie:

  • Ogni azienda è un’azienda di software. Tutte le attività produttive moderne sono basate sul software: anche se non si è una software house, senza software non è possibile fare business! Il dipartimento IT non può essere visto come un “centro di costo” da tagliare, emarginare ed esternalizzare, ma deve essere al centro dell’azione aziendale perché tale è il suo compito. Bisogna eccellere nell’IT se si vuole avere un’opportunità di emergere (e sopravvivere) nel proprio settore di riferimento.
  • Nessuno può ritenersi al sicuro. Non esistono più condizioni di monopoli, in nessun settore: da quello bancario a quello delle macchine industriali pesanti. Basta un nuovo competitor innovativo, che rivoluziona l’approccio al mercato o al prodotto, per condannare l’organizzazione all’estinzione. La domanda non è “quando accadrà anche a me”, perché sta già accadendo ora, la questione è decidere se si vuole essere leader o tentare di sopravvivere finché la fine (certa) non arrivi.
  • Le aziende Agili saranno le uniche a sopravvivere. Per rispondere alle sfide moderne, in un mondo complesso, è indispensabile essere adattivi/reattivi/empirici, costruendo la propria visione di agilità. Non esiste un settore dove queste caratteristiche non facciano la differenza, nemmeno uno. 

Nello specifico, quando si arriva a concentrarsi sulle sfide inerenti una DAE, vengono introdotti (come focus) i seguenti process blade:

da dae processblades

DAE Process Blades

ovvero:

  • Business Operations: focalizzato sulle attività necessarie per fornire servizi ai clienti e supportare i prodotti. Tra esse troviamo: l’help desk, i servizi finanziari(bancari e non), le attività di supporto tecnico, ecc. Come è intuibile, nell’ottica di “deliziare” il cliente, è necessaria una stretta collaborazione con le tue attività di vendita e marketing.
  • Control: i team operativi devono collaborare strettamente con le aree finanziarie e legali, in modo da avere consapevolezza delle risorse disponibili e dei vincoli di azione esistenti, mitigando gli ostacoli che si potrebbero incontrare.
  • Finance: la Disciplined Agile Financesi concentra su obiettivi concreti ed essenziali come garantire il flusso di cassaassicurarsi che il budget sia speso adeguatamenterispetto degli obblighi di tassazionetracciamentoe registrazione delle 
  • Legal: lo scopo primario è quello di garantire che l’organizzazione lavori entro il rispetto delle normative vigenti nel territorio in cui opera. Il legal teamlavora, inoltre, alla definizione di “contratti agili” che consentono di estendere l’agilità oltre il perimetro aziendale, in collaborazione con il people management, il marketing, il procurement, ecc. 
  • Marketing: il suo obiettivo è lo sviluppo di interazioni di successo tra l’organizzazione e il mondo esterno. Il marketing si muove “a due vie”: per i clienti, rappresenta l’organizzazione stessa e le sue offerte, per il resto dell’organizzazione, i (potenziali) clienti. In collaborazione con la gestione dei prodotti, il marketing è attivamente coinvolto nella visione a lungo termine delle offerte.
  • Procurement: il suo principale scopo è quello di efficientare il processo di approvvigionamento, aiutando ad ottenere, nei tempi adeguati, prodotti e servizi da organizzazioni terze. A tale scopo, il team relativo collaborerà con altre parti dell’organizzazione per comprendere le esigenze di approvvigionamento, identificare potenziali fornitori in grado di soddisfarle e collaborare con legalper sviluppare contratti adeguati. Da punto di vista organizzativo, il team di approvvigionamento è spesso parte del team legale o comunque strettamente correlato.
  • Sales: il suo obiettivo è tanto ovvio quanto fondamentale, ovvero vendere i prodotti/servizi ai clienti. Gli addetti alle vendite, lavorano a stretto contatto con il team di marketing, per assicurarsi di essere concentrati sulle vendite che riflettono la strategia generale dell’organizzazione, oltre che con l’IT, per garantire che ciò che sta vendendo sia disponibile o possa essere sviluppato rapidamente. Sales, a livello organizzativo, è spesso combinato con il marketing o ad altre aree aziendali.

Come abbiamo visto per le altre aree, anche DAE è interessato da un workflow esplicativo che mette in relazione tra loro i diversi process blade, non solo quelli specifici appena tracciati.

dae workflow

DAE Workflow

DAE espande quindi una filosofia agile a tutte le aree organizzative, anche quelle storicamente più burocratizzate ed ingessate, promuovendo la cultura dell’innovazione continua in relazione alle sfide che il mercato di oggi (e di domani) presenta ad ogni tipo di organizzazione.

Si conclude così il nostro sesto appuntamento dedicato a PMI DA. Nel prossimo approfondimento introdurremo PMI FLEX, il framework “dinamico” che evidenzia come gestire un value stream sfruttando quanto messo a disposizione dal toolkit DA.

Stay tuned J

Agile@School – Anno quinto, ep. 4

Vista l’emergenza in corso, è passato un po’ di tempo dall’ultimo aggiornamento e di cose ne sono successe: poco dopo l’ultima lezione, infatti, il Coronavirus ha iniziato a diffondersi e sono state prese contromisure sempre più restrittive per arginare il fenomeno. Si è arrivati infine al divieto per tutti i cittadini di uscire di casa, a meno di emergenze e necessità lavorative.

[…] un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Da parte nostra, si può dire che abbiamo avuto “fortuna”, sia perché la nostra attività quotidiana (la programmazione) può essere eseguita anche fuori dall’ufficio via telelavoro, sia perché avevamo già predisposto anche prima del virus gli strumenti per metterla in pratica, per cui siamo stati fra i primi ad adottare l’utilizzo dello smart working che ci permette di lavorare da casa. Engage IT Services nasce in telelavoro, da tre persone che non avevano soldi per un ufficio, e oggi, grazie alla filosofia descritta qui, possiamo dire “ragazzi, da lunedì si lavora da casa” senza nessun problema di sorta. Un problema a dire il vero c’è, il caffè insieme, quello ci manca davvero!

Ma cos’è successo nelle scuole? In quella seguita da noi, in particolare, il professore non si è voluto perdere d’animo e, dopo un paio di lezioni sospese per precauzione, ci ha chiesto disponibilità per tenere una delle nostre lezioni in modalità di meeting online con gli studenti: ovviamente abbiamo accettato con entusiasmo, sia perché ci sarebbe dispiaciuto lasciare indietro i ragazzi sugli argomenti che avevamo preparato, sia perché era un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Ed eccoci qui, tutti pronti da casa con Microsoft Teams configurato e avviato in attesa di essere invitati alla “riunione” della classe. SPOILER: la lezione è andata alla grande e ha guadagnato molto dal fatto di essersi svolta online invece che di persona, e nel seguito vedremo il perché.

Partiamo dallo svolgimento della lezione: cominciamo col dire che questa ha avuto un tono molto da “review”; è stato chiesto ai ragazzi, uno per gruppo, di illustrare ciò che avevano fatto in queste settimane (non crediate che se ne siano stati con le mani in mano, anzi) evidenziando principalmente quale fosse stata l’organizzazione del team negli sviluppi. Dopo ogni presentazione, abbiamo quindi riesaminato le board per capire se i nuovi PBI fossero stati inseriti correttamente e abbiamo fornito consigli su come migliorarne la stesura.

intro-view.png (728×310)

Particolare attenzione è stata posta ancora una volta sulla disciplina necessaria ad adottare una serie di processi. Sebbene in un ambiente scolastico essi possano risultare “pesanti”, a lungo termine non possono che incrementare consapevolezza ed efficienza nel modo di lavorare.

Tutto questo è avvenutotramite schermo condiviso e ciò ha permesso una partecipazione forse più diretta rispetto ad una lezione frontale in cui i ragazzi spesso non riescono a condividere quanto implementato o a interagire direttamente su quanto mostra il professore.
Nonostante molti ragazzi non disponessero di un computer e si fossero collegati con smartphone o tablet, l’impressione è stata che la lezione si trasformasse in qualcosa di più personale. Le distanze “fisiche”, già inevitabili in classe e in questo frangente anche più estese, si sono praticamente annullate. E questo ha portato molta più partecipazione.

[…] essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individuo.

<

p class=”has-text-align-justify”>La lezione è terminata con la richiesta di collegare i repository GitHub dei ragazzi alla nostra board Azure, per poter mostrare loro la prossima volta l’integrazione fra i due mondi: abbiamo quindi mostrato la procedura per la creazione dei Personal Access Token, toccando così anche l’argomento sicurezza nella gestione dei repository.

L’aspetto su cui Pier-Paolo insisterà nella prossima lezione è quello della creazione di valore aggiunto ad ogni iterazione: sembra infatti essere presente un po’ di “dispersione” negli sviluppi. Anche il professor Memoli ha richiesto, dal canto suo, che i ragazzi mostrassero qualcosa di funzionante e tangibile per evidenziare tale problematica.

Il primo esperimento si può quindi dire concluso con successo e non vediamo l’ora di proseguire con la prossima lezione per avere conferma delle nostre impressioni! Una cosa che vogliamo sottolineare è che in questo periodo di emergenza, non solo chi sfrutta i nostri servizi cambia. Cambiamo anche noi e questo non fa altro che incrementare la consapevolezza di come essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individio. Questi ragazzi ci hanno dato un insegnamento non piccolo. Si può fare!

Agile@School – Anno quinto, il progetto in remoto

Si sente spesso dire che la scuola non ha tutti gli strumenti per poter fronteggiare formazione in remoto. In generale, il mondo della formazione scolastica è considerato talvolta un po’ arretrato. In realtà, l’istituto che stiamo seguendo, sia con progetti paralleli, sia come alternanza scuola-lavoro è ed è sempre stata all’avanguardia. Forse sono un po’ di parte, visto che si tratta della scuola in cui ho studiato, ma credo che meriti una degna menzione.

Ancor prima che io potessi contattare i professori per tentare il progetto in remoto, ho ricevuto una telefonata dal professor Christian Memoli che, riassumendo, chiedeva: “abbiamo tutto per fare da remoto, abbiamo Teams, abbiamo strumenti di video conferenza, è un problema per la tua azienda? Noi stiamo già facendo didattica a distanza.”. Che cosa posso dire? Prima di tutto, che l’IISS Gadda di Fornovo Taro è pronto, veramente. Poi, nel mondo del lavoro di cui noi informatici siamo parte, non spesso il telelavoro è ben visto, mentre una scuola dimostra un sentimento responsabile e proattivo.

Attenzione, non fraintendetemi, per la nostra azienda, TUTTI e sottolineo TUTTI i clienti e i fornitori hanno condiviso, chiesto e supportato il lavoro da remoto. Però conosco casi in cui, seppure possibile come strada da percorrere, il telelavoro non è ancora ben visto. Per fortuna la nostra realtà aziendale non ha questo tipo di conflitto, anzi! Consapevolezza e responsabilità vanno per la maggiore, unitamente al rispetto per la salute di tutti.

A partire da mercoledì, seguiremo una serie di incontri (purtroppo ancora fino a data da destinarsi) utilizzando Microsoft Teams (strumento già utilizzato dalla scuola regolarmente), connettendosi in Azure DevOps Services e sfruttando GitHub come già indicato nei post precedenti della serie. Il tutto da remoto! Sento che questo progetto, già interessante, non farà altro che diventarlo ancora di più. Dimostreremo le possibilità dell’informatica, terremo comunque i ragazzi interessati e chiuderemo il progetto, senza farci fermare dallo spazio fisico.

Non vedo l’ora, stay tuned!

Agile@School – Anno quinto, ep. 3

Nella seconda lezione abbiamo deciso di iniziare ad affrontare l’integrazione fra Git e Azure DevOps, in particolare per quanto riguarda il collegamento automatico fra i commit/push e i Task. Questa volta, però, abbiamo incontrato non poche difficoltà. I ragazzi, infatti, hanno lavorato su GitHub fino ad oggi, per cui abbiamo ritenuto opportuno effettuare l’importazione dei loro repository sul nostro Azure DevOps, tramite l’apposita funzione integrata.

Agli studenti, comprensibilmente, non erano stati dati permessi sufficienti per effettuare l’importazione in autonomia, per cui un po’ di tempo è andato perso nel far immettere le loro credenziali, uno alla volta. Superato “facilmente” questo primo ostacolo, i repository sono risultati importati con successo e, dopo una prima revisione dei concetti base di source control e del funzionamento di Git, Pier-Paolo ha seguito i ragazzi nell’operazione di cloning con l’ausilio di SmartGit, a cui erano già da tempo abituati.

log-default-coloring-4f58b1c4.png (1596×792)

Si è partiti con i comandi base di Git (checkout, commit, push/pull) intervenendo direttamente sul codice già scritto dai ragazzi, su schermo condiviso, in modo da dimostrare loro le potenzialità dello strumento. Purtroppo, la condivisione su schermo è stata l’unica strada percorribile, anche in questo caso i permessi erano mancanti. Dobbiamo preparare gli ambienti un po’ meglio la prossima volta!

Altra cosa da notare questa volta è che, durante la lezione, abbiamo avuto modo di toccare, seppure superficialmente, questioni di metodologia di sviluppo. Ad esempio abbiamo affrontato le naming convention, modularità e pulizia del codice, leggibilità, e via discorrendo, tutti argomenti che usualmente non vengono trattati nei classici corso di programmazione.

A fronte di tutte queste problematiche introdotte dal tentativo di migrare i progetti su Azure DevOps, è parso evidente che i ragazzi trarranno più benefici continuando ad utilizzare i loro repository su GitHub. Pier-Paolo si è quindi prefissato di sfruttare la funzionalità “GitHub Connections” la prossima volta. La feature di Azure DevOps permette di collegare un repository GitHub ad un progetto interno, permettendo al tempo stesso di sfruttare il meccanismo di associazione fra commit e Task, come descritto qui.

Kanban board shows GitHub links

Stavolta la lezione è stata forse più importante per noi che per i ragazzi e in retrospettiva individuale abbiamo imparato una importante lezione:

L’utilizzo di strumenti già in essere (non ci stancheremo mai di ripeterlo) è fondamentale per non aggiungere ostacoli ad un già difficoltoso percorso di migrazione culturale. Da queste piccole cose, si denota come una consapevolezza dell’ambiente in cui si lavora e dei tool annessi, avvicini tutti al successo del progetto stesso. E questo vale sia nelle aziende, sia nelle scuole.

<

p class=”has-text-align-justify”>La prossima volta tocca al branching e a comandi Git più “avanzati”, come le pull request, e il livello di difficoltà aumenterà notevolmente… Vediamo come sapranno affrontarla!

Agile@School – Anno quinto, ep. 2

Eccoci arrivati alla seconda lezione, cominciamo finalmente a fare sul serio!

La volta scorsa avevamo chiesto ai ragazzi di provare a inserire le user story sulle board dei loro progetti. Ora, le board erano lande desolate… Forse la causa è da attribuire al concetto di user story, che può essere in qualche modo complesso e non facile da “digerire”. Oppure il motivo è da ricercare in una gita in Spagna di mezzo?

Nessun problema, è comprensibile che le user story non siano di immediata comprensione, soprattutto per questi ragazzi che sono chiamati ad essere clienti, PO e sviluppatori nello stesso tempo. Soprattutto un portale con così tante feature, non è semplice da navigare, per cui, armati di pazienza, Pier-Paolo ha ripreso i concetti daccapo e li ha approfonditi con esempi concreti.

Questa volta, invertendo di fatto il modus operandi della lezione precedente, ha provato a dare molta più importanza alla pratica, quindi, insieme ai docenti ha seguito i ragazzi nel data entry sulle board.

I gruppi avevano già compilato a inizio corso un elenco di attività da eseguire per sviluppare i loro software: chi salvato su un foglio Excel condiviso sul cloud, ben formattato (soprattutto i gruppi con ragazze, sempre precise), chi invece su un file di testo, copiato per ogni studente, aggiornato via email (questo invece sarà un buon punto di partenza per una delle prossime lezioni, ndr). I ragazzi sono comunque stati veloci ad apprendere e, dopo un primo approccio, hanno iniziato anche ad appassionarsi. Si è vista la crescente curiosità rivola a come si gestiscono gli item e a come dovrebbero essere compilati. Sta crescendo la loro parte proattiva, nulla di più bello da vedere in una classe.

Per terminare rilassandosi un po’, Pier-Paolo ha insegnato poi il poker!

Non quello vero, naturalmente, anche se uno dei progetti è un Casinò virtuale, ma il planning poker. E qui proprio il gruppo che sviluppa il Casinò (sarà un caso?) ha immediatamente trovato un sito per poterlo fare online collaborativamente, che è stato subito utilizzato anche dagli altri. Prima abbiamo visto la proattività dei ragazzi, ora siamo addirittura arrivati alla crescita di team. Si bruciano le tappe quando si capisce il valore di alcune nostre azioni!

La lezione è passata piuttosto in fretta, del resto quando ci si diverte accade spesso. Chiudiamo qui con un compito “facile facile” per la prossima volta, cioè inserire i task nei PBI. Chissà se saranno così bravi da buttare giù anche le stime? Vista la crescita, siamo ottimisti 😊

Stay tuned, la prossima volta tocca a Git!

PMI Disciplined Agile: Disciplined Agile IT (pt. 5)

In questo nuovo appuntamento dedicato a Disciplined Agile ci focalizzeremo su Disciplined Agile IT (DAIT).

da f1

DAIT fornisce un quadro d’insieme dei processi e delle azioni da implementare per ottenere una efficace integrazione tra le iniziative di business e le derivate azioni intraprese dall’IT, siano esse relative a nuovi prodotti o alla trasformazione di servizi in essere.

da dait workflow

DAIT Workflow

L’obiettivo è quello di consentire una governance chiara e trasparente delle diverse iniziative di un’organizzazione IT, consentendo di misurarne il valore e i benefici ottenuti.

Per raggiungere questo obiettivo, il toolkit introduce i seguenti Process Blade:

  • Continuous Improvement: si occupa di facilitare la condivisione della conoscenza all’interno dell’organizzazione, in modo da supportare il miglioramento continuo in modo sistematico. 
  • Enterprise Architecture: si concentra sulle dinamiche che caratterizzano lo sviluppo e l’evoluzione di una Disciplined Agile Enterprise Architecture (DA EA), ovvero su come rendere le strutture ed i processi aziendali flessibilifacilmente ampliabilifacilmente evolvibili. Il cuore della DA EA è l’esplorazione collaborativa ed evolutiva, realizzata in modo sensibile al contesto grazie alla collaborazione continua tra gli enterprise architecte i team di delivery.

Come gli altri process blade, anche l’Enterprise Architecture ha una fitta rete di relazioni e dipendenze con il resto degli elementi e processi dell’organizzazione.

da ea workflow

Enterprise Architecture Workflow

  • People Management: nota anche come gestione delle risorse umane(HR), gestione dei talenti,gestione del personale, ecc. Ha l’obiettivo fondamentale di gestione il percorso di crescita delle persone, attraendo e trattenendo talenti in grado di creare team fantastici
  • Portfolio Management: affronta il modo in cui un’organizzazione IT identificaassegnaleprioritàorganizza e governa le diverse attività. Discipline Agile Portfolio Management cerca di farlo nel modo più flessibile possibile supportando la creazione di valore sostenibile nel lungo periodo. Le attività IT, in genere, includono:
    • attività di delivery
    • team di sviluppo stabili
    • esperimenti di business (sulla falsariga di Lean Startup)
    • mantenimento efficace delle soluzioni esistent

Il flusso di relazione con gli altri process blade e i diversi aspetti organizzativi è riassunto nella figura seguente, che evidenzia come l’attività di Portfolio Management “attinge” e condivide informazioni con le diverse funzioni al fine di riallinearsi costantemente con lo stato reale delle attività grazie a quella che viene definita Development Intelligence.

da portfolio workflow

 Portfolio Management Workflow

  • Product Management: include le azioni di identificazioneed evoluzionedella Visione Aziendale della propria organizzazione. In sintesi si occupa di: 
    • identificare e dare la priorità ai potenziali prodotti/soluzioni
    • stabilire le priorità e allocare le funzionalità relative ai prodotti in fase di sviluppo
    • gestire le dipendenze funzionali tra prodotti
    • commercializzare i prodotti ai potenziali clienti

DA Product Management si fonda sulla gestione del prodotto in modo collaborativo ed evolutivo, riflettendo costantemente sul contesto organizzativo in essere.

  • (Lean) IT Governance: si occupa di sviluppare l’opportuna leadership, le opportune strutture organizzativesemplificare iprocessi al fine di consentire all’IT di lavorare come partner strategico al fine di massimizzare la capacità dell’organizzazione di produrre continuo valore per i clienti. 
  • Reuse Engineering: si concentra sulla creazione, la gestione, il supportoe la governancedelle risorse riutilizzabili. Il Reuse Engineering è spesso guidato dal team di enterprise architecture, anche se l’approdo più efficace è quello di disporre di un team specifico.

da dait process blades

DAIT Process Blade

Come visibile dal DAIT Workflow, questi process blade sono strettamente legati tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche e in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile. Nello specifico, gli archi relazionali evidenziano gli elementi di congiunzione, i manufatti se si vuole, che i diversi process blade si scambiano per allinearsi sugli aspetti che li condizionano in modo congiunto.

Disciplined Agile IT si occupa, quindi, della sovrastruttura minima indispensabile per garantire una efficace collaborazione e coordinamento tra tutte le anime che supportano la creazione di soluzioni (oltre il prodotto, quindi), pensate per deliziare i propri clienti.

Si conclude così il nostro quinto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile Enterprise.

Stay tuned J

Agile@School – Anno Quinto (2020)

Anche per l’anno 2020 siamo stati coinvolti per continuare il progetto Agile@School, svolto in collaborazione con la scuola I.I.S.S. Gadda di Fornovo. Questa continuità negli anni è sicuramente un buon segno, perché significa che negli scorsi anni il progetto ha dato i suoi frutti e che l’esperienza sul campo acquisita dagli studenti è stata utile.

Ma, per chi ci segue da poco, descriviamo innanzitutto in cosa consiste il progetto Agile@School.
Questo progetto è nato nel 2016 con l’intento di far conoscere agli studenti il cosiddetto modo di lavorare agile, che consiste nell’adozione di tutta una serie di comportamenti e discipline orientate alla collaborazione, al team working e alla condivisione e rielaborazione di informazioni, che stanno trovando sempre più larga diffusione nel campo dello sviluppo software (ma facilmente applicabili anche in altre professioni). La nostra impressione è che negli ambienti educativi si dia ancora troppa importanza all’insegnamento della programmazione pura (indipendentemente dal linguaggio scelto) a scapito di quanto sta “a contorno”, mentre saper programmare e basta è sempre meno sufficiente affinché gli studenti siano più preparati all’ingresso nel mondo del lavoro.

Edizione 2020

Quest’anno abbiamo delle novità: la prima, l’insegnante! A parte infatti la prima lezione che è stata quasi unicamente “conoscitiva”, di presentazione (sia da parte dei ragazzi, sia da parte nostra), in cui siamo stati presenti in due, le prossime lezioni saranno tenute principalmente da Pier-Paolo Mammi, uno dei nostri nuovi colleghi di lavoro, con il quale seguiremo il progetto direttamente “sul campo”.
Altra novità: mentre nelle edizioni passate gli studenti sono stati guidati dall’inizio alla formazione dei team e alla scelta dei progetti, nell’edizione attuale le squadre sono già formate e ognuna ha già portato avanti lo sviluppo software del progetto assegnato (li vedremo nel seguito). Avremo quindi l’occasione di concentrarci maggiormente sulla parte organizzativa del lavoro “a regime” e di mostrare loro le applicazioni dell’agile development, nonché l’utilizzo di strumenti informatici a supporto, che noi stessi utilizziamo nel nostro lavoro.

Il piano d’attacco

I punti principali sui quali insisteremo saranno principalmente tre:
– Team working: strumenti di collaborazione e condivisione, boards;
– Gestione del progetto in modalità agile: cerimonie, utilizzo di AzureDevOps e gestione degli sprint;
– Controllo del codice sorgente: utilizzo di Git e integrazione con AzureDevOps.

Terremo sicuramente delle spiegazioni più teoriche, ma l’ottica sarà quella di far applicare il più possibile i metodi direttamente ai team di studenti, perché è con la pratica (e la perseveranza) che si fissano meglio i concetti. Proveremo inoltre anche ad “aumentare la posta in gioco”, utilizzando in alcuni casi durante le lezioni una terminologia più aziendale che, se da una parte potrà essere poco gradita dai ragazzi, dall’altra li renderà più preparati all’ambiente professionale.

L’impatto

I ragazzi erano inzialmente un po’ timidi, come è lecito aspettarsi quando incontrano qualcuno di nuovo, ma pian piano si sono un po’ sciolti. Abbiamo poi chiesto ai team di presentare brevemente i loro progetti, descrivendone le funzionalità e indagando in particolar modo sulle funzionalità specifiche che prevedono di implementare, a chi è rivolto il software, con quali modalità sviluppano e come si passano codice e documentazione. Questo per avere un’idea di come hanno impostato il loro lavoro, per esempio se avessero già previsto della documentazione condivisa, piuttosto che un sistema di versioning. Diciamo che qui dovremo lavorare con impegno!

I progetti

La classe è stata suddivisa in quattro team, ciascuno composto da 4/5 studenti, di cui uno di questi durante le presentazioni è stato “eletto all’unanimità” come Leader. E qui va un doveroso ringraziamento al professor Christian Memoli, incaricato di seguire la classe, che si fa costante premura di insegnare ai ragazzi i concetti dell’agile development, al di là della pura e semplice programmazione!

Questi sono i progetti scelti dagli studenti, per i quali è già presente una buona base di codice:

Progetto Casinò
Il progetto consiste nella realizzazione di una serie di tipici giochi da Casinò (Black Jack, Roulette, etc.).

Progetto ClasseViva
Gli studenti realizzeranno una versione alternativa e migliorata dell’attuale sistema di gestione delle presenze in aula, integrandolo con notifiche e messaggistica fra professori e genitori.

Progetto CUP
I ragazzi vogliono realizzare un software per la gestione online completa delle prenotazioni delle visite sanitarie.

Progetto TEP
Il software gestirà la prenotazione, l’emissione e la gestione di biglietti per le linee TEP da parte dei cittadini, comprensivo di parte amministrativa per i dipendenti.

Prossimamente

La prima lezione introduttiva al mondo dell’agile si è poi conclusa con l’assegnazione dei compiti a casa ai team. Dopo aver impostato su AzureDevOps un ambiente TFS dedicato al progetto, comprensivo di repository Git per i quattro progetti, abbiamo chiesto ai ragazzi di caricare il loro codice sorgente sul proprio repository e di cominciare a inserire i Product Backlog Items, compilati con le user stories e le attività.
Da qui partiremo nella prossima lezione per espandere i concetti oggi solo accennati, relativi all’utilizzo di AzureDevOps per la gestione delle attività e di Git come sistema di versioning del codice sorgente.

Stay Tuned.

PMI Disciplined Agile: Disciplined Agile DevOps (pt.4)

Continuiamo ad esplorare Disciplined Agile, concentrandoci sul livello immediatamente successivo a Disciplined Agile Delivery, ovvero Disciplined DevOps.

da f1

Disciplined DevOps è la concretizzazione disciplinata del principio della Continuous Delivery, ovvero un efficiente Value Stream in grado di portare continuamente nuovo valore nelle mani degli stakeholder. 

Ma cosa rende DevOps “disciplinato”?

La sintesi la si incontra nella specifica definizione data da DA:

“Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.”

da disciplined devops

Disciplined DevOps

Nella sostanza, non sono solo i Dev e gli Ops chiamati a collaborare per il successo di una iniziativa di business, ma lo è l’intero ecosistema a supporto di essa

Questo aspetto è fondamentale, anche in relazione alla crescente moltiplicazioni di acronimi come: DevSecOps, DevDataOps, DevXXXOps, ecc. Non ha alcun senso inventare nuovi acronimi… tutto deve essere oliato perfettamente, grazie a cultura/pratiche/automazioni adeguate, in modo da ridurre gli sprechi lungo il value stream ed avere un processo di delivery adeguato basato su un deploy efficiente.

Proprio l’efficienza è un aspetto fondamentale: ogni attività, progetto, elemento, deve essere sempre facilmente collegabile ad una specifica iniziativa di business! Se ciò non è possibile, allora bisogna fermarsi e riflettere se ciò che si sta realizzando non sia un “tecnoware”, ovvero un’attività fine a sé stessa.

Nella sostanza, DA suggerisce di estendere gradualmente l’approccio DevOps alle varie funzioni coinvolte, in modo da far maturare progressivamente nel proprio contesto la Cultura necessaria a tale cambiamento.

da disciplined devops evo

Estendere gradualmente DevOps

Sicuramente non sorprende come il primo passo sia quello di abbattere lo “storico” muro tra Dev e Ops, abbattendo i silos comunicativi ed operativi annessi, proprio come suggeriscono le “Three Ways” di DevOps: FlowFeedback & Experimentation and Learning.

Disciplined DevOps individua 5 process blade espliciti, oltre a “inglobare” Disciplined Agile Delivery descritto nel post precedente:

  • IT Operations, fornisce un ecosistema IT affidabile. Si tratta di garantire l’opportuno livello di Quality of Servicesai propri utenti, cosa che può risultare non banale nelle organizzazioni con molti sistemi legaci e alto debito tecnico annesso. 
  • Support, anche Help DeskEnd-User support, si concentra nell’aiutare gli utenti finali a lavorare con le soluzioni realizzate. Idealmente, le soluzioni dovrebbero essere utilizzate senza il bisogno di nessun supporto in merito, ma spesso ciò non accade e il “support” è “l’ultima linea di difesa” per Deliziare i Clienti con i propri sforzi.
  • Security, il relativo focus è quello di attivare le azioni necessarie a proteggere l’organizzazione da minacce informatiche, virtuali o fisiche che siano. Ciò include procedure come la governance della sicurezzae la gestione delle vulnerabilità. Il tutto impatta sulla capacità di ripristino di emergenza e continuità aziendale, e deve essere un aspetto fondamentale della cultura organizzativa.
  • Data Management, la gestione dei dati è “lo sviluppo, l’esecuzione e la supervisione di piani, politiche, programmi e pratiche che controllano, proteggono, forniscono e migliorano il valore dei dati e delle risorse informative” [Data Management Body of Knowledge]. Per raggiungere tale scopo, DA promuove un approccio pragmatico e semplificato alla gestione dei dati che si adatta al resto dei processi IT: ottimizzare l’intero flusso di lavoro, non sub-ottimizzando la strategia di gestione dei dati. Una gestione dei dati, agile e disciplinata, è una gestione evolutiva e collaborativa, grazie a strategie concrete che forniscono i dati giusti al momento giusto alle persone giuste.
  • Release Management, si occupa della gestione dei rilasci, grazie alla pianificazione, il coordinamentoe la verificadella distribuzione (deploy) delle soluzioni in produzione. Il versioning richiede la collaborazione tra Dev e Ops, cosa che l’approccio agile può portare ad essere anche un’unica entità grazie al concetto di “you build it, you run it

da disciplined devops process blade

DevOps Process Blades

Per concretizzare ed attuare i DevOps Process blade, raggiungendo la pienezza di Disciplined DevOps, DA suggerisce una serie di strategie che afferiscono ad essi:

  • General Strategies(Collaborative work, Automated dashboards, ecc)
  • Teaming Strategies(Production hand-off, Warranty period, ecc)
  • Development Strategies(Canary tests, Split tests, ecc)
  • Operations Strategies(Solution monitoring, Standard platforms, ecc)
  • Support (Help Desk) Strategies(Online information, Online discussion forums, ecc)
  • Release Management Strategies (Release windows, Release train, ecc)
  • Data Management Strategies(Data and information guidelines, Quality data sources, ecc)
  • Security Strategies(Build “rugged software, Automated separation of duties, ecc)
  • Enterprise Architecture Strategies(Reuse mindset, Technical-debt mindset, ecc)

Dovrebbe risultare a questo punto evidente come Disciplined DevOps sia un passo fondamentale nella creazione di una organizzazione agile, consentendo di portare efficacemente la soluzione a “casa” degli stakeholder, prediligendo rilasci brevi e feedback costanti.

Si conclude così il nostro quarto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile IT.

 

Stay tuned J