Was ist Softwareproduktivität?

Im Grunde ist es einfach, es handelt sich um eine Ausgabe im Laufe der Zeit.

Produktivität = Output/Zeit

Der schwierige Teil besteht jedoch darin, ein geeignetes Maß für die Ergebnisse zu finden. Ausgaben im Kontext von Software sind schwer zu standardisieren. In den meisten Fällen können wir uns den Output eines Softwareprojekts als Geschäftswert und/oder bereitgestellte, für den Benutzer erkennbare Funktionen vorstellen.

Warum viele Unternehmen die Softwareproduktivität messen wollen

Manager haben die Pflicht, eine Quantifizierung und eine gewisse Gewissheit über Kosten, Zeitplan und Umfang eines bestimmten Softwareunternehmens anzustreben. Sie werden auch nach Mitteln und Maßnahmen suchen, um:

  • Vergleich mit anderen Organisationen
  • Verfolgen Sie den Fortschritt im Laufe der Zeit
  • Bewerten Sie die Team- und Einzelproduktivität
  • Nutzen Sie die Produktivität, um Offshoring-Entscheidungen zu treffen
  • Nutzen Sie die Produktivität, um Priorisierungsentscheidungen zu treffen

Allgemeine Produktivitätsmaßnahmen

Hauptsächlich konzentrieren wir uns auf die Entwicklerproduktivität, da Entwickler in der Regel am meisten leisten und bei einem Softwareprojekt auch die meisten Kosten verursachen. Es ist aber auch nützlich, die Produktivität anderer Beteiligten zu verstehen, darunter Tester, Analysten, Projektmanager, Designer, Architekten und andere, die an Softwareprojekten beteiligt sind.

Kriterien für eine gute Softwareproduktivitätsmetrik

Es gibt keine perfekte Metrik für den „Output“ der Softwarearbeit, daher müssen wir alternative Proxy-Indikatoren finden, die uns dabei helfen können, der Quantifizierung des „Outputs“ nahe zu kommen.

Idealerweise wollen wir für Software eine „Output-Metrik“, die Folgendes erreicht:

  • korreliert stark mit dem Geschäftswert
  • ist unveränderlich und konsistent, objektiv, wiederholbar und unabhängig überprüfbar
  • ist unabhängig von der Programmiersprache
  • gilt für den Vergleich eines Projekts mit einem anderen.
  • kann dafür verantwortlich sein, dass komplexere Arbeiten fähigeren Teammitgliedern zugewiesen werden
  • die günstig und einfach abgeholt werden können.

Beachten Sie, dass die idealen Kennzahlen für die individuelle Produktivität geringfügig von den idealen Kennzahlen zur Bestimmung der Teamproduktivität abweichen.

Ranking der Software-Metriken

Die folgende Tabelle wurde erstellt von Steve McConnell und wird in dieser Präsentation besprochen zur Einstufung geeigneter Software-Produktivitätsmetriken. COSMIC-Funktionspunkte waren weniger bekannt und eine automatische Größenanpassung war nicht verfügbar, als Steve diese Tabelle zum ersten Mal erstellte. Ich habe die Spalte für KOSMISCHE Funktionspunkte hinzugefügt. Diese zusätzliche Kolumne ist subjektiv und stellt unsere eigene Meinung dar und ist nicht Teil von Steves ursprünglicher Einschätzung.

LOC/SM
FP/SM
CFP/SM
Story Points/SM
360 Peer-Reviews
Managerbewertung
Vorhersehbarkeit der Aufgabenerledigung
Testfälle bestanden
Fehlerraten
Die Messung spiegelt tatsächlich die Produktivität wider 3 4 4 4 3 2 1 4 3
Direkt oder indirekt sind sie für die gesamte oder den größten Teil der Arbeitsleistung verantwortlich 4 4 4 5 5 5 2 4 3
Nützlich zum Messen der Arbeit von Nicht-Programmierern 1 4 4 4 5 5 5 4 4
Widersetzt sich dem „Spielen“ einzelner Mitwirkender 2 5 5 4 3 3 4 4 5
Stark korreliert mit dem Geschäftswert 2 3 4 4 3 4 2 4 3
Objektiv, unabhängig überprüfbar 4 4 5 3 2 2 4 4 4
Die Ausgabe der Messwerte ist unabhängig von der verwendeten Programmiersprache gleich 1 5 5 3 5 5 5 5 5
Unterstützt persönliche Vergleiche innerhalb eines Teams 3 4 4 4 5 4 4 4 4
Accounts dafür, dass die besten Leute die schwierigsten Aufgaben bekommen 2 4 5 4 5 5 1 5 2
Daten können einfach und kostengünstig erhoben werden 3 1 5 3 3 4 3 3 4
25 38 45 38 39 39 31 41 37
Rang 9 5 1 5 3 3 8 2 7

