Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht...

Erfolgreiche Projekt Governance dank

Metriken

Was man nicht messen kann, kann man nicht kontrollieren.Application Lifecycle Management sichert

Produktivität und Qualität11. Juni 2009, Swissôtel Zürich-Oerlikon

Toni Steimle

Inhalt

2Tuesday, April 11, 2023© 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. Projektgeschwindi

gkeit(Project Velocity)

z.B. Qualitätsindikator

en(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


KundenzufriedenheitKundenproblemeFehlerCodequalitä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


Versionsverwaltung

Work 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.


Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht...

Documents

Transcript of Erfolgreiche Projekt Governance dank Metriken Was man nicht messen kann, kann man nicht...