Sessioni 2013

The next decade

J. B. Rainsberger



Lascia un Feedback su joind.in

Two years ago, I looked back at over a decade of progress in the community of Agile software development practitioners. I talked about some alarming trends in our attitudes, our practices and what we teach, but also described the ways in which I believe we’d really advanced the art of software development.

Now, I explore a more interesting question: Where do we go from here? Those alarming trends haven’t all gone away. In fact, some have got worse, and I want to highlight some of things that I think we really need to stop before they destroy all the credibility we’ve built.

Of course, the picture is not bleak: we’ve helped make software development better for so many people, and I’ll talk about where I’d like us to focus our considerable energy to help make the coming decade even better for our field and the lives of our colleagues.

Retrospettive creative. Come diventare un’eccellente facilitatore e supportare il continuous improvement dell’organizzazione

Pierluigi Pugliese

Lascia un Feedback su joind.in

Il nocciolo dell’agilità è la capacità di migliorarsi continuamente e le retrospettive sono la tecnica principe per raggiungere lo scopo. Ma… come facilitare al meglio una retrospettiva? Questo workshop presenta vari modi per raggiungere lo scopo, varie strutture per retrospettive e un’ampia serie di consigli pratici per la loro facilitazione.

È riconosciuto che le retrospettive sono lo strumento principe per supportare il miglioramento continuo del team. Ma nella pratica molti facilitatori utilizzano sempre lo stesso formato e gli stessi esercizi nelle loro retrospettive. Questo succede perché, nonostante la letteratura in materia abbondi di esercizi, non è di solito chiaro quando e come utilizzarli.

Questo workshop si propone di esplorare il mondo delle retrospettive da due punti di vista:
Quello della struttura della retrospettiva: quali alternative sono possibili al classico formato descritto in “Agile Retrospectives” e come scegliere il formato più adatto alla situazione
Quello del ruolo di facilitatore: quali sono gli elementi da considerare per facilitare al meglio una retrospettiva.

Dalla Vision al Prodotto. Abbattere le barriere di comunicazione con i Canvas

Stefano Leli e Giulio Roggero


Lascia un Feedback su joind.in

La comunicazione tra le persone è il primo valore dell’Agile. Trasmettere la vision di un’idea è molto difficile. Attraverso i Canvas è possibile non solo condividere la vision ma anche il viaggio che porterà alla realizzazione dell’intero prodotto.

Adottando i vari Canvas come il Business Model Canvas, il Lean Canvas e il Product Canvas è possibile definire e condividere le ipotesi iniziali, validarle sul mercato misurando i risultati e confrontarle con i risultati attesi. I Canvas quindi non solo ci aiutano nella parte iniziale del progetto ma ci accompagnano per tutto il ciclo di vita del prodotto evolvendo con esso.

Questi concetti non sono strettamente legati al software ma possono essere applicati in contesti differenti.
Durante questo workshop vedremo insieme come, partendo da un’idea, si possa realizzare un prototipo di applicazione mobile in meno di due ore… il tutto sotto forma di gioco.

Introduzione al TDD. Una introduzione al test driven development e il suo legame col design

Carlo Bottiglieri

Guarda il codice su GitHub
Lascia un Feedback su joind.in

Il test driven development è spesso piuttosto difficile. Questa sessione non lo renderà più facile, tenterò invece di spiegare perché è difficile e perché, dopo tutto, ne vale la pena.

Alcuni argomenti che tratterò in questo workshop :
– Note sulle dinamiche dello sviluppo software (perché non abbiamo mai il tempo per scrivere quei test)
– Il ruolo del design nel tdd
– L’importanza di non perdere tempo a scrivere il codice mentre si programma
– La natura arborea dei test per il design
– Valutare se e come framework e librerie supportano il testing, e cosa fare se hai preso quelle sbagliate
– Interessanti alternative al tdd (no, non “solo programmare”)
– Qualche nota su come introdurre il test driven development in un progetto e un team esistenti
– Utili principi di design, pattern e altri parafernalia
– Un sacco di pratica e discussione
Un laptop con un IDE Java aumenterà di molto il piacere (o la sofferenza) del workshop.

Coderetreat. Honor your Craft

Gabriele Lana – con il supporto di Giuseppe Capizzi, Andrea Francia, Filippo Liverani, Carlo Miron e Giorgio Sironi


Lascia un Feedback su joind.in

Migliaia di programmatori nel mondo hanno onorato la loro disciplina partecipando ad un coderetreat, fallo anche tu all’AgileDay

