090610 vortrag projekt_governance_tfs

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

Inhalt

2Wednesday, June 10, 2009© CREALOGIX 2008

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

Metriken

3Wednesday, June 10, 2009© CREALOGIX 2008

z.B. Übrigbleibende Arbeit

(Ramaining Work Chart,

Burndown Chart)

z.B. Projektgeschwindigkeit

(Project Velocity)

z.B. Qualitätsindikatoren

(Quality Indicators)

Probleme wie beispielsweise• Falsche Schätzung• Ungenügende Tests• Umsetzungsschwierigkeiten

Charts werden interpretiert

Massnahmen wie beispielsweise• Neuplanung• Unterstützung

Manifestieren sich in Indikatoren (Metriken).

Was bringen Metriken: Veränderungen erfassen

4Wednesday, June 10, 2009© CREALOGIX 2008

Was bringen Metriken: Benchmarking

5Wednesday, June 10, 2009© CREALOGIX 2008

Was bringen Metriken: Anzahl Bugs im Industrievergleich

6Wednesday, June 10, 2009© CREALOGIX 2008

10 100 1000

1

10

100

1000

1

10

100

1000

1000010000

Projekt 1

Projekt 2

Projekt 3

Quelle: Michael Mah, Agile Conference 2008

Was möchte man messen?

7Wednesday, June 10, 2009© CREALOGIX 2008

Produktqualität

Prozessqualität

Projektfortschritt

Produktqualität

Kundenzufriedenheit

Anzahl Kundenprobleme

Anzahl Fehler

Fehlerdichte (Fehler / Anzahl Codezeilen)

Codequalität

8Wednesday, June 10, 2009© CREALOGIX 2008

Kundenzufriedenheit

Kundenprobleme

Fehler

Codequalität

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

9Wednesday, June 10, 2009© CREALOGIX 2008

Projektfortschritt

Aufgaben-Abarbeitungsgeschwindigkeit

Risikoanteil

Anforderungsabdeckungsgrad

Testabdeckungsgrad / Fehleranteil

10Wednesday, June 10, 2009© CREALOGIX 2008

Wo entstehen Messdaten

11Wednesday, June 10, 2009© CREALOGIX 2008

„Ausführbare Features“

Zeit

Agile ProjekteRein phasenbasierte Projekte

Definieren Implementieren

Testen

Wo entstehen Messdaten

12Wednesday, June 10, 2009© CREALOGIX 2008

Projekt

Szenarien, QoSGrobe AufwandschätzungZeitplan

TestfälleRealisierter Aufwand

Erreichtes Datum

IterationStatus SzenarienStatus QoSTestergebnisseProjektgeschwindigkeit

Build

Story

SzenarienQoS

Velocity

Code AnalyseReview ErgebnisseCode CoverageTestergebnisse

Code und Architektur Richtlinien

Testrichtlinien

StatusBenötigte ZeitEnddatum

DauerAbhängigkeiten

ZeitraumRessourcen

Metriken mit Team System

13Wednesday, June 10, 2009© CREALOGIX 2008

Versions

verwaltungWork items TestsBuilds

Data Warehouse

TFS Reports Excel Sharepoint

Überblick über Metriken

14Wednesday, June 10, 2009© CREALOGIX 2008

Übrigbleibende Arbeit Ungeplante Arbeit Projektgeschwindigkeit

Anzahl Fehler Qualitätsindikatoren Risikogehalt

Gesundes ProjektÜbrigbleibende Arbeit

15Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit unterschätzem AufwandÜbrigbleibende Szenarien

16Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes ProjektRisikoverlauf

17Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit mangelnder RisikostrategieRisikoanteil

18Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes ProjektUngeplante Arbeit

19Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit unterschätzem AufwandUrsache: Ändernde Anforderungen

20Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit unterschätzem AufwandUrsache: Architekturprobleme

21Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes ProjektProjektgeschwindigkeit

22Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes ProjektFehlerrate

23Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit unterschätzem AufwandUrsache: Architekturprobleme

24Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes Projekt:Bug Reactivation

25Wednesday, June 10, 2009© CREALOGIX 2008

Ineffizente Fehlerbehebung

26Wednesday, June 10, 2009© CREALOGIX 2008

Gesundes ProjektQualitätsindikatoren

27Wednesday, June 10, 2009© CREALOGIX 2008

Projekt mit unterschätzem AufwandUrsache: Architekturprobleme

28Wednesday, June 10, 2009© CREALOGIX 2008

QualitätsproblemeUnpassende Tests

29Wednesday, June 10, 2009© CREALOGIX 2008

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)

30Wednesday, June 10, 2009© CREALOGIX 2008

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

31Wednesday, June 10, 2009© CREALOGIX 2008

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

32Wednesday, June 10, 2009© CREALOGIX 2008

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.

33Wednesday, June 10, 2009© CREALOGIX 2008