Existe realmente uma relação entre o número de pessoas designadas para um projeto e o número de defeitos?

12

Aqui está uma citação de um manual de treinamento em andamento sobre SLIM e estimativa de software:

Observe também que há uma correlação entre esforço e defeitos. Isso significa que, quanto mais pessoas forem atribuídas a um projeto de um determinado tamanho, mais defeitos haverá.

Esforço é pessoa-tempo (pessoa-ano, pessoa-mês) para o projeto. Defeitos é a contagem de defeitos detectados em qualquer ponto do ciclo de vida. Tamanho é definido como os casos de uso, pontos de função ou SLOC que compõem o projeto.

Isso parece contra-intuitivo, assumindo um bom processo e engenheiros capazes. Por exemplo, ter mais pessoas significa mais olhos em todos os artefatos (especificações de requisitos, projetos, código, testes). Além de ter mais olhos, minha intuição sugere que há pouca relação entre esforço e defeitos em um projeto que utiliza técnicas de qualidade apropriadas.

Não consegui encontrar nenhum documento, além daqueles sobre o modelo Putnam (que é usado pelo SLIM), que sugere qualquer tipo de relacionamento conhecido entre defeitos e esforço ou defeitos e número de pessoas em um projeto. Esse é um relacionamento conhecido e a afirmação de que "mais pessoas = mais defeitos" é válida?

— Thomas Owens
fonte

10

"adicionar mão-de-obra a um projeto de software atrasado o torna mais tarde" - Fred Brooks

— Oded 30/09

2

@Oded Adicionar pessoas atrasadas não é mencionado. Além disso, a lei de Brooks não diz nada sobre defeitos, mas um aumento nos canais de comunicação para tomar decisões e manter as pessoas informadas. Eu suspeitaria que, como Karl Bielefeldt sugere, dificuldades de comunicação podem levar a defeitos.

— Thomas Owens

@ThomasOwens - Sim, a citação é realmente sobre o aumento dos canais de comunicação (e, portanto, dificuldades), com a suposição de que isso levaria a defeitos.

— Oded

Eu ainda diria que, quando muitos desenvolvedores são lançados em um projeto, isso geralmente indica uma marcha da morte.

— Morgan Herlocker

@ironcode O número de desenvolvedores em um projeto deve ser determinado pelo tamanho e escopo do projeto, e como ele é organizado. Ter muitos desenvolvedores ou adicionar muitos desenvolvedores mais tarde são sinais de mau gerenciamento, talvez uma marcha da morte.

— Thomas Owens

14

Minha intuição é assim:

Quanto mais pessoas designadas para um projeto de determinado tamanho, maior a sobrecarga da comunicação
=> maiores as chances de mal-entendidos e todos os tipos de problemas de comunicação
=> maior o número de defeitos resultantes.

E

Bons desenvolvedores são mais raros, mais difíceis de encontrar e contratar, do que os medíocres / ruins
=> quanto mais pessoas designadas para um projeto de determinado tamanho, menor o nível médio de competência
=> maior o número de defeitos resultantes.

Mas esse pode ser apenas o meu raciocínio, não tenho evidências de apoio.

Como uma observação lateral, suas suposições enfatizadas abaixo são IMHO (infelizmente) bastante fortes, levando em conta o estado de nossa profissão:

Isso parece contra-intuitivo, assumindo um bom processo e engenheiros capazes . [...] minha intuição sugere que há pouca relação entre esforço e defeitos em um projeto que utiliza técnicas de qualidade apropriadas .

— Péter Török
fonte

Atribuí o gráfico Thrashing / Process / Productivity de McConnell para resolver isso. Se você não apresentar novas pessoas, se acostumará com a sobrecarga de comunicação envolvida no projeto desde o início e manter a comunicação apropriada se tornará mais fácil e natural. Isso ocorre de acordo com a Lei de Brooks, quando você adiciona pessoas a um projeto com atraso, o que seria o mesmo que introduzir processo com atraso em um projeto - um aumento nos canais de comunicação significa um aumento no thrashing e uma falha na comunicação que leva a defeitos. Eu posso estar fora da base nisso, no entanto. Seu raciocínio pode ser válido.

— Thomas Owens

Porém, com menos pessoas, é menos provável que elas se atinjam aos seus pontos fortes. É mais fácil contratar alguns bons desenvolvedores que podem ser melhores se puderem se concentrar em uma área em vez de apenas um guru que pode fazer tudo?

— Jeffo

@ Jeff O, você tem razão. OTOH, se cada desenvolvedor se concentrar apenas em sua própria área forte, a comunicação entre eles pode ficar ainda mais problemática.

