Erfahrungen und Experimente im Software Engineering

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

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

3. 1. Einführung 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

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

5. 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!

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

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

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

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

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

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

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

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

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

15. 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. 2.2. Methoden Methoden im Workshop: Weitere • Interviews • Moderierte Gruppendiskussionen • Fragebögen

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

18. 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”

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

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

21. 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”

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

23. 4. Beispiele 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

24. 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!

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

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

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