Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht kontrollieren. Application Lifecycle Management sichert Produktivität und Qualität 11. Juni 2009, Swissôtel Zürich-Oerlikon Toni Steimle

Warum Projekt-Metriken Inhalt Warum Projekt-Metriken Welche Projekt-Metriken gibt es für das Projekt Governance Projekt-Metriken im Team System Wie kündigen sich Projektprobleme in den Metriken an Nicht Teil des Vortrages: Code Metriken, Code Analyse © CREALOGIX 2008 Monday, March 27, 2017

Metriken Probleme wie beispielsweise Falsche Schätzung Ungenügende Tests Umsetzungsschwierigkeiten Manifestieren sich in Indikatoren (Metriken). z.B. Übrigbleibende Arbeit (Ramaining Work Chart, Burndown Chart) z.B. Projektgeschwindigkeit (Project Velocity) z.B. Qualitätsindikatoren (Quality Indicators) Charts werden interpretiert Massnahmen wie beispielsweise Neuplanung Unterstützung © CREALOGIX 2008 Monday, March 27, 2017

Was bringen Metriken: Veränderungen erfassen Quantitative Daten ergänzen qualitative Daten Was tun wenn qualitative Daten nicht verfügbar sind Veränderungen erfassen Benchmarking (Teams, Projekte, Branche) © CREALOGIX 2008 Monday, March 27, 2017

Was bringen Metriken: Benchmarking © CREALOGIX 2008 Monday, March 27, 2017

Was bringen Metriken: Anzahl Bugs im Industrievergleich 10000 10000 1000 1000 Projekt 2 100 100 Projekt 3 Projekt 1 10 10 1 1 10 100 1000 Quelle: Michael Mah, Agile Conference 2008 © CREALOGIX 2008 Monday, March 27, 2017

Was möchte man messen? Produktqualität Projektfortschritt Prozessqualität © CREALOGIX 2008 Monday, March 27, 2017

Produktqualität Kundenzufriedenheit Anzahl Kundenprobleme Anzahl Fehler Fehlerdichte (Fehler / Anzahl Codezeilen) Codequalität Kundenzufriedenheit Kundenprobleme Fehler Codequalität © CREALOGIX 2008 Monday, March 27, 2017

Prozessqualität Gefundene Fehler in Testphase Fehlerfindungsmuster, Fehlerfindungseffizienz Fehlerbehebungseffizienz Fehlerbehebungszeit Durchschnittliches Alter von Fehler Zusatzfehlerrate Planungsgenauigkeit (Zeit und Aufwand) Reviewintensität (z.B. Reviewzeit pro Codezeilen) Abdeckungsgrad: Review, Unit Tests, Manuelle Tests Fehlerwiedereröffnungsrate Codeänderungsrate © CREALOGIX 2008 Monday, March 27, 2017

Projektfortschritt Aufgaben-Abarbeitungsgeschwindigkeit Risikoanteil Anforderungsabdeckungsgrad Testabdeckungsgrad / Fehleranteil © CREALOGIX 2008 Monday, March 27, 2017

Wo entstehen Messdaten Definieren Implementieren „Ausführbare Features“ Testen Agile Projekte Rein phasenbasierte Projekte Zeit © CREALOGIX 2008 Monday, March 27, 2017

Wo entstehen Messdaten Projekt Szenarien, QoS Grobe Aufwandschätzung Zeitplan Testfälle Realisierter Aufwand Erreichtes Datum Iteration Status Szenarien Status QoS Testergebnisse Projektgeschwindigkeit Szenarien QoS Velocity Build Code Analyse Review Ergebnisse Code Coverage Testergebnisse Code und Architektur Richtlinien Testrichtlinien Story Dauer Abhängigkeiten Zeitraum Ressourcen Status Benötigte Zeit Enddatum © CREALOGIX 2008 Monday, March 27, 2017

Metriken mit Team System Work items Versions verwaltung Builds Tests Data Warehouse TFS Reports Excel Sharepoint © CREALOGIX 2008 Monday, March 27, 2017

