Wie in einem vorigen Blog-Eintrag geschrieben, kann teilweise nicht mit sofort mit dem gesamten Team gestartet werden.
Um zur Ziel-Anwendung zu kommen, sind selbst in agilen Projekten aus meiner Sicht 3 Phasen in der Ziel-Anwendungs-Reife notwendig.
Initialer Aufbau Ende zu Ende
Zuerst muss das System überhaupt installiert werden.
Wird mit einer Standard-Software gearbeitet, kann nun ein grundlegender Ende-zu-Ende Prozess anhand von Use Cases oder sogar schon vorhandenen Test Cases durchgespielt werden. Hier kann also schnell mit den Projektteam und dem Fachbereich gestartet werden.
Ist es ein Entwicklungsprojekt, kann diese Zeit viel länger sein und das System muss erst grundlegend aufgebaut werden, bevor die ersten Test Cases überhaupt im System möglich sind. Hier muss also eine Zeit der Entwicklung vorgelagert geplant werden, bevor der Fachbereich im Projekt in der Durchführungs-Phase einsteigt.
Diese Phase ist abgeschlossen, wenn ein Ende Zu Ende Durchlauf mit ganz einfachen Anforderungen und teilweise noch nicht mit allen Detail-Funktionen und flüssiger Arbeitsweise, sowie Schnittstellen vorhanden ist.
Kontinuierliche Detaillierung
Ist das System grundsätzlich verfügbar und kann es vom Fachbereich angewendet werden, muss nun die Anforderungs-Liste aus der Phase „Übersetzung von Grob nach Fein“ umgesetzt werden. Hier können schon Optimierungen enthalten sein, aber der Fokus liegt auf der Umsetzung der definierten Anforderungen.
In der Agilen Vorgehensweise wird oft vom MVP (Minimum Viable Product), also eine Lösung der Anforderungen, die Funktionsfähig ist gesprochen, dass am Ende eines jeden Sprints etwas Funktionierendes herauskommt.
Da oft Funktionalität in einem Kontext von Abhängigkeiten zu vorgelagerten und eventuell nur eine Grundlage für eine Folge -Funktionalität ist, sollte wie im Wasserfall schon der Prozess im Vordergrund stehen und sich daran bei der Umsetzung orientiert werden. Heisst bei der Detaillierung fängt es schon am Anfang der Prozesskette an, und wenn diese umgesetzt ist, kann mit der nächsten, die auf den vorigen beruht weitergearbeitet werden.
Das ist etwas Wasserfall-Gedanke, aber in größeren Projekten gibt es einfach Abhängigkeiten, die, wenn im Folgeschritt noch nicht vorhanden, Mehraufwand bei der Generierung von Daten und Mühe beim Verständnis der Tests nach sich führt.
Somit sollte in diese Phase zwar schon Ende-zu-Ende der Prozess betrachtete und entwickelt und getestet werden, aber nie in der Mitte des Prozesses anfangen, oder wenn in der Mitte des Prozesses etwas fehlt, soweit zurück im Prozess in die Umsetzung zurückgehen, und hierauf den Fokus legen.
Optimierungen sind schon ein Teil dieser Phase, aber nur, wenn sie zwingend notwendig für den Grund-Prozess sind – Ziel ist es, zur Halbzeit der Umsetzungs-Phase alle Prozesse grundsätzlich im System nutzen zu können um Sicherheit zu haben, dass das System grundsätzlich funktioniert.
Viele Projekte setzen bis zum Ende der Umsetzungs-Phase Grundfunktionalitäten um, weil Prioritäten von Anforderungen nicht richtig gesetzt werden, und Komfort-Funktionen realisiert werden, bevor die Grundfunktionalität steht. Das ist aus meiner Sicht eins der grössten Projekt-Risiken.
Optimierung
Ist die Grundfunktionalität gegeben, und eine Lange Liste an Optimierungen durch den Fachbereich oder die Entwicklung identifiziert, kann nun ab der Halbzeit der Umsetzungs-Phase mit den Verschönerungen und Vereinfachungen und Automatisierungen begonnen werden.
Dieser Teil der Umsetzungs-Phase wird viel zu oft zu kurz geplant, oder durch Verzögerungen im Projekt bei der Umsetzung von Anforderungen verkürzt. Das ist aus meiner Sicht ebenso eins der grössten Projekt-Risiken.