— Péter Török

1

A comunicação é mais problemática ou apenas se torna necessária?

— JeffO 30/09

@ Jeff O, IMO, quanto menos entenderem a área um do outro, mais comunicação será necessária e maiores serão as chances de mal-entendidos e falsas suposições.

— Péter Török

5

Poderia ser apenas uma correlação. O gerenciamento tende a designar mais pessoas para ajudar nos projetos que eles consideram mais complexos, ou projetos que estão atrasados devido a muitos bugs intransigentes ou projetos que exigem muito acoplamento entre vários componentes. Se você pudesse tomar decisões gerenciais fora da mistura, suspeito que a correlação pelo menos diminuísse, se não revertesse.

— Karl Bielefeldt
fonte

O único problema com isso é que a mudança (especificamente um aumento) na equipe ao longo do tempo não é mencionada. Apenas diz que se você tiver um projeto com n pessoas, terá m defeitos. A adição de pessoas introduz problemas e problemas de comunicação, mas isso (pelo que sei) está além do escopo do simples relacionamento entre defeitos de pessoas. Concordo que um efeito colateral de adicionar pessoas atrasadas não é apenas um aumento nos canais de comunicação e a necessidade de treiná-las e atualizá-las (Lei de Brooks), mas também um aumento potencial de defeitos. Mas isso está fora de escopo.

— Thomas Owens

Adicionar pessoas atrasadas é apenas um fator que eu mencionei. A Administração ainda tem uma tendência para atribuir mais pessoas na frente de projetos que antecipam sendo mais arriscado ou complexo.

— Karl Bielefeldt

O objetivo do SLIM (e outras ferramentas de estimativa, quando usadas corretamente) é ajudar na estimativa do número necessário de pessoas, custo de um projeto, tempo necessário e assim por diante. No entanto, isso exige que a ferramenta seja entendida e usada corretamente.

— Thomas Owens

3

Dadas as definições recentemente atualizadas de tamanho e esforço, eu sugeriria que talvez os resultados sejam devidos ao fato de que o esforço (total de horas-homem) seja realmente um estimador melhor do tamanho real do projeto do que as medidas que a fonte está usando (o esforço seria uma medida perfeita se todas as equipes e recursos da equipe forem equivalentes).

Portanto, o que realmente está acontecendo é que projetos maiores têm mais defeitos, o que não é surpreendente.

— psr
fonte

2

Isso parece contra-intuitivo, assumindo um bom processo e engenheiros capazes.

Eu não acho que você pode assumir qualquer um deles no mundo real. Quanto mais pessoas em um projeto, maior a probabilidade de você ter maçãs podres que não conseguem acompanhar e desaceleram os melhores desenvolvedores. Mesmo se você seguir as premissas, existem algumas outras coisas que atrasam os projetos e causam mais defeitos à medida que você aumenta o número de pessoas:

sobrecarga de comunicação
sobrecarga de leitura de código (com isso quero dizer que até os melhores desenvolvedores levam mais tempo para ler e consumir o código de outras pessoas do que o seu)
os testes devem ser mais completos (todos nós filmamos com 100% de cobertura de teste, mas isso raramente acontece no mundo real. Quanto mais pessoas você coloca em um projeto, a refatoração mais assustadora fica sem testes automatizados extremamente completos, pois você só espera que suas alterações não terá efeitos colaterais. Nem todos os testes podem ser automatizados de maneira razoável, o que leva ainda mais tempo.)

Na minha experiência, os efeitos negativos de projetos carregados com desenvolvedores diminuem quando o projeto é muito modular e você tem apenas 1 ou 2 pessoas por camada. Não me importo com o sistema de controle de versão que você está usando, pois ter 4 desenvolvedores todos os checkins de mesclagem automática no mesmo arquivo de uma só vez provavelmente será uma má idéia.

— Morgan Herlocker
fonte

Se a única maneira de impedir que 4 desenvolvedores trabalhem no mesmo arquivo é limitar o tamanho da equipe a 3, você terá problemas maiores.

— JeffO 30/09

2

Há uma diferença entre correlação e causalidade; a citação parece estar dizendo que o número total de defeitos tende a ser maior nos projetos em que um número maior de engenheiros está alocado. Isso faz todo o sentido para mim, tenho certeza que o MS Windows tem mais defeitos do que os aplicativos que eu crio, mas isso não significa que meus aplicativos sejam de qualidade superior.

Para dar outro exemplo mais abstrato - se pegarmos o número total de mortes por país e correlacionarmos isso com o número total de médicos no país, tenho certeza de que poderíamos dizer "países com mais médicos tiveram mais mortes". Isso não seria porque os médicos causaram as mortes, mas sim que um grande número de médicos é indicativo de uma grande população.

