Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Erfahrungen und Experimente im Software Engineering Post-Mortem-Analysen und Erfahrungs-Erhebung Florian Heyer."—  Präsentation transkript:

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

2 2 / 26 Gliederung 1.Einführung 2.Post-Mortem-Analyse 1.Prozess 2.Methoden 3.Beurteilung 3.Varianten / Alternativen 4.Beispiele 5.Schluss

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

4 1. Einführung4 / 26 Erfahrungserhebung in Projekten Beobachtend – Fallstudien Rückblickend – Post-Mortem-Analysen (PMA) Kontrollierend – Experimente

5 1. Einführung5 / 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!

6 1. Einführung6 / 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

7 1. Einführung7 / 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

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

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

10 2.1. Prozess10 / 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

11 2.1. Prozess11 / 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: Mitarbeiter – large: darüber hinaus

12 2.1. Prozess12 / 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

13 2.1. Prozess13 / 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 ( Seiten) Dauer: bis zu 6 Monaten

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

15 2.2. Methoden15 / 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

16 2.2. Methoden16 / 26 Methoden im Workshop: Weitere Interviews Moderierte Gruppendiskussionen Fragebögen

17 2.3. Beurteilung17 / 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

18 2.3. Beurteilung18 / 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

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

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

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

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

23 4. Beispiele23 / 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

24 4. Beispiele24 / 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!

25 4. Beispiele25 / 26 Beispiel 2: Spielehersteller Spielehersteller nutzen konsequent PMA Interessante Themen Einsichten in die Prozesse solcher Projekte Beispiel:

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

27 5. Schluss27 / 26 Quellen 1.Torgeir Dingsøyr, Tor Stålhane and Nils Brede Moe: A practical guide to Lightweight Post Mortem Reviews. University of Oslo, Myllyaho, M., Salo, O., Kääriäinen, J., Hyysalo, J. & Koskela, J. (2004). A Review of Small and Large Post-Mortem Analysis Methods. ICSSEA 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 , Torgeir Dingsøyr, Nils Brede Moe, and Øystein Nytrø. Augmenting Experience Reports with Lightweight Postmortem Reviews. PROFES2001, Kaiserslautern, Germany, 10–13 September 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 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), Bonnie Collier, Tom DeMarco, and Peter Fearey: A Defined Process for Project Post Mortem Review; IEEE Software, pp , July Straker, David. A Toolbook for Quality Improvement and Problem Solving, Prentice Hall International (UK) Limited, 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, A.J. Nolan, Learning from Success, IEEE Software, vol. 16 no. 1, Jan./Feb. 1999, pp. 97– Norman L. Kerth: Project Retrospectives: A Handbook for Team Reviews; Dorset House Publishing, 2001.


Herunterladen ppt "Erfahrungen und Experimente im Software Engineering Post-Mortem-Analysen und Erfahrungs-Erhebung Florian Heyer."

Ähnliche Präsentationen


Google-Anzeigen