Como a capacidade deve ser distribuída através das equipes?

Depois de ler isso, Vi que parece haver muita discordância sobre como as equipes ágeis devem ser estruturadas dentro de um grupo de desenvolvedores com capacidade variada (também conhecido como quase todas as equipes). Todos os melhores desenvolvedores devem ser colocados em suas próprias equipes e receber o trabalho de maior prioridade? Isso garantirá que as tarefas mais importantes sejam concluídas. Ao mesmo tempo, você fica com as equipes "menos perfeitas" em outros lugares acumulando dívidas técnicas, mesmo que sejam apenas em tarefas de baixa prioridade. Por outro lado, as equipes uniformemente distribuídas podem ter o benefício de melhorar um pouco os desenvolvedores que estão atrasados, mas têm o potencial de desmotivar seus jogadores mais pesados. Além disso, se você misturar vários bons padrões de design com vários antipadrões terríveis, pode realmente acabar com algo que pode muito bem ser um monte de antipadrões.

Existem alguns riscos conhecidos no A-Teams, mas se a dinâmica estiver correta, acho que sim, colocaria meu pessoal mais forte nos projetos mais importantes, juntamente com os desenvolvedores juniores com maior potencial. Para seus projetos de baixa prioridade, você precisa de um bom líder de equipe, se possível, para evitar que eles se afastem dos trilhos. Dívida técnica vai acontecer, não importa o quê. Nem toda dívida técnica é igual; o custo / responsabilidade da dívida técnica é proporcional ao valor comercial do projeto, portanto, embora seus projetos de menor prioridade possam ter mais verrugas, o custo deles provavelmente ainda é muito menor do que os problemas significativos em seus projetos de alta prioridade. estar.

Lembro-me de quando estava na universidade, um de nossos professores, nos contando uma anedota sobre estruturas de equipes (procurei o artigo sobre o qual ele estava falando agora, mas não consigo encontrá-lo).

Basicamente, a história foi a seguinte:

Um grupo de programadores foi dividido em grupos com base na capacidade, com os piores x programadores sendo agrupados, o próximo x agrupado, etc., e os melhores, agrupados.

Todos receberam a mesma tarefa e receberam um prazo definido para concluí-la.

No final do período, os organizadores analisaram as soluções para as tarefas e, para sua surpresa, descobriram que a solução com melhor desempenho vinha da equipe composta por pessoas comuns. Por outro lado, a equipe formada pelos programadores A * fez uma das piores soluções porque passava o tempo todo discutindo sobre qual era a melhor solução .

Se você precisa de uma equipe que faça as coisas, pegue um monte de caras comuns e um cara dominante que possa liderar, foi a conclusão do estudo (se bem me lembro), caso contrário, os membros mais dominantes passarão mais tempo lutando do que recebendo coisas feitas!

A grande maioria dos desenvolvedores inexperientes talvez não consiga criar projetos robustos e elegantes por conta própria, mas eles podem reconhecê-lo e entendê-lo quando vêem um. Se não puderem, geralmente não têm a aptidão nem a preparação para serem contratados.

Existem também alguns desenvolvedores mais experientes, capazes de entender projetos de software muito complexos, mas não têm a discrição para saber quando algo mais simples seria melhor.

Na minha experiência, você normalmente só tem problemas permanentes com equipes mistas se elas contiverem membros despreparados, membros desnecessariamente complexos ou ambos. Caso contrário, se sua equipe tiver problemas, geralmente eles podem ser corrigidos com melhor comunicação ou designando funções apropriadas.

O agrupamento das melhores pessoas para uma única equipe pode parecer uma ótima solução de curto prazo, mas é uma falha no escopo de longo prazo e possui custos adicionais. Por exemplo, minha empresa prefere quando as pessoas aprendem com seus colegas mais qualificados em vez de pagar por treinamentos. Se você separar as melhores pessoas, elas não poderão transferir conhecimento para pessoas menos qualificadas. Em curto prazo, suas melhores equipes podem ter um bom desempenho, mas, devido à falta de transferência de conhecimento, o número de pessoas qualificadas não aumentará. É muito melhor ter uma equipe com menos desempenho no início e aumentar o desempenho de todas as equipes à medida que as pessoas se tornam mais hábeis.

Além disso, o que acontece se pessoas qualificadas decidirem sair? Quem levará seus projetos?

Outro ponto é que a equipe deve ser composta por pessoas com diferentes conjuntos de habilidades. Você sempre terá tarefas fáceis (e tarefas chatas), caras demais para serem realizadas pelos desenvolvedores mais antigos.

Aqueles que não sabem ensinar, fazem ...

Eu acho que há mais fatores a considerar.

Você obterá mais valor distribuindo aqueles que podem ensinar como líderes de equipe. Eles podem ensinar os outros membros da equipe e ajudar a elevar a qualidade de seu trabalho.

Nem todos os programadores seniores farão bons leads. Essa capacidade de comunicar informações é uma habilidade em si mesma. Essa habilidade não é algo que se desenvolve através da experiência em programação. Ele se desenvolve através do ensino e da explicação.

A atribuição de uma equipe 'A' tem dois problemas significativos. Primeiro é a compatibilidade. Ter equipes que se dão bem e trabalham bem juntas é muito mais importante do que sua "habilidade". Agora, podem ser dois programadores de habilidade "alta", dois programadores de habilidade "baixa" ou uma mistura. O fato de poderem trabalhar bem juntos significa que serão mais produtivos.

A segunda questão lida com crescimento. Dois programadores de habilidades "baixas" não aprenderão muito um com o outro, além de maus hábitos. Da mesma forma, dois programadores "altamente qualificados" não aprenderão muito um com o outro. No entanto, misturar níveis de habilidade "baixo" e alto "ajudará a melhorar as habilidades da habilidade" baixa ", além de melhorar as habilidades dos qualificados" altos ". Como tentar ensinar um assunto encontrará rapidamente seus pontos fracos nesse Não considerei uma habilidade "dominada" até que você possa ensiná-la a outra pessoa.

Do outro lado da moeda, acho que faz sentido manter equipes que possam "acompanhar" umas às outras. Seus programadores do tipo A-Team não querem esperar que os tipos B-Team façam seus bits. Seus tipos de equipe B podem ser intimidados pelo fluxo de trabalho no estilo A-Team.