— Daniel B
fonte

Para o seu exemplo com o Windows, tenho certeza de que o Windows também tem mais oportunidades de defeitos simplesmente porque é maior. Se um desenvolvedor escrevesse um sistema que fosse 10 SLOC e um sistema que fosse 10000 SLOC, o sistema com 10000 SLOC teria uma chance maior de ter um defeito (que inclui erros de digitação que impedem a compilação, ponto e vírgula em falta, erros lógicos etc.) . Normalmente, projetos maiores teriam mais engenheiros, mas a relação não é entre o número de pessoas e defeitos, mas o tamanho e os defeitos.

— Thomas Owens

@ThomasOwens - sim, esse era exatamente o meu ponto.

— Daniel B

Por que os erros não são comparados em relação ao tamanho e complexidade do projeto?

— Jeffo

@ JeffO - Medir de uma maneira relativa é completamente não trivial (como exatamente você faz isso?). Talvez a declaração original esteja sendo tirada do contexto, mas os autores raramente se referem a resultados complexos e calculados simplesmente como "defeitos". Nesse caso, eu esperaria outra palavra como "qualidade" (que implica que algum cálculo foi feito) ou uma frase mais longa como "defeitos por engenheiro designado". Talvez eu esteja sendo um pouco cínica para os autores aqui :)

— Daniel B

@ Jeff Eles seriam. Mas você compararia os defeitos com o tamanho e a complexidade, não com o número de pessoas. À medida que o tamanho e a complexidade aumentam, os defeitos aumentam e o número de pessoas aumenta. Então, sim, embora o número de pessoas aumente, esse aumento de pessoas não aumenta o número de defeitos.

— Thomas Owens

1

Vamos deixar de lado a afirmação sobre o número de pessoas por um momento.

Observar o número de defeitos injetados como uma função do esforço pode fazer sentido, desde que você assuma que o esforço aumentado requer necessariamente um tamanho maior, pois existe uma forte correlação entre o número de defeitos e o tamanho do software.

Portanto, se você presumir que quanto mais esforço for colocado em um projeto, mais linhas de código serão gravadas, provavelmente você poderá usar o esforço como um proxy de tamanho para prever o número de defeitos. A correlação entre o tamanho (por exemplo, LOC) e o número de defeitos foi mostrada repetidamente no trabalho de Watts Humphrey, Capers Jones e outros.

Não vejo como o número de pessoas se encaixa, além de mais pessoas implica mais esforço.

Como uma observação lateral, não confunda correlação com causalidade. Embora exista uma correlação entre o tamanho e o número de defeitos injetados, o tamanho não é a causa. A causa geralmente vem de, como você apontou, problemas de pessoas e processos. Dito isto, os defeitos em função do tamanho são uma grande métrica para entender se há um problema e para medir a eficácia da mudança.

— Michael
fonte

0

Suponho que isso seja limitado a membros da equipe de programação principal e não a uma situação em que haja especialistas como: UI, UX, DBA etc.

Eu acho que precisa ser bem gerenciado, mas isso não é fácil. Pequenas equipes compostas por desenvolvedores de qualidade podem gerenciar a si mesmas. É mais provável que grandes seções de código tenham criado alguém com menos talento.

Ter mais membros da equipe pode facilitar a divisão de tarefas. Coloque os devlopers melhores ou mais experientes nas áreas difíceis. Tire algumas das tarefas mundanas ou que não são de programação dos seus melhores desenvolvedores e deixe que os desenvolvedores juniores lidem com as interrupções. Isso exigirá mais planejamento e reflexão, mas oferece uma oportunidade para alavancar seu talento.

Existe a noção de que é melhor ter um ótimo desenvolvedor que precise adquirir uma nova habilidade do que um desenvolvedor abaixo da média que já a conhece. Isso é ótimo se você tiver tempo. Provavelmente, a razão pela qual mais desenvolvedores estão sendo atribuídos a um projeto é devido à quantidade de trabalho necessária e aos prazos. Você pode ter alguém que possa se concentrar em uma área específica e se tornar mais qualificado. É ótimo ter esse conhecimento abrangente, mas às vezes com um pouco de orientação, um desenvolvedor menor pode receber alguma instrução e segui-lo.

A realidade é que não há muitas pessoas que já gerenciaram uma grande equipe em um projeto de sucesso. Mesmo que todos sejam talentosos, é difícil para as grandes equipes se autogerenciarem. Os egos atrapalham?

— JeffO
fonte