Was ist der Stand der Technik??

Agile Methoden werden heutzutage immer beliebter und haben sich aufgrund ihrer Fähigkeit, eine hohe Kundenzufriedenheit zu erzielen, zu einem Mainstream der Softwareentwicklung entwickelt. Schätzungs- und Metrikberatungen erhalten immer mehr „Agile-Aufträge“ und sollen wertvolle Ratschläge für agile Projektumgebungen liefern. Agile-Methoden unterscheiden sich jedoch von herkömmlichen Wasserfall-Methoden insbesondere in der Art und Weise, wie Schätzungen und Metriken erfasst werden. Eine Recherche in der Literatur und im Internet zu diesen Themen gibt Aufschluss über die Unterschiede und wird unser Wissen erweitern und möglicherweise unsere Fähigkeiten stärken. Es wurden neue Ansätze gefunden, wie bestehende Techniken und Instrumente in agilen Umgebungen angewendet werden können. Das Ergebnis dieser Umfrage umfasst drei Artikel. Dieses erste Papier zeigt den Stand der Metriken in der agilen Softwareentwicklung.

Softwaremetriken im Allgemeinen

Softwaremetriken oder Softwaremessungen sind ein Konzept aus der Softwarebranche. Es kann wie folgt beschrieben werden: nach definierten Grundsätzen Werte auf Eigenschaften von Produkten oder Prozessen anzuwenden, um statistische oder vergleichende Analysen im Rahmen eines zuvor definierten Zwecks durchzuführen.

Software Metrics unterstützt normalerweise drei Interessenbereiche.

• Planung, Prognose
• Überwachung & Kontrolle
• Leistungsverbesserung, Benchmarking

Es gibt viele Softwaremetriken, die für verschiedene Situationen verwendet werden. Putnam und Myers zeigen wunderbar auf, worum es bei dem geht ‘5 Kernkennzahlen‘ für Softwareentwicklung: man entwickelt eine Produkt von akzeptabel Qualität mit einem gewissen Anstrengung in gewisser Weise Zeit. Die Beziehung zwischen Produkt, Qualität, Aufwand und Zeit, wird durch die Produktivität bestimmt, die daher auch gemessen werden muss. Wir werfen einen genaueren Blick auf diese Kernkennzahlen.

Produkt(Größe)
Misst quantitative Eigenschaften, welches die Größe des Produkts bestimmt. Muss vorher oder nachher durchgeführt werden.
Beispiele: ORT, Funktionspunkte, Anzahl der Anwendungsfälle, Anzahl der Funktionen, Benutzergeschichten.

Qualität
Das Produkt muss eine gewisse Qualität besitzen, Wird normalerweise anhand der „Anzahl der Mängel pro Zeitspanne“ bestimmt., die mittlere Zeit bis zum Defekt (MTTD) und die „Fehlerdichte“ (Anzahl der Fehler pro KLOC).

Bemühung
Gemessen in Personenmonaten, die ausschließlich seinem Projekt gewidmet waren.

Dauer
Dies ist die Bearbeitungszeit ohne Unterbrechung zwischen Startdatum und Enddatum des Projekts (z.B.. in Monaten).

Produktivität
Dies ist eine Eigenschaft des Prozesses, d.h.. Der Softwareentwicklungsprozess in der Organisation. Es wird betont, dass es sich dabei nicht um die Produktivität einer oder mehrerer Personen handelt, die sich um die Umsetzung kümmern! Die Produktivität bestimmt die Beziehung zwischen dem Produkt (Größe), Aufwand und Zeit in der sogenannten Softwaregleichung in ihrer Grundform:

Productivity = product size (with a known Quality) / (effort * time)
(refer to the book for explanation)

