In una squadra che pratica il Domain Driven Design, l'intero team dovrebbe partecipare alle riunioni delle parti interessate?

Non penso che riguardi il ruolo, ma riguarda molto l' atteggiamento . In uno scenario perfetto, proverei ad avere tutta la persona interessata nella stessa stanza per discutere attivamente del modello. Ma in uno scenario perfetto ho deciso di avere una stanza disponibile adatta, con gli strumenti necessari e le persone abbastanza disciplinate per gestire questa conversazione. Non è così facile.

Affinché la collaborazione creativa possa effettivamente accadere, una strana cosa non tecnica chiamata alchimia è probabilmente il requisito numero uno. L'esperto di domini è la fonte d'informazione più importante (sebbene non l'unica) e dovrebbe essere a suo agio nell'esplorare il modello insieme al team, o parte di esso. Se gli incontri sono troppo lunghi, noiosi o privi di significato, l'attenzione è persa e abbiamo perso il nostro obiettivo. Inoltre, alcuni sviluppatori potrebbero non avere l'atteggiamento giusto per partecipare a questo incontro. Potrebbe essere utile un ruolo di facilitatore, per evitare che la conversazione diventi troppo tecnica.

L'intero obiettivo è una profonda comprensione condivisa del dominio. Questo non succederà se c'è un livello tra DE e il team. Ma se l'incontro è sgradevole, non accadrà neanche. Quindi la mia regola generale è "portare le persone disposte a partecipare, a meno che ciò non renda l'incontro privo di significato". Secondo il punto di partenza questo potrebbe essere un processo di inserimento graduale di più persone, a partire da quelle che vogliono per partecipare.

Inoltre, il tipo giusto di esperto di domini (quello che conosce le risposte alle domande perché ) potrebbe non essere così facilmente disponibile. Quindi avere un grande incontro quando tutti sono presenti è probabilmente meno efficiente di una riunione più piccola prima.

Diversi anni fa ho lavorato in un posto dove era solito mettere interi team in riunioni, solo per il bene di non escludere nessuno. Ora, per quasi dieci anni, lavoro in un luogo in cui solo quelle persone si incontrano e hanno davvero bisogno di discutere insieme, e gli altri membri del team sono invitati solo occasionalmente (e non per l'intera riunione) a discussioni su argomenti direttamente correlati al loro lavoro.

Da quell'esperienza, posso dirvi che il secondo approccio è molto più efficiente. Tuttavia, funziona così bene perché chiunque può porre domande ai nostri esperti di dominio ogni volta che sorge una domanda, indipendentemente da una riunione formale.

Raccomando anche di dare un'occhiata al libro di Steve Maguire "Debug del processo di sviluppo ". Descrive che un passo importante nel migliorare l'efficienza di un team di sviluppo è di tenerli lontani da distrazioni inutili come riunioni inutili. Dalla mia esperienza personale, posso confermare questo 100%

Le sessioni di modellazione del dominio rispettano le stesse regole di ogni riunione: i partecipanti più attivi, la riunione più disordinata. Nella mia esperienza, non puoi avere una sessione di progettazione veramente focalizzata e produttiva con più di un esperto di dominio e uno o due sviluppatori.

Tuttavia, come fai notare, l'intero team ha bisogno di una conoscenza condivisa del dominio. È qui che le riunioni di pianificazione e stima di Agile fanno da complemento alle piccole sessioni di modellazione del dominio. Qualche tempo prima dell'inizio di un rilascio, l'esperto del dominio spiegherà un gruppo di funzionalità a tutti i membri del team utilizzando il linguaggio ubiquitario che ha preso forma durante le precedenti sessioni di modellazione del dominio. I membri del team possono dare il loro feedback e proporre nuove idee, adattando e arricchendo il linguaggio onnipresente. Poco prima dell'inizio di un'iterazione, l'intero team esaminerà nuovamente un sottoinsieme di queste funzionalità, le rivaluterà e le suddividerà in attività, con l'opportunità di apportare modifiche finali ai dettagli del dominio.

Il linguaggio e il modello ubiquitario relativi a una funzione o un insieme di caratteristiche devono passare attraverso diverse fasi di perfezionamento prima che siano pronte per essere implementate. Queste fasi coinvolgono persone diverse in momenti diversi. Non hai un solo incontro big bang in cui tutto è deciso sul dominio.

C'è un problema con la composizione del tuo team: gli esperti di dominio non fanno parte del team.

Uno dei punti chiave di DDD è includere gli esperti di dominio in team per garantire una migliore collaborazione e l'emergere di un linguaggio ubiquo. Certo, non hanno bisogno di lavorare a tempo pieno per la squadra, probabilmente non ci sarà abbastanza lavoro per loro qui. Ma devono essere sempre disponibili per gli sviluppatori per fare domande e chiarimenti. Questo approccio ha tutti i vantaggi e nessuno degli svantaggi.

L'unico problema è come convincere il cliente a "prestarti" gli esperti del dominio mentre non sono realmente i tuoi dipendenti. Ma sono sicuro che ci sono alcuni modi HR per rendere questo facile e semplice.

Lascia che la responsabilità e l'autorità siano la tua guida. Se qualcuno ha la responsabilità o l'autorità di prendere decisioni, e l'argomento di tali decisioni è discusso, dovrebbero probabilmente essere alla riunione.

Tuttavia, Fred Brooks parla del Design of Design e confronta e contrappone diverse cose che sono state fatte da un comitato con cose che sono state fatte da grandi visionari del software.

Questo dipenderà dall'ambito del progetto e dall'agenda della riunione.

Per tutte le riunioni iniziali di progettazione, potrebbe essere una perdita di tempo coinvolgere tutti i membri del team, in quanto alcuni di questa discussione sarebbero argomenti molto importanti per loro. Invece, potrebbero essere semplificate e facili da capire le descrizioni tecniche da Team Lead.

Inoltre, alcune delle decisioni prese in quella riunione potrebbero non sembrare logiche per tutti gli sviluppatori. Poiché ogni decisione può prendere in considerazione alcune considerazioni non tecniche che non sono discusse apertamente a causa di milioni di altri motivi (politica aziendale, riservatezza, ecc.).