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

Bewertung II – Projektabschluss

Benjamin WösterWitali Aswolinskiy

Shao Jianbo

Grobgliederung

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 Ziel1.2 Definition1.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überdeckungstestDieser Test erfasst alle Sprünge und Entscheidungen im Programm. Das entspricht mindestens einerAusführung aller Kanten, sprich aller Pfeile im Programmgraph.

PfadüberdeckungstestDer 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 Anweisungenpaarweise 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 atomarenBedingungen 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

Pfadüberdeckungstest

Anwendungsüberdeckungs-test

Zweigüberdeckungstest

Mehrfach-Bedingungsüberdeckungstest

Minimal Mehrfach-Bedingungsü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).

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

Ende der Codierung erfolgen Was? Modulspezifikation ModulkonstruktionWie? White Box und Black Box

1.3.3.2 Integrationstesten (Subsystemtesten)

Wann? SubsystemWas? Zusammenfügen der Module Interne Schnittstellen Zusammenspiel der internen Module Externe SchnittstellenWie?

1.3.3.3 Systemtesten

Wann?

Am Ende des Testprozesses

Was? & Wie?

Funktionstest

Recovery

Sicherheit

Last

1.3.3.4 Abnahmetesten

SystemanforderungenEinsatztauglichkeit

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 AbnahmetestenMerkmale

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 Firmen2.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 Projektportal1. Die Dokumentenverwaltungdas 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 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 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 ProjektabschlussProbleme:

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 nehmenalle unmittelbar Beteiligten an einermehrtägigen, moderierten Besprechung teil.

Die optimale Anzahl der Teilnehmer für eineProjektretrospektive wie sie im Folgendenbeschrieben 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


Zeit

Die Retrospektive findet eine bis drei Wochen nach

Projektende statt.

Die optimale Dauer beträgt drei Tage.

Weniger ist hier nicht mehr.


Raum

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


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.


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.

30 Min.

Erfolg definieren

Das Erreichte entdecken 30 - 60 Min.

Sicherheit schaffen

Offen über das Projekt sprechen können

1 - 2 Std.

2.3.5 Übungen - VergangenheitAusgrabungswettbewerb 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.

1 - 2 Std.

Projekt-Retrospektive beenden

Alles hat einmal ein Ende 10 - 30 Min.

2.3.5.1 GegenwartVorstellung 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

1) 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

2) Aufteilung in "artverwandte" Gruppen. Die Teilnehmer sollen sich zu denjenigen Teilnehmern gesellen, mit denen sie während des Projektes am meisten zusammengearbeitet haben.

3) 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:

1) Einige Tage vor der Projektretrospektive werden die Teilnehmer gebeten, nach Fundstücken aus ihrem Projekt zu suchen.

2) Die Fundstücke werden auf dem Boden aufgehäuft, von den jeweiligen Archäologen vorgestellt und durchdiskutiert

3) Abstimmung über die Fundstücke4) Ordnen der Fundstücke, Fotografieren5) Fundstücke einsammeln


Ausgrabungswettbewerb

Beispiele für Fundstücke:

Produktentwicklungspläne, Auslieferungspläne Spielzeugautos

Besonderes Beispiel für das wichtigste Fundstück: Dokumentationsentwicklerin


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.


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 VergangenheitStimmungsbarometer – Teil von Zeitrahmenleiste erstellen

1) Während der Übung "Zeitrahmenleiste erstellen" wird ein Streifen in der Mitte des Papierbandes freigelassen.

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


Passive Analogie – nur bei externen Retrospektiven

1) Film ansehen (bei dem es auf irgendeine Weise um Gruppenarbeit geht)

2) Ü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 ihrePräferenzen.

2.3.5.2 VergangenheitSitzung ohne Manager

Die Führungskräfte arbeiten in einem separaten Raum eine Botschaftfür die Mitarbeiter aus und die Mitarbeiter, begleitet vom Moderator dieBotschaft für die Führungskräfte.


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

1) Die Teilnehmer fassen die Einträge zu Themen zusammen.2) In <artfremden> Teams wird ein Thema untersucht. Während

der Analyse werden Zwischenberichte abgegeben und die Zwischenberichte anderer Teams gelesen.

3) Die Teams erläutern das Problem und sprechen eine Empfehlung an die Führungskräfte aus.

2.3.5.3 ZukunftWunder wahr werden lassen

Die unangenehmsten Probleme werden am Anfang einer Projektretrospektive vermieden.

Nachdem der Moderator das Problem des "letzten, unaussprechlichen Themas" angesprochen hat, diskutiert dasTeam 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

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!

Bring´s zu Papier / Teilübung: Erstellen zweier Plakate

2.3.5.3 Zukunft

Projekt-Retrospektive beenden

1) Der Moderator sammelt anonym die Erwartungen der Teilnehmer an die nächsten Projekte und lässt sie laut vorlesen.

2) Dann regt er die Teilnehmer an, die Erwartungen und Hoffnungen wahr werden lassen.

3) Die Projektretrospektive ist beendet.


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


Wunder wahr werden lassen


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 inhttp://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

Documents

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