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


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


Was bringen Metriken: Benchmarking


Was bringen Metriken: Anzahl Bugs im Industrievergleich


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?


Produktqualität

Prozessqualität

Projektfortschritt

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


„Ausführbare Features“

Zeit

Agile ProjekteRein phasenbasierte Projekte

Definieren Implementieren

Testen

Wo entstehen Messdaten


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


Versions

verwaltungWork items TestsBuilds

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 ProjektRisikoverlauf


Projekt mit mangelnder RisikostrategieRisikoanteil


Gesundes ProjektUngeplante Arbeit


Projekt mit unterschätzem AufwandUrsache: Ändernde Anforderungen


Projekt mit unterschätzem AufwandUrsache: Architekturprobleme


Gesundes ProjektProjektgeschwindigkeit


Gesundes ProjektFehlerrate


Gesundes Projekt:Bug Reactivation


Ineffizente Fehlerbehebung


Gesundes ProjektQualitätsindikatoren


QualitätsproblemeUnpassende 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

Technology

architekturprobleme

benchmarking crealogix

bug reactivation crealogix

bringen metriken

indikatoren metriken

mit fulltest achtung

unit tests

kannman nicht kontrollieren