
Lorenzo Massacci
Facilitatore per team e progetti software - extrategy founder
Actions
Facilitatore e mentor per la gestione di team e progetti software.
Stregato dal software sin dai tempi del commodore vic-20, sperimento da sempre nuove linguaggi e nuove tecniche di programmazione.
Ho iniziato sviluppando applicazioni HTML/PHP, utilizzando negli anni i diversi sistemi e framework come Zend Framework e Symfony. Negli ultimi anni mi sono spostato sullo sviluppo Frontend.
Attualmente mi occupa di sviluppo di applicazioni web o mobile multipiattaforma utilizzando javascript (tramite framework come AngularJS, PhoneGap e Titanium Appcelerator) e Swift per le applicazioni mobile native.
Approdo alle metodologie agili per lavorare meglio e con l’obiettivo di centrare le esigenze del cliente, applicandole sia nell’organizzazione e gestione del progetto (team cross funzionale, user stories, iterazioni, ecc.) sia nella scrittura e gestione del codice (TDD, Refactoring, Continuous Integration).
Nel 2001 ho fondato e-xtrategy, azienda che si occupa di aiutare altre aziende e startup a raggiungere i propri obiettivi di business utilizzando internet, la tecnologia e un approccio lean.
All’interno di e-xtrategy sono responsabile dell’area tecnica, partecipa attivamente alla realizzazione dei progetti web e mobile, organizzando il lavoro in ottica agile e lean attività che svolgo anche come consulenza per clienti e fornitori.
Dal 2014 sono Facilitatore Certificato nella metodologia LEGO® SERIOUS PLAY®.
Nell’edizione 2017 dell’Agile Business Day ho tenuto il talk Real Time Project Portfolio Management (https://vimeo.com/252068166)
Nel 2017 ho tenuto la seconda edizione del workshop per Avanscoperta: Developers vs Managers dal conflitto alla collaborazione (www.avanscoperta.it/it/training/developer-vs-manager-dal-conflitto-alla-collaborazione-con-lego-serious-play/)
Altre partecipazioni a conferenze:
https://vimeo.com/196396367 (Agile Day 2016 intervento sui contratti agili durante la tavola rotonda)
https://vimeo.com/113688015 (Agile Day 2014 talk: condividere obiettivi e prendere decisioni con Lego Serious Play)
http://www.extrategy.net/it/talks/team-agile-vs-budget-fisso-la-nostra-esperienza-e-i-nostri-errori (Better Software 2013 talk: Team Agile vs Budget fisso la nostra esperienza e i nostri errori)
Links
Collaborative decision making in self-organizing teams
Approcciamo in modo agile i nostri progetti ed i nostri team perché crediamo realmente che dare alle persone la possibilità di esprimere a pieno il proprio potenziale sia il modo migliore oggi per far prosperare un organizzazione.
L’undicesimo principio del manifesto agile recita:
"The best architectures, requirements, and designs emerge from self-organizing teams."
Ma il nostro lavoro consiste costantemente nel prendere decisioni. Qual è il modo giusto di avere team che si auto-organizzano ed al tempo stesso prendere decisioni in modo efficace ed efficiente? Come possiamo evitare di avere team anarchici dove ognuno va in una direzione diversa o (forse anche peggiore) dover sempre essere tutti d’accordo prima di prendere una decisione rischiando l’immobilismo?
Nel talk vedremo spunti, principi e tecniche che ci aiutano ad avere team che si auto-organizzano in modo efficace
Adaptive Planning
"Rispondere al cambiamento più che seguire un piano"
Organizziamo il nostro processo di lavoro in sprint o iterazioni, facciamo retrospettive, abbiamo il nostro Product Owner, stand up meeting e user stories, unit test e continuous integration .... però continuiamo a preparare il nostro bel backlog all'inizio del progetto quando abbiamo solo tante ipotesi e lo seguiamo passo passo come fosse una "ricetta".
Nel talk vedremo cosa significa fare un piano adattivo che ci permetta realmente di rispondere al cambiamento.
How to tackle legacy code and live happily with your managers
When we think about legacy code or technical debt we usually think about various way to refactor our code. But there is a very important, and often underestimated, aspect of any refactoring plan: living happily with Project Managers or C-Levels. In this talk, we will cover the main cause of the failure of refactoring plans: miscommunication with the business. After all, like Uncle Bob says "Programming is a social activity".
L'arte di massimizzare la quantità di lavoro non svolto
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

Lorenzo Massacci
Facilitatore per team e progetti software - extrategy founder
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top