Em uma equipe praticando o Design Dirigido por Domínio, toda a equipe deve participar das reuniões das Partes Interessadas?

Eu não acho que é sobre o papel, mas é muito sobre a atitude . Em um cenário perfeito, eu tentaria ter toda a pessoa relevante na mesma sala para discutir ativamente sobre o modelo. Mas, em um cenário perfeito, consegui ter uma sala adequada, com as ferramentas necessárias e as pessoas disciplinadas o suficiente para administrar essa conversa. Não é tão fácil assim.

Para que a colaboração criativa aconteça efetivamente, uma coisa estranha e não técnica chamada alquimia é provavelmente o requisito número um. O Especialista de Domínio é a fonte de informação mais importante (embora não a única) e ele deve estar à vontade para explorar o modelo junto com a equipe, ou parte dela. Se as reuniões são muito longas, muito chatas ou sem sentido, a atenção é perdida e perdemos nosso objetivo. Além disso, alguns desenvolvedores podem não ter a atitude correta para participar desta reunião. Um papel facilitador, para evitar que a conversação se torne técnica demais, pode ser útil.

O objetivo total é um profundo entendimento compartilhado do domínio. Isso não acontecerá se houver uma camada entre o DE e a equipe. Mas se a reunião for desagradável, isso também não acontecerá. Então, minha regra de ouro é "trazer pessoas dispostas a participar, a menos que isso torne a reunião sem sentido". De acordo com o ponto de partida, isso pode ser um processo de inserção gradual de mais pessoas, a partir daquelas que querem participar.

Além disso, o tipo certo de Especialista em Domínio (aquele que conhece as respostas para as perguntas por que ) pode não estar tão facilmente disponível. Portanto, ter uma grande reunião quando todos estão presentes é provavelmente menos eficiente do que ter uma reunião menor mais cedo.

Vários anos atrás eu trabalhei em um lugar onde era comum colocar equipes inteiras em reuniões, apenas para não excluir ninguém. Hoje, há quase dez anos, trabalho em um local onde apenas as pessoas se reúnem para discutir as coisas, e outros membros da equipe são convidados apenas ocasionalmente (e não para toda a reunião) para discussões sobre assuntos diretamente relacionados à sua trabalho.

A partir dessa experiência, posso dizer que a segunda abordagem é muito mais eficiente. No entanto, funciona tão bem porque todos podem fazer perguntas aos especialistas do nosso domínio sempre que surgir uma dúvida, independentemente de qualquer reunião formal.

Eu também recomendo dar uma olhada no livro de Steve Maguire "Depurando o processo de desenvolvimento ". Ele descreve que um passo importante para melhorar a eficiência de uma equipe de desenvolvimento é mantê-los longe de distrações desnecessárias, como reuniões desnecessárias. Pela minha própria experiência, posso confirmar isso 100%

As sessões de modelagem de domínio seguem as mesmas regras de qualquer reunião - quanto mais participantes ativos, mais confusa a reunião. Na minha experiência, você não pode ter uma sessão de design realmente focada e produtiva com mais de um especialista em domínio e um ou dois desenvolvedores.

No entanto, como você indica, toda a equipe precisa de um conhecimento compartilhado do domínio. É aqui que as reuniões de planejamento e estimativa do Agile brilham como um complemento às sessões de modelagem de domínio menores. Algum tempo antes do início de um lançamento, o especialista do domínio explicará um grupo de recursos para todos os membros da equipe usando a linguagem onipresente que tomou forma durante as sessões anteriores de modelagem de domínio. Os membros da equipe podem dar seu feedback e propor novas idéias, ajustando e enriquecendo a linguagem onipresente. Pouco antes do início de uma iteração, toda a equipe examinará novamente um subconjunto desses recursos, reestimando-os e dividindo-os em tarefas, com a oportunidade de fazer ajustes finais nos detalhes do domínio.

A linguagem e o modelo onipresentes pertencentes a um recurso ou a um conjunto de recursos devem passar por vários estágios de refinamento antes de estarem prontos para serem implementados. Esses estágios envolvem pessoas diferentes em momentos diferentes. Você não tem apenas uma reunião do Big Bang em que tudo é decidido sobre o domínio.

Há um problema com a composição da sua equipe: especialistas em domínio não fazem parte da equipe.

Um dos pontos-chave do DDD é incluir especialistas em domínio em equipe para garantir uma melhor colaboração e o surgimento de uma linguagem onipresente. Claro, eles não precisam trabalhar em tempo integral para a equipe, provavelmente não haverá trabalho suficiente para eles aqui. Mas, eles precisam estar disponíveis a qualquer momento para que os desenvolvedores façam perguntas e esclarecimentos. Esta abordagem tem todas as vantagens e nenhuma das desvantagens.

O único problema é como fazer com que o cliente "empreste" os especialistas do domínio enquanto eles não são realmente seus funcionários. Mas tenho certeza que existem algumas maneiras de fazer isso fácil e simples.

Deixe a responsabilidade e a autoridade como seu guia. Se alguém tem responsabilidade ou autoridade para tomar decisões, e o assunto dessas decisões é discutido, elas provavelmente deveriam estar na reunião.

No entanto, Fred Brooks fala sobre o Design de Design e compara e contrasta várias coisas que foram feitas pelo comitê com coisas que foram feitas por grandes visionários de software.

dependerá do escopo do projeto e da agenda da reunião.

Para todas as reuniões iniciais de design, pode ser um desperdício de tempo envolver todos os membros da equipe, já que algumas dessas discussões seriam tópicos realmente importantes para eles. Em vez disso, eles podem simplificar e entender as descrições técnicas do líder de equipe.

Além disso, algumas das decisões tomadas nessa reunião podem não parecer lógicas para todos os desenvolvedores. Como cada decisão pode levar em conta algumas considerações não técnicas que não são abertamente discutidas devido a milhões de outras razões (política da empresa, confidencialidade, etc.).