Gibt es wirklich einen Zusammenhang zwischen der Anzahl der einem Projekt zugewiesenen Personen und der Anzahl der Mängel?

12

Hier ist ein Zitat aus einem Trainingshandbuch in Bezug auf SLIM und Softwareschätzung:

Beachten Sie auch, dass ein Zusammenhang zwischen Aufwand und Mängeln besteht. Dies bedeutet, je mehr Personen einem Projekt einer bestimmten Größe zugeordnet sind, desto mehr Fehler treten auf.

Der Aufwand beträgt Personenzeit (Personenjahre, Personenmonate) für das Projekt. Unter Mängeln versteht man die Anzahl der zu jedem Zeitpunkt im Lebenszyklus festgestellten Mängel. Die Größe ist definiert als die Anwendungsfälle, Funktionspunkte oder SLOC, aus denen das Projekt besteht.

Dies erscheint unter der Annahme eines guten Prozesses und fähiger Ingenieure als kontraproduktiv. Zum Beispiel bedeutet mehr Leute zu haben, mehr Augen für alle Artefakte zu haben (Anforderungsspezifikationen, Designs, Code, Tests). Abgesehen davon, dass ich mehr Augen habe, deutet meine Intuition darauf hin, dass bei einem Projekt, das geeignete Qualitätstechniken einsetzt, nur ein geringer Zusammenhang zwischen Aufwand und Fehlern besteht.

Abgesehen von den Dokumenten zum Putnam-Modell (das von SLIM verwendet wird) konnte ich keine Dokumente finden, die auf eine bekannte Beziehung zwischen Fehlern und Aufwand oder Fehlern und Anzahl der Personen in einem Projekt hinweisen. Ist dies eine bekannte Beziehung und ist die Behauptung, dass "mehr Menschen = mehr Mängel" gültig?

— Thomas Owens
quelle

10

"Hinzufügen von Arbeitskräften zu einem späten Software-Projekt macht es später" - Fred Brooks

— Oded

2

@Oded Das späte Hinzufügen von Personen wird überhaupt nicht erwähnt. Das Gesetz von Brooks besagt auch nichts über Mängel, sondern eine Zunahme der Kommunikationskanäle, um Entscheidungen zu treffen und die Menschen auf dem Laufenden zu halten. Ich würde vermuten, dass Kommunikationsschwierigkeiten, wie Karl Bielefeldt vorschlägt, zu Fehlern führen können.

— Thomas Owens

@ThomasOwens - Ja, das Zitat handelt in der Tat von der Zunahme der Kommunikationskanäle (und damit von Schwierigkeiten), mit der Annahme, dass dies zu Fehlern führen würde.

— Oded

Ich würde immer noch sagen, dass wenn eine Menge Entwickler in ein Projekt geworfen werden, dies oft auf einen Todesmarsch hindeutet.

— Morgan Herlocker

@ironcode Die Anzahl der Entwickler in einem Projekt sollte von der Größe und dem Umfang des Projekts und seiner Organisation bestimmt werden. Zu viele Entwickler zu haben oder zu viele Entwickler später hinzuzufügen, sind Anzeichen für ein schlechtes Management, vielleicht ein Todesmarsch.

— Thomas Owens

14

Meine Intuition geht so:

Je mehr Personen einem Projekt einer bestimmten Größe zugeordnet sind, desto größer ist der Kommunikationsaufwand
=> desto höher ist die Wahrscheinlichkeit von Missverständnissen und Kommunikationsproblemen aller Art
=> desto höher ist die Anzahl der daraus resultierenden Fehler.

Und

Gute Entwickler sind seltener und daher schwieriger zu finden und einzustellen als mittelmäßige / schlechte.
=> Je mehr Personen einem Projekt einer bestimmten Größe zugeordnet sind, desto geringer ist ihr durchschnittliches Kompetenzniveau.
=> Desto höher ist die Anzahl der daraus resultierenden Mängel.

Aber dies mag nur meine Argumentation sein, ich habe keine stichhaltigen Beweise.

Als Randbemerkung sind Ihre unten hervorgehobenen Annahmen meiner Meinung nach (leider) ziemlich stark, wenn man den Stand unseres Berufs berücksichtigt:

Dies erscheint unter der Annahme eines guten Prozesses und fähiger Ingenieure kontraproduktiv . [...] Meine Intuition legt nahe, dass bei einem Projekt , bei dem geeignete Qualitätstechniken zum Einsatz kommen, nur ein geringer Zusammenhang zwischen Aufwand und Fehlern besteht .

