O primeiro problema que vejo é que o processo de estimativa está indo um pouco amplo. Sim, os desenvolvedores devem ter uma palavra a dizer quanto trabalho eles devem desempenhar. Não, isso não significa que adicionar um único botão a um formulário da Web agora é uma história de duas semanas do desenvolvedor (no entanto, muitos pontos equivalem ao processo de estimativa da sua empresa). Se esse é o estado atual, então você, como gerente de projeto, deve estar tentando adivinhar.
Segundo, ouço "do início (design) ao fim (implementação e teste de unidade)" e o primeiro pensamento que vem à mente é "você está fazendo errado". Seus testes de unidade fazem parte do seu trabalho de design como um desenvolvedor / equipe de desenvolvimento e devem ocorrer primeiro; você pega os requisitos básicos, destila-os em uma simples "lista de verificação" de "Se ... Quando ... Então ..." - digite sentenças e depois converta essas sentenças em uma série de testes básicos que afirmam que o programa atende àqueles afirmações e, portanto, os requisitos. Isso acontece antes de você escrever uma linha do código de produção que atenda às asserções dos testes. Se os testes de unidade chegarem por último, depois de já ter implementado o software, você perderá vários aspectos principais dos testes de unidade; em geral, seus desenvolvedores não podem "programar para verde",
Quanto aos desenvolvedores que "possuem" seus recursos, há um sim e um não. Primeiro, uma mudança bastante comum das "equipes auto-organizadas" é uma tendência para os desenvolvedores saírem em pares ou três e trabalharem nas coisas que sabem melhor. Supondo que você tenha um bom conjunto abrangente de conhecimentos de desenvolvedor, de modo que a equipe possa cobrir todo o trabalho a ser realizado em cada iteração dessa maneira, você pode simplesmente deixar isso acontecer; é uma coisa boa para a velocidade, pois os desenvolvedores permanecem focados e familiarizados com as áreas da base de código em que estão trabalhando, de iteração para iteração.
No entanto, um desenvolvedor que possui um recurso para toda a vida é uma mentalidade perigosa, porque reduz o "número de caminhões" da sua equipe (definido francamente como "quantas pessoas poderiam ser atingidas por um caminhão antes que a equipe não pudesse funcionar", dada a pior cenário possível de pessoas específicas atingidas e perda de conhecimento resultante.) Se o cara que você atribuiu ao recurso "Importação de arquivos" do seu software e o possuiu por 2 anos sai de férias por três semanas, tira licença prolongada do FMLA, muda empregos, ou ao extremo, realmente é atropelado por um caminhão e morre, agora você não tem mais ninguém que conheça esse recurso, porque essa área da base de código tem sido o alcance exclusivo de um cara há anos. com esta parte específica da base de código,você perderá velocidade significativa e também se abrirá para problemas adicionais com defeitos, pois o novo cara que está pouco familiarizado com o funcionamento da base de código agora pode permanecer lamentavelmente ignorante das coisas que pode e não pode mudar dentro dela. .
Em vez disso, você deve cultivar uma divisão do trabalho que mantenha o número de seu caminhão no mínimo 2 ou acima e em uma equipe maior (uma dúzia ou mais) mais próxima de 3 ou 4. Dessa forma, se um indivíduo não puder fazer o trabalho , por qualquer motivo, há várias outras pessoas que podem participar. Às vezes, as equipes naturalmente se agitam dessa maneira, especialmente se você introduzir algumas técnicas de XP, como programação em pares ou no estilo dojo (um cara escreve em uma nova asserção com base em nos requisitos que o código não atende; o próximo sujeito codifica para passar no teste e depois adiciona outra asserção de requisito que falha e passa adiante). Por definição, nessas situações, você tem vários olhos olhando para o código, desenvolvendo-o e familiarizando-se com ele.
No geral, a idéia do Agile é promover o desenvolvimento "leve". Sua equipe parece estar atolada em minúcias de processos e documentação, quando o foco principal, conforme o Manifesto Ágil, deve estar nos membros da equipe e em suas interações, e, é claro, no código funcional e de trabalho. Os processos inerentes ao Agile são um meio para atingir um fim e não há uma maneira única de seguir o Agile; até mesmo as estruturas principais do Agile, como o SCRUM, são maleáveis com base nas suas necessidades como empresa, equipe e até mesmo dia a dia (apenas mantenha as idéias básicas dos valores fornecidos por esses processos no coração ao fazer essas alterações).