Contenu connexe Similaire à 090610 vortrag projekt_governance_tfs Similaire à 090610 vortrag projekt_governance_tfs (20) 090610 vortrag projekt_governance_tfs1. 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. 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
3. 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
© CREALOGIX 2008 Wednesday, June 10, 2009 3
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 Wednesday, June 10, 2009 6
7. Was möchte man messen?
Produktqualität Projektfortschritt
Prozessqualität
© CREALOGIX 2008 Wednesday, June 10, 2009 7
8. Produktqualität
Kundenzufriedenheit
Anzahl Kundenprobleme
Anzahl Fehler
Fehlerdichte (Fehler / Anzahl Codezeilen)
Codequalität
Kundenzufriedenheit
Kundenprobleme
Fehler
Codequalität
© CREALOGIX 2008 Wednesday, June 10, 2009 8
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 Wednesday, June 10, 2009 9
10. Projektfortschritt
Aufgaben-Abarbeitungsgeschwindigkeit
Risikoanteil
Anforderungsabdeckungsgrad
Testabdeckungsgrad / Fehleranteil
© CREALOGIX 2008 Wednesday, June 10, 2009 10
11. Wo entstehen Messdaten
Definieren Implementieren
„Ausführbare Features“
Testen
Agile Projekte
Rein phasenbasierte Projekte
Zeit
© CREALOGIX 2008 Wednesday, June 10, 2009 11
12. 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
© CREALOGIX 2008 Wednesday, June 10, 2009 12
13. Metriken mit Team System
Versions
Work items Builds Tests
verwaltung
Data Warehouse
TFS Reports Excel Sharepoint
© CREALOGIX 2008 Wednesday, June 10, 2009 13
14. Überblick über Metriken
Übrigbleibende Arbeit Ungeplante Arbeit Projektgeschwindigkeit
Anzahl Fehler Qualitätsindikatoren Risikogehalt
© CREALOGIX 2008 Wednesday, June 10, 2009 14
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 Wednesday, June 10, 2009 30
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 Wednesday, June 10, 2009 31
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 Wednesday, June 10, 2009 32
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 Wednesday, June 10, 2009 33