Dimitri favre #noprojects - Modern software development focuses on Teams and...Dimitri Favre
Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Dimitri favre #noprojects - Modern software development focuses on Teams and...Dimitri Favre
Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiClaudio Saurin
Oggi ci troviamo a fronteggiare la velocità e l'imprevedibilità del cambiamento, spesso interagendo in modo non lineare con molti elementi fra loro diversi: questa è la definizione di complessità delle organizzazioni.
In questo contesto, innovare il processo di sviluppo di servizi e prodotti è strategico; si tratta di una innovazione manageriale che è prima di tutto una innovazione culturale.
Per fare questo occorrono nuovi stili di leadership e nuove modalità di gestione dei progetti.
Cercheremo di raccontare il passaggio che sta avvenendo nello stile manageriale in diversi contesti, lontano da noi, in modo eclatante (Toyota, Google, Apple) o vicino a noi, in modo silenzioso (la bella azienda della profonda provincia veneta, Breton).
Il manager deve cambiare, guidando il suo team in modo condiviso e divenendone parte integrante, in un panorama che, pur complesso e frammentato, offre strumenti per essere affrontarlo con più serenità.
Le metodologie Lean di derivazione Toyota e le metodologie Agili elaborate per sostenere lo sviluppo turbolento del software, gli strumenti della community 2.0 ed il classico Gantt di progetto, diventano gli ingredienti che, miscelati in funzione del tipo di organizzazione e del progetto, consentono di gestire con efficacia ed efficienza la complessità dei progetti di oggi.
E' riportato anche un esempio di una applicazione di Hybrid Project Management per la gestione dei cantieri edili, sviluppata in collaborazione con l'architetto Daniela Rinaldi di Verona.
Agile Project Management: Integrare metodologie di progetto tradizionali con ...Codemotion
Negli ultimi anni, anche secondo l'approccio Lean Startup, il modo migliore per rilasciare prodotti - non solo software - è tramite framework Agili. Quando si è agili all'interno di un organizzazione più tradizionale, questo approccio spesso si scontra con le prassi di gestione progetti più tradizionali. Nonostante lo scontro - principalmente filosofico - è in realtà possibile integrare metodologie di progetto tradizionali con quelle agili. Durante il talk, dopo una breve introduzione, saranno presentati dei modelli di ciclo di vita Agile e Tradizionale e la struttura consigliata dei team.
L’utilizzo delle Kanban Board nella gestione dello sviluppo software sta crescendo notevolmente ma molto spesso quando si prova a introdurle nascono molti dubbi e non si è mai certi di come partire.
Come e perché funzionano? Quali concetti ci sono dietro? Come possiamo iniziare ad adottarle senza grossi mal di testa?
In questo workshop risponderemo a queste domande e proveremo insieme a disegnare la nostra prima board.
Lo scopo è quello di fornire concetti chiari e applicabili fin da subito.
Agile e l’arte di semplificare progetti complessiGiulio Roggero
Presented at Standard VS Standard conference. September 23, 2011 - http://www.pmi-nic.org/library.asp?pag=Eventi&ID=390&anno=2011&tit=Standard%20Vs%20Standard:%20dai%20concetti%20alla%20realt%E0%20industriale.%20LE%20ISCRIZIONI%20SONO%20CHIUSE
SCRUM WARS - Manuale di sopravvivenza agile per frontendistiSimone Lelli
Lavorate con Agile/SCRUM ma le cose non vanno proprio così bene come ci aspettavamo? Qualche piccolo consiglio per cercare di migliorare e cacciar via il Lato Oscuro dai nostri SCRUM :)
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
An "unconventional" overview of the roles in an agile project through the metaphor of the characters of "Star Wars", presented during the event "Aperitivi di Project Management " of the PMI Central Italy Chapter on 28 February 2018
Andrea Romoli e Fabrizio Faraco - Business Agility ai tempi dello smartworkin...Stefano Saladino
Nei nostri workshop utilizziamo diverse microstrutture, adatte a sviluppare il lavoro in remote working, in modo che messe in fila si capisca cosa significhi progettare un vero e proprio workshop remoto in funzione di un obiettivo finale di un reale team.In questo workshop affronteremo il tema dello sviluppo della creatività in innovazione, sperimentando dal vivo una tra le microstrutture più celebrate, la Mash-up Innovation di HyperIsland. Mash-up è un metodo di generazione di idee collaborative in cui i partecipanti escogitano concetti innovativi combinando insieme diversi elementi. Mash-up dimostra
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiClaudio Saurin
Oggi ci troviamo a fronteggiare la velocità e l'imprevedibilità del cambiamento, spesso interagendo in modo non lineare con molti elementi fra loro diversi: questa è la definizione di complessità delle organizzazioni.
In questo contesto, innovare il processo di sviluppo di servizi e prodotti è strategico; si tratta di una innovazione manageriale che è prima di tutto una innovazione culturale.
Per fare questo occorrono nuovi stili di leadership e nuove modalità di gestione dei progetti.
Cercheremo di raccontare il passaggio che sta avvenendo nello stile manageriale in diversi contesti, lontano da noi, in modo eclatante (Toyota, Google, Apple) o vicino a noi, in modo silenzioso (la bella azienda della profonda provincia veneta, Breton).
Il manager deve cambiare, guidando il suo team in modo condiviso e divenendone parte integrante, in un panorama che, pur complesso e frammentato, offre strumenti per essere affrontarlo con più serenità.
Le metodologie Lean di derivazione Toyota e le metodologie Agili elaborate per sostenere lo sviluppo turbolento del software, gli strumenti della community 2.0 ed il classico Gantt di progetto, diventano gli ingredienti che, miscelati in funzione del tipo di organizzazione e del progetto, consentono di gestire con efficacia ed efficienza la complessità dei progetti di oggi.
E' riportato anche un esempio di una applicazione di Hybrid Project Management per la gestione dei cantieri edili, sviluppata in collaborazione con l'architetto Daniela Rinaldi di Verona.
Agile Project Management: Integrare metodologie di progetto tradizionali con ...Codemotion
Negli ultimi anni, anche secondo l'approccio Lean Startup, il modo migliore per rilasciare prodotti - non solo software - è tramite framework Agili. Quando si è agili all'interno di un organizzazione più tradizionale, questo approccio spesso si scontra con le prassi di gestione progetti più tradizionali. Nonostante lo scontro - principalmente filosofico - è in realtà possibile integrare metodologie di progetto tradizionali con quelle agili. Durante il talk, dopo una breve introduzione, saranno presentati dei modelli di ciclo di vita Agile e Tradizionale e la struttura consigliata dei team.
L’utilizzo delle Kanban Board nella gestione dello sviluppo software sta crescendo notevolmente ma molto spesso quando si prova a introdurle nascono molti dubbi e non si è mai certi di come partire.
Come e perché funzionano? Quali concetti ci sono dietro? Come possiamo iniziare ad adottarle senza grossi mal di testa?
In questo workshop risponderemo a queste domande e proveremo insieme a disegnare la nostra prima board.
Lo scopo è quello di fornire concetti chiari e applicabili fin da subito.
Agile e l’arte di semplificare progetti complessiGiulio Roggero
Presented at Standard VS Standard conference. September 23, 2011 - http://www.pmi-nic.org/library.asp?pag=Eventi&ID=390&anno=2011&tit=Standard%20Vs%20Standard:%20dai%20concetti%20alla%20realt%E0%20industriale.%20LE%20ISCRIZIONI%20SONO%20CHIUSE
SCRUM WARS - Manuale di sopravvivenza agile per frontendistiSimone Lelli
Lavorate con Agile/SCRUM ma le cose non vanno proprio così bene come ci aspettavamo? Qualche piccolo consiglio per cercare di migliorare e cacciar via il Lato Oscuro dai nostri SCRUM :)
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
An "unconventional" overview of the roles in an agile project through the metaphor of the characters of "Star Wars", presented during the event "Aperitivi di Project Management " of the PMI Central Italy Chapter on 28 February 2018
Andrea Romoli e Fabrizio Faraco - Business Agility ai tempi dello smartworkin...Stefano Saladino
Nei nostri workshop utilizziamo diverse microstrutture, adatte a sviluppare il lavoro in remote working, in modo che messe in fila si capisca cosa significhi progettare un vero e proprio workshop remoto in funzione di un obiettivo finale di un reale team.In questo workshop affronteremo il tema dello sviluppo della creatività in innovazione, sperimentando dal vivo una tra le microstrutture più celebrate, la Mash-up Innovation di HyperIsland. Mash-up è un metodo di generazione di idee collaborative in cui i partecipanti escogitano concetti innovativi combinando insieme diversi elementi. Mash-up dimostra
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Come mantenere la competitività aziendale in tempi di cambiamenti veloci e imprevedibili? È possibile innovare in modo coinvolgente e semplice?
Il design thinking e l’agile sono approcci di management particolarmente efficaci e utili, soprattutto per gestire gruppi di lavoro eterogenei. Approfondimento sulle metodologie e come applicarle nel proprio contesto.
Un approccio pratico, facile da comprendere e da implementare in particolare nei team di lavoro che collaborano anche da remoto.
CONTENUTI:
- Cambiamento e innovazione
- Esperienza del lockdown
- Innovazione: creatività e valore
- Design thinking, lean start- up, agile
Collegandoti al seguente link, potrai visionare l’abstract video del seminario online:
https://youtu.be/_fnBT6Ir-gE
I quattro punti cardinali per un orientamento lean nell'impr... insomma.Jacopo Romei
In un mercato già particolarmente competitivo, se l'acqua è poca, far galleggiare la papera diventa ancora più difficile. Reagire alla siccità economica significa asciugare le infrastrutture, ma soprattutto asciugare il modo di pensare.
Focus sui clienti, potenziale sistemico dell'azienda, flusso di valore e policy sprecone sono i 4 specchi delle nostre brame per stabilire chi sia il più lean del reame.
L’elefante nella stanza! Affrontare le “known issues” tra tecnici e managerCodemotion
by Fabio Mora - Essere developer Agili ma lavorare con il management tradizionale è una sfida: significa evolvere vincolati da distanza tra chi “chi decide” e “chi fa”. Recentemente però ho sperimentato sul campo la creazione di un modello d'azienda diverso. Come? Una kanban con un flow nuovo, processi decisionali adatti all’intelligenza collettiva, un sistema di stima del valore generato ed uno di reputazione interna. Un filone di aziende a governance “liquida” sta crescendo e potrebbe abilitare una delle prossime evoluzioni di Extreme Programming. Affrontare problemi, gap di onwership alla nascita é vitale!
L’elefante nella stanza! [con LiquidO™] - Codemotion 2014Fabio Mora
Essere developer Agili ma lavorare con il management tradizionale è una sfida: significa evolvere vincolati da distanza tra chi “chi decide” e “chi fa”. Recentemente però ho sperimentato sul campo la creazione di un modello d'azienda diverso. Come? Una kanban con un flow nuovo, processi decisionali adatti all’intelligenza collettiva, un sistema di stima del valore generato ed uno di reputazione interna. Un filone di aziende a governance “liquida” sta crescendo e potrebbe abilitare una delle prossime evoluzioni di Extreme Programming. Affrontare problemi, gap di onwership alla nascita é vitale!
Breaking the ice with agile - cinque strade per rompere il ghiaccio e introdu...Pietro Di Bello
La nostra esperienza ha mostrato che esistono alcune pratiche “rompighiaccio” che, con un costo di introduzione relativamente basso, permettono di far prendere coscienza alle persone di alcune problematiche e dinamiche tipiche dei progetti software e che ne minano il successo.
La presa di coscienza di queste problematiche e dinamiche è il primo passo per comprendere e abbracciare valori e principi dei metodi agili.
Le pratiche di cui vorremmo parlare e che definiamo “ice breakers” per quel che riguarda le metodologie agili sono: lavagna, standup meeting, retrospective, build automatica, test automatici di accettazione.
A cascata poi queste pratiche se ne portano dietro altre più difficili da adottare fin da subito, ma più facili da far adottare quando le persone prendono coscienza dei problemi che gli impediscono di lavorare in modo efficace (pair, tecnica del pomodoro, user stories, TDD, CI, simple design, daily journal, etc) e abbracciano i principi dell’agile.
Per ogni pratica “ice breakers”, a partire dalla nostra esperienza, illustreremo il motivo per cui secondo noi sono tali, le dinamiche secondo noi migliori per proporne l’introduzione, anti-pattern e resistenze al cambiamento che abbiamo incontrato e come le abbiamo affrontate.
Abitudini eccellenti in azienda SMAU Bologna 2014Lorenzo Paoli
Spesso ci concentriamo su singoli eventi per spiegare successi e fallimenti di un'azienda. Una campagna marketing disastrosa, oppure una negoziazione andata a buon fine. In realtà a fare la differenza sono le abitudini mentali, emozionali e comportamentali che ogni giorno determinano i risultati dei nostri team e di tutta l'organizzazione.
Ecco come sviluppare abitudini mentali, emozionali e comportamentali di eccellenza in azienda.
Presentato a SMAU Bologna 2014 da Lorenzo Paoli
Motivation and leadership beyond technical skills - andrea regoliAndrea Regoli, PMP
Agile non è un insieme di “strumenti” SW o HW ma l’insieme di linee guida che regolano le interazioni.
Perchè un’azienda sia Agile è necessario che il contesto aziendale sia “sano” e i dipendenti si sentano parte dell’azienda.
Il materiale condiviso è il mix di più studi (leadership, agile, classic management) ed esperienze sul campo uniti in maniera da creare un percorso unico.
Lo speech inizierà presentando alcuni studi e teorie per poi muoversi sull’analisi della motivazione che spinge alcuni dipendenti all’interno di aziende a pradurre col sorriso contrapposti ad altri (in realtà differenti) il cui unico obiettivo è lo stipendio.
Verrà quindi analizzato cosa spinge il singolo per poi spostarsi sulle dinamiche di team..
Infine alcuni consigli per migliorare il contesto lavorativo.
Nonostante l’argomento trattato non sia ne “nuovo” ne “innovativo”, lavorando in azienda di consulenza mi accorgo che ad oggi è ancora sconosciuto/ignorato da moltissime realtà aziendali.
Metodologia Lean - alcune note per gestire una startupPierluigi Casolari
Il metodo Lean offre alcuni spunti importanti per la gestione di una startup, che opera in uno stato di forte e costante incertezza sull'ipotesi di valore
Similar to Cosa ho imparato trasformando software factory? (20)
A selection of short stories where Azure DevOps saved the baconMatteo Emili
Session I held at MK.NET, where I introduced the services of Azure DevOps starting from real-world stories of usage or uncommon scenarios where it proved massively beneficial
The computer says no! Software Quality in the DevOps worldMatteo Emili
This document discusses software quality in the DevOps world. It defines code quality as applying processes and practices to ensure the final outcome matches expectations. It recommends using tools and automation for quality, including version control systems, CI servers, code quality scanners, and security analysis tools. Practices like peer reviews, test-driven development, and secure development lifecycles can also increase quality. Quality can be enabled through features like feature flags, circuit breakers, deployment gates, and deployment patterns.
Strategie di migrazione da Team Foundation Server ad Azure DevOps ServicesMatteo Emili
Sessione dell'evento DevOps@Work 2019 sulla migrazione da Team Foundation Server ad Azure DevOps Services in modo granulare - ossia senza utilizzare il servizio di importazione diretta della collection da parte di Microsoft. Copre Build e Release Definition, Work Item e codice sorgente (Git e TFVC).
This document discusses how PowerShell and Azure DevOps can work together for automation and DevOps practices. PowerShell is a powerful automation tool that can interact with Azure DevOps at many points, like using PowerShell scripts in pipelines to automate tasks. Custom scripts can also be packaged as Azure DevOps tasks. The document demonstrates creating custom tasks and using them in pipelines. It recommends applying CI/CD practices like version control, builds, and artifacts feeds to PowerShell libraries to distribute and manage them.
The document discusses various deployment patterns and strategies for improving deployment processes. It begins by describing "rolling deployments" which maintain service availability by deploying to nodes one at a time. "Blue-green deployments" maintain two identical environments that can be switched between. "Canary deployments" progressively expose new changes to a subset of users first before general release. "Shadow deployments" involve silently deploying non-functional changes before functional ones. The document emphasizes that people and processes are important to deployment success in addition to technology and provides additional non-technical suggestions.
This document discusses improving deployment processes through continuous delivery practices. It begins by introducing the author and their background. It then discusses how deployments are often taken for granted or seen as difficult to change. The document outlines several deployment patterns like rolling deployments, blue-green deployments, canary deployments and shadow deployments that can be used to reduce downtime and improve deployment processes. It emphasizes the importance of automation, packaging, and treating the deployment pipeline as critical infrastructure. The document concludes by discussing additional non-technical considerations like access control, keeping production separate, and parameterizing settings.
Containers jumpstart from a DevOps perspectiveMatteo Emili
Containers provide a packaging technology that allows for nimbler, more predictable deployments through packaging applications and their dependencies. This allows for transparent scalability, fewer constraints, and better collaboration between development and operations teams. Containers can be used for both new and legacy applications through containerization tools like Docker and orchestration tools like Kubernetes, which manage container deployments across infrastructure.
Far scalare la Continuous Delivery per il middle managementMatteo Emili
Sessione tenuta a DevOpsHeroes 2017 su approcci per rendere Continuous Delivery praticabile in modo trasversale all'azienda, con attenzione particolare al middle management.
The document discusses development and QA dilemmas in DevOps. It notes that traditionally development was done separately from testing and production environments, but with DevOps there is a focus on continuous delivery through automated pipelines. It acknowledges this is a big change that makes some developers and testers uncomfortable by removing safety nets. It emphasizes that DevOps is about culture and practices, not specific technologies, and that these practices can be used on-premises. It provides examples of how to handle database schema changes and feature rollouts transparently in production. It stresses measuring outcomes through metrics and analytics to learn from users and improve products iteratively.
Tools and practices to use in a Continuous Delivery pipelineMatteo Emili
Continuous delivery pipelines allow developers to automatically compile, test, and store code in an artifact repository. This provides a reliable system that saves development teams time. The document discusses tools and practices for continuous delivery pipelines including infrastructure as code, code quality analysis, and telemetry. It also covers concepts like feature flags, silent deployments, and using analytics to gain insights from telemetry data to improve applications proactively.
Packages as the first choice when deploying - how?Matteo Emili
The document discusses using packages as the primary method for deploying applications and tools. It notes that developers already use packages through tools like NuGet, npm, and ProGet/Artifactory/MyGet. With a continuous integration server, developers can build their own packages. Packages can be used to deploy both tools/libraries and applications, though different packaging technologies may be better suited depending on the intended use and environment. The document demonstrates creating deployment packages and notes that semantic versioning helps avoid dependency issues.
4. CHI SONO?
• Systems Engineering Advisor @ One Identity
• Microsoft MVP – Developer Technologies
• Professional Scrum Master 1
• Microsoft Certified Technology Specialist: Team Foundation Server
• Technology enthusiast
7. QUINDI, CHI SONO?
• Persona con tanti (troppi?) interessi
• Apprendo velocemente ed ho sempre
interesse in qualcosa di nuovo
• A chi interessa: in casa rack 12U con homelab
rispettabile
• Nella community tecnologica da…tempo
immemore
• Iniziato a bloggare a 17 anni, presentare
ad eventi tecnici a 19, poi Microsoft MVP
• I miei interessi principali nel mondo tech:
architettura, ALM, qualitá
• Parlato di DevOps sullo stack Microsoft
(WinOps?) per la prima volta nel 2012
8. PROFESSIONALMENTE?
• Sviluppatore e smanettone autodidatta
• Primo contratto come sviluppatore
durante le scuole superiori (tre
pomeriggi a settimana)
• Il codice era ‘interessante’ per me, ma
scriverlo bene e portare valore non
tecnologico mi interessava di piú
• Ovunque sia stato il mio nome é sempre
stato associato a TFS, ALM, etc.
• Sono stato esposto a diversi tipi di
industria
10. A CHI NON PIACCIONO I
PATTERN?
• L’idea é nata parlando con Giulio Vian ed
altri membri della community
GetLatestVersion.it
• Ci chiediamo regolarmente ‘come risolvo
questo?’ oppure ‘quali benefici mi
apporta quest’altro?’ con problemi che
spaziano dal business al dettaglio
tecnologico
• Nonostante ognuno di noi dia risposte
differenti, nel tempo ho realizzato che ci
sono pattern di situazioni e di reazioni
tipiche specialmente nei progetti di
trasformazione
• Ho iniziato a scavare nel mondo della
psicologia, ed ho aperto il vaso di
Pandora!
11. DEFINISCI
TRASFORMAZIONE!
Una trasformazione ‘legacy to modern’ puó
essere…
• Virtualizzazione o containerizzazione
• Da Waterfall a Scrum/Lean/…
• Zip a Version Control System
• Excel verso Jira
• Dai deploy manuali nel weekend verso la
Continuous Delivery
• Consolidare gli stack ALM/DevOps
• Practice establishment
• Monoliti a microservice
• …
19. PERCHÉ? IL CASO IN
OGGETTO: L’ESSERE UMANO
Non promette bene…
• Paura del cambiamento
• Innato istinto ad evitare il rischio
• Valuta la conoscenza tribale come
importante
• Esperienze soggettive vs esperienze
oggettive
• Credenze irrazionali
• Soffre la pressione di gruppo o di
prestazione
• …
Un profilo psicologico
24. CONSOLIDAZIONE DELLO
STACK ALM AZIENDALE
L’azienda ABC decide di consolidare gli
stack di ALM a livello aziendale con una
soluzione di un singolo vendor, unificando
anni (decadi?) di proprietá intellettuale
nello stesso posto
É un enorme sforzo aziendale che
migliorerá massicciamente come il
software é sviluppato internamente e
permetterá maggiore apertura
Scenario #1
25. UN ESEMPIO PRATICO
• Atlassian Suite+Trello+Excel+Custom &
SVC+CVS+Git+SourceSafe
• Tutto spostato e consolidato su
TFS o Azure DevOps
• É un cambiamento *enorme*
• C’é un livello importante di investimento
richiesto
26. COSA SUCCEDERÁ?
• La gente inizierá a lamentarsi
• Alcuni gruppi/dipartimenti faranno seria
resistenza
• Alcune persone si lamenteranno dicendo
‘Non riesco ad essere produttivo! Tutto é
stato spostato! Non trovo piú nulla!’
• Qualcuno potrebbe rendere la vita molto
difficile
• Ho anche visto esempi di sabotaggio
negli anni…
27. COSA PROBABILMENTE
SUCCEDERÁ?
• L’iniziale resistenza é molto debole o
passiva
• Di solito é fomentata da ‘capi tribú’
• Le persone tendono a seguire ció che
conosce, per istinto innato (‘se
funziona…’)
• Altrettanto importante: cambiamento
significa ripartire, azzerare e ricominciare
• Non siamo abituati a farlo!
28. COSA POTREBBE
ACCADERE?
• Sana competizione interna
• Farsi avanti per supportare l’iniziativa
• Collaborazione fra gruppi per creare
asset riciclabili ed effettuare knowledge
sharing
• Completare il progetto prima possible
per tornare alle normali attivitá il prima
possibile
30. COSA HO IMPARATO
• Fare leva sui risultati tangibili e materiali
• La tempistica giusta fa la differenza, ma
affrettarsi non paga
• La percezione incrementale é essenziale
• Riciclare la conoscenza pre-esistente
permette di raggiungere anche il piú
ostile
• I ritardi sono normali, succedono,
nessuno dará problemi se la percezione
incrementale é forte
33. PERCHÉ É COSÍ
IMPORTANTE?
• Approcci iterative ed incrementali sono
quelli che giocano sulla motivazione
dell’individuo
• Tempistiche ridotte ed un flusso
continuo di prodotti finite fanno sentire il
team in controllo
• É un circolo vizioso positive: il team é
sicuro di se e prende delle decisioni
basate sul proprio ritmo ed esperienza
• Questo é un caso in cui si puó far leva
sulla conoscenza tribale a proprio
vantaggio – un team che si autogestisce
é sicuramente piú produttivo di uno
gestito dall’alto
• É inoltre l’unico modo per confutare la
legge di Parkinson!
39. NEL TEMPO IL VALORE PRODOTTO DA
UN TEAM ‘SEMPRE IMPEGNATO’ CALA
40. DAVVERO?
• Se il team é effettivamente sovraccarico
la qualitá del consegnato sará bassa
• Ci saranno sempre piú bug ed il debito
tecnico andrá alle stelle
• Se il team ha capacitá libera (ma sta
aderendo alla legge di Parkinson) inizierá
a focalizzarsi sui dettagli piú futili
• Il consegnato sará sempre piú ridotto e
ci sará una grossa enfasi sui piccolissimi
cambiamenti implementati
In both cases, value is low
41. WATERFALL TO AGILE
Azienda XYZ decide di saltare sul treno di
Agile, eliminare il suo inefficiente processo
basato su Waterfall ed abbracciare l’Agile
É una iniziativa guidata dall’alto, dove il
management vuole recuperare il distacco
dai temi trendy del mercato ed impedire
che l’azienda rimanga perennemente
dietro ai concorrenti
Scenario #2
45. COME FARLO
FUNZIONARE?
• Un training veloce ed informale é
sufficiente per far partire l’adozione di
Scrum
• Scum é perfetto per questo: stravolge le
tempistiche ma ha un iter molto definito
• Essendo imposto, non c’é bisogno di
comparazioni a questo momento
• Prendi una porzione del prodotto ed
inizia ad implementare un backlog
• Lo sforzo collaborativo rende il
passaggio da pianifcazione a delivery
abbastanza semplice
• Scrum é solo l’inizio. Lean? Scrum?
Scrumbut? L’evoluzione dipende dal
team
46. MAGIA?
• La morale del team é fondamentale
• Lo sviluppo di un software é uno sforzo
di gruppo
• Le persone dovrebbero sentirsi motivate,
non depresse perché il management ha
avuto un altro cambio di umore
• Le metodologie agili mettono tutti sullo
stesso livello, quindi le contribuzioni
individuali hanno grande peso
• La difficoltá di decidere come procedure
é rimossa – in questo caso puó essere
positivo
• I miglioramenti possono essere portati
avanti basandosi su esperienze tangibili
48. LA TEMPESTA PERFETA
• Immaginiamo una situazione dove una
azienda vuole investire in telemetria (sia
reattiva che proattiva)
• C’é un numero X di persone nel ‘Team
della Telemetria’
• Il management crede che sará davvero
efficace: una combinazione di decisioni
basate sui dati ed intelligenza artificiale
che fará spendere in modo migliore il
tempo e le risorse allocate a R&D
• Cosa *realmente* potrebbe accadere?
Scenario #3
(fittizio)
50. MENO É DI PIÚ
• Distorsione cognitiva dove persone di
bassa abilitá hanno una illusoria
superioritá e giudicano erroneamente le
proprie capacitá come superiori di quello
che sono
• Inoltre persone di elevate abilitá
assumono incorrettamente che attivitá
per loro facili siano ugualmente facili per
altre persone
Source: Wikipedia
51. MENO É DI PIÚ
• Esempi comuni si trovano in persone
appena uscite da scuola/universitá, ma
chiunque puó esserne affetto
• É sorprendentemente comune in una
categoria di sviluppatori: quelli che
hanno lavorato per un lungo periodo di
tempo con tecnologia legacy e sono
improvvisamente introdotti in un
ambiente completamente nuovo
• La soluzione é relativamente facile:
abbinare una persona in fase di on-
boarding o mentoring interno quando
richiesto
• Normalmente é un buon segno, di una
persona motivate a migliorare dopo aver
perso la sua illusoria superioritá
53. PIÚ SAI, PEGGIO É
• Pattern psicologico dove l’individuo
dubita dei propri risultati ed ha una
paura interna di essere ‘scoperto’
• Evidenze di risultati tangibili vengono
scartate o minimizzzate come ‘fortuna’,
‘posto giusto al momento giusto’,
‘tempismo perfetto’
Source: Wikipedia
54. PIÚ SAI, PEGGIO É
• Estremamente comune negli sviluppatori
ad altissimo potenziale ed individui di
successo
• La ragione dietro a questo
comportamento é che gli standard
personali di questi soggetti sono molto
piú alti di quelli aziendali
• Review peer-to-peer non fanno che
peggiorare la situazione
• I media non aiutano quando parlano di
tecnologia
• É molto pericolosa perché puó
facilmente portare al burnout
(esaurimento)
55. PIÚ SAI, PEGGIO É
• Affrontare questa sindrome come
cambiamento non é facile
• Nessuno mai dirá ‘credo che non dovrei
essere qui’
• Il modo migliore di approcciare il
problema é di sfruttare canali di
feedback interni (standup meeting?)
• Le persone si sentiranno motivate e
spronate a contribuire, portando ad una
migliore consapevolezza
• Sfortunatamente non é un processo
semplice
57. I AM ONLY HUMAN, AFTER
ALL…
• Le persone sono naturalmente
polarizzate intorno o contro l’elemento
alpha del team
• L’analisi della telemetria é un caso da
rendere il piú automatizzato possible
(ecco uno dei motivi della crescita
esponenziale della telemetria proattiva)
• Essendo il processo guidato dai dati,
mescolare una delle ‘sindromi’
precedenti con un element alpha
significa che il risultato del lavoro del
‘Team della Telemetria’ sará
naturalmente parziale
• Non si puó evitare, fa parte dell’indole
umana – si puó solo mitigare
59. I AM ONLY HUMAN, AFTER
ALL…DI NUOVO!
• Due esseri umani che condividono la
stessa attivitá ripetitiva saranno
sicuramente in competizione
• Proporzionalmente al livello di
competizione (specialmente se sono
coinvolti degli incentivi) il numero di falsi
positive aumenterá
• Oppure il contrario – se ci sono dei
fattori negativi nella valutazione il livello
di segnalazioni sará piú basso dell’atteso
• Mai, mai, mai introdurre competizione in
un team!
62. UNA SITUAZIONE BINARIA
• La tecnologia é dominata da due tipi di
persone: chi capisce cosa non gestisce e
chi gestisce cosa non capisce
• Nel tempo ogni gerarchia tecnica verrá
invertita dalla competenza
Source: Wikipedia
63. UNA SITUAZIONE BINARIA
• Tantissime persone non vogliono essere
promosse a ruoli di ‘management’
• Dall’altro lato, ci sono persone che sono
nella media in ruoli tecnici ma hanno un
ottimo senso del business o di gestione
delle relazioni personali
• É il dovere di una buona azienda
identifcare queste persone e farle
esprimere al meglio
• L’azienda puó solo guadagnare da
questo approccio, facendo leva sulle
migliori competenze delle proprie
persone ed avendo un team
estremamente motivato
Source: Wikipedia
65. INCOMPETENZA?!
• Una persona che é competente nel
proprio lavoro avrá una promozione ad
un livello superiore che richiederá
competenze diverse
• Se la persona promossa manca di queste
competenze avrá un nuovo livello di
incompetenza, e non sará promossa di
nuovo
• Ma se la persona é ancora competente
nel nuovo ruolo sará promossa ancora, e
continuerá ad esserlo finché non
raggiungerá un livello in cui sará
incompetente
• Essendo incompetente, questa persona
non verrá piú promossa e rimarrá
bloccata allo stesso livello fino alla fine
della sua carriera
Source: Wikipedia
66. SUONA FAMILIARE?
• Sembra vada a braccetto con la politica
aziendale
• Molto comune in aziende con grandi
strutture rigide (livelli, gradi, etc)
• Al momento non esiste soluzione – se
non molta attenzione!
Source: Wikipedia