— Péter Török
quelle

Ich schrieb McConnells Thrashing / Process / Productivity-Grafik zu, um das zu lösen. Wenn Sie keine neuen Leute vorstellen, gewöhnen Sie sich frühzeitig an den mit dem Projekt verbundenen Kommunikationsaufwand, und die Pflege der entsprechenden Kommunikation wird einfacher und natürlicher. Dies bricht nach dem Brooks'schen Gesetz zusammen, wenn Sie Leute zu spät zu einem Projekt hinzufügen, was dasselbe wäre, als wenn Sie den Prozess zu spät in ein Projekt einführen. Eine Zunahme der Kommunikationskanäle bedeutet eine Zunahme des Thrashing und eine Unterbrechung der Kommunikation, die zu Fehlern führt. Ich könnte jedoch nicht auf dieser Basis sein. Ihre Argumentation könnte gültig sein.

— Thomas Owens

Bei weniger Menschen ist es jedoch weniger wahrscheinlich, dass sie an ihren Stärken festhalten. Ist es einfacher, ein paar gute Entwickler einzustellen, die vielleicht sogar besser sind, wenn sie sich auf einen Bereich konzentrieren können, anstatt nur auf einen Guru, der alles kann?

— JeffO

@ Jeff O, du hast einen Punkt. OTOH Wenn sich jeder Entwickler nur auf seinen eigenen starken Bereich konzentriert, kann die Kommunikation zwischen ihnen noch problematischer werden.

— Péter Török

1

Ist die Kommunikation störender oder wird sie nur benötigt?

— JeffO

@ Jeff O, IMO, je weniger sie über den Bereich des jeweils anderen Bescheid wissen, desto mehr Kommunikation ist erforderlich und desto höher ist die Wahrscheinlichkeit von Missverständnissen und falschen Annahmen.

— Péter Török

5

Es könnte nur eine Korrelation sein. Das Management tendiert dazu, mehr Mitarbeiter für Projekte einzusetzen, die seiner Meinung nach komplexer sind, oder Projekte, die aufgrund vieler unnachgiebiger Fehler ins Hintertreffen geraten, oder Projekte, die eine große Kopplung zwischen verschiedenen Komponenten erfordern. Wenn Sie Managemententscheidungen aus der Mischung ziehen könnten, würde sich die Korrelation vermutlich zumindest verringern, wenn nicht sogar umkehren.

— Karl Bielefeldt
quelle

