Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
Kanban unbounded - Cosa succede sulla linea di faglia tra il team ed il resto...Alberto Brandolini
Il mio talk a Better Software 2013 riveduto e corretto. Dove parlo di Kanban, management, e del virus dell'esternalizzazione guidata dal mantra della "riduzione dei costi".
Master presentazione 1 come nasce un'ideasculling77
Piccola presentazione il cui tema è l'illustrazione di come VIRGOSISTEMI gestisce i Clienti e le loro esigenze fino a farle diventare dei prodotti finiti.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
Kanban unbounded - Cosa succede sulla linea di faglia tra il team ed il resto...Alberto Brandolini
Il mio talk a Better Software 2013 riveduto e corretto. Dove parlo di Kanban, management, e del virus dell'esternalizzazione guidata dal mantra della "riduzione dei costi".
Master presentazione 1 come nasce un'ideasculling77
Piccola presentazione il cui tema è l'illustrazione di come VIRGOSISTEMI gestisce i Clienti e le loro esigenze fino a farle diventare dei prodotti finiti.
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.
Time Management as a critical skill for a Manager.Which are the most time consuming habits, how to change the ineffective behaviours. Theatre, Neurophisiology, Self-Management
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
Lessons learned on collaborative modeling: how EventStorming survived, and helped us survive the pandemic. And how it evolved to support new collaboration paradigms.
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.
Time Management as a critical skill for a Manager.Which are the most time consuming habits, how to change the ineffective behaviours. Theatre, Neurophisiology, Self-Management
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
Lessons learned on collaborative modeling: how EventStorming survived, and helped us survive the pandemic. And how it evolved to support new collaboration paradigms.
EventStorming was born as a massively in-person workshop to discover and model complex businesses and design event-driven software. But the old ways are no longer viable. After one year of experiments and discoveries in a forced-remote setting we know a lot more about what is still working and what is not.
What happens when you have the luxury of leading software projects without trade-offs and you're a Domain-Driven Design fanatic? You start stretching DDD concepts until it hurts and make experiments un uncharted territory.
In this talk, we'll see a few unconventional approached to Context Mapping and what happens when you fully embrace CQRS and Small Aggregates as a modeling paradigm.
Can software architecture affect the culture and emotions in the workplace? In this talk I look to some ways architectural choices shape collaboration and survivability in the workplace.
Software design as a cooperative game with EventStormingAlberto Brandolini
You got the stickies and the paper roll, and possibly already run a large Big Picture workshop to highlight where the problem is. Now you're in a room with business, software and UX experts hungry for a solution.
How do you make the magic happen?
In this talk, we'll explore some strategies about how to deliver with collaborative modeling, and how to narrow the gap between stickies and working code.
I've spent the last years modelling complex businesses and Software Architectures with EventStorming. The original recipe evolved a lot from the initial one. This is EventStorming state of the art.
Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.
Too often we model processes around the myth of Database Transactions, ofter forgetting what a transaction really means in the real world. This talk shows an easy and cheap approach to use together with EventStorming in order to include User Experience into process modelling
Most software development processes are focused on tracking and delivery. Unfortunately, writing code is no longer the bottleneck. The real bottleneck is the team ability to learn about the domain complexity and do the right thing.
Using EventStorming to drill into domain modelling complexity: from the big picture into the design of aggregates, processes and read models. A different approach to enterprise software modelling.
Software development is not one size fits all. Domain-Driven Design is significant where there's high complexity and high value. In these areas different tools might be needed. EventStorming is the best way I know to gather requirements in a complex environment, and also maps with CQRS/ES architecture perfectly.
There are some recurring themes in Domain-Driven Design applications, and distant domains show more similarities that differences, especially when you start taking into account peculiarities of specific Bounded Contexts. This is where a different type of design could happen.
Put the key stakeholders in the same room with an unlimited modelling surface, and some tricks, and you'll end up not only with a viable model, but also with skeleton for continuous improvement.
Slides of my Pecha Kucha short talk at #ALE14 in Krakow.
There's too much noise around software estimation, and one of the problem is that we try to use the same approach, when we're in practice estimating totally different things.
Collecting requirements or understanding a large system seems such a long and demanding activity. We can do al lot better than this: unlimited modelling space and all the key stakeholder in the same room, with some special spice. :-)
Domain-Driven Design has never been so efficient. This is where DDD meets Kanban, TOC and Management 3.0.
21. Retrospective bad smell
La retrospettiva e’ limitata al team
Ci occupiamo solo dell’ultima iterazione
Discutiamo solo dei temi che possiamo risolvere
22. Retrospective bad smell
La retrospettiva e’ limitata al team
Ci occupiamo solo dell’ultima iterazione
Discutiamo solo dei temi che possiamo risolvere
…cosi’ stiamo nei tempi!!!
28. La natura del problema
“non abbiamo tempo da perdere”
Retrospettiva limitata al team
Problemi originati dall’esterno spesso non toccati
Frustrazione e senso di “commedia”
Gli approcci “di buona volonta’” scalano piuttosto
male
33. Retrospective Workshop
Invita le persone giuste -> TUTTI
Mettiamo a disposizione uno spazio di moderazione
illimitato
Rotolone, pennarelli, post-it, stanza
Modelliamo TUTTO il Business con gli eventi
43. Ricetta
Wild Exploration
Enforce the timeline (qui la gente parla)
Persone e sistemi (qui la gente continua a parlare)
Explicit walkthrough (Nemmeno qua smettono)
Problemi e Opportunita’
Arrow Voting
44. Se tutto fila liscio…
A clear business narrative
A massive
blocker
91. Tutti i numeri sono accessibili a tutti
Stipendi, fatturato, spese, etc…
Anche i processi decisionali sono trasparenti (e spesso
demistificati)
Il difficile e’ spiegarlo all’esterno (Remote Working,
Carte di credito, etc.)