Como atualizar os novos membros da equipe com o projeto? [fechadas]

Estamos prestes a contratar 1-2 novos engenheiros para a equipe de software (composta por 3 desenvolvedores, 1 testador).

Quais são as etapas para integrá-los à equipe?

Minhas idéias são:

• leia a documentação (padrões de codificação, documentos nas metodologias de desenvolvimento que usamos)
• levá-los a ler o código existente
• atribuir-lhes algumas tarefas simples
• no final, torne-os responsáveis ​​pela parte do código

O que mais poderíamos fazer?

O projeto está em um setor médico (sistema de ultrassom) e já está em 5 anos. Temos lançamentos anuais e estamos prestes a concluir um lançamento, quando queremos adicionar 1-2 engenheiros.

O projeto está em fase de manutenção (refatorando o código legado, além de adicionar novos recursos). As coisas estão praticamente dentro do cronograma (mais ou menos).

Vindo de alguém que teve que acelerar várias bases de código diferentes na minha carreira, eis o que eu sugeriria:

1. Passe um curto período de tempo (talvez um dia ou dois) com atividades relacionadas ao uso do produto, para que possam se familiarizar com o que o produto faz. Pode ser a verificação de bugs ou a execução de planos de teste de controle de qualidade ou o treinamento do usuário.
2. Trabalhe em pequenos erros localizados. Isso familiariza o engenheiro com a criação e depuração do aplicativo sem precisar aprender muito da arquitetura.
3. Idealmente, escreva um pequeno novo recurso localizado. Isso permite que eles escrevam um pedaço de código e, à medida que o escrevem, se familiarizam com os bits de código ao redor dos quais seu novo código precisa trabalhar.

A partir daí, expanda o escopo e a complexidade das atribuições ao longo do tempo, dependendo do nível de experiência e aptidão do engenheiro. Isso permitirá que o desenvolvedor expanda seus conhecimentos sobre a base de código naturalmente.

Eu evitaria ler apenas tarefas (documentação ou código). Ler a documentação fica muito chato muito rápido e ler o código aleatório não é útil, pois eles não terão nenhum contexto para trabalhar. Já é difícil ler o código para revisões de código quando você já conhece o produto e a base de código. Não vejo nada de útil em ter um engenheiro novinho em folha lendo o código.

Meu sentimento é que a tolerância da maioria das pessoas em ler a documentação é bastante baixa (boa por um dia ou dois, mas além disso elas provavelmente estarão ansiosas para fazer algo um pouco mais prático).

Eu não acho que você possa realmente entender o código de um aplicativo sem um entendimento razoável do próprio aplicativo. O software presumivelmente possui muitas funcionalidades com as quais eles poderiam "brincar" como usuário; eles precisarão testá-lo eventualmente, então eu espero que seja bastante importante que eles saibam como instalá-lo, configurá-lo e executar tarefas comuns com ele

Pessoalmente, acho que uma visão geral da arquitetura de alto nível geralmente é bastante útil para obter uma noção básica de como as coisas funcionam - talvez aloque uma ou duas horas do tempo de um engenheiro sênior (ou você mesmo, se necessário?) Em sua primeira semana, simplesmente para passar os parafusos básicos da aplicação principal. por exemplo, entender todos os subsistemas e como as coisas estão interligadas, sabendo quais bits são tratados por bibliotecas / softwares de terceiros e quais bits precisam ser mantidos internamente. (A menos que sua organização tenha documentação atualizada de qualidade verdadeiramente excepcional, acho que não há como eles entenderem esse tipo de coisa sem que alguém as explique diretamente usando um quadro branco: )))

Quanto a dar a eles algo "prático", as tarefas de manutenção / busca de bugs podem ser uma boa maneira de mantê-las atualizadas por um tempo (algumas semanas / meses?) - elas estarão em situações nas quais áreas específicas de funcionalidade precisa ser entendido, testado e depurado; ajudando a desenvolver o conhecimento do código, dos requisitos, das ferramentas usadas pela empresa, dos processos de desenvolvimento e do (s) produto (s) como um todo, e espero não precisar gastar muito tempo com o restante da equipe de desenvolvimento

Como líder, passo pelo menos 2 dias com novos desenvolvedores. Descobri que desenvolver um relacionamento no qual é confortável fazer a inevitável pergunta "como está seu progresso?" é uma obrigação. Existe medo em qualquer nova comunidade ... escondemos erros, agimos com perfeição, melhoramos as coisas do que são, diminuímos as dificuldades. Um gerente que passa dois dias com alguém informa que não é disso que se trata sua cultura e permite que eles liderem pelo exemplo. Novos codificadores precisam de uma lição de história sobre de onde você veio e até que ponto você está. Os documentos simplesmente não fazem justiça à tarefa.

Eu só trabalho na indústria há 10 meses (na colocação), mas achei o seguinte me ajudou:

• Trabalhando em equipe com outros desenvolvedores e observando como eles lidam com os problemas.
• Testando o software ajudado, eu precisaria testar o recurso x, o que significa que li a documentação no recurso x. Eu fiz muito isso, ajudou.

Ambos me ajudaram um pouco. Boa sorte.

