Erfahrungen und Experimente im Software Engineering

Post-Mortem-Analysen und Erfahrungs-Erhebung

Florian Heyer

2 / 26

Gliederung

1.Einführung

2.Post-Mortem-Analyse

1.Prozess

2.Methoden

3.Beurteilung

3.Varianten / Alternativen

4.Beispiele

5.Schluss

1. Einführung 3 / 26

Einordnung

● bisherige Vorträge: Wissen & Erfahrung speichern, verwalten, zugänglich machen, daraus lernen

● Woher bekommen wir Erfahrung?– Erfahrungsschatz der Mitarbeiter– Schatz heben ➔ Erfahrungserhebung

● Genauer: Erfahrungserhebung in Projekten

1. Einführung 4 / 26

Erfahrungserhebung in Projekten

● Beobachtend– Fallstudien

● Rückblickend– Post-Mortem-Analysen (PMA)

● Kontrollierend– Experimente

1. Einführung 5 / 26

Grundlagen

● Wann? Meilenstein oder Projektende erreicht● Wer? Erfahrener Leiter von PMAen● Mit wem? Mitglieder des Projektteams, soviele

wie nötig und möglich● Wie? Prozesse und Methoden werden im

Vortrag vorgestellt● Warum?

➔ Implizite und explizite Ziele!

1. Einführung 6 / 26

Implizite Ziele

● Positive sowie negative Erfahrungen des Projekt-Teams

– ermitteln und verstehen– verarbeiten und dokumentieren

● Analyse des Projektverlaufs (wieso geschah es so?)● Anregung von Veränderungen

– implizites Wissen ➔ explizites Wissen– Lernen des Individuums ➔ Lernen der Organisation– Prozessverbesserung

1. Einführung 7 / 26

Explizite Ziele

● Festlegung eines bestimmten Ziels für eine PMA

● “Fokussierung” der PMA● Beispiele:

– Kostensenkung durch bessere Aufwandsschätzungen

– Verbesserung der Kommunikation im Team

1. Einführung 8 / 26

Rollen

● Leiter / Moderator– evtl. unterstützt durch ein Team– sollte nicht aus dem Projektteam kommen

● Projektmitarbeiter● Manager● Kundenvertreter

1. Einführung 9 / 26

Alternative Begriffe

● Project review / audit / retrospective● lessons learned● post implementation review● post iteration review● debriefing● post partum

2.1. Prozess 10 / 26

Allgemeiner Prozess für eine PMA

● Aufteilung in 5 Schritte

1)Rahmenbedingungen

2)Objektive (Kosten, Zeitplan, Qualität) und subjektive Daten

3)Analyse des Projekts unter Berücksichtigung von 1)

4)Priorisierung, Auswahl

5)Erstellung und Veröffentlichung eines Reports

2.1. Prozess 11 / 26

Verschiedene Typen von PMA

● Abhängig von der Projektgrösse● Grobe Klassifikation der Projektgröße

– small: 1-2 Mitarbeiter, bis zu 6 PM– medium: 5-30 Mitarbeiter– average: 30-150 Mitarbeiter– large: darüber hinaus

2.1. Prozess 12 / 26

PMA für small/medium

● 3 Phasen zur Auswertung kleinerer Projekte

1)Vorbereitung

2)Workshop zur Projektgeschichte

1)Daten sammeln

2)Analyse

3)Ergebnisse als Report veröffentlichen (5-15 Seiten)

● Dauer: 1-5 Tage

2.1. Prozess 13 / 26

PMA für average/large

● 5 Phasen zur Auswertung großer Projekte

1)Umfrage zum Projekt durchführen

2)Objektive Daten sammeln zu Metriken

3)Auswertungstreffen

4)Workshop zur Projektgeschichte

5)Ergebnisse als Report veröffentlichen (10 - 100+ Seiten)

● Dauer: bis zu 6 Monaten

2.2. Methoden 14 / 26

Methoden im Workshop: KJ

● nach Kawakita, Jiro● Brainstorming

– Sammlung unstrukturierter Informationen

– Kreativität● Erweiterungen:

Verschachtelung, Beziehungen

2.2. Methoden 15 / 26

Methoden im Workshop: RCA

● Root Cause Analysis● Nach Ishikawa, Kaoru

(1943)● Ishikawa, fishbone oder

cause-effect diagram● Gezielte Suche nach

Gründen für eine Auswirkung

● Strukturierung der Gründe● Analyse der Ergebnisse

aus KJ-Sitzungen

2.2. Methoden 16 / 26

Methoden im Workshop: Weitere

● Interviews● Moderierte Gruppendiskussionen● Fragebögen

2.3. Beurteilung 17 / 26

Vorteile

● Einfache Technik, leicht zu erlernen● lose Struktur, erlaubt Anpassung an eigene

Bedürfnisse● Mitarbeit aller Projektmitglieder wird angestrebt

(TQM)● führt schnell zu Verbesserungen● benötigt keine Vorbereitung der Teilnehmer

2.3. Beurteilung 18 / 26

