Bewertung II – Projektabschluss Benjamin Wöster Witali Aswolinskiy Shao Jianbo

Grobgliederung 1. Softwarebewertung 2. Unternehmensbewertung Einleitung: Bewertung, die Zweite; oder was passiert wenn das letzte Semikolon gesetzt ist? 1. Softwarebewertung 2. Unternehmensbewertung 3. Projektbewertung

Einleitung: Warum wird bewertet? Worauf bezieht sich eine Bewertung? Von wem wird Bewertet? Wann wird bewertet?

1. Software-Testen 1.1 Ziel 1.2 Definition 1.3 Testen Verfahren 1.3.1 White-box Testen 1.3.2 Black-box Testen 1.3.3 Testen im Softwareentwicklungsprozess 1.3.3.1 Modultesten 1.3..3.2 Integrationstesten 1.3.3.3 Systemtesten 1.3.3.4 Abnahme Testen

1. Softwarebewertung 1.1 Ziel Fehler finden und Feedback! 1.2 Definition Testen ist ein Prozess, bei dem die Ursache eines Fehlers lokalisiert, dessen Korrektur überlegt, die Folgen der Korrektur geprüft und die Korrektur durchgeführt wird.

1.3.1 White Box Code ist bekannt! Beim „White- Box Test“ steht dem Tester der gesamte Quellcode zur Verfügung.

Testen Methoden Zweigüberdeckungstest Dieser Test erfasst alle Sprünge und Entscheidungen im Programm. Das entspricht mindestens einer Ausführung aller Kanten, sprich aller Pfeile im Programmgraph. Pfadüberdeckungstest Der Pfadüberdeckungstest deckt alle Pfade zwischen Ausgangspunkt und Endpunkt ab. Das bedeutet, dass hier auch alle Schleifen beachtet werden. Zwei Pfade gelten als gleich, wenn die Anweisungen paarweise identisch und die Länge des Pfades gleich ist. Mehrfacher Bedingungsüberdeckungstest Bei dieser Testart werden alle Variationen aus den atomaren Bedingungen gebildet. Bei n atomaren Bedingungen ergibt das eine Testanzahl von 2n. Minimal mehrfacher Bedingungsüberdeckungstest Jede Bedingung (ob atomar oder nicht) muss mindestens einmal den Wahrheitswert true und einmal den Wert false annehmen.

1.3.1 White Box Mehrfach- Bedingungsüberdeckungstest Minimal Mehrfach- Pfadüberdeckungstest Auf dieser Abbildung ist leicht zu erkennen, welche Testmethoden welche Mächtigkeit aufweisen. Um mindestens das minimale Testkriterium zu erreichen, muss ein Testverfahren gewählt werden, das über dem Zweigüberdeckungstest liegt (bzw. den Zweigüberdeckungstest erhält). Zweigüberdeckungstest Anwendungsüberdeckungs- test

1.3.2 Black Box Code ist unbekannt! Beim „Black- Box“ Testen steht dem Tester nur die Spezifikation der Anwendung zur Verfügung.

1.3.3 Testen im Softwareentwicklungsprozess Aufgabe Aufteilung Modultesten Integrationstesten Systemtesten Abnahmetesten

1.3.3.1 Modultesten Wann? Normalweise soll Modultesten nach dem Was? Ende der Codierung erfolgen Was? Modulspezifikation Modulkonstruktion Wie? White Box und Black Box

1.3.3.2 Integrationstesten (Subsystemtesten) Wann? Subsystem Was? Zusammenfügen der Module Interne Schnittstellen Zusammenspiel der internen Module Externe Schnittstellen Wie?

1.3.3.3 Systemtesten Wann? Am Ende des Testprozesses Was? & Wie? Funktionstest Recovery Sicherheit Last

1.3.3.4 Abnahmetesten Systemanforderungen Einsatztauglichkeit Abnahmetesten ist ein Benutzer-Orientiertes Testen Konzentration auf die Anforderungen des Benutzers. Mitarbeit der Benutzer oder der Benutzervertreter. Test des Systems unter normalen Betriebsbedingungen (Hardware/Systemsoftware)

1.3.3.4 Abnahmetesten Merkmale Die vorhandene Version der Applikation soll für das Testen nicht benutzt werden, sondern die frisch compilierte Version, die von der Entwicklung - Gruppe gestellt wird. Der Testplan legt fest, was wann, wie viel und wie genau getestet werden soll.