Diese Kernkennzahlen unterstützen das zuvor Erwähnte (hauptsächlich) Interessengebiete wie folgt.
Planung und Vorhersage: Produktivität und Produktgröße (in der gewünschten Qualität) indirekt die Kosten bestimmen, Vorlaufzeit und Aufwand.
Überwachung und Kontrolle: Als Produktbestandteil werden alle Arten von Messungen verwendet, prozentualer Aufwand pro geliefertem Produkt im Vergleich zur gesamten Produktgröße zu einem bestimmten Zeitpunkt, Anzahl der während der Entwicklung gefundenen Fehler im Vergleich zur erwarteten Anzahl von Fehlern. Diese Art von Messungen charakterisiert die Leistung des Projektteams.
Verbesserung, Benchmarking: Durch den Aufbau einer Historie mit Schlüsselinformationen aus eigenen abgeschlossenen Projekten kann ein Bezugspunkt ermittelt werden, mit dem zukünftige Projekte verglichen werden können. Auch die eigene Leistung kann mit der Leistung anderer Unternehmen verglichen werden (Benchmarking). Mit diesem zweiten Vergleich kann festgestellt werden, ob die Leistung der Organisation marktkonform ist.

Metriken in agilen Projekten

Agile Methoden haben denselben Ausgangspunkt wie die Wasserfallmethode, nämlich: man entwickelt eine Produkt von akzeptabel Qualität mit einem gewissen Anstrengung in gewisser Weise Zeit.

Der Ansatz und die Prozesse können unterschiedlich sein, aber im Prinzip ist es ein anderer Weg, der zum gleichen Ziel führt. Es ist nicht verwunderlich, dass Software-Metriken in einer agilen Umgebung ihren Platz haben. jedoch, Es gibt einige bemerkenswerte Unterschiede zum Wasserfallansatz. An erster Stelle, Es ist festzuhalten, dass agile Methoden ihre größten Erfolge in kleinen bis mittelgroßen Projekten für kommerzielle Anwendungen erzielen.

Der Fokus der agilen Metriken liegt im Einklang mit dieser begrenzten Größe und konzentriert sich hauptsächlich auf das Team, die aktuelle Iteration, die aktuelle Version. Weniger auf das Projekt und möglicherweise überhaupt nicht auf ein ganzes Projektprogramm. Zusamenfassend, Der Fokus ist nach innen gerichtet. Dies ist wichtig zu beachten, da sich Agile in diesem Punkt deutlich vom Wasserfall-Ansatz unterscheidet. Ein zweiter auffälliger Unterschied zwischen agilen Metriken und Wasserfallmetriken ist der Unterschied in den verwendeten Maßeinheiten. Agile Metriken für das Produkt(Größe) und Produktivität werden in subjektiven Einheiten ausgedrückt (Story-Punkte und Story-Punkte pro Iteration oder Geschwindigkeit) die nur für dieses Projekt und dieses Team gelten. Dies ermöglicht einen Vergleich zwischen Teams, Projekte und Organisationen unmöglich. Wasserfallmetriken werden insbesondere zu Benchmarking-Zwecken in standardisierten Einheiten ausgedrückt.

Die folgende Matrix zeigt die Kernmetriken von Putnam und Myers in beiden Umgebungen.

Kernmetrik	Agil	Wasserfall
Produkt(Größe)	Merkmale, Geschichten	FP, CFP, UCP
Qualität	Mängel/Iteration, Mängel, MTTD	Mängel/Freigabe, Mängel, MTTD
Bemühung	Story-Punkte *)	Personenmonate
Zeit	Dauer (Monate)	Dauer (Monate)
Produktivität	Geschwindigkeit (Story Points/Iteration) **)	Stunden/FP ****)

*)	Story Points sind subjektiv und gelten nur für dieses Projekt und dieses Team
**)	Geschwindigkeit ist subjektiv und gilt nur für dieses Projekt und dieses Team, Benchmarking nicht möglich.
***)	FP und CFP sind objektiv und stellen internationale Standards zur Angabe der Funktionsgröße dar.
****)	Stunden/FP werden von mehreren Schätzungen verwendet & Metrik-Tools für Benchmarking-Zwecke.

 

