Erfahrungen und Experimente im Software Engineering Post-Mortem-Analysen und Erfahrungs-Erhebung Florian Heyer

Gliederung Einführung Post-Mortem-Analyse Varianten / Alternativen Prozess Methoden Beurteilung Varianten / Alternativen Beispiele Schluss

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

Erfahrungserhebung in Projekten Beobachtend Fallstudien Rückblickend Post-Mortem-Analysen (PMA) Kontrollierend Experimente 1. Einführung

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

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

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

Rollen Leiter / Moderator Projektmitarbeiter Manager Kundenvertreter evtl. unterstützt durch ein Team sollte nicht aus dem Projektteam kommen Projektmitarbeiter Manager Kundenvertreter 1. Einführung

Alternative Begriffe Project review / audit / retrospective lessons learned post implementation review post iteration review debriefing post partum 1. Einführung

Allgemeiner Prozess für eine PMA Aufteilung in 5 Schritte Rahmenbedingungen Objektive (Kosten, Zeitplan, Qualität) und subjektive Daten Analyse des Projekts unter Berücksichtigung von 1) Priorisierung, Auswahl Erstellung und Veröffentlichung eines Reports 2.1. Prozess

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

PMA für small/medium 3 Phasen zur Auswertung kleinerer Projekte Vorbereitung Workshop zur Projektgeschichte Daten sammeln Analyse Ergebnisse als Report veröffentlichen (5-15 Seiten) Dauer: 1-5 Tage 2.1. Prozess

PMA für average/large 5 Phasen zur Auswertung großer Projekte Umfrage zum Projekt durchführen Objektive Daten sammeln zu Metriken Auswertungstreffen Workshop zur Projektgeschichte Ergebnisse als Report veröffentlichen (10 - 100+ Seiten) Dauer: bis zu 6 Monaten 2.1. Prozess

Methoden im Workshop: KJ nach Kawakita, Jiro Brainstorming Sammlung unstrukturierter Informationen Kreativität Erweiterungen: Verschachtelung, Beziehungen 2.2. Methoden

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

Methoden im Workshop: Weitere Interviews Moderierte Gruppendiskussionen Fragebögen 2.2. Methoden

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

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” 2.3. Beurteilung

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

3. Varianten / Alternativen 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

3. Varianten / Alternativen 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

3. Varianten / Alternativen Alternative: LIDs Inhalt einer LID (Abbildung aus [9]) Gesamtdokument: unter 10 Seiten (ohne Templates) 3. Varianten / Alternativen

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

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

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

Zusammenfassung Erfolgreiche Unternehmen lernen aus Fehlern Erfolgen Dazu verwenden sie u.a. Post-Mortem- Analysen 5. Schluss

Quellen Torgeir Dingsøyr, Tor Stålhane and Nils Brede Moe: A practical guide to Lightweight Post Mortem Reviews. University of Oslo, 2003. 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. 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. Torgeir Dingsøyr, Nils Brede Moe, and Øystein Nytrø. Augmenting Experience Reports with Lightweight Postmortem Reviews. PROFES2001, Kaiserslautern, Germany, 10–13 September 2001. 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. 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. Bonnie Collier, Tom DeMarco, and Peter Fearey: A Defined Process for Project Post Mortem Review; IEEE Software, pp. 65-72, July 1996. Straker, David. A Toolbook for Quality Improvement and Problem Solving, Prentice Hall International (UK) Limited, 1995. 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. A.J. Nolan, “Learning from Success,” IEEE Software, vol. 16 no. 1, Jan./Feb. 1999, pp. 97–105. Norman L. Kerth: Project Retrospectives: A Handbook for Team Reviews; Dorset House Publishing, 2001. 5. Schluss