• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
090610 vortrag projekt_governance_tfs
 

090610 vortrag projekt_governance_tfs

on

  • 811 views

 

Statistics

Views

Total Views
811
Views on SlideShare
312
Embed Views
499

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 499

http://www.tonisteimle.com 499

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    090610 vortrag projekt_governance_tfs 090610 vortrag projekt_governance_tfs Presentation Transcript

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