Por que adicionar mais pessoas a um projeto atrasado o torna mais tarde?

25

É um ditado bastante comum que adicionar mais programadores a um projeto atrasado tornará as coisas piores. Por que é isso?

project-management

— Henry
fonte

14

O termo para isso é Lei de Brooks ( en.wikipedia.org/wiki/Brooks's_law ).

— Macneil

7

Conselho: leia Brooks '"The Mythical Man-Month". Isso mostrará de onde vem esse ditado, é um livro muito legível, e todo mundo no campo deve lê-lo de qualquer maneira.

— David Thornley

Essa página da Wikipedia está muito bem escrita.

— Henry

Para a prova de como a produtividade diminui com o tamanho da equipe (além de 7 membros da equipe que você entrar em retornos decrescentes), consulte qsm.com/process_improvement_01.html

— Joeri Sebrechts

33

Sobrecarga de introdução

Cada novo desenvolvedor deve ser introduzido na base de código e no processo de desenvolvimento que leva não apenas o tempo da nova pessoa, mas também requer assistência de um desenvolvedor sênior (orientando-o no processo de criação, explique o processo de teste, ajude-o com armadilhas na base de código, revisões de código muito mais detalhadas, etc.) .

Portanto, quanto mais novos desenvolvedores você adicionar ao projeto, mais tempo será gasto para levá-los a um ponto em que eles possam realmente contribuir para o projeto.

— Baelnorn
fonte

Então, se você otimizar 'Introdução', o impacto será menor?

— Henry

9

@ Henry: o problema é que você geralmente não pode otimizar esse aspecto a um nível em que não seja o gargalo. Um novo programador a princípio sabe exatamente 0 sobre seu projeto, seu código e seus processos. É a mesma sobrecarga que é sempre necessária ao adicionar um novo membro da equipe. Mas quando um projeto já está atrasado, a equipe geralmente não tem tempo para fazer uma introdução adequada e, se o fizer, esse tempo está faltando no desenvolvimento real. Portanto, geralmente é uma situação de perda / perda para a equipe e a nova pessoa leva muito mais tempo até que possa contribuir significativamente para o projeto.

— Baelnorn 26/10/10

Com relação ao custo de fazer uma introdução, ele não pode ser gravado em vídeo uma vez e depois transmitido para muitos, para que ele possa treinar um grande número de novos programadores ao mesmo tempo? (Exemplos: Reuniões desenvolvedor ou conferências.)

— rwong

7

@rwong: Não é uma má ideia, mas isso geralmente não é prático. Você não pode apenas apresentar as informações, precisa garantir que os novos caras as entendam. Além disso, se eles são realmente novos (graduados recentes), geralmente há muita informação para apresentar a todos de uma só vez. Descobrimos que um wiki funciona bem, pois todas as informações estão em um único local, e as pessoas podem postar perguntas se houver bits que eles não entendam.

— TMN

Uma possibilidade é designar uma nova pessoa muito competente e fazer com que ela execute tarefas específicas sem incomodar as outras. Eles vão se debater muito e trabalhar lentamente, e alguns gerentes e / ou equipes não suportam ver isso. No entanto, o novo desenvolvedor pode ser uma vantagem líquida quando gerenciado dessa maneira.

— David Thornley

32

Além das outras respostas: Outro fator a considerar é a comunicação.

O pior caso para a quantidade de canais de comunicação em uma equipe (o que não é incomum), é um gráfico completo . Como você pode imaginar, adicionar apenas 1 desenvolvedor pode aumentar muito os canais de comunicação. Com métodos de comunicação mais simplificados, o impacto é menor ... mas ainda aumenta.

— Steven Evers
fonte

Eu estava escrevendo da mesma forma mais ou menos na mesma hora! mas eu não sabia que tinha um nome (um gráfico completo) e sua explicação é melhor, então lá vai meu voto.

— Miguel Veloso

+1. Concordado, este é o maior problema ao adicionar mais membros da equipe.

— Martin Wickman

+1 no problema de longo prazo com a adição de pessoas a um projeto.

— indyK1ng

23

O problema citado no livro que originalmente promulgou esta lei, The Mythical Man-Month , é a comunicação. Ele começa dizendo:

Homens e meses são mercadorias intercambiáveis somente quando uma tarefa pode ser dividida entre muitos trabalhadores sem comunicação entre eles. Isso vale para colher trigo ou colher algodão; nem isso é verdade na programação de sistemas.

Ele menciona o treinamento como parte do problema:

O ônus adicional da comunicação é composto de duas partes: treinamento e intercomunicação. Cada trabalhador deve ser treinado em tecnologia, nos objetivos do esforço, na estratégia geral e no plano de trabalho. Esse treinamento não pode ser particionado; portanto, essa parte do trabalho varia linearmente com o número de trabalhadores.

... mas observa que a intercomunicação é de longe o fator maior :

Como a construção de software é inerentemente um esforço de sistema - um exercício de inter-relações complexas - o esforço de comunicação é grande e rapidamente domina a diminuição do tempo de tarefas individuais causado pelo particionamento. Adicionar mais homens aumenta, não diminui, o cronograma.

Também vale a pena notar que Fred Brooks (o autor) tem o pano de fundo para saber do que está falando. A maior parte do livro é baseada em sua experiência no gerenciamento do projeto OS / 360 da IBM. Apesar de décadas de adeptos pregarem todos os tipos de métodos de gerenciamento "aprimorados" e alguns até criarem nomes interessantes (eXtreme, Agile, Scrum etc.) quando você se dedica a isso, pouca essência ¹ parece ter mudado desde então.

¹ Para a definição de "essência", ver do mesmo autor "No Silver Bullet: Essência e Acidentes em Engenharia de Software", incluído no 20 ^th Anniversary Edition de The Mythical Man-Month .

— Jerry Coffin
fonte

12

Não é meramente ditado; é verificável. Confira The Mythical Man-Month de Brooks .

— John
fonte

1

É um ditado. Pode ou não ser verificável, mas isso não impede que seja um ditado.

— Peter Boughton #

3

Eu não tenho este livro (obviamente). Isso é feito por números concretos ou é anedótico?

— Henry

2

@ Henry: Já faz um tempo desde que eu o li, mas o IIRC, ambos estão presentes em quantidade suficiente para deixar claro o ponto.

— Steven Evers

@ Peter: Editou minha resposta.

— John

@ PeterBoughton É um provérbio. Além disso, não é apenas um ditado.

— SantiBailors

6

Aqui estão algumas reflexões sobre esse assunto ...

Precisa usar os recursos atuais para atualizar os novos recursos sobre o que está acontecendo com o projeto.
O novo recurso pode não estar familiarizado com a base de código, portanto, é necessário mais tempo para se acostumar ao código.

agora, adicionar novos recursos para teste pode não ser uma má idéia ... pode acelerar o processo de teste (se seus casos de teste estiverem bem escritos), e sim, o uso de ferramentas de teste também ajudará.

— aggietech
fonte

1

+1 para adicionar recursos ao teste, não ao desenvolvimento.

— Baelnorn 26/10/10

4

Porque a programação não é um trabalho básico da linha de produção. A atualização de um projeto de software leva tempo. As pessoas novas precisam fazer muitas perguntas, o que leva à produtividade negativa (isto é, aprendizado de pessoas novas, pessoas idosas ensinando-as -> nenhum trabalho real sendo realizado).

Para simplificá-lo, imagine um projeto individual relativamente simples, que está programado para durar uma semana: na quinta-feira, você percebe que ele não será concluído a tempo, que levaria o programador a levar mais de 6 a 7 dias. de 5. Se você adicionar outro programador nesse ponto, ele precisará trabalhar com o programador1 por pelo menos algumas horas ou um dia, fazer muitas perguntas para acelerar a velocidade etc. Você provavelmente não conseguirá qualquer produtividade líquida positiva para o resto da semana. É provável que o novo programador também introduza alguns bugs extras (já que eles não conhecerão o código existente e o programador1), o que interromperá o ciclo de implementação e teste em mais um ou dois dias. O projeto durará facilmente duas semanas úteis completas, em vez da original!

— Bobby Tables
fonte

Bem, seu exemplo é um pouco artificial pelo curto prazo irrealista deixado para o projeto. Altere para um mês e você verá que isso não é necessário. Pessoalmente, acho que a citação foi abusada. É verdade quando se considera programador comum, médio / ruim. Se você tem um bom programador e o prazo não é algo irreal como 1 dia ou 1 semana, a cotação está errada: isso pode ser feito (ajude o projeto).

— N1ckp 27/10/10

@ n1ck É uma generalização - como "cozinheiros demais" - o ponto principal é que simplesmente jogar mão de obra no projeto não necessariamente fará com que seja resolvido mais rapidamente. 1 pessoa para 2? Provavelmente vai. 2 a 4? Variáveis demais - isso depende do tamanho e da estrutura do projeto. 4 -> 8? Definitivamente ficando marginal (pelo menos em termos de retorno do custo).

— Murph

@ Murph: você parece estar pensando principalmente nas mesmas coisas que eu, mas esqueceu uma variável muito importante em sua equação: nível de habilidade da mão de obra adicionada. Foi no meu último comentário, então acho estranho que você tenha perdido. Adicionar cegamente mão-de-obra não é a solução. Adicionar mão-de-obra muito especializada (você não precisa de muitas) pode, é claro, ajudar, e é o que faltava na mítica citação do mês-homem. Esse foi o meu ponto. Caso contrário, eu já sei o que a citação significa.

— N1ckp 27/10/10

Ok, o exemplo poderia ser melhor, mas a generalização ainda é válida?

— Murph

1

Já passei por esse tempo suficiente para saber que é uma daquelas coisas que PODE funcionar em casos muito especializados, mas 99% das vezes não. Não importa o quão bom pareça teoricamente na época. Dito isto, sim, não é um absoluto em preto e branco. É mais como dizer, como os relacionamentos abertos não funcionam. A teoria é boa e tentadora;) ... mas a natureza da besta é tal que, na maioria dos casos, acaba fracassando. Uma espécie de "as exceções provam a regra".