2. Bewertungsmodelle für Firmen 2.1 Warum Bewertungsmodelle? 2.2 CMM 2.3 Bootstrap 2.4 SPiCE 2.5 Fazit

Grund Nach Abgabe des Pflichtenhefts kamen oft Angebote, die sich in ihrer Aufwandsschätzung um einen Faktor 10 voneinander unterschieden. Dies war nicht der Fall weil die geforderten Eigenschaften eines Projekts unzureichend definiert waren, sondern auf Grund unterschiedlicher Auffassung der Firmen was Qualität, Sicherheit und Laufzeit der Software anging. Benötigt wurde also eine Aussage darüber wie erfahren und qualifiziert Unternehmen in ???

2.2 CMM (Capability Maturity Model) 1986 vom SEI (Software Engineering Institute) im Auftrag vom amerikanischen Verteidigungsministerium entwickelt Beschreibt den typischen Werdegang einer Softwareorganisation Unterteilung in 5 Reifegrade Jeder Reifegrad (Maturity Level) Indikator für die Fähigkeit, Software mit der erforderlichen Qualität unter Einhaltung vorgegebener zeitlicher und finanzieller Rahmenbedingungen zu erstellen

Anwendung In ursprünglicher Form Katalog aus 100 Fragen (Ja/ Nein) Fragen thematisch gruppiert Jede Frage einer Reifegradstufe zugeordnet Jede Frage mit vermerk ob ein positives Ergebnis notwendig für das Erreichen der zugehörigen Stufe ist 1993 Überarbeitung: Identifikation der für die systematische Entwicklung von Software wesentlichen Prozesse und ihre Gruppierung in so genannte Schlüsselpraktiken (Key Practice Areas), die genau einer der 5 Reifegradstufen zugeordnet sind

Reifegrade

Bootstrap Setzt auf CMM auf, stützt sich aber auch auf die ISO 9000 Normenreihe Gliederung von Software-Prozessen in Organisation Methode Engineering support Produkt engineering Prozess engineering Technologie

Verbesserungen Fragenkatalog (140 Management, 115 Projekte) durch 4-Punkte-Skala zu beantworten Einzelne Fragen können ausgeschlossen werden Nicht der absolute Reifegrad des Unternehmens steht im Mittelpunkt, sondern der Grad der Beherrschung der einzelnen Prozesse

Der Bootstrap

Auswertung

Fazit Bewertungsmodelle werden immer stärker bei der Auswahl der geeigneten Firma für ein Projekt berücksichtigt. Die Modelle selbst befinden sich in ständiger Entwicklung, werden Komplexer und gehen immer mehr auf einzelne stärken/ schwächen der Firmen ein. Ein Leistungsprofil wird somit in Zukunft teil der Selbstdarstellung von Firmen sein. Der Erfolg befürwortet eine solche Vorgehensweise. Firmen, die sich auf hohen „Evolutionsstufen“ halten, sind im durchschnitt 20% eher in der Lage Projekte Terminnah abzuschließen.

1.Projektportale

„In einer Studie über ‚Aufwände im Projektmanagement‘ (Uni Frankfurt und UB Campana & Schott) wurden wichtige Ergebnisse zum Kommunikationsmanagement festgestellt. Hier wurden in 25 Unternehmen die Abstimmungs- und Kommunikationsprozesse bei Meetings, Telefonaten usw. untersucht. Der Aufwand für Kommunikation im Projekt liegt inzwischen bei mehr als fünfzig Prozent - so das Ergebnis der Studie.“ Quelle: http://www.mittelstand-spezial.de/Artikel/projektportal.html

Kommunikation ohne Projektportale Jeder Mitarbeiter hat eigene Vorstellungen über den „besten“ Kommunikationsweg Berichte und Informationen werden nicht wieder gefunden Die Suche nach Informationen kostet mehr Zeit als notwendig Mitarbeiter arbeiten zweigleisig und entwickeln die gleichen Dokumente nochmals Ein Mitarbeiter hat wichtige Daten auf seinem PC und andere haben nur schwer Zugriff, falls der Mitarbeiter ausfällt Die wichtigsten Daten und Ergebnisse befinden sich auf dem Notebook des Projektleiters