Ein Rundgang im Web zum Einsatz von Metriken in der Agile-Community ergibt ein vielfältiges Bild. Einige Berater schlagen Kennzahlen vor, die „in der Nähe der bleiben“. Manifest „. In dieser Kategorie entstehen Ziele als „Einblick in das Vertrauen des Sponsors“., ‘ Verständnis für „Kundenzufriedenheit“ und „Motivation des Teams“. Die Perspektive, aus der „Agilisten’ Schauen Sie sich die Kennzahlen an, wird durch die Präsentation auf gut veranschaulicht Agile Metriken von Mike Griffith. Neben den „Agilisten“ gibt es Berater, die sich auf die traditionellen Kennzahlen konzentrieren, Allerdings nutzen diese Metriken agile-eigene Konzepte und Einheiten wie Features, Iterationen, Story Points und Geschwindigkeit.

In diesem Zusammenhang ein bemerkenswertes Dokument, das Kürzliche These von Hanna Kulas. Dieses Dokument zeigt auf, warum Agile so besonders ist und wie bestimmte Produktmetriken in agile Projekte integriert werden können. Darüber hinaus wird geprüft, was gemessen wird und welche Vorteile festgestellt werden können. Die Anwendung dieser Produktkennzahlen kann zu einer Steigerung der Kundenzufriedenheit aufgrund einer höheren Produktqualität und geringeren Entwicklungskosten führen, was wiederum das Ergebnis eines verbesserten Verständnisses des Softwareentwicklungsprozesses ist.

Bemerkenswert und charakteristisch für Agilität ist das Fehlen von Metriken für Benchmarking oder andere Formen des externen Vergleichs. Die für das Produkt verwendeten Maßeinheiten (Größe) und Produktivität sind subjektiv und gelten ausschließlich für das jeweilige Projekt und Team. Aus Sicht eines Akquisitionsmanagers oder Sponsors gibt es keine Möglichkeit, Entwicklungsteams oder ausschreibende Auftragnehmer hinsichtlich der Produktivität zu vergleichen. Daher erfolgt die Auswahl eines Auftragnehmers nach rationalen Gesichtspunkten (Produktivität) ist praktisch unmöglich.

Im Folgenden werden die „agilen“ Metriken zusammengefasst, die im Web gefunden wurden; ihren Zweck und wie sie gemessen werden. Beachten Sie, dass die meisten Metriken „Überwachung“ unterstützen & Kontrolle'. Offensichtlich unterscheidet sich die agile Umgebung in diesem Interessengebiet nicht so sehr von der traditionellen Wasserfallumgebung.

„Agile“ Metriken, Ergebnisse einer Umfrage im Internet

Die folgenden Tabellen zeigen Metriken, die von verschiedenen „Agile-Beratern“ in vielen Fällen entsprechend ihrer eigenen Praxis empfohlen werden. Die Metriken sind um die zuvor in diesem Dokument erwähnten Interessenbereiche herum gruppiert.

Metriken für Planung, Prognose

Metrisch	Zweck	Wie misst man
Anzahl der Funktionen	1. Einblick in die Größe des Produkts (und die gesamte Veröffentlichung). 2. Wenn der Status auf Features angewendet wird: Einsicht im Gange.	Das Produkt umfasst Funktionen, die wiederum Geschichten umfassen. Funktionen werden als „zu erledigen“ gruppiert, 'im Gange', und „akzeptiert“.
Anzahl der geplanten Storys pro Iteration/Release	1. Einblick in die Größe des Produkts (und die gesamte Veröffentlichung). 2. Wenn der Status auf Storys angewendet wird: Einsicht im Gange.	Die Arbeit wird in Geschichten beschrieben, die in Story Points quantifiziert werden. Geschichten werden als „zu erledigen“ gruppiert, 'im Gange', und „akzeptiert“.
Anzahl der akzeptierten Geschichten pro Iteration/Release	Um den Fortschritt der Iteration/Veröffentlichung zu verfolgen	Formelle Registrierung akzeptierter Geschichten.
Teamgeschwindigkeit	Siehe Überwachung & Kontrolle
ORT	Gibt den Umfang der abgeschlossenen Arbeit an (Fortschritt), Berechnung anderer Metriken, d. h. Defektdichte.	Gemäß den vereinbarten Regeln, welche LOCs gezählt werden sollen.

