Preciso desse bebê em um mês - me envie nove mulheres!

Sob quais circunstâncias - se houver - a adição de programadores a uma equipe realmente acelera o desenvolvimento de um projeto já atrasado?

As circunstâncias exatas são obviamente muito específicas para o seu projeto (por exemplo, equipe de desenvolvimento, estilo de gerenciamento, maturidade do processo, dificuldade do assunto, etc.). Para escanear isso um pouco melhor, para que possamos falar sobre isso em outras simplificações exageradas, vou reafirmar sua pergunta:

Em que circunstâncias, se houver, a inclusão de membros da equipe em um projeto de desenvolvimento de software que está atrasado pode resultar em uma redução na data real de entrega com um nível de qualidade igual ao se a equipe existente pudesse trabalhar até a conclusão?

Há várias coisas que considero necessárias , mas não suficientes, para que isso ocorra (em nenhuma ordem específica):

• Os indivíduos propostos a serem adicionados ao projeto devem ter:
  • Pelo menos uma compreensão razoável do domínio do problema do projeto
  • Ser proficiente no idioma do projeto e nas tecnologias específicas que eles usariam para as tarefas que receberiam
  • Sua proficiência deve / não / ser muito menor ou muito maior que o membro existente mais fraco ou mais forte, respectivamente. Membros fracos esgotarão sua equipe existente com problemas terciários, enquanto uma nova pessoa muito forte atrapalhará a equipe com a maneira como tudo o que fizeram e estão fazendo está errado.
  • Ter boas habilidades de comunicação
  • Seja altamente motivado (por exemplo, seja capaz de trabalhar de forma independente sem insistir)
• Os membros da equipe existentes devem ter:
  • Excelentes habilidades de comunicação
  • Excelentes habilidades de gerenciamento de tempo
• O líder / gerenciamento do projeto deve ter:
  • Boa capacidade de priorização e alocação de recursos
  • Um alto nível de respeito dos membros da equipe existentes
  • Excelentes habilidades de comunicação
• O projeto deve ter:
  • Uma especificação de projeto de software boa, concluída e documentada
  • Boa documentação das coisas já implementadas
  • Um design modular para permitir que pedaços claros de responsabilidade sejam cortados
  • Processos automatizados suficientes para garantir a qualidade do nível de defeito exigido. Podem incluir itens como: testes de unidade, testes de regressão, implantações automatizadas de compilação etc.)
  • Um sistema de rastreamento de bug / recurso que está atualmente no local e em uso pela equipe (por exemplo, trac, SourceForge, FogBugz, etc).

Uma das primeiras coisas a serem discutidas é se a data de envio pode ser adiada, se os recursos podem ser cortados e se algumas combinações das duas permitirão que você satisfaça a liberação com sua equipe existente. Muitas vezes, são alguns recursos que estão realmente sobrecarregando os recursos da equipe que não agregam valor igual ao investimento. Portanto, faça uma revisão séria das prioridades do seu projeto antes de qualquer outra coisa.

Se o resultado do parágrafo acima não for suficiente, visite a lista acima. Se você percebeu o recibo com antecedência, a adição dos membros da equipe certos no momento certo pode salvar a liberação. Infelizmente, quanto mais perto você chegar da data prevista de envio, mais problemas poderão ocorrer com a adição de pessoas. Em um ponto, você cruzará o "ponto sem retorno", onde nenhuma quantidade de alteração (exceto a remessa do ramo de desenvolvimento atual) pode salvar sua versão.

Eu poderia continuar, mas acho que atingi os principais pontos. Fora do projeto e em termos de sua carreira, o sucesso futuro da empresa, etc. uma das coisas que você definitivamente deve fazer é descobrir por que você estava atrasado, se algo poderia ter sido feito, alertá-lo mais cedo e quais medidas você precisa tomar para evitá-lo no futuro. Um projeto atrasado geralmente ocorre porque você era:

• Chegou atrasado antes de começar (mais coisas do que tempo) e / ou
• escorregou 1 hora, 1 dia no horário.

Espero que ajude!

Isso só ajuda se você tiver um projeto orientado a recursos.

Por exemplo, considere isso:

Você precisa pintar um cartaz grande, digamos 4 por 6 metros. Um pôster tão grande que você provavelmente pode colocar duas ou três pessoas na frente dele e mandá-las pintar em paralelo. No entanto, colocar 20 pessoas na frente dele não funcionará. Além disso, você precisará de pessoas qualificadas, a menos que queira um pôster de baixa qualidade.

No entanto, se o seu projeto é encher envelopes com cartas prontas (como você PODE ter vencido! ), Quanto mais pessoas você adicionar, mais rápido ele será. Há alguma sobrecarga na distribuição de pilhas de trabalho, portanto você não pode obter benefícios até o ponto em que tem uma pessoa só. envelope, mas você pode obter benefícios de muito mais do que apenas 2 ou 3 pessoas.

