090610 vortrag projekt_governance_tfs

960 views
869 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
960
On SlideShare
0
From Embeds
0
Number of Embeds
512
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

090610 vortrag projekt_governance_tfs

  1. 1. Erfolgreiche ProjektGovernance dank MetrikenWas 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. 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. 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
  4. 4. Was bringen Metriken: Veränderungen erfassen© CREALOGIX 2008 Wednesday, June 10, 2009 4
  5. 5. Was bringen Metriken: Benchmarking© CREALOGIX 2008 Wednesday, June 10, 2009 5
  6. 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. 7. Was möchte man messen? Produktqualität Projektfortschritt Prozessqualität© CREALOGIX 2008 Wednesday, June 10, 2009 7
  8. 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. 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. 10. Projektfortschritt Aufgaben-Abarbeitungsgeschwindigkeit Risikoanteil Anforderungsabdeckungsgrad Testabdeckungsgrad / Fehleranteil© CREALOGIX 2008 Wednesday, June 10, 2009 10
  11. 11. Wo entstehen Messdaten Definieren Implementieren „Ausführbare Features“ Testen Agile Projekte Rein phasenbasierte Projekte Zeit© CREALOGIX 2008 Wednesday, June 10, 2009 11
  12. 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. 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. 14. Überblick über Metriken Übrigbleibende Arbeit Ungeplante Arbeit Projektgeschwindigkeit Anzahl Fehler Qualitätsindikatoren Risikogehalt© CREALOGIX 2008 Wednesday, June 10, 2009 14
  15. 15. Gesundes ProjektÜbrigbleibende Arbeit© CREALOGIX 2008 Wednesday, June 10, 2009 15
  16. 16. Projekt mit unterschätzem AufwandÜbrigbleibende Szenarien© CREALOGIX 2008 Wednesday, June 10, 2009 16
  17. 17. Gesundes ProjektRisikoverlauf© CREALOGIX 2008 Wednesday, June 10, 2009 17
  18. 18. Projekt mit mangelnder RisikostrategieRisikoanteil© CREALOGIX 2008 Wednesday, June 10, 2009 18
  19. 19. Gesundes ProjektUngeplante Arbeit© CREALOGIX 2008 Wednesday, June 10, 2009 19
  20. 20. Projekt mit unterschätzem AufwandUrsache: Ändernde Anforderungen© CREALOGIX 2008 Wednesday, June 10, 2009 20
  21. 21. Projekt mit unterschätzem AufwandUrsache: Architekturprobleme© CREALOGIX 2008 Wednesday, June 10, 2009 21
  22. 22. Gesundes ProjektProjektgeschwindigkeit© CREALOGIX 2008 Wednesday, June 10, 2009 22
  23. 23. Gesundes ProjektFehlerrate© CREALOGIX 2008 Wednesday, June 10, 2009 23
  24. 24. Projekt mit unterschätzem AufwandUrsache: Architekturprobleme© CREALOGIX 2008 Wednesday, June 10, 2009 24
  25. 25. Gesundes Projekt:Bug Reactivation© CREALOGIX 2008 Wednesday, June 10, 2009 25
  26. 26. Ineffizente Fehlerbehebung© CREALOGIX 2008 Wednesday, June 10, 2009 26
  27. 27. Gesundes ProjektQualitätsindikatoren© CREALOGIX 2008 Wednesday, June 10, 2009 27
  28. 28. Projekt mit unterschätzem AufwandUrsache: Architekturprobleme© CREALOGIX 2008 Wednesday, June 10, 2009 28
  29. 29. QualitätsproblemeUnpassende Tests© CREALOGIX 2008 Wednesday, June 10, 2009 29
  30. 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. 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. 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. 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

×