Metriken für Überwachung & Kontrolle (Fortschritt und Leistung)

Metrisch	Zweck	Wie misst man
Iterations-Burndown	Leistung pro Iteration, „Sind wir auf dem richtigen Weg?“?‘.	Der Aufwand bleibt bestehen (in Std) für die aktuelle Iteration (Der aufgewendete/geplante Aufwand drückt die Leistung aus).
Teamgeschwindigkeit pro Iteration	Um die historische Geschwindigkeit für ein bestimmtes Team zu erfahren. Kann nicht zum Vergleich verschiedener Teams verwendet werden.	Anzahl der realisierten Story Points pro Iteration innerhalb dieser Version. Velocity ist team- und projektspezifisch.
Burn-Down freigeben	Um den Fortschritt einer Veröffentlichung von Iteration zu Iteration zu verfolgen: „Sind wir für die gesamte Veröffentlichung auf dem richtigen Weg?“.	Anzahl der Story-Punkte, die nach Abschluss einer Iteration innerhalb der Veröffentlichung zu erledigen sind (Die Extrapolation mit einer bestimmten Geschwindigkeit zeigt das Enddatum).
Burn-up loslassen	Wie viel „Produkt“ kann innerhalb des vorgegebenen Zeitrahmens geliefert werden?.	Anzahl der nach Abschluss einer Iteration realisierten Story Points im Vergleich zur Gesamtzahl der Story Points (der Veröffentlichung). Auf einer Zeitleiste wird der Fortschritt der „Umfangsvervollständigung“ angezeigt..
Anzahl der Testfälle pro Iteration	Um den Umfang der Testarbeit pro Iteration zu erfahren. Um den Testfortschritt zu verfolgen.	Anzahl der Testfälle pro Iteration, die als „nachhaltig“ erfasst wurden, „fehlgeschlagen“ und „zu tun“.
Zykluszeit (Kapazität des Teams)	Um Engpässe im Prozess zu ermitteln; Die Disziplin mit der geringsten Kapazität ist der Engpass.	Anzahl der Storys, die pro Disziplin innerhalb einer Iteration bearbeitet werden können (d.h.. Analyse- UI-Design-Codierung - Gerätetest- Systemtest).
Littles Gesetz – „Zykluszeiten sind proportional zur Warteschlangenlänge“.	Einblick in die Dauer; Wir können die Fertigstellungszeit basierend auf der Warteschlangenlänge vorhersagen.	In Arbeit (# Geschichten) dividiert durch die Kapazität des Prozessschrittes.

Metriken für Verbesserung (Produktqualität und Prozessverbesserung)

Metrisch	Zweck	Wie misst man
Kumulierte Anzahl von Mängeln	Um die Wirksamkeit von Tests zu verfolgen.	Protokollierung jedes Fehlers im Fehlermanagementsystem.
Anzahl der Testsitzungen	Um den Testaufwand zu verfolgen und ihn mit der kumulierten Anzahl von Fehlern zu vergleichen.	Extraktion von Daten aus dem Fehler-Repository.
Fehlerdichte	Bestimmung der Qualität der Software im Hinblick auf „Mängelfreiheit“.	Die kumulierte Anzahl von Fehlern geteilt durch 1000LOCs (BLOCK).
Fehlerverteilung pro Ursprung	Um zu entscheiden, wo Qualitätssicherungsressourcen zugewiesen werden sollen.	Durch Protokollierung der Fehlerursache im Fehlerspeicher und Extrahieren der Daten mithilfe eines automatisierten Tools.
Fehlerverteilung pro Typ	Erfahren Sie, welche Arten von Mängeln am häufigsten auftreten und helfen Sie, diese in Zukunft zu vermeiden.	Durch Protokollierung der Art der Fehler im Fehlerspeicher und Extrahieren der Daten mithilfe eines automatisierten Tools.
Fehlerzykluszeit	Einblick in die Zeit, einen Fehler zu beheben (Geschwindigkeit der Fehlerbeseitigung). Je schneller die Auflösung, die geringere Codierung „oben“ wird erzeugt.	Eröffnungsdatum des Mangels abzüglich des Lösungsdatums (normalerweise das Abschlussdatum im Fehlerspeicher).

Notiz: Es gibt auch „Metriken“.’ fand heraus, dass diese Maßnahme „Einblick in das Vertrauen des Kunden“ ist ‘ und ‘ Einblick in die Kundenzufriedenheit“. Allerdings gelingt es der Agile-Community bei diesen Metriken nicht, plausibel zu machen, warum diese Aspekte speziell auf Agile zutreffen und daher nicht berücksichtigt werden. Ich beziehe mich auf meine eigene Erfahrung von mehr als 30 Seit Jahren werden diese Aspekte in allen Arten von Projektumgebungen gemessen. Ähnliches gilt in etwa für den Einsatz der Earned-Value-Methode.

Schlussfolgerungen

Diese Tour im Internet und durch Veröffentlichungen führt zu den folgenden Schlussfolgerungen.

1. Die in den Agile-Methoden verwendeten Metriken und die verwendeten Einheiten (Story-Punkte, Geschwindigkeit) sind nicht standardisiert. Dies macht Benchmarking problematisch, wenn nicht unmöglich.
2. Wenn realisierte Story Points als LOCs ausgedrückt werden, kann eine Entsprechung mit standardisierten funktionalen Größeneinheiten hergestellt werden (FPn); Sogar die Produktivität einer Organisation oder die Produktivität eines Teams kann bestimmt werden.
3. Agile Methoden könnten von der Einbeziehung von Produktmetriken profitieren, da die Kundenzufriedenheit aufgrund einer höheren Produktqualität und geringerer Entwicklungskosten durch ein verbessertes Verständnis des Softwareentwicklungsprozesses steigt.
4. Innerhalb der Agile-Community werden viele Metriken entwickelt, Das sind im Wesentlichen die gleichen wie die Metriken innerhalb der Wasserfallmethode, Allerdings nutzen sie agile eigene Einheiten und Konzepte.
5. Agile Methoden erkennen die „funktionale Größe“ nicht an. Die „Größe“ einer Veröffentlichung wird als Anzahl der Features oder Storys ausgedrückt. Die Messung „Story Points“ ergibt keinen (funktional) Größe, sondern eher ein Maß an erforderlichem Aufwand.

Links zu einigen Websites

• Groß sichtbar – Agile Metriken und Diagnosen
• Skaliertes agiles Framework – Metriken
  Diese Website von Dean Leffingwell nimmt eine Sonderstellung ein. Das Scaled Agile Framework ist eine Philosophie und Methodik, die die agile Entwicklung in eine „schlanke“ Unternehmensstrategie umwandelt. Einige der im Diagramm erwähnten „Kunst“-Metriken sind in den obigen Tabellen enthalten.
• Institut für Softwaretechnik – Sieben Kategorien agiler Metriken
• Führende Antworten – Qualitätsprojektmanagement

 

 

Über den Autor

John Kammelar ist Metrics Consultant bei metrieken.nl, Dies hilft Unternehmen dabei, Einblicke und Kontrolle über Kosten und Zeit für die Softwareentwicklung und -verwaltung zu erhalten. Sie quantifizieren die Funktionalität mit der Funktionspunktanalyse. Basierend auf dieser Analyse kann eine realistische Schätzung des Zeit- und Kostenaufwands vorgenommen werden. Dieser Blog ist Teil einer Serie von drei Artikeln, die das Ergebnis einer umfassenden Umfrage sind. Dieser erste Teil zeigt den Stand der Metriken in der agilen Softwareentwicklung. Alle Artikel können hier heruntergeladen werden metrieken.nl Webseite.

Ein Blogbeitrag repräsentiert die persönliche Meinung des Autors
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.