Was ein Projektportal leistet Einheitliche Kommunikation Zentrale Ablage für alle Dokumente Jeder Mitarbeiter hat Zugriff auf alle für ihn relevanten Daten Daten sind immer in der aktuellen Version verfügbar (Versionsverwaltung) Die Transparenz für das Projekt erhöht sich, da alle Mitarbeiter Zugriff auf das Portal haben.

Woraus besteht ein Projektportal Die Dokumentenverwaltung das Herz des Projekts speichert alle gemeinsam genutzten Materialien wie Statusberichte, Projektanträge, Verträge, etc. Versionsverwaltung Wer hat wann welches Dokument geändert Welchen Aufgaben wurde wann eine neue Priorität zugeordnet Wer hat den Zeitplan geändert Welchen Status besitzt die jeweilige Version eines Dokuments

2. Die Arbeitsplanung Aufgaben erstellen für Projektmitglieder Zuweisen von Prioritäten und Ressourcen an Aufgaben Setzen von Meilensteinen Kontrolle des Projektverlaufs anhand von GANTT-Diagrammen Aufgabenpool Individuelle Protokolle über die Arbeitszeit, die in einer Aufgabe stecken

3. Das Diskussionsforum 4. Die Ereignisberichte Konferenzsystem Diskussion von Ideen Vorschläge für Lösungen Allgemeine Kommentare 4. Die Ereignisberichte Feedbackmechanismus Information für alle Teammitglieder Optische Kennzeichnung von Änderungen an Dateien

5. Der Projektkalender 6. Der Privatbereich Sammelt sämtliche Termine Besprechungen Meilensteine Automatische Nachricht an betroffene Personen bei Änderungen oder neu angesetzten Einträgen 6. Der Privatbereich Für persönliche Dokumente Notizen Archivierung

Weitere Bestandteile: Durch modularen Aufbau beliebig erweiterbar Suchmaschine zur Volltextsuche System zur Steuerung der Zugriffsrechte Schnittstellen zu externen Systemen um z.B. direkt auf Daten von Kunden oder Mitarbeitern zugreifen zu können Automatisierte Dokumentation

2.2 Projektabschluss 2.2.1 Probleme beim Projektabschluss 2.2.2 Projektabschlusssitzung

2.2.1 Probleme beim Projektabschluss das "Wir"-Gefühl der Gruppe schwächt sich ab, da gegen Ende die Mitglieder ausscheiden. Projekte werden in die Länge gezogen, da die neuen Aufgaben unbekannt oder abschreckend sind. Teammitglieder verlassen kurz vor dem Abschluss das Projekt um neue Aufgaben zu übernehmen, und die zum Schluss anfallenden und langweilige Arbeiten wie Dokumentation nicht übernehmen zu müssen. Falls das Projekt weniger erfolgreich ist, wollen sie sich auch damit weniger identifizieren lassen.

2.2.1 Probleme beim Projektabschluss Lösungsansatz: - Das Projekt mit einer Veranstaltung bewusst beenden - Für die Mitarbeiter einen klaren Neubeginn setzen

2.2.2 Projektabschlusssitzung Analyse und Bewertung der Projektergebnisse Prozessanalyse und Bewertung Analyse der Konsequenzen auf Nachprojekte Sicherstellung der erworbenen Erfahrungen Verteilung der noch offenen Aufgaben

2.3 Projektretrospektive 2.3.1 Definition 2.3.2 Ziele 2.3.3 Raum, Zeit und Beteiligte 2.3.4 Phasen 2.3.5 Übungen 2.3.6 Eine Projektretrospektive 2.3.7 Fazit

2.3.1 Definition Nach dem Abschluss eines Projektes nehmen alle unmittelbar Beteiligten an einer mehrtägigen, moderierten Besprechung teil. Die optimale Anzahl der Teilnehmer für eine Projektretrospektive wie sie im Folgenden beschrieben wird, beträgt zwischen 9 und 35.

2.3.2 Ziele Warum sollte sie gehalten werden? Die Geschichte erzählen Wer aus einem Fehler nicht lernt, macht einen Zweiten Schaden am Team reparieren Sich am Erreichten erfreuen

2.3.3 Raum, Zeit und Beteiligte Die Retrospektive findet eine bis drei Wochen nach Projektende statt. Die optimale Dauer beträgt drei Tage. Weniger ist hier nicht mehr.

