DDD è di destra?

Nov 29 2022

"DDD è una cosa di destra!" Dietro questa affermazione provocatoria (ideale per lanciare una sessione unconf e avere persone), Simon Chaveneau ha voluto porsi la questione dell'impatto del Domain Driven Design (DDD) sulla nostra organizzazione (Product-Tech) per produrre software. È successo durante la nostra prima non-conferenza in Agicap, organizzata per permettere alle persone di Prodotto e di Tecnologia di incontrarsi per discutere, imparare, condividere, ridere, ma soprattutto prendere quota rispetto alla nostra quotidianità.

"DDD è una cosa di destra!"

Dietro questa affermazione provocatoria (ideale per lanciare una sessione unconf e avere persone), Simon Chaveneau ha voluto porsi la questione dell'impatto del Domain Driven Design (DDD) sulla nostra organizzazione (Product-Tech) per produrre software. È successo durante la nostra prima non-conferenza in Agicap, organizzata per permettere alle persone di Prodotto e di Tecnologia di incontrarsi per discutere, imparare, condividere, ridere, ma soprattutto prendere quota rispetto alla nostra quotidianità.

Il nostro 1° unconference ad Agicap, 13 ottobre 2022

Durante una non conferenza, il programma è stabilito dal pubblico. Viene fatto durante una sessione iniziale di "Market Place" al mattino. Durante questa prima plenaria della giornata, tutti possono prendere adesivi, un pennarello e poi presentare le proprie sessioni davanti a tutti. Poi le persone li posizionano nel programma del giorno (per maggiori informazioni su questa non conferenza, c'è questo thread twitter )

Ma torniamo all'argomento e all'intrigante sessione proposta da Simon.

Versione francese di "DDD è una cosa di destra!"

Il regno della proprietà privata?

Per riassumere il discorso iniziale di Simon: se intere sezioni del nostro IS appartengono a team — ciascuno responsabile di uno o più Bounded Context (BC) — non ci troviamo di fronte a una versione software della proprietà privata (con filo spinato intorno ai BC, ecc. .)? Da qui il suo provocatorio “ DDD è roba di destra! ”

E con la domanda sussidiaria: “Non saremmo più efficienti con un'organizzazione basata su feature team? (con tutti in grado di lavorare su tutti i BC sulla strada per i loro casi d'uso)"

Beh… devo ammettere che questa sessione si è rivelata molto più fruttuosa di quanto avessi inizialmente sperato perché ne è scaturita una discussione davvero affascinante sulla nostra modalità di organizzazione Prodotto/Tecnologia.

Ma piuttosto che dettagliare il percorso intrapreso da questa sessione in cui eravamo molto numerosi (sicuramente interessante da descrivere nel contesto di un altro post), descriverò direttamente ciò che ho conservato e pensato sull'argomento.

Alcune osservazioni

