Dar a novos recrutas um subprojeto separado de desenvolvedores experientes ajudará os novatos a aumentarem mais rapidamente?

Temos 7 desenvolvedores em uma equipe e precisamos duplicar nosso ritmo de desenvolvimento em um curto período de tempo (cerca de um mês). Eu sei que existe uma regra de bom senso que "se você contratar mais desenvolvedores, você só perde em produtividade nos primeiros meses". O projeto é um serviço da web de comércio eletrônico e possui cerca de 270 mil linhas de código.

Minha idéia no momento é dividir o projeto em dois subprojetos mais ou menos independentes e deixar a nova equipe trabalhar no menor dos dois subprojetos, enquanto a equipe atual trabalha no projeto principal. Ou seja, a nova equipe trabalhará na funcionalidade de checkout, que acabará se tornando um serviço da web independente para diminuir o acoplamento. Dessa forma, a nova equipe trabalha em projetos com apenas 100 mil linhas de código.

Minha pergunta é: essa abordagem ajudará os desenvolvedores iniciantes a se adaptarem facilmente ao novo projeto? Quais são outras maneiras de estender a equipe de desenvolvimento rapidamente, sem esperar dois meses até que os novatos comecem a produzir mais software do que erros?

=======

ATUALIZAR

Essa empresa falhou completamente, mas não pelos motivos mencionados por vocês. Antes de tudo, fiquei mal informado sobre o tamanho e a capacidade da nova equipe. Eu deveria tê-los avaliado eu mesmo. Segundo, a contratação acabou sendo um trabalho árduo naquele local. No local da sede, a contratação era muito mais fácil, mas na cidade da segunda equipe havia aparentemente uma escassez de desenvolvedores com a qualificação necessária. Como resultado, em vez de projetar 1,5 meses, o trabalho se estendeu para cerca de 4,5 meses e foi cancelado no meio pela alta gerência.

Outro erro que cometi (e fui avisado por Alex D) é que estava tentando vender a refatoração para a alta gerência. Você nunca vende refatoração, apenas recursos.

A inicialização acabou sendo bem-sucedida de qualquer maneira. A refatoração que nunca aconteceu se transformou em dívida técnica: o sistema tornou-se mais monolítico e menos sustentável, a produtividade do desenvolvedor diminuiu gradualmente. Não estou no time agora, mas espero que eles o completem no futuro próximo. Caso contrário, eu não daria um centavo pela sobrevivência do projeto.

Embora, eu concordo como todos os outros aqui, que:

"... adicionar mais desenvolvedores a um projeto atrasado, torna o projeto, atrasar mais ..."

Eu tenho a sensação de que você fará em qualquer lugar, então ...

Sua ideia pode ajudar, se o projeto existente, for suficientemente organizado, por módulos, subsistemas ou subprojetos.

O que você pode querer tentar é dar a eles pequenos pedaços / módulos / formulários / classes do seu projeto, para trabalhar, em vez de todo o projeto.

Se você usa um banco de dados, convém fazer uma cópia de um banco de dados em funcionamento com dados e acessá-los a partir do módulo ou subsistema de código com o qual trabalhará.

Não basta ter novos desenvolvedores que conhecem a linguagem de programação ou o ambiente de programação, as aplicações de software podem se tornar muito complexas.

Você tem alguma documentação da aplicação como: UML, ER, Codd-Yourdon, o que seja?

Boa sorte.

Minha pergunta é: essa abordagem ajudará os desenvolvedores iniciantes a se adaptarem facilmente ao novo projeto?

"Novato" pode significar algo novo para você ou pode ser novo para trabalhar como desenvolvedor de software. Se você for contratar um grupo de desenvolvedores para trabalhar em um projeto importante dentro do cronograma, verifique se pelo menos a maioria dos novos contratados são desenvolvedores experientes e, de preferência, aqueles que escreveram projetos semelhantes aos que você está tentando construir.

Quais são outras maneiras de estender a equipe de desenvolvimento rapidamente, sem esperar dois meses até que eles comecem a produzir mais software do que erros?

• Compre ou licencie um produto existente em vez de tentar criar o seu próprio. Você realmente precisa reinventar a roda de pagamento?

• Como eu disse acima, contrate pessoas com experiência em criar o tipo de sistema que você deseja.

• Mesmo antes de contratar essa nova equipe, você deve pensar no que eles precisam saber sobre o que você já tem. Reserve um tempo suficiente para as sessões de treinamento para ajudá-las a acelerar.

• Você criou um conjunto de requisitos por escrito? Se não, faça isso agora. Se você espera projetar o projeto em vez de permitir que a nova equipe faça isso, também deve preparar um documento de design claro, mas esteja aberto a alterações em resposta às sugestões dos novos membros da equipe.

• Você tem um processo de desenvolvimento bem definido? Banco de dados de bugs? Controle de versão? Processo de revisão de código? Guia de estilo? Coloque essas coisas no lugar.