Überblick über Metriken Übrigbleibende Arbeit Ungeplante Arbeit Projektgeschwindigkeit Anzahl Fehler Qualitätsindikatoren Risikogehalt © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Übrigbleibende Arbeit Komponenten - Endtermin bei grünem Bereich eingehalten - Leicht ansteigende Anzahl Anforderungen - Relativ konstanter Resolved Bereich. Testing kommt nach. Das Diagramm für übrigbleibende Arbeit zeigt oft eine S-förmige Kurve. Nach einigen Anlaufschwierigkeiten performt das Team am besten. Am Schluss werden die Problemfälle behandelt. In diesem Diagramm wird der Endtermin erreicht. © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit unterschätzem Aufwand Übrigbleibende Szenarien © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Risikoverlauf © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit mangelnder Risikostrategie Risikoanteil © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Ungeplante Arbeit © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit unterschätzem Aufwand Ursache: Ändernde Anforderungen © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit unterschätzem Aufwand Ursache: Architekturprobleme © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Projektgeschwindigkeit Dies Grafik ist das Schlüsselelement in der Projektabschätzung. Letztendlich zeigt es die Steigungen der Kurven, die in der Grafik „Remaining Work“ abgebildet sind. Auch hier die für viele Projekte typische S-Kurve nicht vergessen: Mitten im Projekt ist die grösste Geschwindigkeit, umgeben von Anlaufschwierigkeiten und unvorhergesehene Schwierigkeiten am Ende. Man sieht direkt wie schnell die einzelnen Work Items abgearbeitet werden. Dabei wird jedoch vorausgesetzt, dass alle Work Items, die gezählt werden, d.h. Bugs, Tasks, Szenarios, etc. jeweils den gleichen Aufwand haben, ansonsten ist die Grafik nicht aussagekräftig. Diese Voraussetzung ist jedoch unrealistisch. Sinnvoll ist daher oft auch ein Filter auf Szenarien. © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Fehlerrate © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit unterschätzem Aufwand Ursache: Architekturprobleme © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt: Bug Reactivation © CREALOGIX 2008 Monday, March 27, 2017

Ineffizente Fehlerbehebung © CREALOGIX 2008 Monday, March 27, 2017

Gesundes Projekt Qualitätsindikatoren Interpretation Hier wird der Verlauf von Qualitätsindikatoren bei einem gesunden Projekt gezeigt. Es werden zusätzliche Tests hinzugefügt. Dabei erhöht sich auch die Testabdeckungsrate (Code Coverage). Die Codeänderungsrate nimmt ab, was auf eine saubere Architektur hinweist. Die Fehler werden abgearbeitet. Anforderungen Builds müssen richtig für Code Coverage und Testing konfiguriert sein. Beispielsweise darf nicht die *.DLL Funktionalität für das Testen verwendet werden, da dabei keine Code Coverage ausgeführt wird. Typisches Problem: Die Anzahl der Tests steigt nicht, obwohl die Entwickler zusätzliche Tests hinzufügen und implementieren: Die Testliste ist falsch konfiguriert, d.h. die Tests sind nicht in der relevanten Liste hinzugefügt. © CREALOGIX 2008 Monday, March 27, 2017

Projekt mit unterschätzem Aufwand Ursache: Architekturprobleme © CREALOGIX 2008 Monday, March 27, 2017

Qualitätsprobleme Unpassende Tests © CREALOGIX 2008 Monday, March 27, 2017

Risiken bei Anwendung von Metriken Einseitige Anreize durch unvollständige Messung (z.B. hohe Code Coverage jedoch keine saubere Behandlung von Sonderfällen) Motivationsprobleme. Es wird nur das gemacht, was gemessen wird. Ungewolltes Konkurrenzverhalten (z.B. Vergleich Projektgeschwindigkeit von Teams) Bluffing (z.B. Zufügen von sinnlosen Workitems um Scope Creep vorzutäuschen) © CREALOGIX 2008 Monday, March 27, 2017

Zu beachten Relativ konstante Anzahl Szenarien notwendig Szenarien und Tasks sollten nicht zu unterschiedlich lang sein Genügend kleine Szenarien und Tasks Daily Builds mit Fulltest (Achtung: Smoke Tests) Tests müssen in Testliste enthalten sein Builds müssen richtig für Code Coverage und Testing konfiguriert sein © CREALOGIX 2008 Monday, March 27, 2017

Was nicht gemessen wurde Offene Arbeit in Arbeitstagen (und nicht in #Workitems) Qualität der Testauswahl Qualitätsprobleme, welche sich nicht in Bugs manifestiert Zunahme von Requirements oder nur Detaillierungsgrad Risikoanteil der mit abgearbeiteten Szenarien reduziert wird © CREALOGIX 2008 Monday, March 27, 2017

Schlusswort Metriken sind immer nur eine Ergänzung aber kein Ersatz von Teamkommunikation. Metriken sind besonders wertvoll bei verteilten Teams . Metriken sind eine Modellierung der Wirklichkeit. Das Modell ist nie vollständig. Wichtig ist zu wissen, was nicht gemessen wird. Eine Interpretation ist anspruchsvoll und braucht Erfahrung. Die Anwendung von Metriken muss im Einklang mit der gewählten Projektmethode sein. Sollen Metriken zur Verfügung stehen, muss dies von Anfang an geplant werden. © CREALOGIX 2008 Monday, March 27, 2017