Transcript Erfahrungen und Experimente im Software Engineering Post-Mortem-Analysen und Erfahrungs-Erhebung Florian Heyer Gliederung 1.Einführung 2.Post-Mortem-Analyse 1.Prozess 2.Methoden 3.Beurteilung 3.Varianten / Alternativen 4.Beispiele 5.Schluss 2 / 26

Erfahrungen und Experimente im
Software Engineering
Post-Mortem-Analysen und
Erfahrungs-Erhebung
Florian Heyer
Gliederung
1.Einführung
2.Post-Mortem-Analyse
1.Prozess
2.Methoden
3.Beurteilung
3.Varianten / Alternativen
4.Beispiele
5.Schluss
2 / 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
3 / 26
Erfahrungserhebung in Projekten
●
Beobachtend
–
●
Rückblickend
–
●
Fallstudien
Post-Mortem-Analysen (PMA)
Kontrollierend
–
Experimente
1. Einführung
4 / 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
5 / 26
Implizite Ziele
●
Positive sowie negative Erfahrungen des ProjektTeams
–
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
6 / 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
7 / 26
Rollen
●
Leiter / Moderator
–
evtl. unterstützt durch ein Team
–
sollte nicht aus dem Projektteam kommen
●
Projektmitarbeiter
●
Manager
●
Kundenvertreter
1. Einführung
8 / 26
Alternative Begriffe
●
Project review / audit / retrospective
●
lessons learned
●
post implementation review
●
post iteration review
●
debriefing
●
post partum
1. Einführung
9 / 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
10 / 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
11 / 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
12 / 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.1. Prozess
13 / 26
Methoden im Workshop: KJ
●
nach Kawakita, Jiro
●
Brainstorming
●
–
Sammlung
unstrukturierter
Informationen
–
Kreativität
Erweiterungen:
Verschachtelung,
Beziehungen
2.2. Methoden
14 / 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
15 / 26
Methoden im Workshop: Weitere
●
Interviews
●
Moderierte Gruppendiskussionen
●
Fragebögen
2.2. Methoden
16 / 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
17 / 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”
2.3. Beurteilung
18 / 26
Varianten, Alternativen
●
Allgemeiner PMA-Prozess ermöglicht Tailoring
–
●
Experience reports
–
●
●
Light-weight post-mortem reviews
werden vom Projektleiter erstellt
Goal-Question-Metric (GQM)
Light-weight documentation of experiences
(LID)
3. Varianten / Alternativen
19 / 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
20 / 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
21 / 26
Alternative: LIDs
Inhalt einer LID
(Abbildung aus [9])
Gesamtdokument:
unter 10 Seiten
(ohne Templates)
3. Varianten / Alternativen
22 / 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
23 / 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
24 / 26
Beispiel 2: Spielehersteller
●
Spielehersteller nutzen konsequent PMA
●
Interessante Themen
●
Einsichten in die Prozesse solcher Projekte
●
Beispiel: http://www.gamasutra.com/
4. Beispiele
25 / 26
Zusammenfassung
●
●
Erfolgreiche Unternehmen lernen aus
–
Fehlern
–
Erfolgen
Dazu verwenden sie u.a. Post-MortemAnalysen
5. Schluss
26 / 26
Quellen
1. 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. 129141, 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.
5. Schluss
27 / 26