Eu iria de alto a baixo.

Demonstre o aplicativo o mais rápido possível

Uma das coisas mais importantes é que o desenvolvedor tem uma idéia no que trabalhará. Durante a demonstração, aponte algumas das coisas que estão em desenvolvimento recente e a direção que o aplicativo está seguindo.

Explicar a arquitetura de alto nível

Isso também é muito importante. Permita que o novo desenvolvedor ouça e faça perguntas. Faça isso como um exercício de grupo com os outros desenvolvedores, que esperançosamente entrarão em contato e o ajudarão. Isso permitirá que o novo desenvolvedor saiba que não há problema em falar aberta e honestamente.

Tenha um ótimo documento de embarque pronto

Ter um ótimo documento de embarque não ajuda apenas os novos desenvolvedores, mas também os antigos. Pode conter expectativas, links úteis e informações de configuração do ambiente. (Não posso dizer quantas vezes eu usei nossa integração para configurar meu ambiente quando recebo um novo computador ...) Isso deve ser bem estruturado e direto ao ponto, não deve demorar e não deve ser um depósito de lixo para todos pequeno detalhe.

Incentive-o a fazer perguntas (e esteja disponível para respondê-las)

Com as respostas, guie-as, mas não diga a elas o que fazer. Dê-lhes dicas, mas permita-lhes finalmente descobrir por si mesmos.

Ajude os outros membros da equipe a receber o recém-chegado

Existem dois lados da moeda quando alguém se junta a uma equipe. A equipe precisa ter as ferramentas para receber o novo desenvolvedor também.

Deixe-os pegar uma pequena tarefa ou duas

Permita que eles adicionem algo novo e visível ao projeto que seja demonstrável. Quando for demonstrado, indique quem fez e que bom trabalho eles fizeram. Isso pode realmente aumentar a auto-estima. Quanto mais rápido eles sentem que estão agregando valor, mais rápido eles sentem que fazem parte da equipe. Quanto mais rápido eles se sentirem habilitados a fazer o melhor que puderem.

Incentive-os a realizar tarefas mais difíceis quando se sentirem cada vez mais à vontade

Bons candidatos farão isso naturalmente.

Um fluxo de "orientação" pelo qual passei (e achei útil) foi algo como:

1. Uma breve apresentação dando ao "Quadro Geral" quais são os componentes, como o encaixe e a arquitetura geral.
2. Uma visão geral do código, introdução às funções que lidam com a lógica principal do (s) componente (s) atribuído (s) a mim. Cobrimos algumas coisas relacionadas a convenções e estilo de codificação.
3. Foram atribuídos vários problemas em aberto e erros de baixa prioridade (que foram localizados em grande parte no componente atribuído a mim e bastante simples).
4. Era esperado que depurasse o aplicativo e pedisse ajuda com coisas que não conseguia decifrar.
5. Depois que a correção foi feita, fui orientado pelo processo (revisão de código, teste no nível do desenvolvedor etc.) de liberação para integração.
6. Repita o procedimento para as demais tarefas / bugs alocados.

Eu acho que essa abordagem (e variações dela) será útil porque:

• Este foi um trabalho mais prático e relativamente independente (constante, sem manutenção, etc.). Portanto, fornece espaço / tempo suficiente para a nova pessoa se acostumar com o código e com a maneira como as coisas são feitas na equipe.
• Também é benéfico para a equipe como um todo, pois algumas tarefas / bugs de baixa prioridade podem ser resolvidos. A pessoa que ajuda as novas pessoas também tem mais tempo para lidar com as tarefas que lhes são atribuídas, uma vez que não é necessária a manutenção constante das mãos e o horário pode ser especificamente agendado para lidar com problemas / questões que a nova pessoa possa enfrentar.

As contratações iniciais precisam de uma tarefa pequena, mas não muito pequena e bem definida para trabalhar. Dessa forma, eles podem começar a entender como o código é estruturado, tentando descobrir como realizar sua tarefa. No processo, surgirão perguntas e, nesse ponto, você pode direcioná-las para a documentação ou outros recursos que eles podem usar para ajudá-los a internalizar a base de código. Também ajuda se o ciclo de desenvolvimento, consolidação e implantação for curto e eles puderem ver os frutos de seu trabalho em ação o mais rápido possível.

É assim que eu vou

1. Dê a eles algumas tarefas relacionadas ao projeto (por exemplo: se o seu projeto for um aplicativo de banco de dados, peça a eles que apenas criem um aplicativo para se conectar ao banco de dados e que executem alguma operação simples).
2. Quando você perceber que eles entenderam a ideia de trabalhar, faça uma demonstração do Projeto
3. Peça que eles leiam a documentação.
4. Familiarize-os com os estilos e padrões de codificação
5. Posteriormente, faça alguns exercícios de depuração (para conhecer o fluxo do projeto).
6. Peça a eles que fixem um ponto que você já corrigiu (apenas para descobrir a lógica deles).
7. Finalmente, faça-os parte do projeto.

Lembre-se: não importa o quanto você tente, até e a menos que o participante compreenda o projeto completamente, você não será capaz de realizar um trabalho mais eficiente com ele.