2.3.3 Raum, Zeit und Beteiligte A) Intern: vor Ort, z.B. auf Firmengelände - Kostengünstig und leicht zu erreichen B) Extern: Projektauswertung mit Übernachtungsmöglichkeit - Vollständiges Eintauchen in das Thema

2.3.3 Raum, Zeit und Beteiligte Moderator: Außenstehender neutral Kenntnisse und Erfahrungen im Bereich des Projektthemas. Hier: Softwareentwicklung. Mit Leuten umgehen können . Fähig sein, Konflikte aufzulösen und Schuldzuweisungen in konstruktive Informationen umzuwandeln. Fähig sein, die Stimmung im Team zu spüren.

2.3.3 Raum, Zeit und Beteiligte Teilnehmer Die Führungskräfte Die Softwareentwickler Wichtige Kunden und ebenfalls aus Bereichen: Dokumentierung Qualitätssicherung Kundendienst

2.3.4 Phasen Gegenwart: Der Anfang Die Teilnehmer bauen einer Vertrauensbasis zum Moderator auf sind überzeugt, dass der Prozess ein positives Ergebnis liefern wird sind empfänglich für Entdeckungen entwerfen Verhaltensrichtlinien, die während der gesamten Projektretrospektive gelten.

2.3.4 Phasen Vergangenheit: Die Geschichte Die Teilnehmer teilen ihre Geschichten über das Projekt und erfahren, wie umfangreich das Projekt wirklich war vergleichen den tatsächlichen und den geplanten Planverlauf und erkennen die Probleme beheben den Schaden, der in Beziehungen zu anderen Teammitgliedern entstanden ist wertschätzen, was sie während des Projektes geleistet und gelernt haben

2.3.4 Phasen Zukunft: Im Illuminator das nächste Projekt Die Teilnehmer finden Wege, um aus Erfahrungen aus dem abgeschlossenen Projekt zu lernen planen den Ablauf: probieren neue Methoden aus, gehen Kompromisse ein um die bestehenden Arbeitsabläufe zu ändern.

2.3.5 Übungen - Gegenwart Übung Zweck Dauer Vorstellung Workshop einleiten 30 Min. Ich bin zu beschäftigt Neugierde wecken, Überzeugen, dass eine Retrospektive kein Zeitverlust ist. Erfolg definieren Das Erreichte entdecken 30 - 60 Min. Sicherheit schaffen Offen über das Projekt sprechen können 1 - 2 Std.

2.3.5 Übungen - Vergangenheit Ausgrabungswettbewerb Sich an das Projekt erinnern, darüber nachdenken, Dokumente sammeln. 1 - 2 Std. Zeitrahmenleiste erstellen Die Teilnehmer überblicken das Gesamtprojekt 5 - 8 Std. Stimmungsbarometer Verständnis aufbauen 1-2 Std. Anerkennungen aussprechen "Gute Arbeit!" 1 Std. Passive Analogie Entspannung Parallele zum Projekt ziehen 2,5 Std. + 2 Std. Sitzung ohne Manager Meinung offen vertreten 2 - 3 Std. Schadensbehebung durch Spiel Der Schaden durch Stress wird allmählich behoben. 1Std.

2.3.5 Übungen - Zukunft Übung Zweck Dauer <Artfremde> Teams Lösungen für Probleme entwickeln. 5 - 6 Std. Wunder wahr werden lassen Emotionsgeladene Probleme angehen. 1 - 2 Std. Bring´s zu Papier Die Ergebnisse der Retrospektive festhalten, und katalogisieren. Projekt-Retrospektive beenden Alles hat einmal ein Ende 10 - 30 Min.

2.3.5.1 Gegenwart Vorstellung Gruppe willkommenheißen Ablauf besprechen Teilnehmer mit Sofortbildkameras ausstatten. Ich bin zu beschäftigt Überzeugen, dass eine Retrospektive kein Zeitverlust ist. Erfolg definieren Definition von Norman Kerth: "Ein erfolgreiches Projekt ist eines, von dem jeder sagt: Ich wünsche, ich könnte es noch einmal ganz genauso machen."

2.3.5.1 Gegenwart Sicherheit schaffen Die Grundregeln jeder Projektretrospektive: Jede Beteiligung einer Projektretrospektive ist freiwillig Keine Witze auf Kosten anderer Anonyme Abstimmung über das Sicherheitsgefühl. Die Stimmzettel werden auf einem Flipchart ausgewertet. Die Skala ist fünfteilig: Angefangen mit: 1:"Ich kann frei reden" bis 5:"Ich werde lediglich meinem Chef zulächeln„

