Erfahrungen und Experimente im Software Engineering

Präsentation zum Thema: "Erfahrungen und Experimente im Software Engineering"—  Präsentation transkript:

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

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

3 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 Erfahrungserhebung in Projekten
Beobachtend Fallstudien Rückblickend Post-Mortem-Analysen (PMA) Kontrollierend Experimente 1. Einführung

5 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 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 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 Rollen Leiter / Moderator Projektmitarbeiter Manager Kundenvertreter
evtl. unterstützt durch ein Team sollte nicht aus dem Projektteam kommen Projektmitarbeiter Manager Kundenvertreter 1. Einführung

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

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 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: Mitarbeiter large: darüber hinaus 2.1. Prozess

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

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

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

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

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

23 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 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 Beispiel 2: Spielehersteller
Spielehersteller nutzen konsequent PMA Interessante Themen Einsichten in die Prozesse solcher Projekte Beispiel: 4. Beispiele

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

27 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 Springer Verlag, pp , 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 , May-June 2002. Alf Inge Wang, Tor Stålhane. "Using Post Mortem Analysis to Evaluate Software Architecture Student Projects", cseet, pp , 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 , 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