In Steves ursprünglicher Einschätzung war die Schlussfolgerung ein knappes Ergebnis zwischen mehreren Ansätzen, wobei „Testfälle bestanden“ der höchste Wert war. Mit der Einführung a) eines einfacheren Ansatzes zur funktionalen Dimensionierung (COSMIC-Funktionspunkte vs. IFPUG-Funktionspunkte) und b) der automatisierten Dimensionierung scheint es nun eine klare Leitmetrik für die Bewertung der Produktivität zu geben – COSMIC-Funktionspunkte.

Irreführende Produktivitätsmaße

Es gibt keine perfekte Metrik für Softwarearbeit, aber einige sind nützlich und gültig. Es gibt auch einige, die wahrscheinlich irreführen, missbraucht werden oder zu nicht hilfreichem Verhalten anstiften.

Zeilen von Code

Das Maß für die Produktivität ist hier die Anzahl der im Laufe der Zeit geschriebenen Codezeilen. Angesichts der Tatsache, dass die Anzahl der Codezeilen für eine bestimmte Funktionalität bei verschiedenen Entwicklern um das Zehnfache variieren kann, kann die im Laufe der Zeit bereitgestellte LOC bestenfalls nur eine Annäherung sein. Es ist leicht zu messen, aber nicht unbedingt ein gutes Maß. Unterschiedliche Programmiersprachen erfordern eine unterschiedliche Anzahl an Codezeilen und variieren erheblich von einer Programmiersprache zur anderen. Die Verwendung von Codezeilen kann Entwickler auch dazu ermutigen, zusätzliche überflüssige Zeilen zu schreiben, nur um als „produktiv“ eingestuft zu werden. Dies hat den gegenteiligen Effekt wie beabsichtigt, da es zu zusätzlichen Wartungskosten führen kann.

Story-Punkte

Story Points sind ein subjektiver, nicht standardmäßiger Proxy für die Aufwandsschätzung. Einige werden behaupten, dass sie Komplexität „messen“. Bestenfalls können sie einen Hinweis auf die Schwierigkeit einer bestimmten Aufgabe geben. Im Wesentlichen handelt es sich hierbei um einen Hinweis auf „ideale Mitarbeitertage“. Diese sind für Vertragsarbeiten ungeeignet und können nicht zum Vergleich eines Teams mit dem anderen oder eines Projekts mit dem anderen verwendet werden. Durch die Übernahme von Story Points ist kein „Lernen“ oder keine „kontinuierliche Verbesserung“ erreichbar.

Geschichte zählt

Die Größe der User Story kann erheblich variieren, unabhängig davon, ob Sie die Größe in COSMIC-Funktionspunkten oder in idealen Personaltagen schätzen. Bei einer Story kann es sich um eine 10-minütige technische Aufgabe handeln, bei einer anderen Story kann die Umsetzung eines Teams einen ganzen Monat in Anspruch nehmen. Unserer Erfahrung nach variieren die Geschichten in der Größe von 0 CFP bis 120 CFP.

Andere Maßnahmen zur Teamproduktivität

Eine auf Scorekarten basierende Produktivitätsbewertung kann unter bestimmten Umständen nützlich sein, insbesondere wenn die Kartenwerte sowohl teamübergreifend normalisiert als auch so gewählt sind, dass sie alle Kriterien widerspiegeln, die die Organisation verwenden möchte.