Il coderetreat è un format noto che viene ripetuto molte volte durante l’anno in molte parti del mondo, dal sito ufficiale (http://coderetreat.org/about)
“Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of ‘getting things done’, the coderetreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.”

La giornata si divide in iterazioni, ogni iterazione di un ora è organizzata nel seguente modo:
45 minuti di esercizio
~10 minuti di retrospettiva (obiettivo quello di condividere brevemente le impressioni dell’ultimo esercizio, eventualmente di aggiustare il tiro per le iterazioni successive, formare le coppie per la prossima iterazione)
~5 minuti di pausa (tirare un po’ il fiato, fisicamente rilocarsi sui tavoli).

Regole:
il codice prodotto viene cancellato (rigorosamente) alla fine di ogni iterazione
le coppie cambiano di continuo

Dotazione:
e’ consigliato venire con un laptop con almeno un ambiente di sviluppo e un framework per i test unitari installato. Tecnicamente basta averne solo uno per coppia, ma per non rischiare, chi puo’ lo porti in ogni caso.
Facendo il cambio di coppie potrà anche capitare di lavorare con qualcuno che usi un linguaggio diverso che magari non si conosce. Comunque i facilitatori si impegneranno a favorire le diverse esigenze e interessi. La giornata serve soprattutto per imparare, possibilmente divertendoci. Lo scopo non e’ di arrivare a finire il problema, quanto piu’ quello di raffinare sempre di piu’ l’approccio con cui lo si affronta.

Leading Self-organizing Teams

Andrea Provaglio

Lascia un Feedback su joind.in

La tua azienda ha adottato un approccio Agile, ma le persone nel tuo team non mostrano il livello di partecipazione e responsabilità che speravi? I processi decisionali non funzionano ancora bene? La leadership è confusa? Il morale del team è basso?
Allora non stai ottenendo alcuni dei benefici che una mentalità Agile – e, in particolar modo, l’auto-organizzazione – può portare in un gruppo di lavoro.

Durante questo workshop vedremo, tramite brevi spiegazioni, discussioni aperte e esercizi pratici, perché l’auto-organizzazione è così importante, quali fattori la ostacolano, e come creare un ambiente di lavoro che la supporta.
Il workshop è rivolto a team leader, a manager; e, in generale, a chiunque sia nella posizione di orientare un gruppo di lavoro verso un obiettivo condiviso, lasciando al gruppo l’autonomia di prendere decisioni che lo riguardano e che siano allineate con l’obiettivo stesso.

I partecipanti avranno modo di discutere e sperimentare approcci legati ai seguenti temi:
creare allineamento tramite meeting efficaci
co-creare obiettivi condivisi
assistere i manager nell’essere leader e facilitatori di cambiamenti
posizionarsi al proprio corretto livello di guida nel team
uscire da una cultura di attribuzione di colpe (blaming culture)
migliorare la gestione di conflitti

I partecipanti saranno coinvolti in esercizi pratici e guidati, con i quali sperimentare in prima persona i concetti esposti. Molti di questi esercizi possono essere riportati nella propria organizzazione come strumenti per migliorare la comunicazione e partecipazione nel team.

The Birthday Greetings Kata. Impara a separare il modello del dominio dall’infrastruttura con l’architettura esagonale

Matteo Vaccari

Guarda il codice su GitHub
Lascia un Feedback su joind.in

Come creare codice flessibile? Una regola di base è dare a ciascun oggetto una sola responsabilità ben definita. Vogliamo che la nostra logica applicativa sia semplice; che esprima chiaramente le regole del business; e che sia separata dalla logica che gestisce transazioni e persistenza, dalle API di terze parti, o altri servizi di infrastruttura. Il codice ben fattorizzato è così semplice che sembra “codice giocattolo” (Lance Walton).

Per ottenere questo obiettivo, possiamo strutturare la nostra applicazione secondo l’architettura esagonale, anche chiamata “ports and adapters”, resa famosa da Alistair Cockburn. In questa architettura il codice del dominio sta al centro, mentre l’infrastruttura sta intorno. Le dipendenze a livello di codice sorgente puntano tutte dall’infrastruttura al dominio e non viceversa. La clean architecture di Uncle Bob è molto simile.

Il “Birthday Greetings Kata” è un semplice esercizio che ho inventato per me e i miei colleghi; serve a capire bene come applicare l’architettura esagonale in pratica. Dal 2009 questo esercizio è stato presentato a diverse conferenze. In questa occasione voglio ripresentare l’esercizio in un formato leggermente diverso: non come un esercizio di refactoring ma come un esercizio di ATDD.
Maggiori informazioni: http://matteo.vaccari.name/blog/archives/154

Come comprendere la cultura aziendale e vivere felici (o almeno consapevoli)

Marco Trincardi

Lascia un Feedback su joind.in

Comprendere la cultura aziendale in cui ci si trova a lavorare è fondamentale per interpretarne valori e messaggi, e capire come trattarli quando si vuole parlare di agile (sopratutto in un contesto poco agile)

Chiunque abbia cercato di introdurre metodi Agili, si è spesso scontrato con resistenze ed incomprensioni.
In alcuni casi, il livello di incomprensione porta ad avere la sensazione di parlare lingue diverse.
Per spiegare cosa accade, e per trovare delle soluzioni, il workshop propone una chiave di lettura basata sulla definizione di cultura aziendale.
I partecipanti saranno coinvolti in una serie di attività, da cui emergeranno tematiche quali :
Cos’è la cultura aziendale e perché è importante parlarne.
Come individuare tipologie di cultura aziendale e quali caratteristiche hanno.
Se Agile fosse una cultura, esiste una tipologia di riferimento?
Quali valori agili sono compatibili con la cultura circostante.
Quali azioni sono più efficaci per superare le resistenze.
E’ possibile cambiare la cultura aziendale?

Instilling Scrum

Andrea Rodriguez e Raoul Buzziol


Lascia un Feedback su joind.in

Perché Scrum? Come si fa? Cosa ci guadagno? Impara le basi del processo empirico realizzando il tuo prodotto in maniera iterativa e incrementale… giocando.

Scrum è un processo di sviluppo che sta diventando mainstream in molti ambienti. Non è qualcosa che si può installare, ma “immettere a piccole stille” (diz.). Per comprenderne le ragioni e l’efficacia è necessario sperimentarlo di persona ed il modo migliore per iniziare è attraverso la pratica; il workshop è orientato alla realizzazione di un prodotto guidata da una vision, contando su uno dei più potenti strumenti di apprendimento: il gioco. Non mancheranno impedimenti, ma un efficace team auto organizzato conseguirà il successo… in maniera iterativa ed incrementale!

Come scegliere un coach agile?

Pierluigi Pugliese


Lascia un Feedback su joind.in

Molte organizzazioni si appoggiano a dei coach agili per essere supportati in una transizione agile ma… come si sceglie una tale figura professionale? E che tipi di coach agili ci sono? Questa presentazione interattiva vuole fornire una struttura per identificare la persona più adatta alle vostre necessità!

Per vari motivi, nel corso degli anni mi sono ritrovato di frequente a dover selezionare persone per vari ruoli professionali: programmatori, manager a vari livelli, ScrumMasters, Product Owners, etc. Ma la complessità maggiore l’ho riscontrata nella selezione dei coach agili in quanto sotto questo nome comune si ritrovano vari tipi di figure professionali con varie skills e varie possibilità di inserimento all’interno dell’organizzazione.
Saper distinguere tra i vari “tipi” di coach agili e capire qual’è quello più utile per la vostra organizzazione è, a mio parere, un’elemento molto importante per il successo di una transizione agile.
Vedremo anche dei casi pratici di coach agilli e di organizzazioni, per mettere in pratica quanto appreso.

Agile Requirements – alla ricerca del filo rosso

Fabio Armani


Lascia un Feedback su joind.in

I requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.

Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.

Wiki-like collaborative development for seamless customer involvement

Carlo Bonamico e Paolo Predonzani

Lascia un Feedback su joind.in

We have known for a long time that customer/developers constant collaboration is a key element of successful software projects and services. How can we reduce the “impedance mismatch” between even simple requirements such as a user story and the actual application?
Behaviour Driven Development have proven effective thanks to collaboration with users on a textual description of the specifications which is subsequently “completed” by developers.

How can we push the concept even further? how can we create a workflow where the specifications “became” progressively the application? a bit like documentation is progressively sketched and refined in a wiki?
How can we implement these ideas today, with existing Open Source tools? what are the challenges? what are the limitations and issues yet to overcome? real-world experience is included.

Agile in 45 minuti

Giulio Roggero


Lascia un Feedback su joind.in

E’ la prima volta che sentite parlare di Agile? Volete capire di cosa si tratti? Questo talk fa per voi!
State provando ad applicare Agile ma avete ancora le idee confuse, Agile in 45 minuti vi mostrerà la strada da seguire.
Scrum, Kanban, XP, Pomodoro Technique, Agile Manifesto e altro ancora saranno i protagonisti di questa sessione.
45 minuti sono pochi? Sara’ una vera e propria sessione Lean, fluente ed essenziale, portate carta e penna per gli appunti!

Dalle stalle alle stelle: viaggio attraverso la “Agile Fluency”

Alessandro Bonometti

Lascia un Feedback su joind.in

Una PMI, leader nel suo settore, da tempo incamminata sulla strada dell’agile.
Tre team di sviluppo, ognuno con il suo prodotto e il suo PM, che hanno lottato per anni di contro codice e pratiche legacy, vincendo: TDD, Pair programming, Acceptance Tests, Continuous Integration, erano ormai la normalità quotidiana. Doveva essere il Nirvana degli sviluppatori, ma qualcosa ancora non andava…

Il matrimonio di un collega, un open bar vista lago e un’idea che si fa strada: non fermiamoci qui!

Nel giro di pochi mesi i tre team diventano un unico team cross-prodotto. I PM diventano (proxy) PO. Viene eletto uno Scrum Master…sembrava una difficoltà insormontabile, e invece nel giro di pochi mesi il delivery è radicalmente migliorato e gli sviluppatori…

Come è cominciato il viaggio? Da dove siamo partiti? Che strumenti abbiamo utilizzato? Quali ostacoli abbiamo dovuto schivare? Dove siamo adesso? Dove vogliamo arrivare?

When TDD goes awry

Uberto Barbini



Lascia un Feedback su joind.in

A voyage into today Java enterprise worse practices.
Have you ever seen 10 mocks used to tests a couple of lines of code?
Beans with tons of getters/setters?
The same code repeated all over again with little differences?
The three pasta antipattern: spaghetti, ravioli and lasagna.
From my personal experience, some examples of terrible code, written trying to follow industry best practices and tdd.
Understanding the design and the goals, will help to find the way to improve it.

Product Owner? Owner di cosa? Prodotto o Progetto?

Donato Mangialardo

Lascia un Feedback su joind.in

Product Owner. Ma la “P” significa Prodotto o Progetto? Spesso alcuni pensano “Prodotto” mentre altre pensano “Progetto”, e altre ancora pensano Prodotto i giorni pari e Progetto i giorni dispari, oppure come conviene al momento. E viene dil mal di pancia. Ma forse stiamo guardando il Prodotto sbagliato?

Vediamo prima le differenze tra Prodotto e Progetto/Servizio, con esempi reali che derivano proprio da questo “dilemma”.
Uno non e’ meglio dell’altro, ma spesso si vedono organizzazioni in cui alcune persone pensano Prodotto mentre altre pensano Progetto, e altre ancora pensano Prodotto o Progetto a seconda della convenienza personale. E vengono dei gran mal di pancia. Spesso si pensa che “facciamo Servizi o Progetti/Prodotti per i ns clienti, mentre invece il ns reale Prodotto [qualcosa che incontra la domanda ed il bisogno di n clienti alla volta] e’ la ns. capacita’ di fornire un certo servizio in un certo campo in modo ripetibile, su cui attorno abbiamo creato un business
Una volta partiti con Lean/Agile (o a meta’ del guado) serve un allineamento costante tra mercato reale [gruppo di buyers potenziali ed utenti con problemi comuni, e quali sono questi problemi], management, vendite, development, epiche che il Boss capisce, e anche la P di “Personas”. Questo allineamento manca troppo spesso. Ma perche’ soffrire?? Ci sono seplici strumenti che ci semplificano la vita, a partire da domani, basta partire…
Strumenti utilizzati nei Case Study
– Lean Canvas
– Personas “quelle che fatte bene le usano anche i commerciali”
– MVP (Minimal Viable Lean Canvas, Minimal Viable Personas, …)

Outcome not Output

Stefano Maraspin


Lascia un Feedback su joind.in

Le pratiche agili aiutano a domare incognite e complessità dei progetti software, riuscendo in molti casi a garantire la produzione di codice di buona qualità. Ma è ciò sufficiente? Cosa succede al manifesto agile quando a un progetto lavorano più team? E poi, ok user story; ma come raccoglierle? E in base a cosa prioritizzarle? Saranno quelle che vuole il cliente? E soprattutto, sará ciò importante? Se queste domande t’incuriosiscono, segui il talk. Avremo la possibilitá di confrontarci e imparare, ragionando assieme su questi dubbi, che porrò come spunto di riflessione, per poi condividere la mia esperienza.

I progetti software sono colmi di rischi e incognite. Gli approcci agili aiutano a controllare questi pericoli, e spesso anche a rilasciare codice sorgente di buona qualità. Ma è ciò sufficiente a garantire il successo di un progetto? Le user story sono sempre lo strumento giusto con cui partire? Nella realtà, quando lavoriamo tra team diversi riusciamo sempre a rispettare gli individui e valorizzare le interazioni? Negli ultimi 18 mesi abbiamo introdotto e sperimentato all’interno del nostro team diverse pratiche derivanti da approcci agili e user centered. In questo talk condivido e argomento le pratiche che si sono dimostrate più efficaci, ponendo enfasi su un principio fondamentale della Lean UX: Outcome, not output.

TDD anche su iOS

Andrea Francia


Lascia un Feedback su joind.in

Test Driven Development su iOS è possibile e persino utile.
Invece di leggere blog post che sottointendono che TDD su iOS sia difficile e inutile venite a vedere chi lo usa sul serio e ha il coraggio di programmare ad una conferenza davanti ad altre persone.

Avvertenze:
questo talk non contiene paternali sul perché si dovrebbe (o non si dovrebbe) fare TDD
in questo talk non verranno usati strumenti complicati
in questo talk verrà scritto ed eseguito codice dal vivo
Dopo una brevissima introduzione passerò a sviluppare guidato dai test una semplice applicazione per iPhone.

Document it… But just in time!!

Alessandro Campeis e Marco Trincardi

Lascia un Feedback su joind.in

In un contesto agile la documentazione è utile solo se porta valore senza nel contempo rappresentare un peso per lo sviluppo.
Per ottenere ciò è necessario capire come creare solo quello di cui abbiamo veramente bisogno, nel momento in cui ne abbiamo bisogno, nella forma più conveniente.

Documentare un progetto è un’attività costosa, sia nella fase di creazione che di manutenzione. Se la documentazione prodotta non viene letta, o non veicola conoscenza, diventa uno spreco (waste).
In questa sessione vogliamo mostrare con esempi reali, come un team Agile affronti l’argomento, scelga gli strumenti in funzione del contesto e sfatare il mito Agile = No Documentazione.
Anche per la documentazione il nostro obbiettivo è chiaro: creare solo quello di cui abbiamo veramente bisogno, nel momento in cui ne abbiamo bisogno, nella forma più conveniente.
Documentazione Just in Time!

Dreaming

Andrea Provaglio


Lascia un Feedback su joind.in

Accompagnare un’idea dalla sua nascita al suo completamento (per esempio, un progetto software) è un viaggio non-lineare che alcuni sembrano essere in grado di affrontare meglio di altri, in particolare modo quando l’esatta destinazione non è chiaramente definita.
È un viaggio che richiede almeno tre elementi chiave: intento, ordine e azione. Questi tre elementi sono molto più legati al business di quanto possa apparire e possono essere utilizzati come un modello efficace per capire e migliorare le dinamiche, i processi, i ruoli e gli artefatti presenti in team e aziende.
In questa presentazione vedremo come i tre elementi chiave sono attivi e presenti, in modi diversi, in aziende Agile e non-Agile; come sono correlati a ruoli e pratiche Agile come Product Owner, backlog e test; in che modo possono essere utilizzati per portare maggiore focalizzazione e allineamento tra diverse aree della nostra organizzazione, azienda o team; e come possano essere una chiave di lettura della complessità organizzativa.
Forniremo anche consigli pratici su come utilizzare i concetti proposti e presenteremo pratiche concrete di immediato utilizzo. Alcuni dei temi toccati saranno:
saper leggere, da una nuova prospettiva, le dinamiche sommerse in organizzazioni Agile, non-Agile e quasi-Agile
capire aspetti fondamentali che rendono alcune aziende e team di prodotto più efficaci e funzionali di altre
comprendere lo spazio organizzativo in cui opera il ruolo di Product Owner, piuttosto che quello dei team tecnici
gestire e popolare il backlog in modo allineato a un intento creativo di business

Pratiche agili di sviluppo applicate all’infrastruttura

Giuseppe Leone e Marco Trincardi

Lascia un Feedback su joind.in

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.

La salute del software

Guido Pederzini e Marco Arena

Lascia un Feedback su joind.in

Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.

Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.

Le parole sono importanti!

Francesco Degrassi

Lascia un Feedback su joind.in

Il linguaggio che usiamo influenza fortemente non solo la nostra comunicazione, ma anche il modo in cui inquadriamo la realtà che ci circonda e ci relazioniamo con gli altri.
Partendo da alcuni esempi di uso comune, vedremo come l’impiego di termini ambigui, imprecisi e talvolta in contrapposizione ai valori ed i principi fondamentali dello sviluppo agile influenzi negativamente il modo di pensare e comunicare nostro, di colleghi e clienti.

Bravi si diventa

Filippo Liverani


Lascia un Feedback su joind.in

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.

Test sulle immagini

Giorgio Sironi

Lascia un Feedback su joind.in

assertLooksGood(screenshot) sembra impossibile da definire, ma non lo é.

assertEquals(“Quello che mi aspetto”, risultato) è una delle prime asserzioni che si scrivono nei test automatici. Quando lavoriamo con HTML e JavaScript le asserzioni diventano un po’ più complicate, dovendo parsare il DOM o far girare un interprete. Quando si arriva ad asserire su immagini PNG può diventare impossibile.
Questo talk si propone di fornire alcuni pattern e strumenti per costruire test di regressione sulle immagini (come una foto della vostra homepage) che rimangano stabili nel tempo.
Il formato è quello di un lightning talk, essendo il contenuto molto tecnico e trasmissibile anche con riferimenti esterni.
Chi puó trarre beneficio da questo talk: programmatori che sanno scrivere test, interessati peró ad automatizzare validazioni di solito lasciate all’umano.

Agile @Scale: Hello World!

Felice Pescatore


Lascia un Feedback su joind.in

Scopo di questa sessione è quello di illustrare l’applicazione di Agile in un contesto @Scale, descrivendone le potenzialità e l’adozione in contesti aziendali particolarmente ostili ai metodi Agili, grazie ad una loro applicazione diretta.

Quanti di voi, professionisti impegnati nelle gestione del produzione del software, si sono sentito dire dal responsabile della propria (nuova) azienda: “l’Agile non si applica al nostro contesto” oppure “dobbiamo quantomeno adottare un approccio ibrido (leggasi water-scrum-fall) perché abbiamo bisogno di strumenti di controllo/valutazione del team”?
Probabilmente tutti!
E per quanto si tenti di spiegare in modo semplice e conciso che un approccio Agile non è “un insieme di best practice” ma una metodologia ben definita, organizzata e che, a fronte di un effort di applicazione tutt’altro che irrilevante, la sua adozione porterà ad una nuova cultura aziendale e ad un miglioramento dei risultati produttivi, convincere lo “sponsor” aziendale, oltre che colleghi e stakeholder vari, è tutt’altro che semplice.
Dal punto di vista del management, le metodologie Agili “pure” risultano spesso inadeguate e, paradossalmente, le metodologie “tradizionali” (da Waterfall al modello a Spirale) sono strutturate in modo più robusto per accompagnare l’intero Application Lifecycle Management (ALM). Ciò è tanto più vero, quanto più l’azienda è legata ad un approccio che predilige il pattern “command-and-control”. O almeno questa è l’illusione che si ha e che deriva da decenni di relativa applicazione… nonostante i decenni di relativi fallimenti!
Inoltre le metodologie Agili si concentrano sulla produzione di Valore, ma tale termine viene spesso assimilato alla produzione di codice, che se da un lato è il vero risultato del lavoro di una tipica azienda IT, dall’altro non è detto che sia l’unico costrutto a produrre valore. Un esempio: se gli stakeholder (non il solo Cliente!) richiedono un documento che descriva l’Architettura, tale documento è di per se un Valore e non c’è nessun motivo per sottovalutarne l’importanza, tutt’altro.
Per superare tali ostilità e convincere la propria azienda ad adottare Agile, è possibile estenderne il relativo campo d’azione, utilizzando framework come DAD (Discplined Agile Delivery) o SAFe (Scaled Agile Framework) per abbracciare l’intero ALM.
Il talk si basa sull’esperienza diretta di applicazione di DAD all’interno della mia azienda, fortemente burocratizzata e legata a procedure spesso complesse e di opinabile efficienza.
Il talk sarà suddiviso in tre parti primarie:
– Dall’Agile ai framework/metodologie @Scale;
– DAD, SAFe e gli altri;
– L’applicazione pratica.
Il talk mira a porre le basi per consentire di rispondere alla domanda: “come adottiamo Agile nella nostra impresa tenendo presente la necessità di avere una visione d’insieme del ciclo produttivo?

Agile Forensics

David Bonilla


Lascia un Feedback su joind.in

Agile methodologies like Scrum, Kanban or the Pomodoro Technique have a lot of artifacts to study and diagnose what’s happening in our team. In this talk, we will examine agile graphs with a “medical” approach, It’s going to be fun!

Some people still think that “agile” means lack of tools to track how well we are performing. However, agile methodologies like Scrum, Kanban or the Pomodoro Technique have a lot of artifacts to study and diagnose what’s happening in our team.
In this talk, we will examine agile graphs with a “medical” approach, to discover the symptoms in our “patients”. We will try to identify the “disease” (if it exists) and the “cure”.
If you attend the talk, you should expect a reality check, a passionate agile “doctor” wearing his stethoscope and tons of REAL agile graphs from some of the best software teams around the World. It’s going to be fun!

Uno, Nessuno, Centomila… Progetti

Gaetano Mazzanti


Lascia un Feedback su joind.in

Gestire un singolo progetto è un conto, gestire un insieme/portafoglio di progetti è tutt’altra cosa, giusto?
Per non parlare di servizi e supporto, tutt’altro contesto e tipo di problematiche, ovvio no?
Invece…
Incertezza e variabilità: le stesse.
Principi e criteri alla base delle decisioni chiave: gli stessi.
Cosa fare? chi lo fa? quando? quanto costa ritardare?
Lasciare aperte il maggior numero di opzioni, ritardare le decisioni, minimizzare i rischi.
E’ “tutto” qui.

vi occupate di un solo progetto? o di molti progetti in parallelo?
lavorate a un prodotto legacy? oppure a un’idea di startup?
non gestite “progetti” ma fornite servizi? oppure fornite supporto?
scenari molto diversi -> approcci molto diversi, giusto? non proprio.
uno, nessuno, centomila progetti?
c’è in comune molto più di quanto si possa immaginare:
origine e tipologia delle idee e richieste (chi chiede, cosa chiede), criteri di selezione (cosa si fa e cosa no), persone (chi lo fa), metriche (per imparare, migliorare).
visualizzare cosa sta accadendo, evidenziare e affrontare blocchi, impedimenti, problemi, gestire l’incertezza e la complessità sono aspetti comuni a tutti questi scenari.
è solo/tutto un problema di flusso…

Lean anche io: no tu no.

Andrea Scavolini e Simone Vannicola


Lascia un Feedback su joind.in

Condivisione dell’esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili: i nostri fallimenti, i problemi incontrati e le sfide aperte.

La sessione sarà incentrata sulla condivisione dell’esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente – fornitore.
La sessione risponderà a domande come.
Ma che piano do al CIO che mi chiede un Gantt dell’intero progetto e io ho solo delle Release?
Come gestisco rilasci incrementali ogni due settimane se gli utenti sono sommersi di lavoro?
Come mi destreggio tra i tool non modulari dei Big Vendors che altri hanno scelto per me?
Quando lavoro su architetture molto complesse e rigide, come riduco il Big Design Up Front?
etc.

Agile Design Thinking: l’innovazione efficace

Matteo Vignoli, Piergiorgio Grossi e Sara Burani

Lascia un Feedback su joind.in

E’ noto che i team Agile siano molto efficaci nell’esplorare nuovi prodotti e rilascinare valore in modo rapido. Riteniamo che oggi, sebbene con i propositi più innovativi, le squadre tendano a diventare macchine che devono elaborare continuamente feature, una sorta di “feature crunching machine”. Il nostro obiettivo è quello di permettere ai team Agile di consegnare in modo affidabile innovazioni rivoluzionarie ai loro clienti.
A partire da risultati empirici sui bisogni incontrati dai professionisti che operano nell’ambito Agile e nell’innovazione, abbiamo sviluppato una metodologia in grado di combinare le virtù dell’Agile Software Development e del Design Thinking.

Da un lato, il Design Thinking è ideale per indagare i bisogni degli utenti e per la fase di ideazione, e, dall’altro lato, il forte orientamento all’azione dell’Agile può tradurre rapidamente le idee in prototipi funzionanti.
Queste due metodologie portano con sé punti di vista diversi, ma possono essere combinate in un approccio integrato in grado di migliorare l’interazione con l’utente e aumentare la capacità di esplorare nuove soluzioni, attraverso una maggiore attenzione al needfinding.
Abbiamo chiamato questo approccio Agile Design Thinking.

Imparare giocando? Non è roba da bambini!

Paolo D’Amora e Nicola Chiariello

Lascia un Feedback su joind.in

Gamification è il processo che utilizza il gioco come forma per rendere più efficiente l’apprendimento facendo leva sul fattore emozionale.

Perchè priorizzare? Quali sono gli effetti del task switching? Come il fast feedback può migliorare la qualità del nostro prodotto? L’apprendimento è uno degli aspetti fondamentali della nostra giornata lavorativa.
In questa sessione impareremo come la Gamification può essere uno strumento efficace di teaching dei valori e principi Agili.

Quando “Embrace Change” è difficile.

Fabio Mora


Lascia un Feedback su joind.in

Il 4° punto del Manifesto Agile può essere molto complicato non solo in XP, ma anche sul piano personale, relazionale e caratteriale. Sono aspetti fondamentali e trasversali del lavoro (e non solo). Ma abbracciare il cambiamento non è esattamente nella natura umana; è sfidante, è difficile… Fortunatamente però siamo in grado di apprendere e modificare il nostro comportamento in modi infiniti. Per arrivare ad ottimi risultati.

Siete in una situazione in cui sapete di poter dare molto, ma non riuscite ad innescare la scintilla del cambiamento?
Oppure desiderate che un vostro collega, il vostro team lo facesse ed invece non sembra esserci speranza?
Nel management classico o tradizionale si leggono libri con titoli come “Gestione delle risorse umane e motivazione al lavoro”. Ma forse essere trattati come risorse e non persone non è più sufficiente, e poi non è molto efficace motivare al cambiamento attraverso trucchetti o persuasione. Qualche suggerimento per capire meglio perché è difficile, gli ingredienti utili per cambiare e per capire la motivazione.
Sempre tenendo presente che la “svolta indotta”, quella che inizia con “Da domani iniziamo a…” o “Ho deciso che da oggi…” è quella più difficile da portare avanti.

Effective Code Transformations in C++

Marco Arena e Paolo Polce


Lascia un Feedback su joind.in

Aiutati da esempi reali e sfruttando gli strumenti messi a disposizione dal nuovo C++11, affronteremo trasformazioni di codice C++ efficaci, volte a migliorare la qualità del codice e del lavoro in C++. Il tutto attraverso il percorso pragmatico di un team agile.

Le novità introdotte dal C++11 (e tra poco dal C++14) non offrono solo l’opportunità di migliorare e di semplificare codice esistente, ma anche – e soprattutto – quella di rinnovare completamente il proprio stile, favorendo la qualità del codice e la produttività degli sviluppatori. Accompagnati da esempi reali, parleremo di come un team agile abbia accolto queste novità in una codebase un po’ anziana, trasformandola in modo efficace e migliorando i propri coding standards.
Con alcuni snippet C++/C# mostreremo anche quanto il C++ si sia avvicinato a linguaggi di più alto livello e, utilizzando la nostra recente esperienza e le nuove linee guida, rivisiteremo alcuni design pattern classici. Parleremo, brevemente, anche di concorrenza in C++ – finalmente standard – e di come sia possibile beneficiare da subito di costrutti quali task, parallel for each e continuation, tipici di molti linguaggi noti.
In definitiva questo talk è per tutti! C++-isti o meno, vi presenteremo la nostra recente esperienza in modo pragmatico e vi mostreremo che sviluppare in C++ oggi è più semplice e veloce rispetto al passato.

Model Storming. Learning complexity faster, together.

Alberto Brandolini


Lascia un Feedback su joind.in

Modellare un sistema complesso, nell’ambito di una singola giornata, risolvendo conflitti tra stakeholders e sviluppatori e definendo un’architettura aperta e robusta alle future evoluzioni, il tutto esplorando diverse alternative e divertendosi? Fatto.

How to grow Agile professionals

Angel Diaz-Maroto Alvarez

Lascia un Feedback su joind.in

As an Agile professional I’ve been asking myself for years: what can I offer to my organisation as an Agile Coach? What can I give to the agile community as an Agile practitioner? What competencies do I need to develop in my organisation to successfully implement Agile? How can I become a better agile professional and help others to do so?
Coaches, teams, organisations and Agile communities have a duty to actively contribute to the growth of agile practitioners. For that, it’s essential to understand what key competencies have to be developed in Agile coaches, Scrum masters and Agile Managers among other Agile professionals to reach their next level.

Lyssa Adkins and Michael K. Spayd, describe in their whitepaper “Developing Great Agile Coaches” (http://www.agilecoachinginstitute.com/wp-content/uploads/2011/08/Agile-Coaching-Competencies-whitepaper-part-one.pdf) The Agile Coach Competency Framework. This is one big clue to answer these questions. Over the past two years, this framework has guided the development of hundreds of agile coaches. Agile managers and champions also use it to obtain “truth in advertising” to hire the right coach at the right time.
This competency framework consists of eight primary areas of competence that provide a focus for education and professional development for Agile professionals. This areas are:
Agile-Lean Practitioner: Knowledge & Application
‘Process-focused’ competencies: Coaching & Facilitating
‘Content-focused’ competencies: Teaching & Mentoring
Domain Mastery (Technical Mastery, Business Mastery and Transformational Mastery)
Lyssa Adkins presented a similar session in the Agile 2013 conference in Nashville. A video where I expressed my thoughts about the framework was shown in that session.

Dal TDD al BDD

Claudio Pattarello


Lascia un Feedback su joind.in

In questa sessione si vuole esporre le analogie delle due pratiche, mostrare come passare dal TDD al BDD in modo progressivo senza la necessità di introdurre nuovi framework. Nella seconda parte si esporrà anche l’utilizzo di framework pensati per il BDD per evidenziare come i test possono diventare più chiari e diventare uno strumento semplice per l’introduzione degli Acceptance Test.

La prima volta che ho scritto un test, mi sono chiesto “ma a cosa serve questa roba?”.
Con il tempo ho capito come usare veramente i mock objects migliorando il mio design.
Poi sono maturato e con il TDD ho iniziato a progettare codice più pulito e controllato, con meno dispendio di energie.
Ma mi mancava ancora qualcosa. Volelo i tests organizzati meglio, che coprissero determinate situazioni.
Perché allora non usare il BDD direttamente nella scrittura degli unit tests?
Così ho iniziato ad organizzare i miei tests partendo dai comportamenti che volevo testare.
I tests sono un’arma a doppio taglio. Se fatti bene aiutano molto, ma se scritti senza padronanza possono diventare dei mostri che portano a falsi positivi e complicano la manutenzione del prodotto.

Abbattere i silos e diventare agili e snelli: lessons from the trenches

Michele Finelli

Lascia un Feedback su joind.in

Il talk si propone di descrivere una situazione in cui si è trovato il relatore, la ristrutturazione della casa, che sebbene sembri non entrare per nulla nel tema della conferenza, invece c’entra, eccome!

Cosa si nasconde dietro il movimento DevOps ? E più in generale, uscendo dal contesto del software, cosa puó portare il mondo Agile alle imprese ?
In breve, il rapporto tra cliente, direzione lavori, impresa, muratori, idraulico, elettricista, l’acquisto dei sanitari, la scelta delle piastrelle e gli imprevisti del tubo del gas, mostreranno sotto mentite spoglie i topoi più tipici del mondo del lavoro, qualunque sia l’ambito, ma con particolare enfasi riguardo al mondo dell’IT e delle sviluppo software.
Cercare di applicare un approccio Agile in costesto diverso ha permesso di capire meglio alcune idee e alcune principi (o forse no, lo vedremo) e in particolare di apprezzare alcune sfumature del movimento DevOps.

Esperienze di vita vissuta agilmente tra successi e fallimenti

Luca Foppiano

Lascia un Feedback su joind.in

Un viaggio di ricordi e progetti, analizzando l’esperienza agile all’European Patent Office.

SCRUM e’ una metodologia di sviluppo agile diventata sempre piu’ popolare e che ha visto una crescita nel mercato soprattutto tra le organizzazione Enterprise. Sono stati prodotti molti casi di studio in tutto il mondo che hanno supportato SCRUM come metodologia di successo.
Tuttavia SCRUM non e’ la soluzione a tutti i problemi, e non garantisce il successo a priori (come non e’ necessariamente la principale causa di fallimento), comunque l’adattamento all’ambiente e ai limiti dell’organizzazione, e’ un fattore chiave che può` cambiare il risultato del progetto.
SCRUM oggi e’ la metodologia di sviluppo ufficiale all’European Patent Office, dove sto lavorando da quasi cinque anni. L’idea e’ di presentare la mia esperienza come ricorderei una avventura, dove fallimenti e successi mi hanno aiutato ad acquisire esperienza e competenze. Ci concentreremo sulle sfide, sugli impedimenti e sulle prove di adattamento che abbiamo provato nei vari progetti.