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.
Organisations and usually pretty bed when it comes to self diagnose their own problem and even worse when choosing a solution for the badly diagnosed problem.
Understanding the basic of complexity and system thinking can help a lot, providing foundations for a different mindset and a surprising solutions toolkit.
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.
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.
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.
Organisations and usually pretty bed when it comes to self diagnose their own problem and even worse when choosing a solution for the badly diagnosed problem.
Understanding the basic of complexity and system thinking can help a lot, providing foundations for a different mindset and a surprising solutions toolkit.
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.
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.
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.
Every organisation pretends to be unique, but they mostly follow similar mechanics. Discover how your organisation too falls into common pitfalls and antipatterns and how you can leverage the situation to improve it.
As a Software Architect and consultant I designed software with some artefacts in mind. As an entrepreneur I found myself on the other side of the fence. I'd improve distribute holistic knowledge through EventStorming and Domain-Driven Design rather than partition the system with User Stories.
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.
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.
Every organisation pretends to be unique, but they mostly follow similar mechanics. Discover how your organisation too falls into common pitfalls and antipatterns and how you can leverage the situation to improve it.
As a Software Architect and consultant I designed software with some artefacts in mind. As an entrepreneur I found myself on the other side of the fence. I'd improve distribute holistic knowledge through EventStorming and Domain-Driven Design rather than partition the system with User Stories.
2. About me
Mi piace risolvere problemi
O scrivere software che li risolva
My e-mail: alberto.brandolini@gmail.com
Blog: http://ziobrando.blogspot.com
Twitter: @ziobrando
Thursday, September 19, 13
3. About me
In the IT field since ZX Spectrum
Generally in large scale projects (I might be biased)
Strategic IT Consultant
Trainer (Avanscoperta & Skills Matter)
Technical Writer
Blogger: http://ziobrando.blogspot.com
Twitter: @ziobrando
My e-mail: alberto.brandolini@gmail.com
Thursday, September 19, 13
24. Sistema 1
Risposte associative immediate
Parallelismo ... anche involontario
Basso consumo
Sistema 2
Thursday, September 19, 13
25. Sistema 1
Risposte associative immediate
Parallelismo ... anche involontario
Basso consumo
Sistema 2
Risposte complesse che richiedono
concentrazione
Thursday, September 19, 13
26. Sistema 1
Risposte associative immediate
Parallelismo ... anche involontario
Basso consumo
Sistema 2
Incapace di parallelismo
Risposte complesse che richiedono
concentrazione
Thursday, September 19, 13
27. Sistema 1
Risposte associative immediate
Parallelismo ... anche involontario
Basso consumo
Sistema 2
Elevato consumo
Incapace di parallelismo
Risposte complesse che richiedono
concentrazione
Thursday, September 19, 13
29. “Hai 2 persone in più...
consegnerai prima”
Thursday, September 19, 13
30. “Hai 2 persone in più...
consegnerai prima”
Thursday, September 19, 13
31. “Hai 2 persone in più...
consegnerai prima”
- Linearità di rendimento (falso)
Thursday, September 19, 13
32. “Hai 2 persone in più...
consegnerai prima”
- Linearità di rendimento (falso)
- Costi di avviamento lineari o
nulli(falso)
Thursday, September 19, 13
33. “Invece di un Senior
abbiamo assunto 2
Junior”
Thursday, September 19, 13
34. “Invece di un Senior abbiamo
assunto 2 Junior”
Thursday, September 19, 13
35. “Invece di un Senior abbiamo
assunto 2 Junior”
- Linearità di rendimento (falso)
Thursday, September 19, 13
36. “Invece di un Senior abbiamo
assunto 2 Junior”
- Linearità di rendimento (falso)
- Proporzione lineare tra costo e
valore (falso)
Thursday, September 19, 13
37. “Invece di un Senior abbiamo
assunto 2 Junior”
- Linearità di rendimento (falso)
- Proporzione lineare tra costo e
valore (falso)
- Costi di avviamento lineari
(falso)
Thursday, September 19, 13
40. “Intanto vai avanti con le altre
cose”
- Costo nullo del context switch
(falso)
Thursday, September 19, 13
41. “Intanto vai avanti con le altre
cose”
- Costo nullo del context switch
(falso)
- Le attività lasciate aperte
restano ferme (falso)
Thursday, September 19, 13
42. “Intanto vai avanti con le altre
cose”
- Costo nullo del context switch
(falso)
- Le attività lasciate aperte
restano ferme (falso)
- Fare è sempre meglio di non
fare (falso)
Thursday, September 19, 13