090610 vortrag projekt_governance_tfs
-
Upload
tonisteimle -
Category
Technology
-
view
788 -
download
1
Transcript of 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