Portanto, se o seu projeto puder ser facilmente dividido em pequenos blocos, e se os membros da equipe puderem acelerar rapidamente (como ... instantaneamente), a adição de mais pessoas fará com que seja mais rápido, até certo ponto.

Infelizmente, muitos projetos não são assim em nosso mundo, e é por isso que a dica da docgnome sobre o livro Mythical Man-Month é realmente um bom conselho.

Talvez se as seguintes condições se aplicarem:

1. Os novos programadores já entendem o projeto e não precisam de tempo de aceleração.
2. Os novos programadores já são proficientes no ambiente de desenvolvimento.
3. Não é necessário tempo administrativo para adicionar os desenvolvedores à equipe.
4. Quase nenhuma comunicação é necessária entre os membros da equipe.

Vou informá-lo na primeira vez que vir tudo isso de uma vez.

De acordo com o Mythical Man-Month, a principal razão pela qual a inclusão de pessoas em um projeto atrasado o torna mais tarde é a sobrecarga de comunicação O (n ^ 2).

Eu experimentei uma exceção primária a isso: se houver apenas uma pessoa em um projeto, ele quase sempre estará condenado. Adicionar um segundo acelera quase sempre. Isso ocorre porque a comunicação não está sobrecarregada nesse caso - é uma oportunidade útil para esclarecer seus pensamentos e cometer menos erros estúpidos.

Além disso, como você obviamente sabia quando publicou sua pergunta, os conselhos do Mês do Homem Mítico se aplicam apenas a projetos atrasados . Se o seu projeto ainda não está atrasado, é bem possível que a adição de pessoas não o faça mais tarde. Supondo que você faça corretamente, é claro.

Se os programadores existentes são totalmente incompetentes, a adição de programadores competentes pode ajudar.

Eu posso imaginar uma situação em que você tinha um sistema muito modular e o (s) programador (es) existente (s) nem havia iniciado em um módulo muito isolado. Nesse caso, atribuir apenas essa parte do projeto a um novo programador pode ajudar.

Basicamente, as referências ao Mythical Man Month estão corretas, exceto em casos planejados como o que inventei. O Sr. Brooks fez uma pesquisa sólida para demonstrar que, após um certo ponto, os custos de rede e comunicação da adição de novos programadores a um projeto superam os benefícios que você obtém com a produtividade deles.

• Se as novas pessoas se concentrarem em testar
• Se você pode isolar recursos independentes que não criam novas dependências
• Se você pode ortogonalizar alguns aspectos do projeto (especialmente tarefas sem codificação, como design / layout visual, ajuste / indexação de banco de dados ou instalação de servidor / configuração de rede) para que uma pessoa possa trabalhar nisso enquanto outras continuam com o código do aplicativo
• Se as pessoas se conhecerem, a tecnologia, os requisitos de negócios e o design, o suficiente para poder fazer as coisas com um conhecimento de quando pisarão nos dedos uma da outra e como evitar isso (isso, é claro, é muito difícil de organizar, se ainda não é o caso)

Somente quando você tiver, nesse estágio avançado, algumas tarefas independentes (quase 0% de interação com outras partes do projeto) ainda não executadas por ninguém e você poderá trazer para a equipe alguém que seja especialista nesse domínio. A adição de um membro da equipe deve minimizar a interrupção para o restante da equipe.

Em vez de adicionar programadores, pode-se pensar em adicionar ajuda administrativa. Qualquer coisa que remova distrações, melhore o foco ou melhore a motivação pode ser útil. Isso inclui sistema e administração, além de coisas mais prosaicas, como almoços.

Obviamente, todo projeto é diferente, mas a maioria dos trabalhos de desenvolvimento pode garantir uma certa colaboração entre os desenvolvedores. Onde esse é o caso, minha experiência tem sido a de que recursos novos podem desacelerar involuntariamente as pessoas em quem eles confiam para torná-los mais rápidos e, em alguns casos, essas podem ser as pessoas-chave (aliás, geralmente são as pessoas-chave que seriam necessárias). o tempo para educar um newb). Quando estão atualizados, não há garantias de que o trabalho deles se encaixe nas 'regras' estabelecidas ou na 'cultura do trabalho' com o restante da equipe. Então, novamente, pode fazer mais mal do que bem. Portanto, essas são as circunstâncias em que pode ser benéfico:

1) O novo recurso possui uma tarefa árdua que requer um mínimo de interação com outros desenvolvedores e um conjunto de habilidades que já foram demonstradas. (ou seja, portando código existente para uma nova plataforma, refatorando externamente um módulo morto que está atualmente bloqueado na base de código existente).

