O que fazer com uma equipe de desenvolvimento que está morrendo de fome? [fechadas]

É péssimo estar no caminho crítico como desenvolvedor normal, especialmente se você estiver atrasado. Quando você é o desenvolvedor sênior, que a equipe procura liderança, é ainda pior.

Quando o trabalho para a maioria da equipe fica parado, esperando por uma peça crítica, o que o resto da equipe deve fazer? Temos acesso limitado à peça crítica, para que outros simplesmente esperem, não importa o que façamos. Quando os outros procuram conselhos sobre o que fazer, o que é uma boa resposta?

Aprimore testes de unidade, testes funcionais, documentação, ferramentas, etc. Há uma infinidade de coisas que podem ser feitas em tempo de inatividade enquanto aguarda o caminho crítico.

Embora eu goste da resposta sobre como melhorar os testes, a documentação etc., e ela é boa, você também pode olhar para:

• Ajudando o componente do caminho crítico, seria mais rápido com a programação de equipe / amigo?
• Reestruturando o componente crítico em vários subcomponentes nos quais todos podem trabalhar.
• Escolha o componente crítico com algo, possivelmente áspero, que faz basicamente o mesmo trabalho, mas possivelmente não é rápido o suficiente para a produção.
• Estabeleça uma API para o componente crítico, corrija isso mais ou menos em pedra e ajude a obter a funcionalidade básica desse componente implementada (sujeita a alterações na implementação, mas não na API).
• Veja se você pode usar versões anteriores problemáticas conhecidas do componente crítico para trabalhar no restante do sistema em que a funcionalidade é "boa o suficiente por enquanto".

Também é uma boa idéia iniciar a fase "lições aprendidas" agora, registrando que esses componentes críticos precisam ser iniciados no início do processo de desenvolvimento, possivelmente antes da montagem do restante da equipe.

Você precisa de um plano de backup para sua entrega tardia

Se uma peça crítica já está atrasada, não há garantia de que ela não escorregue ainda mais. O que então? Você apenas espera para sempre? Esse não é o tipo de resposta que você deseja fornecer à gerência superior.

Construa um simulador

Uma maneira de gerenciar o risco é começar o trabalho em um simulador (arnês, calço, topo, como você quiser chamar) para substituir a peça crítica que falta.

Possui uma interface definida? Implementá-lo.

Possui documentação detalhada? Imite o melhor que puder.

É apenas ideia de alguém? Veja se você pode obter um protótipo.

Então, quando eles deslizam a agenda novamente ....

Dessa forma, quando eles atrasarem o cronograma novamente, você terá um ás no bolso de trás para fechar a lacuna. Sua equipe não será apenas desbloqueada (eles podem se integrar ao simulador), mas você obterá um ativo valioso de software.

Se eles atrasarem ainda mais a programação, use o tempo para escrever testes de integração automatizados (no seu simulador, por enquanto). Dessa forma, quando eles entregam a coisa real, você pode simplesmente executar seus testes e detectar quaisquer diferenças comportamentais entre a maquete e a entrega. Isso permitirá que você se concentre nos pontos que precisa revisar. Como bônus, você rapidamente terá uma idéia do quanto eles cortam os cantos à medida que o tempo acaba.

Se o componente crítico tiver uma interface conhecida e se não houver esperança de fazê-lo em um curto espaço de tempo, por que não criar um teste duplo (por exemplo, uma simulação )?

Isso permitiria à equipe continuar a codificação, embora os resultados do teste fossem um pouco menos significativos.

Além do óbvio "faça todas as coisas que você não conseguiu fazer até agora", parece que você e sua equipe não têm a tranqüilidade de fazer qualquer coisa não relacionada ao projeto final. O que é compreensível, mas não é útil.

Portanto, o verdadeiro problema pode ser relaxar com isso. Não estou dizendo indiferente. Esteja ciente de sua responsabilidade, do que você pode fazer para ajudar e, se isso deixar você com tempo em suas mãos, aproveite. Você não pode nem precisa ficar no seu pé o tempo todo. Se você é um líder, eu diria que esta deve ser sua mensagem. Transferir seu nervosismo para a equipe não tornará uma equipe mais produtiva quando for importante.

Você não diz qual metodologia está usando, o que dificulta aconselhar exatamente.

Onde trabalho, se houver um bloqueador, todas as mãos da bomba farão o possível para acelerar o desenvolvimento.

Considere se pode haver um problema maior com você como líder assumindo demais. Sim, as pessoas o procurarão por liderança técnica, mas isso não significa que alguns dos membros mais capacitados da equipe não possam compartilhar a carga de trabalho se forem orientados.

Além disso, existe algum outro trabalho não crítico em que eles possam avançar? Além disso, existe algum trabalho concluído que possa ser mais aprimorado (refatorado, removendo dívidas técnicas, documentação, adicionando testes etc.).

Se realmente não houver nada, forneça algo a eles - analise registros, construções, documentos, planos de teste, projetos, diagramas, escreva agendas, organize reuniões, faça sessões de sacola marrom, compartilhe conhecimento etc. Há sempre algo a fazer. Se as pessoas estão dispostas a ficar sentadas sem fazer nada na moeda da empresa, elas devem ser escaladas, já que claramente não são jogadores de equipe.