Existe-t-il vraiment une relation entre le nombre de personnes affectées à un projet et le nombre de défauts?

12

Voici une citation d'un manuel de formation au travail concernant SLIM et l'estimation de logiciel:

Notez également qu'il existe une corrélation entre l'effort et les défauts. Cela signifie que plus il y aura de personnes affectées à un projet d'une taille donnée, plus il y aura de défauts.

L'effort est le temps-personne (années-personnes, mois-personnes) pour le projet. Les défauts sont le nombre de défauts détectés à tout moment du cycle de vie. La taille est définie comme les cas d'utilisation, les points de fonction ou le SLOC qui composent le projet.

Cela semble contre-intuitif, en supposant un bon processus et des ingénieurs compétents. Par exemple, avoir plus de personnes signifie plus de regards sur tous les artefacts (spécifications des exigences, conceptions, code, tests). En plus d'avoir plus d'yeux, mon intuition suggère qu'il y a peu de relation entre l'effort et les défauts sur un projet qui utilise des techniques de qualité appropriées.

Je n'ai pas pu trouver de documents, à part ceux sur le modèle Putnam (qui est utilisé par SLIM), qui suggèrent une sorte de relation connue entre les défauts et l'effort ou les défauts et le nombre de personnes sur un projet. Est-ce une relation connue et l'affirmation selon laquelle "plus de gens = plus de défauts" est-elle valable?

— Thomas Owens
source

10

"l'ajout de main-d'œuvre à un projet logiciel tardif le rend plus tard" - Fred Brooks

— Oded

2

@Oded Ajouter des personnes en retard n'est pas du tout mentionné. De plus, la loi de Brooks ne dit rien sur les défauts, mais une augmentation des canaux de communication pour prendre des décisions et tenir les gens informés. Je soupçonne que, comme le suggère Karl Bielefeldt, les difficultés de communication peuvent entraîner des défauts.

— Thomas Owens

@ThomasOwens - Oui, la citation concerne en effet l'augmentation des canaux de communication (et donc des difficultés), avec l'hypothèse que cela conduirait à des défauts.

— Oded

Je dirais quand même que lorsque des tas de développeurs sont lancés sur un projet, cela indique souvent une marche vers la mort.

— Morgan Herlocker

@ironcode Le nombre de développeurs sur un projet doit être dicté par la taille et la portée du projet et son organisation. Avoir trop de développeurs ou ajouter trop de développeurs plus tard sont des signes de mauvaise gestion, peut-être une marche de la mort.

— Thomas Owens

14

Mon intuition va comme ceci:

Plus il y a de personnes affectées à un projet de taille donnée, plus les frais de communication sont importants
=> plus les risques de malentendus et toutes sortes de problèmes de communication sont
élevés => plus le nombre de défauts en résultant est élevé.

Et

Les bons développeurs sont plus rares, donc plus difficiles à trouver et à embaucher, que les médiocres / mauvais
=> plus il y a de personnes affectées à un projet de taille donnée, plus leur niveau moyen de compétence est faible
=> plus le nombre de défauts en résultant est élevé.

Mais ce n'est peut-être que mon raisonnement, je n'ai aucune preuve à l'appui.

En remarque, vos hypothèses soulignées ci-dessous sont à mon humble avis (malheureusement) assez solides, compte tenu de l'état de notre profession:

Cela semble contre-intuitif, en supposant un bon processus et des ingénieurs compétents . [...] mon intuition suggère qu'il y a peu de relation entre l'effort et les défauts sur un projet qui utilise des techniques de qualité appropriées .

— Péter Török
source

J'ai attribué le graphique Thrashing / Process / Productivity de McConnell pour résoudre ce problème. Si vous n'introduisez pas de nouvelles personnes, vous vous habituez tôt aux frais de communication impliqués dans le projet et maintenir la communication appropriée devient plus facile et plus naturel. Cela se décompose en vertu de la loi de Brooks, lorsque vous ajoutez des personnes à un projet en retard, ce qui reviendrait à introduire un processus tardivement dans un projet - une augmentation des canaux de communication signifie une augmentation du thrashing et une interruption de la communication qui entraîne des défauts. Je pourrais être hors de base, cependant. Votre raisonnement est peut-être valide.

— Thomas Owens

Mais avec moins de personnes, vous êtes moins susceptible de leur permettre de conserver leurs forces. Est-il plus facile d'embaucher quelques bons développeurs qui pourraient être meilleurs s'ils peuvent se concentrer sur un domaine au lieu d'un seul gourou qui peut tout faire?

— JeffO

@Jeff O, vous avez raison. OTOH si chaque développeur se concentre uniquement sur son propre domaine fort, la communication entre eux peut devenir encore plus gênante.

— Péter Török

1

La communication est-elle plus gênante ou devient-elle simplement nécessaire?