Das einzige Problem dabei ist, dass eine Änderung (insbesondere eine Erhöhung) des Personals im Laufe der Zeit nicht erwähnt wird. Es heißt nur, wenn Sie ein Projekt mit n Leuten haben, werden Sie m Defekte haben. Das Hinzufügen von Personen verursacht Kommunikationsaufwand und -probleme, aber das (soweit ich das beurteilen kann) geht über den Rahmen der einfachen Beziehung zwischen Personenfehlern hinaus. Ich stimme zu, dass ein Nebeneffekt des verspäteten Hinzufügens von Personen nicht nur eine Zunahme der Kommunikationskanäle und die Notwendigkeit ist, die Menschen zu schulen und auf den neuesten Stand zu bringen (Brooks'sches Gesetz), sondern auch eine mögliche Zunahme von Fehlern. Aber das liegt außerhalb des Rahmens.

— Thomas Owens

Das Hinzufügen von Leuten zu spät ist nur ein Faktor, den ich erwähnt habe. Das Management hat immer noch eine Tendenz , mehr Menschen zuweisen vorne sie riskante oder komplex antizipieren zu Projekten.

— Karl Bielefeldt

Der Sinn von SLIM (und anderen Schätzungstools, wenn sie richtig eingesetzt werden) besteht darin, bei der Schätzung der erforderlichen Anzahl von Personen, der Projektkosten, des Zeitaufwands usw. zu helfen. Dies setzt jedoch voraus, dass das Werkzeug richtig verstanden und verwendet wird.

— Thomas Owens

3

Angesichts der kürzlich aktualisierten Definitionen von Größe und Aufwand würde ich vorschlagen, dass die Ergebnisse möglicherweise darauf zurückzuführen sind, dass der Aufwand (gesamte Mannstunden) tatsächlich eine bessere Schätzung der tatsächlichen Projektgröße darstellt als die von der Quelle verwendeten Maßnahmen (Aufwand wäre) Eine perfekte Maßnahme, wenn alle Teams und Teamressourcen gleichwertig sind.

Was also wirklich passiert, ist, dass größere Projekte mehr Mängel aufweisen, was überhaupt nicht verwundert.

— bA
quelle

2

Dies erscheint unter der Annahme eines guten Prozesses und fähiger Ingenieure als kontraproduktiv.

Ich glaube nicht, dass Sie beides in der realen Welt annehmen können. Je mehr Leute an einem Projekt beteiligt sind, desto wahrscheinlicher ist es, dass Sie schlechte Äpfel haben, die nicht mithalten können und die besten Entwickler bremsen. Selbst wenn Sie den Annahmen folgen, gibt es ein paar andere Dinge, die Projekte verlangsamen und mehr Fehler verursachen, wenn Sie die Anzahl der Personen erhöhen:

Kommunikationsaufwand
Overhead beim Codelesen (damit meine ich, dass selbst die besten Entwickler mehr Zeit benötigen, um den Code anderer Leute zu lesen und zu konsumieren als ihren eigenen)
Die Tests müssen gründlicher sein (Wir alle arbeiten für eine 100% ige Testabdeckung, aber das kommt in der Praxis nur selten vor. Je mehr Leute Sie in ein Projekt einbinden, desto erschreckender wird das Refactoring ohne äußerst gründliche automatisierte Tests, da Sie nur auf Änderungen hoffen keine Nebenwirkungen haben. Nicht alle Tests können in angemessener Weise automatisiert werden, was noch mehr Zeit in Anspruch nimmt.)

Meiner Erfahrung nach gehen die negativen Auswirkungen von Projekten, die mit Entwicklern beladen sind, weit zurück, wenn das Projekt sehr modular ist und Sie nur 1 oder 2 Personen pro Schicht haben. Es ist mir egal, welches Versionskontrollsystem Sie gerade verwenden. Es ist wahrscheinlich eine schlechte Idee, wenn 4 Entwickler alle Checkins automatisch in derselben Datei zusammenführen.

— Morgan Herlocker
quelle

Wenn die einzige Möglichkeit, die Arbeit von 4 Entwicklern an derselben Datei zu verhindern, darin besteht, die Teamgröße auf 3 zu begrenzen, treten größere Probleme auf.

— JeffO

2

Es gibt einen Unterschied zwischen Korrelation und Kausalität. Das Zitat scheint zu sagen, dass die Gesamtzahl der Mängel bei Projekten, bei denen mehr Ingenieure eingesetzt werden, tendenziell höher ist. Das macht für mich durchaus Sinn, ich bin sicher, dass MS Windows mehr Fehler aufweist als die von mir erstellten Anwendungen, aber das bedeutet nicht, dass meine Anwendungen eine überlegene Qualität aufweisen.

Um ein anderes, abstrakteres Beispiel zu nennen: Wenn wir die Gesamtzahl der Todesfälle pro Land als Korrelation mit der Gesamtzahl der Ärzte im Land betrachten, können wir mit Sicherheit sagen, dass "Länder mit mehr Ärzten mehr Todesfälle hatten". Dies liegt nicht daran, dass die Ärzte den Tod verursacht haben, sondern dass eine große Anzahl von Ärzten auf eine große Bevölkerung hinweist.

— Daniel B
quelle

Für Ihr Beispiel mit Windows bin ich sicher, dass Windows auch mehr Möglichkeiten für Fehler hat, einfach weil es größer ist. Wenn ein Entwickler ein System mit 10 SLOC und ein System mit 10000 SLOC erstellt hätte, hätte das System mit 10000 SLOC eine höhere Wahrscheinlichkeit für einen Defekt (einschließlich Tippfehler, die das Kompilieren verhindern, fehlende Semikolons, Logikfehler usw.). . Größere Projekte haben in der Regel mehr Ingenieure, aber die Beziehung besteht nicht aus der Anzahl der Mitarbeiter und den Fehlern, sondern aus der Größe und den Fehlern.

— Thomas Owens

@ThomasOwens - yepp, das war genau mein Punkt.

— Daniel B

Warum werden Fehler nicht mit der Größe und Komplexität des Projekts verglichen?

— JeffO

@JeffO - Relativ zu messen ist absolut nicht trivial (wie genau machst du das?). Vielleicht wird die ursprüngliche Aussage aus dem Zusammenhang gerissen, aber Autoren bezeichnen komplexe, berechnete Ergebnisse selten einfach als "Mängel". In einem solchen Fall würde ich ein anderes Wort wie "Qualität" (was impliziert, dass einige Berechnungen durchgeführt wurden) oder einen längeren Ausdruck wie "Defekte pro zugewiesenem Ingenieur" erwarten. Vielleicht bin ich hier ein bisschen zynisch gegenüber den Autoren :)

