Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht kontrollieren. Application Lifecycle Management sichert Produktivität.

Präsentation zum Thema: "Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht kontrollieren. Application Lifecycle Management sichert Produktivität."—  Präsentation transkript:

1 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

2 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

3 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

4 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

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

6 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

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

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

9 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

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

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

12 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

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

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

15 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

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

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

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

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

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

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

22 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

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

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

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

26 Ineffizente Fehlerbehebung
© CREALOGIX 2008 Monday, March 27, 2017

27 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

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

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

30 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

31 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

32 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

33 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