C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
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.
My 'Phoenix Project'—One Developer's Evolutionary JourneyBurr Sutter
What do Gene Kim and his apparent doppelgänger Burr Sutter have in common beyond strikingly similar goatees? DevOps. Building on Kim's iconic tech novel 'The Phoenix Project,' this lightning talk for All Things Open (with opensource.com) highlights Sutter's own 'Phoenix Project' DevOps experience earlier in his career. "We quickly understood that the only way out was forward—together—devs, ops, DBAs, and our business people—the whole team. We hero'ed up, worked in a fundamentally new way, and succeeded at the the impossible." Follow Burr on Twitter @BurrSutter
C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
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.
My 'Phoenix Project'—One Developer's Evolutionary JourneyBurr Sutter
What do Gene Kim and his apparent doppelgänger Burr Sutter have in common beyond strikingly similar goatees? DevOps. Building on Kim's iconic tech novel 'The Phoenix Project,' this lightning talk for All Things Open (with opensource.com) highlights Sutter's own 'Phoenix Project' DevOps experience earlier in his career. "We quickly understood that the only way out was forward—together—devs, ops, DBAs, and our business people—the whole team. We hero'ed up, worked in a fundamentally new way, and succeeded at the the impossible." Follow Burr on Twitter @BurrSutter
Seo horror stories - ConvegnoGT 2013 - Andrea ScarpettaAndrea Scarpetta
La seo è morta ? La seo è inutile ? In questa presentazione realizzata per il convegnoGT 2013 evidenzio alcuni casi reali in cui uno degli aspetti della Seo più ignorati è invece causa di problemi senza fine. Sto parlando del "supporto seo" che assieme ai a intelligence e strategia, compongono una campagna di search marketing di successo.
L’arte di massimizzare la quantità di lavoro non svoltoextrategy
L’arte di massimizzare il lavoro non svolto è uno dei 12 principi alla base del manifesto agile e spinge i team ad abbracciare l’idea di lavorare su una serie di attività condivise, capaci di portare realmente valore al progetto. La sua applicazione tocca i contesti operativi come quelli tattici e manageriali perchè lavora sulla complessità delle relazioni che intercorrono tra gli attori di un progetto e il processo che abilita la sua realizzazione.
Ma che significa realmente? e come possiamo applicarlo concretamente nei nostri progetti?
“Semplicità” è un concetto estremamente generico e fraintendibile, cosa significa per un progetto software?.
“Massimizzare la quantità di lavoro non svolto”: quindi lavorare meno! Bel proposito ma come si rapporta con il primo principio: “La nostra massima priorità è soddisfare il cliente rilasciando software di valore…”
Nella mia esperienza, spesso questo principio viene sottovalutato o peggio ignorato perché non viene capito fino in fondo e soprattuto non banale rapportarlo con il lavoro di tutti i giorni.
Nel talk farò un viaggio attraverso la gestione di un progetto software secondo le metodologie agili evidenziando quando e come i due principi (massimizzare il lavoro non svolto e la massima priorità è soddisfare il cliente) ci sono di aiuto e da guida per la gestione dei nostri progetti, facendo esempio concreti di come nella mi a esperienza li ho applicati o li ho visti applicare
L'arte di massimizzare la quantità di lavoro non svoltoextrategy
L’arte di massimizzare il lavoro non svolto è uno dei principi del Manifesto Agile che spinge a lavorare su attività che portino valore al progetto. Si può applicare a contesti operativi e manageriali lavorando sulla complessità delle relazioni tra gli attori di un progetto e il processo di realizzazione.
Come si rapporta con il principio: “La nostra massima priorità è soddisfare il cliente rilasciando software di valore”?
Come farsi capire dagli Informatici (Smau Roma 2013)Walter Vannini
Chiunque abbia a che fare con personale informatico (dipendente o fornitore) conosce la difficoltà di farsi capire e di ottenere risultati conformi alle aspettative o (apriti cielo!) agli obiettivi di business.
Questo non deve però demoralizzare perché farsi capire dagli informatici è possibile e perfino facile, una volta scoperti i meccanismi.
Nel seminario, con uno stile leggero, rigoroso e ricco di casi concreti vengono illustrati:
•i preconcetti dell’informatico verso il cliente –e come smontarli
•come ottenere trasparenza e responsabilità
•come valutare il contributo dell’informatica all’azienda.
Cicerus - una piattaforma per lo sviluppo di chatbotPaolo Montrasio
di Alessandro Re, dgsgroup.it Un framework che permette di creare chatbot con una interfaccia grafica, riducendo il codice alle parti relative ai processi di business. Si può definire il flusso della conversazione ed avere un fallback umano.
Presentato a Milano Chatbots il 14 dicembre https://www.meetup.com/Milano-Chatbots-Meetup/events/245463095/
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.
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!
In Visual Studio 2010 è apparso un nuovo linguaggio: F#. Volete sapere cos'è, da dove nasce e come si scrive in F# ? Ve lo spiegherà il nostro illustre socio Marco Parenzan, che non dimenticherà di illustrarvi perchè in tanti stanno iniziando ad apprezzarlo ancor più del C#... il che è tutto dire!
Una unità didattica introduttiva sui metodi di PM "di frontiera", all'epoca innovativa (Anni '90), ora forse un po' vintage... E' stata proposta in numerosi corsi di Project Management presso grandi e piccole aziende, istituzioni, pubbliche amministrazioni e centri di ricerca. A distanza di molti anni sto iniziando a rielaborarla, alla luce di tante recenti esperienze di lavoro e ricerca, anche rispetto al nuovo contesto delle "metodologie agili".
Il futuro è dato: Data Science e Network Science e l'azienda del XXI secolo (...Walter Vannini
Alcune Aziende hanno già compreso che la propria sopravvivenza dipende solo dalla quantità e qualità dei propri asset intangibili. Ma poche sono disposte a trarne la conseguenza che siano i dati a fornire la migliore prospettiva sul da farsi e la migliore qualità delle decisioni direzionali. Invece, il management by numbers è una rivoluzione silenziosa dietro a molti dei maggiori successi commerciali più recenti, da Google e Apple alle piattaforme social alle aziende di produzione. Scopriamo come l’azienda può liberarsi da una visione superata e ridisegnarsi attorno ai propri dati per ottenere più velocità nel rispondere alle richieste del mercato del XXI secolo e più profitti.
Seo horror stories - ConvegnoGT 2013 - Andrea ScarpettaAndrea Scarpetta
La seo è morta ? La seo è inutile ? In questa presentazione realizzata per il convegnoGT 2013 evidenzio alcuni casi reali in cui uno degli aspetti della Seo più ignorati è invece causa di problemi senza fine. Sto parlando del "supporto seo" che assieme ai a intelligence e strategia, compongono una campagna di search marketing di successo.
L’arte di massimizzare la quantità di lavoro non svoltoextrategy
L’arte di massimizzare il lavoro non svolto è uno dei 12 principi alla base del manifesto agile e spinge i team ad abbracciare l’idea di lavorare su una serie di attività condivise, capaci di portare realmente valore al progetto. La sua applicazione tocca i contesti operativi come quelli tattici e manageriali perchè lavora sulla complessità delle relazioni che intercorrono tra gli attori di un progetto e il processo che abilita la sua realizzazione.
Ma che significa realmente? e come possiamo applicarlo concretamente nei nostri progetti?
“Semplicità” è un concetto estremamente generico e fraintendibile, cosa significa per un progetto software?.
“Massimizzare la quantità di lavoro non svolto”: quindi lavorare meno! Bel proposito ma come si rapporta con il primo principio: “La nostra massima priorità è soddisfare il cliente rilasciando software di valore…”
Nella mia esperienza, spesso questo principio viene sottovalutato o peggio ignorato perché non viene capito fino in fondo e soprattuto non banale rapportarlo con il lavoro di tutti i giorni.
Nel talk farò un viaggio attraverso la gestione di un progetto software secondo le metodologie agili evidenziando quando e come i due principi (massimizzare il lavoro non svolto e la massima priorità è soddisfare il cliente) ci sono di aiuto e da guida per la gestione dei nostri progetti, facendo esempio concreti di come nella mi a esperienza li ho applicati o li ho visti applicare
L'arte di massimizzare la quantità di lavoro non svoltoextrategy
L’arte di massimizzare il lavoro non svolto è uno dei principi del Manifesto Agile che spinge a lavorare su attività che portino valore al progetto. Si può applicare a contesti operativi e manageriali lavorando sulla complessità delle relazioni tra gli attori di un progetto e il processo di realizzazione.
Come si rapporta con il principio: “La nostra massima priorità è soddisfare il cliente rilasciando software di valore”?
Come farsi capire dagli Informatici (Smau Roma 2013)Walter Vannini
Chiunque abbia a che fare con personale informatico (dipendente o fornitore) conosce la difficoltà di farsi capire e di ottenere risultati conformi alle aspettative o (apriti cielo!) agli obiettivi di business.
Questo non deve però demoralizzare perché farsi capire dagli informatici è possibile e perfino facile, una volta scoperti i meccanismi.
Nel seminario, con uno stile leggero, rigoroso e ricco di casi concreti vengono illustrati:
•i preconcetti dell’informatico verso il cliente –e come smontarli
•come ottenere trasparenza e responsabilità
•come valutare il contributo dell’informatica all’azienda.
Cicerus - una piattaforma per lo sviluppo di chatbotPaolo Montrasio
di Alessandro Re, dgsgroup.it Un framework che permette di creare chatbot con una interfaccia grafica, riducendo il codice alle parti relative ai processi di business. Si può definire il flusso della conversazione ed avere un fallback umano.
Presentato a Milano Chatbots il 14 dicembre https://www.meetup.com/Milano-Chatbots-Meetup/events/245463095/
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.
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!
In Visual Studio 2010 è apparso un nuovo linguaggio: F#. Volete sapere cos'è, da dove nasce e come si scrive in F# ? Ve lo spiegherà il nostro illustre socio Marco Parenzan, che non dimenticherà di illustrarvi perchè in tanti stanno iniziando ad apprezzarlo ancor più del C#... il che è tutto dire!
Una unità didattica introduttiva sui metodi di PM "di frontiera", all'epoca innovativa (Anni '90), ora forse un po' vintage... E' stata proposta in numerosi corsi di Project Management presso grandi e piccole aziende, istituzioni, pubbliche amministrazioni e centri di ricerca. A distanza di molti anni sto iniziando a rielaborarla, alla luce di tante recenti esperienze di lavoro e ricerca, anche rispetto al nuovo contesto delle "metodologie agili".
Il futuro è dato: Data Science e Network Science e l'azienda del XXI secolo (...Walter Vannini
Alcune Aziende hanno già compreso che la propria sopravvivenza dipende solo dalla quantità e qualità dei propri asset intangibili. Ma poche sono disposte a trarne la conseguenza che siano i dati a fornire la migliore prospettiva sul da farsi e la migliore qualità delle decisioni direzionali. Invece, il management by numbers è una rivoluzione silenziosa dietro a molti dei maggiori successi commerciali più recenti, da Google e Apple alle piattaforme social alle aziende di produzione. Scopriamo come l’azienda può liberarsi da una visione superata e ridisegnarsi attorno ai propri dati per ottenere più velocità nel rispondere alle richieste del mercato del XXI secolo e più profitti.
An overview about Continuous Delivery. What is it? Why should you care about it? See how your team can implement Continuous Delivery in order to deliver business value in a sustainable yet efficient way.
Il fatto che rilasci continui e frequenti portino estremo valore è un fatto noto a tutti, ma spesso averne coscienza non è sufficiente per iniziare un percorso di cambiamento. Servono investimenti, formativi e tecnologici, che vanno motivati anche economicamente.
Nel mio talk vi parlerò di casi reali in cui abbiamo costruito una soluzione pratica, basata su alcune metriche del Lean, che permette di rispondere alla domanda:
“Come posso valutare il ritorno dell’investimento di questo cambiamento?”
Talk presentato all'Italian Agile Days 2016 https://vimeo.com/197750655
How do you handle renaming of a resource in RESTful wayXPeppers
In this presentation we are going to investigate the issue regarding the move or rename of an existing resource in RESTful. Have you ever encountered this problem? How did you handled it? Let's talk about it.
La tecnica del pomodoro - Come viene adottata in XPeppersXPeppers
Vi raccontiamo come in XPeppers siamo abituati a usare la tecnica del pomodoro. Quali sono i benefici e i consigli che raccomandiamo a chi si avvicina per la prima volta.
Collective code ownership in Extreme ProgrammingXPeppers
What can we do to improve communication and knowledge sharing in an Agile team? Collective Code Ownership is one of the most important rules in Extreme Programming: every member of the team is responsible for the architecture.
In this talk we'll explore the connection between CCO and the other XP rules, and we'll see some techniques that can help us in following this good practice.
Most of the times Agile is described as a set of practices. In this presentation I will give a different point of view of Agile, where practices are just a means to build an effective working culture.
An amazing opportunity for all the coders to improve their TDD skills in a safe and thrilling environment. Our lab is a 3 hours intensive practice event, focusing on the practice of TDD, essential for software development and design, away from the pressures of ‘getting things done’.
Many IT operations teams are used to managing infrastructure manually or with simple one-off scripts. This manual work and lack of verifiable behavior results in many issues and in uncertainty. In software development, Test Driven Development (TDD) is well recognized for improving design, increasing code quality, and allowing refactoring and better knowledge sharing.
Similar benefits can be gained in infrastructure projects when infrastructure is treated as code, driving that code development with tests. Configuration management tools such as Chef and Puppet allow infrastructure to be easily described as code and provide a complete support to introduce and run tests. This can allow development and operations teams to collaborate and confidently deliver working infrastructure code.
Pensate ad un’azienda fortemente gearchica, command & control, con procedure da seguire tassativamente.
Fatto? Se rispondete “una Banca” avete indovinato.
Come si fa a introdurre l’Agile in una cultura così diversa rispetto ai valori agili?
Vogliamo raccontarvi la nostra esperienza nel condurre l’introduzione dell’Agile in una delle più importanti banche italiane.
Vi racconteremo i successi, gli ostacoli, i fallimenti, le cose che abbiamo imparato, a quali compromessi siamo scesi, e cosa rimane da fare per uscire dalla fase pilota e estendere l’adozione nel 2016.
Hiring Great People: how we improved our recruiting process to build and grow...XPeppers
Check for open positions in XPeppers and send us your cv http://bit.ly/1Y1rClm
Getting the right people will help create a great team, and will let it grow healthy. Moreover, it will keep it rooted in your company culture, and sustaining that same culture in turn.
Nevertheless, too often recruiting is overlooked or completely delegated to HR or external recruiting agencies.
We share our experience in building our actual recruitment process, how we got to this recruitment workflow, what lessons we’ve learned and what are the key elements of a recruitment process. We also examine some differences compared to a more “traditional” way of selecting and assessing people.
An example of Continuous Delivery in Java presented at Italian Agile Days 2015. How you can improve your Continuous Delivery pipeline using an iterative and incremental approch
La passione non è sufficiente e il talento è sopravvalutato.
La vera differenza tra chi eccelle in una disciplina e tutti gli altri
è la pratica.
I risultati ottenuti facendo pratica sono funzione non solo della
quantità di tempo investito ma anche della qualità della pratica
stessa, è quindi importante un approccio strutturato.
Partendo dagli studi del Dr. K. Anders Ericsson sulla pratica
deliberata vedremo una carrellata delle tecniche che ci permettono di
migliorare nella programmazione e nell’applicazione dei metodi agili.
Gestire l’infrastruttura come se fosse codice, ha degli indubbi vantaggi, soprattutto in un team agile che ha più esperienze Dev piuttosto che Ops.
In questa sessione vi racconteremo la nostra esperienza, problemi, vantaggi e cosa abbiamo imparato.
Lo unified tooling è l’area di interesse DevOps che fonde pratiche di software development a quelle di system administration, con lo scopo di semplificare il processo di deployment di ambienti complessi. In questo talk vengono esposte le esperienze di un team di dev che è riuscito a gestire e replicare ambienti complessi, ricorrendo a strumenti e pratiche delle metodologie agili. Saranno evidenziati i vantaggi ottenuti e le problematiche riscontrate.
2. The Phoenix Project
L’idea del Romanzo
● Descrive i problemi dell’IT e i
cambiamenti necessari per migliorare
la situazione
● Mostra gli step per il successo con le
pratiche che oggi rientrano nel
“DevOps” e nei metodi “Agile”
<<I’d like to think that “The Phoenix Project”
is what Dr. Goldratt would have written if he
wrote “The Goal” today, and had Tarantino or
Scorsese as a novel coach>>
3. L’azienda
Parts Unlimited
Azienda che produce ricambi per
automobili:
● C’è “fermento” nel consiglio di
amministrazione per dare una svolta
all’azienda che ha in conti in rosso...
● Steve viene rimosso dall'incarico di
Presidente e Bob riprende il suo posto
dopo che era andato in pensione
4. Il protagonista
Bill
Bill è un manager del reparto IT:
● Viene promosso - in modo inaspettato -
a “VP of IT Operations”
● Ha il compito di risollevare il reparto IT:
○ Poco budget, poche risorse, poco tempo, tanti
problemi!
○ C’è il “muro” tra Dev, Ops, Sec (e business...)
○ Il reparto IT è nell’occhio del ciclone
● Ci mostra come superare gli ostacoli!
5. Lo scontro tra i reparti
Il reparto Sviluppo e
di Sicurezza
“Che cosa c’è peggio di uno sviluppatore?
Uno sviluppatore in combutta con uno della
sicurezza”
● Il deployment durano giorni con un
sacco di ore perse per sistemare
problemi
● Update e patch di sicurezza su sistemi
datati…
● Scambio di colpe reciproche!
6. Il progetto
The Phoenix Project
E’ il progetto che dovrebbe risolvere i problemi aziendali
● L’azienda è in grave ritardo con la concorrenza e il progetto dovrebbe
colmare il gap ma…
○ … il progetto è vecchio di 2 anni e non ancora in produzione
● Il reparto IT non riesce a stargli dietro...
○ Bill cerca di capire il carico di lavoro del suo reparto
○ All’inizio del suo mandato regna il caos!
■ Tutti lavorano sodo ma le cose vanno decisamente male
7. Il buono
Erik
Erik è il personaggio che aiuta Bill
nel percorso…
● Il lavoro dell’IT è come quello
di un impianto industriale:
○ I materiali in ingresso sono i
progetti assegnati all’IT
○ Come si arriva al massimo
throughput?
■ occorre monitorare i progetti
■ ci sono dei vincoli da tenere sotto
controllo
■ ...
8. Il cattivo
Sarah
Cercherà di mettere i bastoni tra le
ruote a Bill
● E’ il falco, mira ad una promozione e
non si pone molti scrupoli
○ Spinge per mandare in deployment in
progetto Phoenix nonostante i pareri
negativi dei reparti Dev e Ops
● Assegna dei task al reparto IT secondo
le proprie esigenze (scavalcando Bill)
○ e.g., modifica al DBMS
● … ma Bill ha un bel team… :)
9. Il “piccolo” team IT
Il team di Bill
… ma Bill ha un bel team… :)
● I primi step verso il successo
○ Progetto di Monitoring
■ Capire chi fa cosa e il “work in
progress” WIP
■ Che tipi di lavoro svolgono nel reparto?
■ Evitare l’unplanned work
○ Board Kanban intorno a Brent
■ Brent è un vincolo!
○ Improvement Kata
■ “Culture of improvements”
■ Velocizzare i processi (e.g. sostituzione
laptop)
10. Il guru
Brent
Brent è la chiave per capire i
fallimenti e per la loro risoluzione
● E’ la persona con più
competenze
○ ...è l’unico che sa risolvere i
problemi
○ ...è uno shortcut per implementare
lavori di altri team
○ Non riesce a dedicarsi al goal
principale: il progetto phoenix!
11. Il caos
I problemi di deployment, conformità
normative, sicurezza, ...
● Sistemi vecchi da aggiornare
● Cambiamenti al DB non tracciati
● Failure nell’ambiente di produzione:
○ Non funziona il sistema delle buste paga
● I sistemi business richiedono che i servizi IT funzionino correttamente!
● Si scopre che alcuni sistemi “core” che andrebbero modificati sono
gestiti in outsourcing
12. Il “grande” team
Il cambiamento deve
essere globale
...il CEO organizza un meeting con i
manager per superare i problemi di
mancanza di fiducia tra i team
● Gli invita a parlare delle propria storia
e delle proprie vulnerabilità
● ...mette in atto un cambiamento sia
umano che di fiducia reciproca tra i
responsabili e i team
○ Inizia la collaborazione e il cambio dei
processi aziendali
13. Il “grande” team
Collaborazione tra Dev, Ops, Sec e
Business
● Dev e Ops iniziano a non saltare le riunioni tra team
● Brent da “vincolo” diviene “leva”
○ La sua visione di insieme aiuta a creare una pipeline completa
● Il reparto Security partecipa alla collaborazione individuando in che
punto della pipeline inserire solo i controlli necessari - non superflui -
● Si scopre che gli obiettivi aziendali non coincidono con le aspettative
del progetto Phoenix
○ Viene creato un progetto minore chiamato Unicorn
■ Il progetto permette al business di fare proposte al cliente ed avere un rapido
feedback…
■ Il reparto business utilizza questa possibilità per aumentare le vendite alla festa
del ringraziamento
14. Il rapporto tra IT e Business
Ridurre i tempi di rilascio, avere
feedback maggiori = miglior business!
As if Steve knows what I’m thinking, he says, “You know, when Erik and I first
met, many months ago, he said that the relationship between IT and the business
is like a dysfunctional marriage—both feel powerless and held hostage by the
other. I’ve thought about this for months, and I finally figured something out.
“A dysfunctional marriage assumes that the business and IT are two separate
entities. IT should either be embedded into business operations or into the
business. Voilà! There you go. No tension. No marriage, and maybe no IT
Department, either.”