— Daniel B

@ Jeff Sie würden sein. Aber Sie würden Defekte mit der Größe und Komplexität vergleichen, nicht mit der Anzahl der Personen. Mit zunehmender Größe und Komplexität nehmen die Mängel und die Anzahl der Personen zu. Also ja, obwohl die Anzahl der Menschen zunimmt, erhöht diese Zunahme der Menschen nicht die Anzahl der Defekte.

— Thomas Owens

1

Lassen Sie uns die Behauptung über die Anzahl der Personen für einen Moment beiseite legen.

Ein Blick auf die Anzahl der als Funktion des Aufwands injizierten Fehler kann sinnvoll sein, solange Sie davon ausgehen, dass ein höherer Aufwand zwangsläufig eine höhere Größe erfordert, da ein enger Zusammenhang zwischen der Anzahl der Fehler und der Softwaregröße besteht.

Wenn Sie also davon ausgehen, dass je mehr Aufwand in ein Projekt investiert wird, desto mehr Codezeilen werden geschrieben, können Sie den Aufwand wahrscheinlich als Proxy für die Größe verwenden, um die Anzahl der Fehler vorherzusagen. Die Korrelation zwischen Größe (z. B. LOC) und Anzahl der Defekte wurde in Arbeiten von Watts Humphrey, Capers Jones und anderen immer wieder gezeigt.

Ich verstehe nicht, wie die Anzahl der Personen passt, außer dass mehr Menschen mehr Aufwand bedeuten.

Verwechseln Sie die Korrelation nicht mit der Kausalität. Zwar besteht eine Korrelation zwischen der Größe und der Anzahl der injizierten Defekte, die Größe ist jedoch nicht die Ursache. Wie Sie bereits ausgeführt haben, liegt die Ursache in der Regel bei Personen- und Prozessproblemen. Das heißt, Defekte als Funktion der Größe sind eine gute Messgröße, um zu verstehen, ob es ein Problem gibt, und um die Wirksamkeit von Veränderungen zu messen.

— Michael
quelle

0

Ich gehe davon aus, dass dies auf Mitglieder des Kernprogrammierteams beschränkt ist und nicht auf Situationen, in denen Spezialisten wie UI, UX, DBA usw. tätig sind.

Ich denke, es muss gut gemanagt werden, aber das ist nicht einfach. Kleine Teams aus Qualitätsentwicklern können sich selbst verwalten. Es ist wahrscheinlicher, große Teile des Codes zu vermeiden, die von weniger talentierten Personen erstellt wurden.

Mehr Teammitglieder können die Aufgabenteilung erleichtern. Stellen Sie die besseren oder erfahreneren Entwickler auf die schwierigen Gebiete. Nehmen Sie Ihren besseren Entwicklern einige der alltäglichen oder nicht programmierbaren Aufgaben weg und lassen Sie die Junior-Entwickler die Unterbrechungen bewältigen. Dies erfordert mehr Planung und Überlegung, bietet jedoch die Möglichkeit, Ihr Talent zu nutzen.

Es gibt die Vorstellung, dass es besser ist, einen großartigen Entwickler zu haben, der sich eine neue Fähigkeit aneignen muss, als einen unterdurchschnittlichen Entwickler, der es bereits weiß. Das ist großartig, wenn Sie die Zeit haben. Wahrscheinlich liegt der Grund dafür, dass einem Projekt mehr Entwickler zugewiesen werden, am Arbeitsaufwand und an den zeitlichen Beschränkungen. Möglicherweise haben Sie jemanden, der sich auf ein bestimmtes Gebiet konzentrieren und kompetenter werden kann. Es ist großartig, über ein umfassendes Wissen zu verfügen, aber manchmal kann ein kleinerer Entwickler mit ein paar Anweisungen damit arbeiten.

Die Realität ist, dass es nicht viele Leute gibt, die jemals ein großes Team für ein erfolgreiches Projekt geleitet haben. Selbst wenn sie alle talentiert sind, ist es für große Teams schwierig, sich selbst zu verwalten. Stören Egos?

— JeffO
quelle