Un software efficace è un software allineato alle sfide aziendali . Per allineato intendiamo un software che prende in prestito i termini giusti dal campo del dominio, che articola correttamente i concetti chiave del business e richiama il meno possibile la complessità accidentale causata da problemi tecnici. Questa è una delle principali sfide del Domain Driven Design (DDD), come spiegato qui in 3 minuti .
La legge di Conway non è un'opzione che si potrebbe scegliere di non prendere.‍♂️ Agisce un po' come certe leggi fisiche come l'attrazione della gravità. Possiamo provare a combatterlo ;-) ma è ancora valido sulla terra. La legge di Conway è quella legge del 1967 che afferma che
"Qualsiasi organizzazione che progetta un sistema (definito in senso lato) produrrà un progetto la cui struttura è una copia della struttura di comunicazione dell'organizzazione".
In altre parole, l'architettura di un software è necessariamente il risultato delle modalità di comunicazione delle persone coinvolte nella sua progettazione. Ad esempio, un compilatore sviluppato da 3 team molto probabilmente funzionerà in 3 passaggi o avrà 3 moduli distinti.
Inverse Conway Maneuver (ICM) ti fa pensare che si possa controllare la legge di Conway. Inizialmente questa manovra inversa consigliava saggiamente di “ abbattere i silos che limitano la capacità del team di collaborare efficacemente”. Ma negli anni si è trasformata in una stupida raccomandazione: “ cambia la tua organizzazione per raggiungere la tua architettura target ”. Sciocco perché ricorda: “La cultura si mangia la strategia a colazione”. Maggiori informazioni qui in quel thread interessante.
Il Domain Driven Design non impone alcuna organizzazione. Fornisce le chiavi per consentire la sopravvivenza, anche nei casi di organizzazioni disfunzionali (con squadre che sono in guerra o si ignorano a vicenda). DDD ci aiuta a comprendere le questioni di potere e le questioni sociali tra i team. Di conseguenza, è piuttosto uno strumento di liberazione contro i nostri determinismi ( quindi uno strumento di sinistra direi ;- )
DDD , invece, ci fornisce gli strumenti per poter progettare un software efficiente e il più allineato possibile rispetto al dominio. Tra questi il concetto di Bounded Context (BC), che ci propone di progettare modelli per gli usi, circondarli e proteggerli da confusioni/falsi amici/incomprensioni derivanti da altri contesti.
Per un maggiore allineamento ed efficienza, DDD raccomanda inoltre vivamente di sfidare regolarmente la nostra visione e la nostra modellazione della soluzione. Significa anche rivoluzionare e cambiare i modelli di volta in volta seguendo un momento eureka (chiamato Design Breakthrough ). Ecco perché qui teniamo regolarmente sessioni di mappe contestuali che perfezionano costantemente la nostra visione del campo con le persone del prodotto.
I team di sviluppo hanno equilibri fragili. Occorrono circa 6 mesi di convivenza e relazioni interpersonali affinché un team di sviluppo sia davvero efficace. Aggiungi o rimuovi una singola persona da questo team e non è più lo stesso team (vedi Dynamic Reteaming ). In termini di efficienza, preferisco le squadre che stanno insieme e cambiano soggetto, rispetto alle squadre che vengono semplicemente esplose/ridistribuite in base alle materie. Certo, se qualcuno è stufo della propria squadra o dei propri soggetti, bisognerebbe fare di tutto per consentirgli di cambiare squadra (stare bene personalmente è ancora più importante per la nostra efficienza collettiva)
La nostra attuale organizzazione ei nostri team qui in Agicap sono piuttosto affiliati a uno o più Contesti Limitati per tener conto della complessità del problema e per capitalizzare un minimo delle nostre rispettive competenze di business. Di tanto in tanto, alcuni team potrebbero avere un ambito troppo ampio e dobbiamo tagliare e assegnare meglio il nostro contesto delimitato. D'altra parte, questa divisione di BC deve rimanere legata a concetti di business (ricordare DDD)
Nulla vieta di avere team di funzionalità in un'organizzazione che fa DDD , a condizione che tutti rispettino i confini di Bounded Contexts.
Per il momento, preferiamo di gran lunga la pratica dello Swarming (una sorta di task force istituita con persone di diversi team ma in cui la responsabilità e la proprietà dell'artefatto finale (strumento, API, libreria) è definita dall'inizio. Aiuta per evitare la sindrome del “Bene, abbiamo fatto qualcosa insieme, ma chi lo manterrà adesso?!?”). Al di là della sua efficacia nel far collaborare le persone giuste a seconda dell'argomento, lo swarming apporta molto capitale sociale alla nostra organizzazione promuovendo temporaneamente relazioni interpersonali tra team (super utili per il futuro quando tutti torneranno nella propria squadra).
La nostra attuale organizzazione di prodotto è impostata su 1 Product Manager (PM) per team di sviluppo, ma forse sarebbe interessante avere PM più associati agli argomenti aziendali che al proprio team?

Infine, direi che non c'è più proiettile d'argento nell'organizzazione di quello che abbiamo nello sviluppo. Feedback continui, domande e sperimentazione sono i nostri compagni in questo percorso di miglioramento continuo per realizzare in modo efficace software che sia rilevante per i nostri utenti.