Número um - primeiro aprenda como usar o software para descobrir quais problemas ele resolve da perspectiva do usuário. Se não tiver uma interface do usuário (por exemplo, é um serviço de back-end ou algo assim), deixe-os usar qualquer interface disponível para consumi-lo. Obter uma nova visão da visão do usuário sobre o seu software é sempre bom e pode ajudar o novo funcionário a ver coisas que você não pode, devido ao fato de já estar incorporado no projeto.

Depois disso, um bom primeiro projeto pode ser algo como um complemento ou um novo módulo a ser adicionado ao software, minimizando a quantidade de conhecimento necessário da base de código existente. Escrever algo novo sempre será mais fácil do que executar uma correção de bug, o que pode exigir muitas alterações em muitos arquivos de origem. Na minha opinião, atribuir a um novo funcionário uma tarefa de correção de bug provavelmente os desligará da sua empresa.

Seu esquema para familiarizar os novos com o projeto parece razoável. Mas lembre-se de que eles terão muito a aprender no começo. Isso geralmente é uma situação avassaladora. Você terá que ser paciente e responder às mesmas perguntas repetidamente. Isso é normal, os novos desenvolvedores precisam aprender muito, não subestime isso. Se você se zangar com essas perguntas repetidas, corre o risco de que elas não façam perguntas e tentam descobrir coisas sozinhas que talvez sejam muito lentas, na melhor das hipóteses, mas freqüentemente impossíveis. Também eles terão que aprender a linguagem. A maioria dos projetos de equipes desenvolve seu próprio idioma. Ao explicar conscientemente, tente evitar o jargão. Explique essas coisas como você explicaria para sua mãe. Mais uma vez, seja paciente.

Além disso, você pode tentar integrá-los aos demais membros da equipe, tentando algumas tarefas no estilo do centro de avaliação, por exemplo, construir uma ponte em 45 minutos a partir de 4 folhas de papel com uma xícara de café. Usamos essa técnica em um curso prático de engenharia de software para obter um grupo de 8 alunos para quebrar o gelo antes de trabalharem em um único projeto por 3 semanas. Ajuda a acelerar a fase de formação da equipe.

1) Dê a eles uma explicação sobre suas regras e diretrizes de código. Também forneça uma explicação geral de como seu aplicativo funciona e a estrutura geral do código.

2) Encontre alguns pequenos bugs ou projetos que são amplamente independentes de outro código. Explique o que precisa ser feito, onde está o código e verifique-os regularmente.

3) Comece lentamente a dar-lhes projetos cada vez maiores, enquanto verifica cada vez menos.

4) Sente-se ao lado deles de tempos em tempos. Você pode aprender muito apenas olhando como alguém lida com um problema. Coisas pequenas como "oh, você pode procurar funções no seu código pressionando ctrl-". são muito úteis.

Agora, descobri que existem dois extremos :

• Alguém que faz uma pergunta a cada cinco minutos. "O que esse Path.Join faz?". Eles devem procurar o Google primeiro para obter uma resposta e somente procurá-lo quando não conseguem encontrar uma resposta.

• E o outro extremo, alguém que trabalha por meio dia sem fazer uma única pergunta. Eles devem achar que é uma boa coisa fazer perguntas. Eu só quero que eles tentem primeiro eles mesmos.

Esta foi a minha fórmula e usada com vários novos participantes - essas etapas provaram ser altamente eficazes.

a) Todos os novos desenvolvedores receberão uma introdução sobre os requisitos do projeto e os processos de desenvolvimento por 2 dias.

b) Atribuir 3 semanas de tarefa de escrever testes Junit para o código que não possui cobertura suficiente.

c) Quando terminar 3, atribua pequenas tarefas

d) Atribuir tarefas complexas e concluídas.

Eu acho que apenas atribua algumas tarefas pequenas, peça para que escrevam alguns testes de unidade, faça com que eles depurem algumas falhas de regressão. Nada muito grande ou exigente, mas o suficiente para tê-los em pé.

Você também deve designar um desenvolvedor sênior, de preferência por novo desenvolvedor que possa ajudar a orientar o candidato.

E sim, faça-os documentar o que estão aprendendo sobre o sistema. Estou assumindo aqui que você tem algum tipo de páginas wiki internas. Caso contrário, é definitivamente uma obrigação, tanto a longo como a curto prazo - uma maneira surpreendentemente rápida de fazer as pessoas acelerarem. As páginas da Wiki não devem conter apenas a documentação do código, mas também limitações conhecidas (como software: D), soluções alternativas, métricas de desempenho de tempo / memória, etc.

Não explique apenas as boas práticas e os padrões de codificação, mas explique como o código de leitura está estruturado. Explique o que o software deve fazer e como isso é ou será alcançado.

Eles não entenderão até que haja algum trabalho a ser feito, então sugiro que se dividam em duas partes, uma antes de começar o trabalho real e a segunda parte depois de começarem a trabalhar. Eles procurarão em alguns códigos ou documentações e pensarão " WTF !? ". Quando isso ocorre, alguém os acompanha e explica os pequenos detalhes.