Schwierigkeiten

● keine Zeit für den “Blick zurück”● Ergebnisse abhängig von Erfahrung des Leiters● interne Konflikte● rollenspezifische Verhaltensweisen im

Workshop● Projekt / Meilenstein nicht abgeschlossen● Mitarbeiter erinnern sich selektiv● “alle an einen Tisch bekommen”

3. Varianten / Alternativen 19 / 26

Varianten, Alternativen

● Allgemeiner PMA-Prozess ermöglicht Tailoring– Light-weight post-mortem reviews

● Experience reports– werden vom Projektleiter erstellt

● Goal-Question-Metric (GQM)● Light-weight documentation of experiences

(LID)

3. Varianten / Alternativen 20 / 26

Alternative: LIDs

● Ziel: Minimierung des Aufwands für systematisches Lernen aus Erfahrung

● Ersatz für aufwändigere Methoden● Aufwand ca. 2 PT● Verwendbar für signifikante Projektaktivitäten

3. Varianten / Alternativen 21 / 26

Alternative: LIDs

● Erfahrungserhebung durch Befragung und die Sammlung von verwendeten Dokumenten

● Verarbeitung zu einer “Geschichte” mit Links zu den gesammelten Dokumenten

● 2. Bedeutung:– “Deckel” auf einem Speichertopf für Dokumente

● Geschichte illustriert ein Beispiel zu einer “best practise”

3. Varianten / Alternativen 22 / 26

Alternative: LIDs

Inhalt einer LID (Abbildung aus [9])

Gesamtdokument: unter 10 Seiten (ohne Templates)

4. Beispiele 23 / 26

Beispiel 1: Studentische Projekte

● Nachbetrachtung von Softwareprojekten in Gruppen von 4-5 Studenten in einem Semester

● Verwendung einer Light-weight PMA zur Erfahrungserhebung in den Teams

● Zeitaufwand pro Team: 3 Stunden

4. Beispiele 24 / 26

Beispiel 1: Studentische Projekte

● Ergebnis: Erfahrungen zu den Aspekten– Aufgabenstellung– Verwendete Methoden und Prozesse– Softwareumgebung (Simulation)– Kommunikation im Team

● Verbesserung der Aspekte im nächsten Semester!

4. Beispiele 25 / 26

Beispiel 2: Spielehersteller

● Spielehersteller nutzen konsequent PMA● Interessante Themen● Einsichten in die Prozesse solcher Projekte● Beispiel: http://www.gamasutra.com/

5. Schluss 26 / 26

Zusammenfassung

● Erfolgreiche Unternehmen lernen aus– Fehlern– Erfolgen

● Dazu verwenden sie u.a. Post-Mortem-Analysen

5. Schluss 27 / 26

Quellen1. Torgeir Dingsøyr, Tor Stålhane and Nils Brede Moe: A practical guide to Lightweight Post Mortem

Reviews. University of Oslo, 2003.2. Myllyaho, M., Salo, O., Kääriäinen, J., Hyysalo, J. & Koskela, J. (2004). A Review of Small and Large

Post-Mortem Analysis Methods. ICSSEA 2004.3. Tor Stålhane, Torgeir Dingsøyr, Geir Kjetil Hanssen, and Nils Brede Moe: Post Mortem – An

Assessment of Two Approaches; In Reidar Conradi and Alf Inge Wang (Eds.). Empirical Methods and Studies in Software Engineering: Experiences from ESERNET, LNCS 2765. Springer Verlag, pp. 129-141, 2003.

4. Torgeir Dingsøyr, Nils Brede Moe, and Øystein Nytrø. Augmenting Experience Reports with Lightweight Postmortem Reviews. PROFES2001, Kaiserslautern, Germany, 10–13 September 2001.

5. Andreas Birk, Torgeir Dingsøyr, and Tor Stålhane: Postmortem: Never leave a project without it; IEEE Software, Special Issue on Knowledge Management in Software Engineering, pp. 43-45, May-June 2002.

6. Alf Inge Wang, Tor Stålhane. "Using Post Mortem Analysis to Evaluate Software Architecture Student Projects", cseet, pp. 43-50, 18th Conference on Software Engineering Education & Training (CSEET'05), 2005.

7. Bonnie Collier, Tom DeMarco, and Peter Fearey: A Defined Process for Project Post Mortem Review; IEEE Software, pp. 65-72, July 1996.

8. Straker, David. A Toolbook for Quality Improvement and Problem Solving, Prentice Hall International (UK) Limited, 1995.

9. Kurt Schneider, "LIDs: A Light-Weight Approach to Experience Elicitation and Reuse", presented at Second International Conference on Product Focused Software Process Improvement, PROFES 2000, Oulu, Finland, 2000.

10. A.J. Nolan, “Learning from Success,” IEEE Software, vol. 16 no. 1, Jan./Feb. 1999, pp. 97–105.11. Norman L. Kerth: Project Retrospectives: A Handbook for Team Reviews; Dorset House Publishing,

2001.