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

 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 Wednesday, June 10, 2009 2

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

Manifestieren sich in Indikatoren (Metriken).

z.B. Übrigbleibende Arbeit z.B. Projektgeschwindigkeit z.B. Qualitätsindikatoren
(Ramaining Work Chart, (Project Velocity) (Quality Indicators)
Burndown Chart)
Charts werden interpretiert

Massnahmen wie beispielsweise
• Neuplanung
• Unterstützung

Was bringen Metriken: Veränderungen erfassen


Was bringen Metriken: Benchmarking


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

Was möchte man messen?

Produktqualität Projektfortschritt

Prozessqualität


Produktqualität

 Kundenzufriedenheit
 Anzahl Kundenprobleme
 Anzahl Fehler
 Fehlerdichte (Fehler / Anzahl Codezeilen)
 Codequalität
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


Projektfortschritt

 Aufgaben-Abarbeitungsgeschwindigkeit
 Risikoanteil
 Anforderungsabdeckungsgrad
 Testabdeckungsgrad / Fehleranteil


Wo entstehen Messdaten

Definieren Implementieren

„Ausführbare Features“

Testen

Agile Projekte
Rein phasenbasierte Projekte

Zeit


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

Metriken mit Team System

Versions
Work items Builds Tests
verwaltung

Data Warehouse

TFS Reports Excel Sharepoint


Überblick über Metriken

Übrigbleibende Arbeit Ungeplante Arbeit Projektgeschwindigkeit

Anzahl Fehler Qualitätsindikatoren Risikogehalt


Gesundes Projekt
Übrigbleibende Arbeit


Projekt mit unterschätzem Aufwand
Übrigbleibende Szenarien


Gesundes Projekt
Risikoverlauf


Projekt mit mangelnder Risikostrategie
Risikoanteil


Gesundes Projekt
Ungeplante Arbeit


Ursache: Ändernde Anforderungen


Ursache: Architekturprobleme


Gesundes Projekt
Projektgeschwindigkeit


Gesundes Projekt
Fehlerrate


Gesundes Projekt:
Bug Reactivation


Ineffizente Fehlerbehebung


Gesundes Projekt
Qualitätsindikatoren


Qualitätsprobleme
Unpassende Tests


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)


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


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


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.


090610 vortrag projekt_governance_tfs

Weitere ähnliche Inhalte

Ähnlich wie 090610 vortrag projekt_governance_tfs

090610 vortrag projekt_governance_tfs