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

12

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.

Dmitry Negoda
fonte
2
se você contratar mais desenvolvedores, você só solta na produtividade nos primeiros meses - Eu nunca ouvi falar se ele, mas tenho certeza de que é mais
BЈовић
2
O que acontece quando você tenta integrar as duas partes novamente? Existe uma chance de as duas partes passarem nos seus próprios testes, mas um grande teste de integração em todo o lote falhará? Eu suspeito que você vai descobrir que a lei de Brook não é tão facilmente contornada. Excelente pensamento criativo; vale um +1. E eu realmente gostaria de saber como isso funciona para você.
Dawood diz que restaura Monica
1
javana: Nós vamos contratar desenvolvedores experientes
Dmitry Negoda
2
@DmitryNegoda Se você puder encontrá-los em tempo suficiente. Os desenvolvedores experientes normalmente não estão desempregados, portanto, mesmo que você os entreviste e ofereça a eles um cargo amanhã, eles provavelmente precisarão avisar o atual empregador algumas semanas antes de começarem. Se eu fosse você, prepararia um plano de contingência, por exemplo, como se preparar para trabalhar noites e fins de semana por um tempo.
maple_shaft
4
Não importa o quão surpreendente de um desenvolvedor que você começa, eles não vão entender 100k linhas de código em menos de um mês ~ talvez três semanas
Ryathal

Respostas:

1

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.

umlcat
fonte
Estamos falando de apenas 100K linhas de código, não é tão complexo, no entanto obrigado pela preocupação
Dmitry Negoda
1
@ Dmitry Negoda: complexidade não é uma função do LOC.
jmoreno
Há uma pesquisa considerável (por exemplo, por Boehm) que mostra que a produtividade do programador, em média, é uma função do LOC.
precisa
15

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.

Caleb
fonte
1
+1 para definir por escrito de requisitos, eles estão desatualizados um pouco ...
Dmitry Negoda
3
E quem vai entrevistar essas novas contratações, atualizar os requisitos escritos e os documentos de design, preencher o banco de dados de bugs, gastar tempo nas sessões de treinamento ... ?? São os desenvolvedores atuais? Porque isso significa que eles não estarão desenvolvendo em tempo integral. Então a velocidade de desenvolvimento diminui . Opa
precisa saber é
O código é auto-documentado e vamos contratar apenas desenvolvedores experientes. E sim, os desenvolvedores atuais ajudarão os novos e sua velocidade diminuirá um pouco. Só espero que a contratação de desenvolvedores no projeto 100K loc não seja tão dolorosa quanto a contratação no projeto 270K loc, e essa foi a questão.
Dmitry Negoda
Você tem um wiki interno ou tudo está armazenado em documentos do Word espalhados pela LAN?
Spencer Rathbun
1
100k, 50k ou 10k representarão a mesma coisa - uma tonelada de código que nenhuma pessoa estará transferindo para sua cabeça. Se houver centenas de linhas de código, isso é razoável. Depois de conseguir vários milhares, você tem um sistema complexo e os desejos de velocidade geralmente não são alcançados.
Michael Durrant
12

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.

Péter Török
fonte
4
+1 - você definitivamente deseja usar seus antigos desenvolvedores para trazer os novos integrantes. Embora seja inevitável que isso o atrapalhe um pouco.
Mikera
+1 também. Você deseja que seus desenvolvedores experientes orientem as novas pessoas. Mesmo que os novos funcionários tenham muita experiência, eles não saberão exatamente como sua empresa faz as coisas.
Andy Andy
9

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.

Alex D
fonte
Ainda não há prazos. Esperamos um aumento sério no número de clientes em potencial, criando parcerias. Queríamos apenas que nossa solução fosse mais competitiva, para que os parceiros nos escolhessem. Não são os prazos que buscamos, sua capacidade demonstrável de oferecer novos recursos. Mas obrigado pela preocupação.
Dmitry Negoda
Se for esse o caso, talvez em vez de tentar dobrar seu ritmo de desenvolvimento em uma única etapa, talvez você possa tentar "acelerar" por um período de tempo.
Alex D
4

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.

mhoran_psprep
fonte
Não entendo como o teste de novos recursos ajudará a entender a base de código. Também estamos contratando engenheiros de controle de qualidade, para que os desenvolvedores desenvolvam e testem os testadores.
Dmitry Negoda
2

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. .

HLGEM
fonte
Sim, para todas as suas perguntas, exceto a última.
Dmitry Negoda
0

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.

JeffO
fonte
Mike Partridge mudou minha pergunta. Eu não vou jogar ninguém do precipício. É claro que os novos desenvolvedores trabalharão em conjunto com os experientes, apenas em um subprojeto diferente.
Dmitry Negoda
Só espero que a contratação de desenvolvedores no projeto 100K loc não seja tão dolorosa quanto a contratação no projeto 270K loc, e essa foi a questão.
Dmitry Negoda