Was ist Softwareproduktivität?
Eigentlich ist es ganz einfach: Produktivität ist einfach Ausgabe im Laufe der Zeit.
Der schwierige Teil ist jedoch, ein geeignetes Maß für die Ergebnisse zu finden. Ergebnisse – zumindest im Kontext von Software – lassen sich nur schwer standardisieren. In den meisten Fällen können wir diese Ergebnisse im Hinblick auf den Geschäftswert und/oder die Bereitstellung benutzererkennbarer Funktionen betrachten.
Warum wollen so viele Unternehmen die Softwareproduktivität messen? Ist das wirklich so wichtig?
Bei jedem Software-Projekt müssen Manager nach einer Quantifizierung und einem gewissen Maß an Sicherheit hinsichtlich Kosten, Zeitplan und Umfang suchen. Sie werden auch nach Mitteln und Maßnahmen suchen, um …
- …Vergleich mit anderen Organisationen
- …den Fortschritt im Laufe der Zeit verfolgen
- …die Produktivität des Teams und einzelner Personen zu bewerten
- …nutzen Sie die Produktivität, um Offshoring-Entscheidungen zu treffen
- …nutzen Sie die Produktivität, um Priorisierungsentscheidungen zu treffen
Allgemeine Produktivitätsmaßnahmen
Wir konzentrieren uns in erster Linie auf die Produktivität der Entwickler, da Entwickler im Allgemeinen die aktivsten und teuersten Mitglieder eines Softwareprojekts sind. Es ist jedoch auch nützlich, die Produktivität anderer zu verstehen, darunter Tester, Analysten, Projektmanager, Designer, Architekten und alle anderen, die zum Erfolg dieser Projekte beitragen.
Kriterien einer guten Softwareproduktivitätsmetrik
Leider gibt es keine perfekte Messgröße für den „Output“ von Softwarearbeit. Daher müssen wir alternative, Proxy-Indikatoren finden, die uns näher an die Quantifizierung des Outputs heranführen.
Idealerweise wollen wir für Software eine „Output-Metrik“, die Folgendes erreicht:
- korreliert stark mit dem Geschäftswert
- ist nicht manipulierbar, sowie konsistent, objektiv, wiederholbar und unabhängig überprüfbar
- ist unabhängig und funktioniert unabhängig von der Programmiersprache
- ist gültig für den Vergleich eines Projekts mit einem anderen
- kann dafür verantwortlich sein, dass komplexere Arbeiten fähigeren Teammitgliedern zugewiesen werden
- kann günstig und einfach abgeholt werden
Als Randbemerkung: Ideale Messgrößen für die individuelle Produktivität unterscheiden sich geringfügig von denen zur Ermittlung der Teamproduktivität. Verwenden Sie, was für Ihr Szenario am besten funktioniert.
Ranking von Softwaremetriken
Die folgende Tabelle wurde erstellt von Steve McConnell und wird in dieser Präsentation besprochen zum Ranking geeigneter Softwareproduktivitätsmetriken. COSMIC-Funktionspunkte waren weniger bekannt und die automatische Größenanpassung war nicht verfügbar, als Steve diese Tabelle erstellte. Wir haben hier die Spalte für COSMIC-Funktionspunkte hinzugefügt. Diese zusätzliche Spalte ist subjektiv und unserer Meinung nach 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 das Ergebnis ein Kopf-an-Kopf-Rennen zwischen mehreren Ansätzen, wobei „Bestandene Testfälle“ am höchsten bewertet wurde. Mit dem Aufkommen eines einfacheren Ansatzes zur funktionalen Größenbestimmung (COSMIC-Funktionspunkte vs. IFPUG-Funktionspunkte) und zur automatisierten Größenbestimmung scheint es nun eine klare führende Messgröße zur Beurteilung der Produktivität zu geben: KOSMISCHE Funktionspunkte.
Irreführende Produktivitätsmaße
Es gibt zwar keine perfekte Messgröße für die Arbeit mit Software, aber manche sind nützlicher als andere. Manche Messgrößen können jedoch irreführend sein, missbraucht werden oder zu nicht hilfreichem Verhalten anstiften.
Codezeilen (LOC)
Entwickler können die Anzahl der Codezeilen, die für eine bestimmte Funktionalität geschrieben werden, stark variieren. Es ist leicht zu messen, aber nicht unbedingt ein Gut Maß, da verschiedene Programmiersprachen unterschiedliche Mengen an Code erfordern und die Unterschiede zwischen ihnen enorm sein können. Die Verwendung von Codezeilen als Maß kann Entwickler auch dazu verleiten, überflüssige Zeilen zu schreiben, nur um ihre Produktivität zu steigern. Dies hat einen kontraintuitiven Effekt, da es zusätzliche Wartungskosten verursachen kann.
Story-Punkte
Story Points sind ein subjektiver, nicht standardisierter Proxy zur Aufwandsschätzung. Manche behaupten, sie messen die Komplexität; die Realität ist jedoch, dass sie im besten Fall könnte geben einen Hinweis auf den Schwierigkeitsgrad einer bestimmten Aufgabe. Im Wesentlichen sind dies Hinweise auf „ideale“ Tage für Mitarbeiter. Sie sind für Vertragsarbeit ungeeignet und können nicht verwendet werden, um ein Team mit dem nächsten oder ein Projekt mit dem nächsten zu vergleichen. Durch die Übernahme von Story Points ist kein Lernen oder kontinuierliche Verbesserung möglich.
Geschichte zählt
Auch die Größe von User Stories kann erheblich variieren. Eine Story kann eine zehnminütige technische Aufgabe für eine Einzelperson sein; eine andere Story kann einen ganzen Monat Arbeit für ein ganzes Team erfordern. Unserer Erfahrung nach reichen Stories von 0 bis 120 CFP, was die Anzahl zu einer inkonsistenten Metrik macht.
Andere Maßnahmen zur Teamproduktivität
Eine Scorecard-basierte Produktivitätsbewertung kann in manchen Fällen sinnvoll sein, insbesondere wenn die Kartenwerte sowohl teamübergreifend normalisiert als auch so gewählt werden, dass sie alle Kriterien widerspiegeln, die das Unternehmen 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.
Der Gewinner: COSMIC-Funktionspunkte
Unsere empfohlene Ausgabekennzahl ist COSMIC-Funktionspunkte (CFP). Hier ist der Grund:
- CFP wurzelt in Grundprinzipien des Softwareverhaltens (Eingaben, Ausgaben, Lesen und Schreiben).
- CFP ist benutzerorientiert; es richtet sich nach dem, was nötig ist, um Mehrwert schaffen an den Benutzer.
- CFP ist ein angemessener Ersatz für Geschäftswert.
- CFP passt gut Zu tatsächlicher Aufwand.
- CFP hat eine Definition für eine individuelle Maßeinheit.
- CFP bietet eine Messung der Größe, der wichtigste Faktor bei der Bestimmung kosten Und Dauer eines Projekts.
- CFP ermöglicht es Managern, Nicht-Entwicklungsaktivitäten verwalten, mit CFP als Basismetrik.
- CFP ist offen, frei und unabhängig.
- CFPs sind geeignet für unvollständige Anforderungen (dh agil).
- CFPs sind geeignet für fast jede Art von Software.
- CFP frühe Schätzung ist fast vollständig automatisiert (natürlich von ScopeMaster).
Unter Softwareentwicklungsproduktivitätsmessung versteht man die Aufzeichnung der Metriken und Attribute eines Softwarevorhabens zu Vergleichszwecken.
Wie produktiv sind unsere Softwareentwickler?
Möchten Sie wissen, ob Ihr Team produktiver ist als andere Teams oder als der Branchendurchschnitt?
Sie können die Aktivitäten eines Teams mit denen eines anderen innerhalb einer Organisation vergleichen. internes BenchmarkingDer Vergleich mit einer anderen ähnlichen Organisation wird bezeichnet als Externes Benchmarking. Obwohl Branchen-Benchmarks interessant sein können, gelten lokale und interne Benchmarks im Allgemeinen als die zuverlässigsten.
Benchmarking und Bewertung der Softwareentwicklungsproduktivität Ihres Teams
Wenn Sie ein großartiges Team haben, warum veröffentlichen Sie nicht Ihren Produktivitätsindex? Er könnte Ihnen dabei helfen, Entwicklungsaufträge zu gewinnen. Alles was Sie brauchen, ist ein Satz User Stories aus einem früheren Projekt, etwa eine Stunde und Zugriff auf ScopeMaster.
- Nehmen Sie eine Reihe von Anforderungen aus einem aktuellen Projekt. Laden Sie sie in ScopeMaster hoch und lassen Sie den Analysator die Größe berechnen.
- Geben Sie für den Produktivitätsrechner den gesamten Projektaufwand (in persönlichen Tagen), die Projektdauer (in Monaten) und die Fehlerbeseitigung ein, die Sie letztendlich im Projekt erreicht haben.
- ScopeMaster ermittelt dann die Produktivitätsindex Ihres Teams.
…und das ist alles!
Wenn Sie über dem Durchschnitt liegen (ca. sechs auf dem Index), dann sind Sie auf dem Weg zur Größe. Wenn Sie möchten, können wir den Produktivitätsindex Ihres Teams sogar in unserer Rangliste veröffentlichen!
Denken Sie daran: Seien Sie vorsichtig bei irreführenden Messwerten. STory Points, Codezeilen, T-Shirt-Größen und Manntage sind allesamt manipulierbare, leicht manipulierte Techniken zur Schätzung von Zeit und Aufwand. Halten Sie sich für optimale Ergebnisse an ISO-Standardmethoden zur funktionalen Größenbestimmung.