Es ist wichtig, Kriterien auszuwählen, die sich auf die Werte der Organisation (Qualität und Leistung) konzentrieren. Es ist auch wichtig, die Teams auf die wahren Ziele des Unternehmens auszurichten.

Empfehlung

KOSMISCHE Funktionspunkte

Unser empfohlenes Ausgabemaß sind COSMIC Function Points (CFP). Unsere Gründe für diese Empfehlung sind:

  1. CFP basiert auf grundlegenden Prinzipien des Softwareverhaltens (Eingaben, Ausgaben, Lese- und Schreibvorgänge).
  2. CFP ist benutzerorientiert – es richtet sich nach dem aus, was erforderlich ist, um dem Benutzer einen Mehrwert zu bieten
  3. CFP ist ein angemessener Indikator für den Geschäftswert.
  4. CFP passt sehr gut zum tatsächlichen Aufwand.
  5. CFP hat eine Definition für eine einzelne Größeneinheit.
  6. CFP bietet eine Messung der Größe, die der wichtigste Faktor bei der Bestimmung von Kosten und Dauer eines Projekts ist.
  7. Mit CFP können Manager auch nicht entwicklungsbezogene Aktivitäten verwalten, indem sie CFP als Basismetrik verwenden.
  8. CFP ist offen, kostenlos und unabhängig.
  9. CFP eignet sich für unvollständige Anforderungen (z. B. Agile).
  10. CFP eignet sich für nahezu jede Art von Software
  11. Die frühe CFP-Schätzung erfolgt größtenteils automatisiert (durch ScopeMaster®)

Unter Softwareentwicklungsproduktivitätsmessung versteht man die Aufzeichnung der Metriken und Attribute eines Softwarevorhabens zu Vergleichszwecken.

CFP ist eine zuverlässige Methode zur Bewertung der Softwareproduktivität

Wie produktiv sind unsere Softwareentwickler?

Möchten Sie wissen, ob Ihr Team produktiver ist als ein anderes oder als die Branchennormen?

Sie können die Aktivitäten eines Teams mit denen eines anderen innerhalb einer Organisation vergleichen, internes Benchmarking. Der Vergleich mit einer anderen ähnlichen Organisation wird als externes Benchmarking bezeichnet.

Obwohl Branchen-Benchmarks interessant sein können, sind lokale/interne Benchmarks am zuverlässigsten.

Benchmarking der Softwareentwicklungsproduktivität – bewerten Sie Ihr Team

Wenn Sie ein großartiges Team haben, warum veröffentlichen Sie dann nicht Ihren Produktivitätsindex? Vielleicht hilft er Ihnen dabei, Entwicklungsarbeit zu gewinnen?

Sie benötigen lediglich eine Reihe von User Stories aus einem früheren Projekt, etwa 1 Stunde und Zugriff auf ScopeMaster.

  1. Nehmen Sie eine Reihe von Anforderungen aus einem aktuellen Projekt. Laden Sie sie in ScopeMaster hoch. Lassen Sie den Analysator die Größe ermitteln.
  2. Addieren Sie zum Produktivitätsrechner den Gesamtaufwand (in Personentagen), die Dauer (in Monaten) und die Fehlerbeseitigung, die Sie erreicht haben.
  3. Es wird dann die ermittelt Produktivitätsindex Ihres Teams.

Und das ist alles.

Wenn Sie über dem Durchschnitt liegen, sagen wir 6+ für ein Web-Team, dann sind Sie auf dem Weg zur Größe. Wenn Sie möchten, veröffentlichen wir den Produktivitätsindex Ihres Teams in unserer Rangliste.

Hüten Sie sich vor irreführenden Kennzahlen

Story Points, Codezeilen, T-Shirt-Größen und Manntage sind alle spielbar oder leicht zu manipulieren, Techniken, die normalerweise zur Schätzung von Aufwand und Zeit verwendet werden. Sie werden ausnahmslos für eigene Zwecke manipuliert. Nur funktionale Größenbestimmungsmethoden nach ISO-Standard sind schwer zu manipulieren.

Benchmarking der Softwareentwicklung