Qual é a melhor maneira de dividir o trabalho entre desenvolvedores

Minha equipe e eu estamos reconstruindo um site que desenvolvemos há cerca de dez anos e queremos fazê-lo no Agile.

Então, depois de passar muito tempo lendo (provavelmente não o suficiente), estou tendo problemas com a questão de como dividir o trabalho entre desenvolvedores.

Vou ser mais específico e dizer que o site é dividido em módulos separados que não têm muita integração entre si.

Qual é a melhor / maneira mais aceita de dividir o trabalho entre os desenvolvedores?

• Dando a cada pessoa um módulo diferente para trabalhar.
• Atribua todos os desenvolvedores ao mesmo módulo e divida o trabalho por diferentes partes do módulo (UnitTesting, DAL e Mapping, Logics, UI)
• Atribua todos os desenvolvedores ao mesmo módulo e divida o trabalho por lógicas diferentes (por exemplo, cada desenvolvedor é responsável por uma lógica específica (provavelmente um método no BL) e é UnitTesting, DAL e Mapping and UI ...

Ou talvez algo completamente diferente?

Minha equipe está tentando se tornar "ágil" há alguns lançamentos agora, mas fazer parte de uma grande corporação não facilitou exatamente isso. Não vou fingir que tenho a resposta, mas posso compartilhar algumas das minhas observações.

• Dividindo desenvolvedores por módulo:

  • Você precisa ter cuidado, porque se as pessoas trabalharem muito isoladas, sua equipe não se beneficiará do compartilhamento cruzado de habilidades e conhecimentos
  • O planejamento de reuniões e levantamentos diários pode se tornar incrivelmente chato para todos, se as pessoas se concentrarem demais em seus próprios módulos e não tiverem uma visão geral. Quando as pessoas ficam entediadas, começam a checar e você perde muito do benefício que o ágil traz para a mesa
  • Você pode acabar com alguns componentes escritos muito bem e outros componentes, bem ... nem tanto. Se as pessoas trabalharem isoladamente, seus funcionários mais antigos não serão capazes de treinar os mais jovens.

• Todo mundo trabalha no mesmo módulo ao mesmo tempo

  • Tentamos isso em um lançamento, quando a gerência decidiu que eles impunham agilidade a toda a equipe e será completamente o seu caminho. É como um acidente de trem absoluto. Tivemos uma equipe de 9 desenvolvedores entregando em um ano o que normalmente teria sido feito por 1 desenvolvedor. (Eu posso estar exagerando aqui, mas não muito).
  • Ninguém sentiu que havia espaço para respirar. Aqueles que não se preocupavam com software se sentiam em casa porque, por fazer parte de um pacote maior, acabam se diluindo no grupo. Aqueles de nós que eram apaixonados por software, sentiam-se absolutamente sufocados, pois não havia liberdade para mudar ou sair dos limites com o que 9 pessoas concordaram.
  • Todas as reuniões foram para sempre a ponto de eu querer me matar. Muitas pessoas com uma opinião na mesma sala são forçadas a trabalhar na mesma DLL. O horror.
• No último lançamento, decidimos tentar algo diferente
  • Em primeiro lugar, divida o grupo de desenvolvimento em equipes menores de 3-4 desenvolvedores. Cada equipe trabalhava em relativo isolamento, mas dentro da equipe as pessoas trabalhavam muito mais coesa.
  • Com essa abordagem, os levantamentos são rápidos e as reuniões de planejamento levam de 1 a 2 horas, em comparação com as sólidas 4 horas.
  • Todo mundo se sente envolvido porque cada equipe discute apenas com o que os desenvolvedores dessa equipe se preocupam.
  • O líder técnico de cada equipe conversa periodicamente com outros líderes técnicos para garantir que o projeto geral esteja no caminho certo.
  • Em vez de tornar as pessoas "proprietárias" de um módulo específico, atribuímos áreas de especialização para as pessoas; portanto, quando iniciamos o projeto, parecia que as pessoas tinham seu próprio módulo, mas depois de vários meses, os desenvolvedores começaram a olhar o código um do outro como áreas começaram a se sobrepor.
  • Revisões de código são essenciais. Este foi o segundo lançamento em que tínhamos uma política rígida de revisão de código e todos na equipe os amavam. O especialista de uma área específica está sempre em uma revisão de código quando outra pessoa modifica esse código.
  • Com as revisões de código, temos um monte de compartilhamento de conhecimento e você pode ver a melhoria geral da qualidade do código de nossas equipes. Também porque o código é revisado com tanta frequência, quando as pessoas entram na área de especialização de outra pessoa, é provável que já tenham visto o código pelo menos algumas vezes.
  • Parte maior de cada equipe é sugada para as reuniões de revisão de design; portanto, mesmo que nunca tenham visto o código, todos estão familiarizados com o fluxo geral de todos os módulos pelos quais sua equipe é responsável.
  • Fizemos isso por cerca de 10 meses e parece que começamos com uma abordagem de módulo isolado e nos transformamos em todo mundo trabalha em tudo. Mas, ao mesmo tempo, ninguém se sente limitado ou limitado. E para garantir que os caras ainda tenham alguma autoridade, nós os deixamos como especialistas na área, mesmo que isso seja uma formalidade agora.

Estamos fazendo a última coisa e, embora haja muito espaço para melhorias, no geral toda a nossa equipe ficou muito feliz e isso diz muito, quando fazemos parte de uma corporação gigante.

Uma coisa importante em que erramos nas primeiras três vezes em que "fomos ágeis" é em cada uma dessas vezes em que as pessoas são instruídas a trabalhar e recebem instruções sobre como trabalhar. Essa é a maneira número um de fazer com que sua equipe perca completamente o interesse no projeto e, então, você está com um problema real.

Em vez disso, tente o oposto. Diga à equipe que eles podem fazer o que quiserem e como gerente / líder (se você é um, se não o faz repetir essas palavras), seu trabalho é garantir que eles sejam o mais produtivos e felizes possível. Processo não é uma coisa ruim, mas o processo deve estar presente para ajudar sua equipe quando perceber que precisa de um, e não o contrário.

Se alguns membros da sua equipe preferirem trabalhar isoladamente, deixe-os (até certo ponto). Se eles preferem trabalhar em pares, deixe-os fazer isso. Certifique-se de deixar seu pessoal escolher o seu próprio trabalho o máximo que puder.

Por fim, e isso é muito importante e sempre é esquecido. Você não vai conseguir esse direito (a menos que você seja o super-homem, ou pelo menos o batman). Realizar reuniões retrospectivas regulares é extremamente importante. Quando lançamos retrospectivas, elas foram feitas pelo livro e parecia mais um processo pelo qual você precisava passar. Não é para isso que serve a retrospectiva. É para ouvir sua equipe, identificar áreas que causam mais dor e corrigi-las para que todos possam seguir em frente com seu trabalho. Aparentemente, os engenheiros de software em geral, como o fornecimento de produtos e recursos, e a mais importante reunião retrospectiva de mensagens precisam se comunicar, é que isso é apenas para seu benefício. Você deseja identificar e enfrentar obstáculos, começando pelos maiores (ou mais fáceis, existem "

Faça uma reunião com a equipe, mostre a eles a lista de tarefas e pergunte quem quer fazer o que.

Não pense em módulos. Pense em elementos de funcionalidade. Descreva esses elementos de funcionalidade por histórias de usuários (ou de outra forma) e não se esqueça de descrever critérios de aceitação (provavelmente definidos por seu aplicativo atual e altere as expectativas dos negócios). Coloque seus elementos funcionais em lista de pendências. Em seguida, deixe a empresa priorizar qual funcionalidade deve ser entregue primeiro (você trabalhará de forma incremental e iterativa e a prioridade informará o que deve ser implementado primeiro).

Depois de ter isso, pelo menos em parte do aplicativo original, você estará pronto para o desenvolvimento. O que acontece a seguir depende da metodologia ágil selecionada. A parte importante é que cada funcionalidade geralmente pode ser dividida em várias tarefas e os membros da equipe selecionam as tarefas que desejam fazer - isso é chamado de auto-organização. Quando você começa com a agilidade, a auto-organização pode precisar de ajuda, onde alguém garantirá que tarefas populares e impopulares sejam compartilhadas igualmente pela equipe. Quando a equipe estiver mais madura, os desenvolvedores não hesitarão em discordar da organização atual e isso será tratado automaticamente dentro da equipe.

Pensar nos módulos desde o início não precisa ser um bom caminho. Você está reescrevendo o aplicativo por algum motivo e talvez a arquitetura atual do aplicativo, com base na separação incorreta do módulo, seja um dos motivos ocultos dos problemas visíveis. Além disso, você pode descobrir que algumas funcionalidades dos módulos existentes serão completamente redefinidas e movidas para outro local.

Embora eu concorde com a resposta de David, achei que poderia se beneficiar de alguns detalhes:

• Ágil significa que você não toma essas decisões e as impõe à equipe. Não há gerente / líder de projeto como esse. Somente a equipe.
• Os que sabem melhor como dividir o trabalho são os próprios membros da equipe.
• Discuta seu backlog e descubra o que você deseja realizar na próxima iteração / sprint.
• Use o poker planejamento ou métodos semelhantes para ter uma idéia de quanto trabalho você está indo para dividir qualquer maneira, e só então começar a dividir-se pacotes de trabalho reais em conjunto .

Basicamente, o ponto principal é: ninguém aqui no SE pode responder a essa pergunta para você, nem há muito sentido nisso, porque é muito melhor se você apresentar uma resposta como equipe.

A abordagem mais simples é geralmente a melhor.

Eu evitaria dividir tarefas em grupos como testing / log / UI / etc, a menos que você possa definir algumas razões muito boas e claras para isso. Meu raciocínio é que, quando você permite que os programadores trabalhem fora de suas áreas habituais de especialização, isso pode manter as coisas mais interessantes e desafiadoras para eles, e permitir que eles se desenvolvam e cresçam dentro de seu campo. Se você acha que as restrições de tempo exigem que você divida o trabalho com base na experiência, garanta no mínimo que cada desenvolvedor ainda seja obrigado a fazer seu próprio teste de unidade e use a revisão de código e a aceitação de testes para detectar problemas. Escrever seus próprios testes é muito ágil, e esperar o tempo dos testadores se tornarem disponíveis pode ser um desperdício.

Ao enfrentar esse mesmo tipo de dilema, empreguei a seguinte abordagem:

• Escopo do projeto. Dê a si mesmo uma idéia do que você está se metendo e desenvolva uma lista de recursos, dividindo o projeto em uma série de tarefas.

• Priorizar recursos. Decida quais recursos devem ser concluídos com antecedência e quais fornecerão valor imediato aos seus clientes. Não se preocupe se seus desenvolvedores acabam trabalhando nos mesmos módulos, mas verifique se você possui um bom processo e ferramentas para gerenciar mesclagens de código.

• Envolva sua equipe e peça aos desenvolvedores que o ajudem a dividir os recursos em uma lista de tarefas gerenciadas com mais facilidade. Revise em grupo e ajuste as tarefas conforme necessário para que possam ser estimadas com mais facilidade.

• Peça a cada desenvolvedor que escolha uma tarefa para implementar - ou um grupo de tarefas, dependendo de como suas iterações serão executadas - na parte superior da fila de prioridades, na qual o desenvolvedor gostaria de trabalhar.

• Faça com que cada desenvolvedor trabalhe em apenas uma coisa até que ela seja concluída antes de passar para a seleção do próximo item na parte superior da fila de prioridade. Você pode ficar tentado a fazer com que seu pessoal altere as tarefas ocasionalmente, no entanto, isso levará ao desperdício em termos de tempo do desenvolvedor. Se você se deparar com gargalos de dependência, precisará ajustar suas prioridades de tarefas e minimizar o desperdício.

• Não tenha medo de ter desenvolvedores executando com iterações sobrepostas e gerencie seus lançamentos de acordo. Isso ajudará a minimizar o tempo perdido entre as liberações que aguardam a conclusão das tarefas.

Por fim, ser Agile é encontrar uma solução que funcione bem para sua equipe, sua empresa e seus clientes. Cabe a você ajustar seu processo, encontrando o equilíbrio de práticas que funcionará melhor para você. Como dividir suas tarefas será uma parte muito importante de um processo muito maior, mas deve ser mantido o mais simples possível para incentivar a participação voluntária e evitar problemas difíceis de resolver relacionados ao processo, desenvolvidos posteriormente.

Nenhuma discussão organizacional da equipe de desenvolvedores estaria completa sem mencionar a Equipe Cirúrgica do Dr. Fred Brooks .

A fórmula básica é: uma equipe cirúrgica por unidade de trabalho

Definindo uma equipe cirúrgica

O conceito da equipe cirúrgica é baseado em duas idéias fundamentais:

1. Menos desenvolvedores são melhores por unidade de trabalho porque a conversa cruzada mata a produtividade.
2. Os desenvolvedores de alto desempenho superam os de baixo desempenho (e, de acordo com Brooks, não existe um desenvolvedor de médio rendimento), então é melhor dar a eles o trabalho mais importante a fazer e limitar suas distrações.

Uma equipe cirúrgica é composta de 3 a 10 desenvolvedores:

1. Um programador chefe. Um desenvolvedor de alto desempenho, que faz a maior parte da programação real.
2. Um co-piloto. Outro desenvolvedor de alto desempenho, que faz alguma programação, mas também algumas tarefas administrativas, como participar de reuniões e reunir requisitos.
3. 1 - 8 assistentes. Brooks os descreve como desenvolvedores responsáveis ​​por itens como documentação, limpeza de código, pesquisa, ferramentas / algoritmos de escrita, testes etc. Na década de 60, Brooks propôs exatamente 8 funções, mas com ferramentas modernas você pode precisar de apenas 1 ou 2, e provavelmente deve ser atribuído com base nas necessidades do seu projeto.

Definindo uma unidade de trabalho

Então, agora que podemos montar uma equipe, como os designamos?

• Se o projeto é muito pequeno , isso é fácil. Você designa uma equipe cirúrgica para todo o projeto.
• Caso contrário, você precisará começar com uma pessoa ou equipe responsável pela arquitetura do projeto inteiro . Caberá a eles modularizar o software adequadamente, para que o trabalho possa ser dividido entre sub-equipes adicionais. A equipe de arquitetura também pode assumir outro trabalho, para não espalhar os desenvolvedores por demais.

Você deve ver três padrões básicos e aceitáveis ​​emergindo:

1. Exatamente 1 subequipe para cada camada (UI, DAL, etc.)
2. Exatamente 1 sub-equipe para cada módulo (Página inicial, Site de suporte, Loja)
3. Uma mistura dos dois (uma equipe de estrutura de baixo nível e uma equipe focada na interface do usuário para cada módulo)

Dependendo do número de desenvolvedores e módulos (e escalas de tempo), geralmente faço com que meus desenvolvedores escolham um módulo interessante (para eles) e um módulo desafiador (de preferência algo que eles não fizeram) e, em seguida, divido o restante por nível de habilidade e restrições de tempo. Acho que isso dá aos meus desenvolvedores algo em que eles querem trabalhar e algo para pressioná-los.

Claro que isso nem sempre funciona ...

Aqui está o que eu faria:

Se todos os módulos forem pequenos, você poderá atribuir um módulo para cada um deles. Caso contrário, faça o seguinte:

1. Defina o tamanho de cada módulo, complexidade e habilidades necessárias para fazê-lo.
2. Defina as habilidades de cada membro da equipe.
3. Defina quais pessoas trabalham bem juntas e quais não funcionam bem com outras pessoas.
4. Atribua módulos grandes a equipes de pessoas que trabalham bem em conjunto com base nos requisitos de habilidades do módulo e nas habilidades da equipe.
5. Atribua os módulos restantes a pessoas que não conseguem trabalhar bem com outras pessoas com base nos requisitos de habilidades do módulo e nas habilidades da equipe.

O que foi dito acima não funcionará se as pessoas que não gostam de trabalhar com outras pessoas forem as mais proficientes e esse for um caso comum, portanto, faça uma exceção a 4 e 5 de acordo.