2) O projeto é gerenciado de forma que o tempo de outros membros mais experientes da equipe possa ser compartilhado para ajudar a acelerar a novidade e orientá-los ao longo do caminho para garantir que seu trabalho seja compatível com o que já foi feito.

3) Os outros membros da equipe são muito pacientes.

Suponho que a adição de pessoas no final do trabalho possa acelerar as coisas se:

1. O trabalho pode ser feito em paralelo.

2. A quantia economizada pelos recursos adicionados é mais do que a quantidade de tempo perdida ao fazer com que as pessoas com experiência no projeto expliquem as coisas para aqueles que são inexperientes.

EDIT: Eu esqueci de mencionar, esse tipo de coisa não acontece com muita frequência. Geralmente é algo bastante direto, como telas de administrador que fazem CRUD simples em uma tabela. Atualmente, esses tipos de ferramentas podem ser gerados principalmente de qualquer maneira.

Tenha cuidado com os gerentes que se dedicam a esse tipo de trabalho para distribuir. Parece ótimo, mas, na realidade, geralmente não há o suficiente para reduzir qualquer tempo significativo do projeto.

• Módulos independentes que ainda precisam ser iniciados
• Faltando ferramentas de desenvolvimento que eles possam integrar (como um gerente de compilação automatizado)

Principalmente, estou pensando em coisas que os deixem fora do caminho das pessoas em desenvolvimento no momento. Eu concordo com Mythical Man-Month, mas também acho que há exceções em tudo.

Eu acho que adicionar pessoas a uma equipe pode acelerar um projeto mais do que adicioná-las ao próprio projeto.

Costumo me deparar com o problema de ter muitos projetos simultâneos. Qualquer um desses projetos poderia ser concluído mais rapidamente se eu pudesse me concentrar apenas nesse projeto. Ao adicionar membros da equipe, eu poderia fazer a transição para outros projetos.

Obviamente, isso pressupõe que você contratou desenvolvedores capazes e motivados, capazes de herdar grandes projetos e aprender de forma independente. :-)

Se o recurso extra complementar sua equipe existente, pode ser o ideal. Por exemplo, se você estiver prestes a configurar seu hardware de produção e verificar se o banco de dados está realmente ajustado, em vez de apenas retornar bons resultados (que sua equipe conhece como especialistas em domínio), emprestando tempo a um bom dba que trabalha no projeto a seguir para o seu pode acelerar a equipe sem muito custo de treinamento

Basta colocar. Tudo se resume a comparar o tempo restante e a produtividade que você obterá de alguém, excluindo a quantidade de tempo que os recursos adicionais levam para acelerar e ser produtivo e subtrair o tempo investido em ensiná-los pelos recursos existentes. Os principais fatores (em ordem de significância):

1. Quão bom é o recurso em buscá-lo. Os melhores desenvolvedores podem acessar um novo site e ser produtivos corrigindo erros quase instantaneamente com pouca assistência. Essa habilidade é rara, mas pode ser aprendida.
2. A segregabilidade de tarefas. Eles precisam ser capazes de trabalhar em objetos e funções sem tropeçar nos desenvolvedores existentes e atrasá-los.
3. A complexidade do projeto e documentação disponível. Se for um aplicativo ASP.Net de práticas recomendadas de baunilha e cenários comuns de negócios bem documentados, um bom desenvolvedor pode ficar preso imediatamente. Esse fator, mais do que qualquer outro, determinará quanto tempo os recursos existentes terão para investir no ensino e, portanto, o impacto negativo inicial dos novos recursos.
4. A quantidade de tempo restante. Isso também é frequentemente mal calculado. Freqüentemente, a lógica será que temos apenas x semanas restantes e levará x + 1 semanas para que alguém se apresse. Na realidade, o projeto vai escorregar e, de fato, ainda restam duas semanas de desenvolvimento, e obter mais recursos o mais cedo ou mais tarde ajudará.

Onde uma equipe já está acostumada a emparelhar a programação, a adição de outro desenvolvedor que já seja experiente em emparelhamento pode não tornar o projeto lento, principalmente se o desenvolvimento estiver em andamento no estilo TDD.

O novo desenvolvedor se tornará lentamente mais produtivo à medida que entenderem mais a base de código, e quaisquer mal-entendidos serão detectados muito cedo por seus pares ou pelo conjunto de testes que é executado antes de cada check-in (e, idealmente, deve haver uma verificação em pelo menos a cada dez minutos).

No entanto, os efeitos das despesas gerais extras de comunicação precisam ser levados em consideração. É importante não diluir muito o conhecimento existente do projeto.

Adicionar desenvolvedores faz sentido quando a produtividade contribuída pelos desenvolvedores adicionais excede a produtividade perdida no treinamento e gerenciamento desses desenvolvedores.