Agiler Projektansatz bewährt sich bei ungewisser Machbarkeit und hoher Komplexität

Unser letzter Blogeintrag zum Thema Lösungsansätze im Projektgeschäft thematisierte die Erstellung eines hybriden Szenarios als angepasste Strategie. Die klassischen DWH-Technologien in SAP HANA werden mithilfe des SAP HANA Smart Data Access (SDA) um Reporting-Tools in Echtzeit ergänzt, so dass auch anspruchsvolle Aufgaben agil bewältigt werden können.

In einem anderen Projekt waren zuletzt individuelle Anpassungen und benutzerdefinierte Implementierungen im großen Umfang notwendig, was mit einem klassischen Lösungsansatz kaum umsetzbar wäre. Die Standardmittel reichten nicht aus, die gewünschten Anforderungen an das Modell umzusetzen. Dazu kam die Frage, ob es überhaupt technisch machbar wäre. Dies alles war ausschlaggebend dafür, vom klassischen Wasserfall-Projektansatz wegzugehen und stattdessen einen agilen Projektansatz zu wählen. Damit spart man sich bei sehr hoher Komplexität eine langwierige Vorabanalyse, an deren Ende immer noch nicht klar wäre, ob alles machbar ist.

Schema des agilen Projektansatz

Erste Schritte

Zunächst bauten wir einen Prototyp mit eingeschränkter Funktionalität, um die generelle Machbarkeit zu belegen.

Das nächste Level

Nachdem sich der Prototyp bewährt hatte, haben wir ihn Schritt für Schritt erweitert. Dabei galt es jedes Mal aufs Neue abzuwägen, ob eine neue Anforderung in der angedachten Art und Weise umgesetzt werden sollte.

Reparieren oder Wegwerfen?

Mit der Zeit wurde es immer schwieriger neue Anforderungen in die existierende Umgebung einzufügen. Man sah sich mit dem aus dem Alltag bekannten Dilemma konfrontiert, ob man etwas Altes reparieren oder wegwerfen soll und wählte die bewährte Lösung „Recyceln“.
Im Redesign wurde das alte Modell in seine Bestandteile zerlegt und in einer neuen Struktur wiederverwendet

Wenn es am schönsten ist…

Zu guter Letzt war die Implementierung auf einem Stand, mit dem alle Anforderungen auf ansprechende Art und Weise abgebildet werden konnten. So konnten wir das Projekt abschließen und für zukünftige Änderungsanforderungen in die Obhut des Supports übergeben.

Eckpfeiler des Projektes

Die Basis für den Erfolg des Projektes war zum einen die Diskussionsbereitschaft des Kunden – denn es muss klar sein, dass das Resultat in einem solchen Fall manchmal von den ursprünglichen Anforderungen entsprechen kann. Zum anderen musste von Seiten der Entwickler auf eine vorausschauende Modellierung und Programmierung geachtet werden. Da zu Beginn des Projektes noch nicht alles ausdefiniert war, galt es sich nichts zu verbauen, um neue Anforderungen möglichst unkompliziert ergänzen zu können.
Genauso wichtig war eine saubere Anwendung der Methoden im Projektmanagement (Transparenz, Überprüfung, KISS-Prinzip, etc.), welche wir je nach Präferenz des Kunden beispielsweise auch nach SCRUM und Tool-unterstützt (JIRA o.ä.) umsetzen.