— JeffO

@Jeff O, OMI, moins ils comprennent le domaine de l'autre, plus la communication est nécessaire et plus les risques de malentendus et de fausses hypothèses sont élevés.

— Péter Török

5

Cela pourrait simplement être une corrélation. La direction a tendance à affecter plus de personnes pour aider sur les projets qu'ils jugent plus complexes, ou les projets qui prennent du retard en raison de nombreux bogues intransigeants, ou les projets qui nécessitent beaucoup de couplage entre les différents composants. Si vous pouviez prendre des décisions de gestion hors du mélange, je soupçonne que la corrélation diminuerait au moins, sinon s'inverserait.

— Karl Bielefeldt
source

Le seul problème avec cela est que le changement (en particulier une augmentation) des effectifs au fil du temps n'est pas mentionné. Il dit simplement que si vous avez un projet avec n personnes, vous aurez m défauts. L'ajout de personnes introduit des frais généraux et des problèmes de communication, mais cela (d'après ce que je peux dire) dépasse la portée de la simple relation entre les personnes-défauts. Je conviens qu'un effet secondaire de l'ajout tardif de personnes n'est pas seulement une augmentation des canaux de communication et la nécessité de former des personnes et de les mettre à niveau (Brooks 'Law), mais aussi une augmentation potentielle des défauts. Mais c'est hors de portée.

— Thomas Owens

Ajouter des personnes en retard n'est qu'un des facteurs que j'ai mentionnés. La direction a toujours tendance à affecter d'avance plus de personnes aux projets qu'elle prévoit être plus risqués ou complexes.

— Karl Bielefeldt

Le but de SLIM (et d'autres outils d'estimation, lorsqu'ils sont utilisés correctement) est d'aider à estimer le nombre de personnes nécessaires, le coût d'un projet, le temps requis, etc. Cependant, cela nécessite que l'outil soit compris et utilisé correctement.

— Thomas Owens

3

Compte tenu des définitions récemment mises à jour de la taille et de l'effort, je dirais que les résultats sont peut-être dus au fait que l'effort (nombre total d'heures-homme) est en fait un meilleur estimateur de la taille réelle du projet que les mesures utilisées par la source (l'effort serait une mesure parfaite si toutes les équipes et les ressources de l'équipe étaient équivalentes).

Par conséquent, ce qui se passe vraiment, c'est que les grands projets ont plus de défauts, ce qui n'est pas surprenant du tout.

— psr
source

2

Cela semble contre-intuitif, en supposant un bon processus et des ingénieurs compétents.

Je ne pense pas que vous puissiez supposer l'un ou l'autre de ces éléments dans le monde réel. Plus il y a de personnes sur un projet, plus vous avez de chances d'avoir de mauvaises pommes qui ne peuvent pas suivre et qui ralentiront les meilleurs développeurs. Même si vous partez des hypothèses, il y a quelques autres choses qui ralentissent les projets et causent plus de défauts lorsque vous augmentez le nombre de personnes:

frais généraux de communication
lecture du code (par cela, je veux dire que même les meilleurs développeurs prennent plus de temps pour lire et consommer le code des autres que le leur)
les tests doivent être plus approfondis (nous visons tous une couverture de test à 100%, mais cela arrive rarement dans le monde réel. Plus vous mettez de personnes sur un projet, plus le refactoring est effrayant sans tests automatisés extrêmement approfondis, car vous espérez simplement que vos changements n'aura pas d'effets secondaires. Tous les tests ne peuvent même pas être automatisés de manière raisonnable, ce qui prend encore plus de temps.)

D'après mon expérience, les effets négatifs des projets chargés de développeurs diminuent considérablement lorsque le projet est très modulaire et que vous n'avez que 1 ou 2 personnes par niveau. Peu m'importe quel système de contrôle de version que vous utilisez, avoir 4 développeurs qui fusionnent automatiquement tous les enregistrements dans le même fichier à la fois sera probablement une mauvaise idée.

— Morgan Herlocker
source

Si la seule façon d'empêcher 4 développeurs de travailler sur le même fichier est de limiter la taille de l'équipe à 3, vous avez de plus gros problèmes.

— JeffO

2

Il y a une différence entre corrélation et causalité; la citation semble indiquer que le nombre total de défauts a tendance à être plus élevé pour les projets où un plus grand nombre d'ingénieurs est affecté. Cela est parfaitement logique pour moi, je suis sûr que MS Windows a plus de défauts que les applications que je crée, mais cela ne signifie pas que mes applications sont de qualité supérieure.

Pour donner un autre exemple plus abstrait - si nous prenions le nombre total de décès par pays et corrélions cela avec le nombre total de médecins dans le pays, je suis sûr que nous pourrions dire "les pays avec plus de médecins ont eu plus de décès". Ce ne serait pas parce que les médecins ont causé les décès, mais plutôt qu'un grand nombre de médecins indique une population importante.

— Daniel B
source

Pour votre exemple avec Windows, je suis sûr que Windows a également plus de possibilités de défauts simplement parce qu'il est plus grand. Si un développeur écrivait un système qui était 10 SLOC et un système qui était 10000 SLOC, le système avec 10000 SLOC aurait plus de chances d'avoir un défaut (qui inclut des fautes de frappe qui empêchent la compilation, les points-virgules manquants, les erreurs logiques, etc.) . En règle générale, les projets plus importants ont plus d'ingénieurs, mais la relation n'est pas entre le nombre de personnes et les défauts, mais la taille et les défauts.

— Thomas Owens

@ThomasOwens - yepp, c'était exactement ce que je voulais dire.

— Daniel B

Pourquoi les erreurs ne seraient-elles pas comparées à la taille et à la complexité du projet?

— JeffO

@JeffO - Le mesurer de manière relative n'est pas du tout trivial (comment faites-vous exactement?). Peut-être que l'énoncé original est sorti de son contexte, mais les auteurs se réfèrent rarement à des résultats complexes et calculés simplement comme des "défauts". Dans un tel cas, je m'attendrais à un autre mot comme "qualité" (ce qui implique que certains calculs ont été effectués), ou une phrase plus longue comme "défauts par ingénieur affecté". Je suis peut-être un peu cynique envers les auteurs ici :)

— Daniel B

@Jeff Ils le seraient. Mais vous compareriez les défauts à la taille et à la complexité, pas au nombre de personnes. À mesure que la taille et la complexité augmentent, les défauts augmentent et le nombre de personnes augmente. Alors oui, bien que le nombre de personnes augmente, cette augmentation de personnes n'augmente pas le nombre de défauts.

— Thomas Owens

1

Mettons de côté l'assertion sur le nombre de personnes pendant un moment.

Il peut être judicieux d'examiner le nombre de défauts injectés en fonction de l'effort tant que vous supposez qu'un effort accru nécessite nécessairement une taille accrue, car il existe une forte corrélation entre le nombre de défauts et la taille du logiciel.

Donc, si vous supposez que plus l'effort est mis dans un projet, plus de lignes de code sont écrites, vous pouvez probablement utiliser l'effort comme proxy pour la taille pour prédire le nombre de défauts. La corrélation entre la taille (par exemple LOC) et le nombre de défauts a été maintes fois démontrée dans les travaux de Watts Humphrey, Capers Jones et d'autres.

Je ne vois pas comment le nombre de personnes s'intègre, sinon plus de personnes implique plus d'efforts.

En remarque, ne confondez pas la corrélation avec la causalité. Bien qu'il existe une corrélation entre la taille et le nombre de défauts injectés, la taille n'est pas la cause. La cause vient généralement, comme vous l'avez souligné, des problèmes de personnes et de processus. Cela dit, les défauts en fonction de la taille sont une excellente mesure pour comprendre s'il y a un problème et pour évaluer l'efficacité du changement.

— Michael
source

0

Je suppose que cela est limité aux membres de l'équipe de programmation principale et non à une situation où il y a des spécialistes comme: UI, UX, DBA, etc.

Je pense que cela doit être bien géré, mais ce n'est pas facile. De petites équipes composées de développeurs de qualité peuvent se gérer elles-mêmes. Il est plus probable d'éviter que de grandes sections de code ne créent quelqu'un avec moins de talent.

Le fait d'avoir plus de membres d'équipe peut faciliter la répartition des tâches. Mettez les devlopers meilleurs ou plus expérimentés dans les zones difficiles. Supprimez certaines des tâches banales ou hors programmation de vos meilleurs développeurs et laissez les développeurs juniors gérer les interruptions. Cela nécessitera plus de planification et de réflexion, mais offre la possibilité de tirer parti de votre talent.

Il y a l'idée qu'il vaut mieux avoir un grand développeur qui a besoin d'acquérir une nouvelle compétence qu'un développeur en dessous de la moyenne qui le sait déjà. C'est super si vous avez le temps. La raison pour laquelle davantage de développeurs sont affectés à un projet est probablement en raison de la quantité de travail requise et des délais. Vous pouvez avoir quelqu'un qui peut se concentrer sur un domaine spécifique et devenir plus qualifié. C'est génial d'avoir cette connaissance complète, mais parfois avec un peu de direction, un dev mineur peut prendre des instructions et courir avec.

La réalité est qu'il n'y a pas beaucoup de gens qui ont jamais dirigé une grande équipe sur un projet réussi. Même s'ils sont tous talentueux, il est difficile pour les grandes équipes de s'autogérer. Les egos gênent-ils?

— JeffO
source