Qual a melhor forma de envolver o desenvolvedor júnior no design de um aplicativo a partir do zero? [fechadas]

Somos uma equipe de 3 desenvolvedores (2 desenvolvedores experientes e um júnior).

Acabamos de iniciar um novo projeto. Projetamos o aplicativo, concentramos esforços na escolha da arquitetura certa e agora estamos lançando as primeiras linhas de código. Estamos escrevendo o núcleo, qual será a base de todo o aplicativo.

Também não é uma aplicação fácil. Requisitos de alto desempenho, modelo de entidade complexo, massivamente distribuído etc.

Estamos todos fora da nossa zona de conforto, especialmente os juniores. Ele não tem experiência para criar um bom design antecipadamente. Isso não é um problema, porque eu e o outro desenvolvedor estamos lá para ajudar e nós dois acreditamos em orientação e formação de equipes, mas ... não sabemos exatamente qual seria a melhor maneira de fazer isso, para que ele uma experiência agradável e aprende a quantidade máxima de habilidades.

Nós dois percebemos que não tínhamos um júnior em novos projetos, apenas em projetos existentes, onde era mais fácil para o júnior, porque ele tinha uma base de código inteira para aprender e inspirar. Mas para este aplicativo, quase não temos código. Nós apenas começamos.

Estávamos pensando em algumas abordagens:

• peça para ele tentar sozinho por alguns dias, depois intervir e refatorar o código junto com ele, conduzi-lo na direção certa e depois repetir => Pode não ser uma experiência divertida para ele, pois apontaremos seus erros em todos os refatores ;
• faça com que ele pare de programar com um de nós => ele pode se tornar apenas um "espectador" e concordar com tudo o que fazemos, sem realmente aprender muito ou digerir muita informação;
• faça-nos construir o esqueleto de cada módulo, com um design sólido e, em seguida, dê-lhe o módulo para adicionar as peças que faltam => pode não ser divertido pegar depois de nós e existe o risco de ele prestar atenção apenas para preencher as lacunas e não para todo o design.

Como podemos envolvê-lo no design para que ele não se sinta deixado de fora dele e para que ele aprenda muito com a experiência e ganhe confiança suficiente para experimentá-lo por conta própria?

Eu recomendo as seguintes diretrizes:

• Envolva o desenvolvedor júnior em suas reuniões de design e solicite sua opinião. Isso fará com que ele pense sobre o cenário geral, mesmo que ele não esteja pronto para fazer o design de alto nível.
• Tente isolar e definir claramente um módulo do aplicativo a ser atribuído ao desenvolvedor júnior. Descreva por escrito quais são as entradas / saídas e outros requisitos do módulo. Evite atribuir a ele um módulo que não pode ser facilmente testado ou que só pode ser testado quando integrado a outros módulos ainda a serem gravados.
• Talvez o desenvolvedor júnior possa ajudar de outras maneiras além da codificação do aplicativo principal. Por exemplo, ele poderia escrever código de teste. Longe de ser um trabalho servil, escrever bons scripts de teste faz uma contribuição valiosa para o projeto e também fornece ao desenvolvedor júnior uma sólida compreensão do projeto.

Acho que depende de qual área você deseja que esse desenvolvedor júnior melhore. Quando eu era (muito) júnior, eles costumavam me fornecer APIs que eu precisava criar uma coisa confinada em particular, como:

• esta função fornece N número de pessoas da tabela Pessoal
• esta função fornece estatísticas de pessoal, dada a identificação do pessoal

->

Tarefa: crie uma página com uma lista de pessoal que mostre suas estatísticas quando um registro pessoal for clicado. Aqui está uma página de amostra simples criada anteriormente no projeto.

O aspecto mais importante da tarefa especificada é ser solucionável apenas pelos recursos fornecidos e não requer nenhuma alteração neles.

Todas as três maneiras parecem boas para mim. Na verdade, tentar 10 maneiras ágeis diferentes ao mesmo tempo deve fornecer bons resultados em breve, pelo menos você saberá qual caminho funciona e qual não funciona (qual deles funcionará melhor depende muito das personalidades dos jogadores).

O problema de programação dos pares não ocorrerá se você se ater ao processo com os chapéus de digitação / pensamento alternando a cada 10 minutos (mais ou menos), sem exceção, seguindo o processo originalmente descrito por Kent Beck (não me lembro onde)

Quanto ao envolvimento de outras pessoas no design - o que descobrimos que ajuda é se, durante a fase de design, alguns documentos de design (com alguns modelos UML) são criados. As outras pessoas (seu filho mais novo) podem então lê-las, revisá-las e fazer o papel de advogado do diabo. Esse papel de uma terceira parte independente e preservada pode ser realmente muito benéfico, por exemplo, para testes exploratórios - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries