Como adicionar um novo desenvolvedor à equipe

Dirijo uma pequena empresa composta por apenas 2 desenvolvedores. Estamos construindo um aplicativo muito grande para um de nossos clientes. O desenvolvimento deste projeto já dura 1,5 anos.

Agora esse cliente garantiu um patrocínio importante e está organizando eventos relacionados a este projeto. Portanto, agora temos um prazo em 2 meses e não podemos perdê-lo.

Estamos pensando em adicionar um novo desenvolvedor à equipe e estou pensando no que podemos fazer para ajudar sua integração.

Esta é a situação:

• Estamos nos aproximando do limiar da lei de Brooks - o ponto em que adicionar novos desenvolvedores será contraproducente.
• O aplicativo é relativamente bem projetado, mas a implementação é caótica em alguns pontos (especialmente em códigos mais antigos).
• Existem testes de unidade apenas para códigos mais recentes. Quando esse projeto começou, não realizamos testes regularmente.
• A documentação e os comentários estão incompletos.
• A aplicação é grande e complexa.
• O cliente anotou quase todos os detalhes de seu projeto, de uma maneira muito clara e "amigável ao programador".

É uma boa ideia adicionar uma pessoa agora? Nesse caso, o que podemos fazer para ajudar o novo desenvolvedor a integrar-se à equipe?

EDITAR:

O patrocinador está organizando um evento esportivo na Internet para a próxima primavera. Ele deve começar em um dia específico do ano. Nós não podemos mudar isso.

O que nós desenvolvedores (eu sou um dos dois) precisamos fazer é:

• Conclusão do aplicativo existente (cerca de 25% do trabalho a ser realizado).

• Criando um novo módulo, essencial para a organização deste evento (cerca de 75% do trabalho a ser realizado). Este novo módulo não pode ser desenvolvido sem entender a API do programa principal.

Não posso fazer uma estimativa exata do tempo, mas estamos em uma situação de risco.

A melhor coisa a fazer é não jogar o novo desenvolvedor no fogo, mas criar algumas funcionalidades e / ou correções de bugs nas quais o desenvolvedor não deve ter problemas para entrar. Encontre uma área que precise de trabalho que não exija que uma pessoa conheça toda a arquitetura, requisitos e base de código de uma só vez. Talvez peça a ele que trabalhe na documentação para aprender o sistema mais rapidamente.

Em vez de adicionar um novo desenvolvedor à equipe, considere adicionar um consultor experiente pelo período de dois a três meses para lidar com o aumento temporário da carga de trabalho da sua empresa. A idéia é conseguir alguém que possa lidar com um tempo de inicialização quase zero, mas ao mesmo tempo pode não ser necessariamente o melhor complemento para sua equipe.

Mesmo se você acha que o aumento da carga de trabalho não é temporário, agora provavelmente não é o melhor momento para aumentar sua equipe organicamente: adicionar um terceiro desenvolvedor é uma coisa estressante para uma equipe, mesmo sem a pressão do prazo do projeto; prazo apertado apenas piora a transição.

A desvantagem é que, em troca de uma ajuda temporária, você obterá o código escrito por alguém de fora. Para atenuar esse risco, certifique-se de que você faça todas as revisões de código com ele. Certifique-se de revisar e entender todos os testes de unidade dele também.

É uma boa ideia adicionar uma pessoa agora?

Não. Se possível, tente fazer o cliente concordar em reduzir o escopo.

Adicionar uma pessoa tão tarde adicionará um risco significativo, e o prazo não pode ser ultrapassado (até onde eu entendi).

Não faça isso.

Ainda.

Visão tradicional

Na sua pergunta, você se refere à lei de Brooks no Mythical Man-Month .

A adição de mão de obra a um projeto de software atrasado o torna mais tarde.

Ignorar a lei de Brook tem um preço. Não faça multitarefa. Concentre-se na entrega do seu produto mínimo viável (MVP). Em seguida, concentre sua energia no recrutamento, recursos, treinamento e gerenciamento de um novo membro da equipe.

Dois meses é tão curto. Planeje o recrutamento com uma lista de seleção e você verá como isso pode consumir tempo.

Larry Page e Sergei Brin passaram dois anos escolhendo a equipe inicial do Google. Sua escolha para o funcionário número três também deve ser cuidadosa.

Agile, nova visão do milênio

A competição impulsiona as equipes dinâmicas mais agora do que na época em que Mythical Man-Month foi escrito (meados da década de 1960). Carreiras longas em uma empresa se foram. Agora, migramos frequentemente entre projetos e empresas. A rápida formação de equipes cria sucesso. O aumento lento é um fator limitante grave. Grandes exemplos vêm de projetos de código aberto, startups e o aumento do uso de projetos de equipe em cursos de ciência da computação.

Potencialmente, as equipes Agile levam em consideração as restrições em seus agendamentos. Eles não se atrasam porque são otimizados para os recursos disponíveis. A integração de novas equipes é mais uma restrição e é considerada uma troca entre objetivos de curto e longo prazo. A equipe do Agile integra continuamente o código. Por que não as pessoas também?

A integração técnica e social da equipe ágil para novos funcionários pode usar:

• scrums diários
• programação em par
• refatoração
• adicionando testes de unidade ausentes
• engordando documentação enxuta
• revisões de código

O Cordeiro Sacrificial

Em " Padrões organizacionais de desenvolvimento ágil de software", James Coplien discute a dinâmica do grupo e os custos de adicionar novos membros da equipe. Seu padrão "Cordeiro Sacrificial" atribui toda a orientação e treinamento a uma pessoa, protegendo o restante da equipe da interrupção.

É uma estratégia que você pode considerar implementar.

Outra estratégia é atribuir mentores de novos contratados que cobrem perguntas de novos contratados por horas específicas a cada dia. Se você pode poupar apenas um cara, talvez ele trabalhe sem interrupção pela manhã ou à tarde e responda perguntas à tarde ou pela manhã, respectivamente. O grupo em que eu participei teve dez estagiários no último verão, então muitas pessoas foram muito interrompidas.

Atualmente, a orientação é realizada por uma pessoa, principalmente durante e imediatamente após o scrum da manhã (das 8h30 às 9h15, combinado) e à tarde entre as 12h e as 3h30 (ele trabalha das 7h às 15h30). PM).

Estou muito animado por você ter mencionado a Lei de Brook. Bem feito. O principal problema com a adição de outro desenvolvedor é a sobrecarga para mantê-los atualizados e a sobrecarga do estado de sincronização com eles sobre onde você está no projeto. Portanto, se você decidir obter um terceiro desenvolvedor, eu tentaria o seguinte:

• Dê ao novato uma área em que os custos atualizados sejam baixos e ele possa avançar o mais rápido possível. Isso vai depender muito de quem você contrata e de quais habilidades eles têm.
• Certifique-se de que esta área esteja fracamente acoplada a outras áreas do aplicativo, para que a sobrecarga da sincronização seja menor. Enviá-lo para fazer um trabalho intenso no banco de dados e reorganizar as tabelas pode ser demais.
• Faça o que puder para manter o moral atualizado. Como outros observaram, adicionar um novo membro da equipe pode ser estressante, portanto, talvez um investimento em bebidas com gás possa ajudar.

Se você seguir rigorosamente a Lei de Brook, provavelmente nunca aumentará sua equipe.

O truque é atrair a nova pessoa sem ser atingido com muita lentidão em sua equipe atual. Eventualmente, a nova pessoa estará pronta, e você poderá superar o obstáculo.

No seu caso? Eu recomendaria que a nova pessoa escrevesse todos esses testes de unidade ausentes.

1. Isso é extremamente necessário como proteção contra erros de regressão, que o queimará mais rápido do que qualquer desaceleração da Brooks.
2. Nova pessoa vai aprender as entranhas do seu sistema. É um pouco de tentativa de fogo - mas a saída deles não está entrando no código de produção, portanto há pouco risco.
3. Coloque um limite rígido para quanto tempo os outros membros da equipe podem levar. Por exemplo, faça com que eles enfileirem perguntas e permitam apenas 30 minutos por dia interagindo com outros membros da equipe até que o prazo seja cumprido.

Além disso, vamos ser sinceros: você terá que gerenciar o escopo e as expectativas do cliente, independentemente de trazer ou não uma nova pessoa. A recompensa vem no próximo ciclo.

Ed Yourdon fez um ótimo comentário sobre a Lei de Brook. Ele disse: é claro que adicionar pessoas fará com que você vá mais devagar - mas quando um projeto está em risco é a única vez que a gerência atrai novas pessoas. Portanto: tome-os, minimize o impacto na versão atual e livre-se dos que apresentam desempenho ruim o mais rápido possível. Dessa forma, com o tempo, você pode formar uma equipe forte.

Se você trabalha em outros projetos, pode dar a ele um tempo livre para que os dois desenvolvedores atuais se concentrem nos grandes resultados finais do prazo que podem ajudar.

Você diz que precisa completar 25% do trabalho original, além de um novo trabalho. E você precisa fazer isso em dois meses - quando você levou 18 meses para fazer 75% do trabalho. Para ser muito franco, isso indica para mim que suas habilidades de estimativa são aproximadamente médias para um programador focado em código - ou seja, você acha que as coisas levarão cerca de metade a um terço, enquanto realmente são.

O Heroics pode permitir que você entregue o produto contratado, mas isso não fará nenhum favor para você ou seu cliente. Será péssimo e cheio de bugs nessas condições, e você estará funcionando com fumaça.

Lembre-se de que o tempo gasto na contratação também terá um grande impacto na sua disponibilidade - isso não é algo que você pode fazer em um fim de semana; leva tempo para encontrar funcionários talentosos que se encaixam bem. Espere passar pelo menos algumas semanas pesquisando, entrevistando etc. Espere que você e seu funcionário existente percam cerca de 10 horas por semana de tempo produtivo enquanto pesquisam.

Minha recomendação:

Sente-se com seu cliente, explique que você está louco e trabalhe com ele para reduzir o escopo ao mínimo.

Editar Acabei de ver a data aqui. Então, como isso acabou? (Agradecemos à Ars Technica por postar uma pergunta de três meses;)

Existem algumas maneiras diferentes de considerar a investigação:

1. Adie a contratação do novo desenvolvedor até que o prazo termine, para que seja mais fácil se concentrar em passar o conhecimento do domínio para o novo cara. Essa seria minha preferência, pois poderia ser um pouco desafiadora de algumas maneiras.

2. Traga o novo desenvolvedor para trabalhar na documentação, testes de unidade e outras coisas que não estão alterando nenhum código existente. Isso seria o que eu sugeriria se você trouxesse o novo funcionário para tentar minimizar o impacto na carga de trabalho atual.

A data já passou, mas para quem ler isso mais tarde.

O principal a considerar é que o cliente nessa situação tem muito mais a perder do que você. Eles já gastaram muito dinheiro e têm um evento importante chegando que pode fazer ou quebrar seus negócios. Você já tem o dinheiro deles e perder um único cliente não deve prejudicar seus negócios. Se isso acontecer, você terá outros problemas comerciais sérios além do terrível gerenciamento de projetos.

Sua melhor aposta é negociar um subconjunto essencial de funcionalidades e depois trabalhar horas extras para fazê-lo. Se você não pode fazer um subconjunto menor acontecer ou não está disposto a fazer horas extras nessa situação, provavelmente não deve estar no negócio. Isso pode significar colocar outros clientes em espera, no entanto, acho que seus outros clientes não pagaram por três anos-homem, portanto coloque seus recursos onde está o dinheiro.

Se eles não estiverem dispostos a negociar o escopo, então você está pronto para falhar.

Não há chance de entregar este projeto completamente dentro do prazo. Se você acha que ainda tem 25% de um projeto que levou 18 meses para ser entregue até agora, então tem pelo menos 6 meses (de ~ 2 desenvolvedores). Adicionar outra pessoa não mudará isso significativamente.

Como foi apontado, o recrutamento leva tempo. Minha experiência é que leva um mês no mínimo. Em seguida, adicione treinamento e seu tempo acabou.

Espero que tenha funcionado para você.