• Não espere milagres. Você deseja contratar uma equipe de sete pessoas e tê-las trabalhando produtivamente em questão de semanas, mas querer isso não significa que você pode ter isso. Dependendo da sua localização, pode levar muito mais que um mês para encontrar sete pessoas adequadas. Tentar apressar as coisas agora só causará dor e despesa posteriormente.

IMHO colocando todos os novos desenvolvedores no novo projeto, separados da sua equipe existente, é obrigado a trazer problemas. Sim, isso pode permitir que sua equipe antiga continue trabalhando mais ou menos no ritmo atual. No entanto, os novos caras não terão idéia sobre a arquitetura geral e o cenário geral, então eles levarão muito tempo para se atualizar ... e mesmo assim eles podem estar indo na direção errada.

Sugiro dividir sua equipe existente em duas e contratar novos membros nas duas equipes. Dessa forma, existem pessoas em ambas as equipes que podem orientar os recém-chegados e garantir que uma visão arquitetônica comum e coerente seja mantida.

Caso contrário, concordo com Caleb em documentar requisitos claros, definir o processo e as ferramentas de desenvolvimento e reservar tempo para treinamento ... e também esperar que uma equipe de 7 pessoas seja contratada e se atualize dentro de um mês é irrealista.

Dmitry, dobrar seu ritmo de desenvolvimento em pouco tempo é uma meta incrivelmente ambiciosa. Algumas boas sugestões foram postadas aqui; mas, não importa o que você tente, saiba que isso pode não acontecer . se o seu ritmo de desenvolvimento não dobrar, quais seriam as consequências, na perspectiva dos negócios? Você está tentando pressionar para cumprir um prazo?

Se você está tentando cumprir um prazo, poderia fazê-lo de maneira mais confiável cortando recursos? Eu descobri que uma ótima maneira de tornar "prazos perdidos" aceitáveis ​​para um cliente é fazer lançamentos incrementais; libere uma versão que possui um subconjunto dos recursos necessários e, à medida que mais recursos estiverem prontos, libere-os de forma incremental, até a liberação final.

Então você está tentando ser a equipe que não é vítima do Mês do Homem Mítico . Você terá vários problemas, alguém da equipe terá que fazer as entrevistas técnicas e terá que esperar algumas semanas depois que eles aceitarem a posição antes de começarem. Pode levar dois meses até que os novos desenvolvedores estejam na frente de seus teclados.

Todo novo funcionário tem uma produtividade negativa nos primeiros meses. A situação piorou porque os desenvolvedores atuais precisarão orientá-los, diminuindo ainda mais a produtividade do sistema.

A outra parte do MMM era que, à medida que a equipe cresce, o mesmo ocorre com os problemas de comunicação. As reuniões se tornam maiores, as cadeias de e-mail se tornam mais longas ...

Eu os reunia em grupos menores e sabia que, por um longo tempo, a produtividade não será proporcional ao aumento do tamanho da equipe. Perceba também que a drenagem do fluxo de caixa durante os primeiros meses pode ser significativa, devido aos custos de embarque e equipamentos.

Em seu comentário a Alex D, você mencionou "Não são os prazos que esperamos, sua capacidade demonstrável de fornecer novos recursos". Portanto, mude para um estilo de desenvolvimento que role os recursos em partes menores e com mais frequência. Peça aos novos membros da equipe que testem os novos recursos, que os ajudarão a entender a base de código.

Seria melhor contratar ninguém novo e analisar seus processos para ver onde é possível fazer alterações para acelerar as coisas. Quanto mais cedo os bugs são encontrados, menos tempo leva para corrigi-los; então, como você está testando? Você está fazendo análises de código? Você está prestando atenção à qualidade da exigência? Você tem processos de compilação e de plotagem automatizados? Você tem testes automatizados? Você está tendo reuniões de stand-up diárias (incrível o quanto o desenvolvimento pode ser mais rápido quando alguém pede sua punição todos os dias!)? Você está usando processos ágeis? Você tem algumas falhas básicas de design que devem ser tratadas para acelerar o restante do desenvolvimento (o design ruim pode atrasar incrivelmente um projeto de desenvolvimento).

Por favor, leia o mês do homem mítico. Você claramente precisará informar para a gerência sênior por que eles estão fazendo as escolhas desgastadas para acelerar um projeto. .

Então você quer jogá-los de um penhasco e ver se eles podem voar? Acho que quando você descobre as coisas por conta própria, elas tendem a ficar com você a longo prazo, em vez de apenas ter soluções dadas a você. No entanto, isso pressupõe que você realmente descubra melhores soluções. Não vejo por que você não pode permitir que essa equipe tenha um líder qualificado que equilibrará, deixando que cometam alguns erros por conta própria, além de fornecer orientação e instrução aprendendo com exemplos de qualidade.