— Bobby Tables

4

Fred Brooks escreveu um livro inteiro "The Mythical Man-Month", respondendo a essa pergunta.

Aqui está a versão quick-n-dirty:

1) Há um limite de quanto você pode dividir um projeto em partes distintas para atribuir a mais programadores.

2) Dividir um projeto para mais pessoas aumenta a quantidade de comunicação necessária para coordenar todas as partes do aplicativo. Mais comunicação = mais trabalho.

3) Para cada pessoa que você adicionar ao projeto, adicione mais de um canal de comunicação que deve ser navegado para a equipe. Esse número cresce geometricamente e aumenta a quantidade de comunicação que deve acontecer. Mais comunicação = Mais trabalho.

4) Existe uma "J-Curve" quando você adiciona cada membro da equipe. Ou seja, os recursos produtivos existentes precisam gastar tempo para atualizar as novas pessoas que, de outra forma, poderiam ter gasto trabalhando no projeto. Por fim, você pode aumentar a capacidade, mas isso atrasa temporariamente o projeto. Quanto mais tarde no projeto, mais é preciso aprender, mais pronunciado é o efeito.

— JohnFx
fonte

4

Outro fator que não vi mencionado é que algumas tarefas precisam ser realizadas em uma ordem específica. Você não pode executar a tarefa 4 até que a tarefa 3 seja concluída porque depende de 3. Não adianta contratar alguém para executar a tarefa 4 ao mesmo tempo em que alguém está realizando a tarefa 3. Muitas vezes, no final de um projeto , as tarefas que precisam de outras coisas concluídas primeiro são as tarefas restantes.