2.3.5.1 Gegenwart Sicherheit schaffen Aufteilung in "artverwandte" Gruppen. Die Teilnehmer sollen sich zu denjenigen Teilnehmern gesellen, mit denen sie während des Projektes am meisten zusammengearbeitet haben. Die Gruppen diskutieren, voneinander getrennt, welche Grundregeln aufgestellt werden könnten, um die Atmosphäre sicherer zu gestalten.

2.3.5.1 Gegenwart Sicherheit schaffen Mögliche Grundregeln: Wir versuche, den anderen nicht zu unterbrechen Wir werten die Meinung der anderen weder als richtig noch als falsch, sondern einfach als Meinung. Wir hören uns alles an, was jemand zu sagen hat, bevor wir eine Antwort formulieren Wir entscheiden, bevor wir sprechen, ob das, was wir zu sagen haben, zum gegebenen Zeitpunkt wichtig genug ist. Letzte Regel: Die Grundregeln können nach jeder Pause ergänzt oder überarbeitet werden.

2.3.5.2 Vergangenheit Ausgrabungswettbewerb Verlauf: Einige Tage vor der Projektretrospektive werden die Teilnehmer gebeten, nach Fundstücken aus ihrem Projekt zu suchen. Die Fundstücke werden auf dem Boden aufgehäuft, von den jeweiligen Archäologen vorgestellt und durchdiskutiert Abstimmung über die Fundstücke Ordnen der Fundstücke, Fotografieren Fundstücke einsammeln

2.3.5.2 Vergangenheit Ausgrabungswettbewerb Beispiele für Fundstücke: Produktentwicklungspläne, Auslieferungspläne Spielzeugautos Besonderes Beispiel für das wichtigste Fundstück: Dokumentationsentwicklerin

2.3.5.2 Vergangenheit Zeitrahmenleiste erstellen Die Übung ist zweiteilig: A) Zeitrahmenleiste erstellen Verlauf: Eine Wand wird mit zwei Reihen Papier bedeckt, jeweils ein Meter breit und neun bis achtzehn Meter lang. Das Papier wird in sinnvolle Zeitabschnitte unterteilt. Jeder hält auf diesem Papier wichtige Ereignisse fest.

2.3.5.2 Vergangenheit Zeitrahmenleiste erstellen B) Darin nach Gold suchen Freiwillige Schriftführer notieren auf fünf Flipcharts: Was funktionierte gut und sollte nicht vergessen werden Was haben wir gelernt Was sollte beim nächsten Mal anders werden Über was denken wir noch immer nach Was wir noch eingehender besprechen müssen

2.3.5.2 Vergangenheit Stimmungsbarometer – Teil von Zeitrahmenleiste erstellen Während der Übung "Zeitrahmenleiste erstellen" wird ein Streifen in der Mitte des Papierbandes freigelassen. Die Teilnehmer gehen den Streifen entlang und zeichnen eine Linie. Oben : Ein Super Job Mitte: Ein Job Unten: Ein mieser Job Anerkennung aussprechen "Gute Arbeit!„ Jeder spricht eine Anerkennung für jemand anderen aus. Die Übung geht so lange bis jeder mindestens eine Würdigung erhalten hat. Die Anerkennung bildet die Grundlage für die Bestätigung des Selbstwertgefühls und die Bereitschaft, die Möglichkeit zu Veränderung in Betracht zu ziehen.

2.3.5.2 Vergangenheit Passive Analogie – nur bei externen Retrospektiven Film ansehen (bei dem es auf irgendeine Weise um Gruppenarbeit geht) Über Frage diskutieren: - Ähnliche Ereignisse? - Fehler der Protagonisten? - Taten der Protagonisten, die im Projekt gut gewesen wären - Mit wem identifizieren können? Die Teilnehmer erkennen ihren Temperamenttyp und ihre Präferenzen.

