Review Theorie und Praxis und warum es trotzdem schief geht.

Ich habe mal wieder meine alten Aufzeichnungen überfolgen und dabei folgendes Mindmap im Bereich der Prüf-/Testarten gesichtet. ;-) Dieses hat jetzt schon mind. 5 Jahre auf den Buckel.

Interessant an dem Thema ist der Unterschied von Theorie und Praxis. Im Bereich der statischen Prüfverfahren konnte ich so wieder einiges lernen. ;-)

Im letzten Randprojekt lief es folgendermassen ab:

Der Review wurde an eine Firma im Auftrag gegeben, die faktisch von Schulung, Training, Eigene Projekte, Unterstützung von Firmen alles macht. Sollte ich nochmal so eine Situation erleben, werde ich mich vorher genauer erkundigen, ob die Methoden religiös praktiziert werden.

Bleiben wir mal bei der Theorie. Die Herausforderung, das "Team" war interdisziplinär. Laut Lehrbuch würde man das Team aufbauen. Der Teambildungsprozess mit den typischen Phasen Forming, Storming, Norming und Performing wurde schon mal nicht durchlaufen. Zugegeben, man kann nicht immer nach Lehrbuch arbeiten, da häufig auch zu viel Ideologie im Spiel ist, aber die Grundprinzipien sollten in einem Projekt erkennbar sein.

Die Folgen davon:

Es gab keine intensiven Beziehungen zwischen den Projektbeteiligten. Versuche wurden mit der Begründung Single Point of Contact an den wichtigen Schnittstellen abgewürgt.
Ein Gemeinschaftsgeist für das Projekt bestand auch nicht. Die Folge hiervon, es kam weder ein Team noch eine Arbeitsgruppe zustande, eher ein Gegeneinander.

Dieser Punkt liegt eigentlich in der Verantwortung der Projektleitung und zeigt das Theorie und Praxis zwei Welten darstellen können.

Wie sah nun die Theorie beim Review aus:


Theorie	Praxis
Hauptziel eines Reviews ist die frühzeitige Erkennung von Fehlern.	Der Review wurde in der letzten Hermes-Phase angeordnet und die Anforderungsspezifikation diente nicht als primäre Grundlage.
Die Prüfung soll den Autor des Quellcodes unterstützen.	Die "Wir können alles Firma" stellte eine Liste mit Kritikpunkten bereit, die Anfangs mehrdeutige Aussagen und zum Ende keine Aussagen zur Verbesserung für den Autor bereitstellte. Lediglich 2 Hinweise waren wirklich brauchbar, da diese auf der Integrationsumgebung messbar waren.
Ergebnis ist eine Mängelliste mit dem entsprechenden Status.	Von 4 möglichen Vorgehensmodellen und Methoden, nutzte die "Wir können alles Firma" die Gelegenheit ihr Vorgehensmodell als den Quasi-Standard zu erklären und Werbung für ihre Methode zu machen. Natürlich wurde die Gelegenheit nicht ausgelassen, ein Grüppchen für sich zu gewinnen. Bei diesem Projekt war das auch nicht schwierig. Das eigentliche Ziel wird dabei ersichtlich und muss von mir nicht ausgeschrieben werden.

Abschliessend kann man sagen, das in jeden Witz auch ein wenig Wahrheit liegt:

Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles funktioniert und keiner weiss warum. In diesem Projekt waren Theorie und Praxis vereint, nichts funktionierte und keiner wusste warum. ;-)

Das Projekt hat aber auch ein Vorteil: Nachdem ich dieses "Chaos" erlebte, schätze ich die langjährigen Geschäftspartner noch mehr. ;-)