Eles também costumam ser algumas das tarefas mais complexas que precisam ser executadas, as mesmas que exigem a melhor compreensão de todo o design para evitar a quebra do que já foi concluído. Eles também geralmente exigem o conhecimento mais amplo do domínio comercial. Depois de trabalhar no projeto por meses, posso executar a tarefa em uma semana ou menos. Alguém novo passaria mais de uma semana se acostumando (e me afastando de minhas tarefas para um bom período de tempo para responder a perguntas) e provavelmente, mesmo se extremamente habilidoso, levar mais tempo para fazer a tarefa. Não é porque ele ou ela não é competente, mas por não estar familiarizado com a estrutura real do projeto ou com o back-end do banco de dados.

— HLGEM
fonte

+1. Esta foi uma questão importante no meu último emprego. A gerência estava no mega "mês do homem" acrescentando "mania" a um grande projeto sem pensar nas coisas. Em um ponto, nossa equipe foi treinada por ser lenta - porque nossas coisas precisavam ser integradas ao projeto principal. Mas, em seguida, os novos contratados sobre o principal projeto não poderia chegar até a velocidade rápida o suficiente, então WE tem muito à frente (em coisas que precisavam de seus back-ends concluída). Em um ponto, estávamos desenvolvendo front-ends para back-ends e testes de equipamento. Não é um bom fluxo.

— Bobby Tables