2.3.5.2 Vergangenheit Sitzung ohne Manager Die Führungskräfte arbeiten in einem separaten Raum eine Botschaft für die Mitarbeiter aus und die Mitarbeiter, begleitet vom Moderator die Botschaft für die Führungskräfte. Schadensbehebung durch Spiel A) Unstrukturierte Aktivitäten Reden Sie wenigstens 30 Minuten lang nicht über das Projekt B) Strukturierte Aktivitäten Billard, Tischtennis, Tennis, Poker. Diese Aktivitäten sollen von den Teilnehmern selbst gewählt und geplant werden.

2.3.5.3 Zukunft Artfremde Teams Mittel: Flipcharts "Über was denken wir noch immer nach" und "Was wir noch eingehender besprechen müssen", aus "Zeitrahmenleiste erstellen„. Die Teilnehmer fassen die Einträge zu Themen zusammen. In <artfremden> Teams wird ein Thema untersucht. Während der Analyse werden Zwischenberichte abgegeben und die Zwischenberichte anderer Teams gelesen. Die Teams erläutern das Problem und sprechen eine Empfehlung an die Führungskräfte aus.

2.3.5.3 Zukunft Wunder wahr werden lassen Die unangenehmsten Probleme werden am Anfang einer Projektretrospektive vermieden. Nachdem der Moderator das Problem des "letzten, unaussprechlichen Themas" angesprochen hat, diskutiert das Team darüber. Beispiel: "Zu viele Chefs haben zu wenige Softwareentwickler geführt. Das Ergebnis war ein mit Vorurteilen überfrachteter Streit auf verschiedenen Führungsebenen wegen der zu geringen und ausgepowerten Anzahl an Entwicklern."

2.3.5.3 Zukunft Bring´s zu Papier / Teilübung: Erstellen zweier Plakate Nie wieder! Lieber so! Ein System von der Größe eines Elefanten bauen! Bau eine Mücke – sehr klein, sehr effektiv, wird sofort bemerkt und hat ein kurzes Leben. Code schreiben, wenn wir nicht wissen, worum es geht. Liefere eine klitzekleine Version des angeforderten Systems in einem Bruchteil der vorgegebenen Zeit! Utopische Termine als Vorgaben akzeptieren. Entwickle deine eigenen Pläne und setze deine eigenen Ziele!

2.3.5.3 Zukunft Projekt-Retrospektive beenden Der Moderator sammelt anonym die Erwartungen der Teilnehmer an die nächsten Projekte und lässt sie laut vorlesen. Dann regt er die Teilnehmer an, die Erwartungen und Hoffnungen wahr werden lassen. Die Projektretrospektive ist beendet.

2.3.6 Eine Projektretrospektive Situation: Projektteam: 24 Mitglieder, 21 nehmen an der Retrospektive teil. Das Projekt wurde mich sechsmonatiger Verspätung, aber ohne schwerwiegende Fehler beendet. Während des Projektes wurde Code neugeschrieben, zwei Teilnehmer gingen in den vorzeitigen Ruhestand. Führungskräfte nervös, unsicher wegen ihrer Fähigkeiten Softwareentwickler zurückhaltend, erschöpft und auf die Führungskräfte sauer, weil dise sich zu Ende zu stark in ihr Gebiet eingemischt hätten. Projektleiter und wissenschaftliche Mitarbeiter im Konflikt, da diese sich geweigert hatten, bestimmte Komponenten zu entwickeln. Sie sahen dies als Verlust ihrer forscherischen Freiheit.

2.3.6 Eine Projektretrospektive Tag 1 Tag 2 Tag 3 Erfolg definieren Zeitrahmenleiste Teil 2 Artfremde Teams Sicherheit schaffen Ausgrabungswettbe-werb Zeitrahmenleiste erstellen Teil 1 Mittagspause Anerkennung aussprechen Sitzung ohne Manager Präsentation für die Führungskräfte Statt passive A.: Weingutbesuch Schadensbehebung durch Spiel Wunder wahr werden lassen

2.3.6 Eine Projektretrospektive Herausgearbeitete Vorschläge: Teams sollen Verantwortung dafür übernehmen, dass ihr Teil in die Projektarchitektur passt Mehr Analyse und Planung vor der Codephase Die beiden ebenbürtigen Teile: Forschung und Technik anerkennen Die gesamte Retrospektive findet sich in http://www.retrospectives.com/pages/Anatomy.html

2.3.7 Fazit Die beste und wahrscheinlich die einzige Möglichkeit aus einem abgeschlossenen Projekt zu lernen. In Deutschland kaum bekannt.

Danke für Eure Aufmerksamkeit