2

O ditado que sempre funcionou para mim é que você não pode conseguir nove mulheres para fazer um bebê em um mês.

— reexecutar
fonte

Se você acha que um projeto de software é como um bebê, não mora no mundo real. Há alguma verdade na citação, mas este é o exemplo perfeito de como tirar as coisas do contexto: -1

— n1ckp 27/10/10

1

Obviamente não. Mas as pessoas com quem você vende linhas de tempo também não entendem o desenvolvimento de software. As analogias são exatamente para esse propósito, relacionando um conceito desconhecido a uma entidade conhecida.

— reprise

2

Outra analogia que Brooks faz é comer em um restaurante. Uma cozinha bem administrada pode fazer muitas refeições em paralelo, mas há limites de quão rápido ela pode fazer uma única refeição sem cozinhar mal ou queimar.

— David Thornley

@runun: o problema com sua analogia é que não há analogia entre trabalhadoras e mulheres grávidas. As mulheres no seu caso poderiam ser mais facilmente comparadas à empresa , e não às trabalhadoras. É por isso que falha tanto na minha opinião. O mais próximo que consigo pensar seria na comida, mas isso seria mais como uma linha de códigos, então não, não trabalhadores.

— N1ckp 27/10/10

1

@ n1ck: Minha impressão é que você discorda porque não entende, para ser sincero. Brooks não estava falando em substituir pessoas inúteis por pessoas competentes, porque ele estava em uma situação em que todos os empregados ainda eram considerados competentes.

— David Thornley

2

Eu também sugeriria "Peopleware", de DeMarco e Lister.

E "The Deadline", de DeMarco, apresenta isso e várias outras doenças e falácias de gerenciamento de projetos de software de uma maneira alegre e muito legível.

Ele também investiga a dinâmica das pessoas que trabalham no projeto / equipe e detalha como as coisas como comunicação e introdução esgotam o tempo de trabalho disponível de uma equipe.

Esses livros são muito baratos, eu sugiro que você os compre (Amazon ou The Book Depository os têm) e faça uma leitura. As respostas curtas aqui não podem realmente fazer justiça à pergunta.

— rapid_now
fonte

2

Porque ninguém leva tempo para ter um processo bem planejado, testado e bem pensado para: contratar, treinar, desenvolver e supervisionar programadores e muito menos prepará-los para acelerar um projeto em particular.

Se você está gerenciando uma equipe de desenvolvedores, deve ter vários contatos agora mesmo de pessoas que gostaria de contratar se tiver uma vaga. Participe de grupos de desenvolvedores.

Quão rápido você pode ter uma nova configuração de máquina de desenvolvimento e pronta para usar?

Você já testou a documentação e as especificações do seu projeto, mostrando-as a um desenvolvedor em outro projeto? Eles analisaram e determinaram que poderiam começar a trabalhar no projeto, se necessário?

Qual é o cronograma do projeto?

Economize para um dia chuvoso, porque quando um projeto fica para trás, é mais como um furacão.

— JeffO
fonte

1

Além do problema de comunicação (sobre o qual penso que todas as outras respostas estão falando), também é muito possível que uma pessoa adicionada a um projeto crie bugs, porque ainda não conhece o código muito bem.

Sempre que sou adicionado a um projeto, tento sempre não quebrar as coisas. Isso significa que sou muito mais lento em consertar as coisas primeiro.

— Paul D. Waite
fonte

0

Eu gostaria de salientar algo totalmente ignorado até agora pelas outras respostas.

No momento em que as pessoas são adicionadas a um projeto atrasado, normalmente muita coisa deu errado em toda a organização. A gerência e o cliente não estão felizes. As pessoas foram pressionadas a seguir em frente. As coisas estão bem tensas.

Agora imagine que você faz parte dessa equipe. Obviamente, nada disso é culpa sua. O planejamento (nenhum dos quais foi seu) tem sido muito otimista. Todas as decisões erradas foram tomadas sem consultar você. Você está tentando tirar o melhor proveito disso e, de repente, um monte de gente nova está sendo levada. Que mensagem isso transmite?

As pessoas lá em cima obviamente perderam a fé em você. Eles chamaram os meninos grandes para compensar o que você estragou.

Você ainda estará motivado para fazer disso um sucesso? Ou ... você ficará cada vez mais frustrado e prefere ver a coisa toda falhar?

Não tenha pressa :-).

— Martin Maat
fonte