Agile darf keine Ausrede für fehlende Projektplanung sein!

Geschrieben von Marco Griep

Stellen Sie sich vor, sie bekommen einen Auftrag ein Fahrzeug zu entwickeln, dieses Fahrzeug soll Ihren Klienten von A nach B befördern. Ohne auch nur die Rahmenbedingungen zu kennen, fangen Sie an ein nach bestem Wissen und Gewissen ein Elektroauto zu entwickeln. Nachdem das Fahrgestell fertig und die Batterie eingebaut ist, kommt die Anforderung, dass das Fahrzeug sehr lange Strecken zurücklegen können muss. Somit bauen Sie den Antrieb und die Elektronik wieder raus und bauen einen Benzinmotor ein und Getriebe ein. Sie sind froh, dass Sie frühzeig das Problem beheben konnten und haben 60 % vom Weg bereits erledigt. Jetzt nur noch die Reifen montieren und dem Kunden eine Testfahrt ermöglichen. Plötzlich kommt die Anforderung, dass das Fahrzeug ja auch das Meer überqueren muss. Auf dem Wasser sind Reifen natürlich überflüssig und das Fahrgestell ist nicht wasserdicht. Alles wieder zurück auf Anfang, ein Amphibisches Fahrzeug muss her. Oder am besten doch gleich ein Flugzeug bauen? Was hier natürlich etwas überspitzt beschrieben wird, ist leider gar nicht so unrealistisch. Agil wird oft als Ausrede für fehlende Projektplanung bzw. Abstimmung mit den Rahmenbedingungen missbraucht. Das Problem ist in diesem Fall nicht die Softwareentwicklung, sondern das kein ein Software Architekt die Funktionalen und Nicht-funktionalen Anforderungen vorab bestimmt hat.

Was ist Agile Projektplanung?

Was ist agile Projektplanung oder agile Produktentwicklung überhaupt? Agil beschreibt einen Ansatz, flexibel auf wechselnde Anforderungen an Produkten reagieren zu können. Letztendlich wird dabei absichtlich auf das klassische Wasserfallmodell sowie Pflichtenhefte verzichtet und stattdessen flexibel auf die Anforderungen des Kunden im laufenden Projekt eingegangen.

Dieser Ansatz ist gut und in der Softwareentwicklung gängige Praxis. Das Problem dabei ist aber das der Kunde bzw. der Product Owner oft selbst nicht weiß was genau er eigentlich möchte. Somit wird gerade in Softwareprojekten häufig einfach nach besten Wissen und Gewissen losprogrammiert und hinterher stellt sich heraus das es ganz anders sein soll. Kleine Änderungen, Feature Requests agil im laufenden Projekt umzuprogrammieren ist dabei gar nicht das Problem. Wenn ich jedoch fundamentale Konzepte (Authentifizierungsmethoden von Verzeichnisdienst zu App Authentifizierung ändern, Cloud native Anwendung ja/nein, Wechsel des Datenbanksystems etc.) ständig über den Haufen geworden werden oder hinterher geändert werden müssen wird es umständlich, besonders wenn der Kunde bereits auf dem System arbeitet. Genau da kommen wir an die etwas „überspitze“ Geschichte aus der Einleitung zurück. Wenn kein grober Rahmen mit den fix definierten Kernanforderungen definiert ist, wird das Projekt zum Desaster und läuft Gefahr, dass das Budget ausgeht.

Die Rolle eines Software Architekten

Ein Softwarearchitekt plant und konstruiert die Software. Er macht sich Gedanken um Systemarchitektur, Services, Komponenten und hat die Aufgabe ein Konstrukt zu konzeptionieren das den Anforderungen, der Manpower, den Wissensstand des Teams und vor allem dem Budget für das Projekt entspricht. Je variabler die Anforderungen am Projekt sind, umso flexibler muss Softwarearchitektur das abfangen können. Nichtsdesto trotz muss vor der ersten Codezeile genaustens festgelegt werden, welche Eigenschaften die Software aufweisen muss.

Gerade in kleinen Entwicklungsteams und bei wenig Budget muss hier ein Kompromiss gefunden werden. Wer volle Flexibilität, Skalierbarkeit und haufenweise Feature-Toggles möchte, muss dies oft teuer bezahlen und die Entwicklung braucht hier auch Zeit und Manpower. Daher mein Appell an alle die ein „Grüne Wiese Projekt beginnen“. Plant zuerst die groben Rahmenbedingungen und legt diese auch Vertraglich fest. Alle anderen Änderungen können „agile“ bearbeitet werden.

Die unten aufgeführten Punkte sind meiner Meinung nach relevant und beziehen sich auf Softwareentwicklungsprojekte.

Wo soll die Software laufen? On-Premise, Cloud oder Hybrid?

Abhängig davon müssen Punkte der Netzwerktraffic und Bereitstellung / Update der Anwendung berücksichtigt werden. Läuft die Anwendung in der Cloud, gibt es Latenzen zwischen Client und Server. Auch die Bereitstellung der Anwendung und deren Updates läuft on-premise anders als bei Cloud-Installationen.

Soll die Anwendung Multimandatenfähig sein?

Vorab: Mehrere Mandanten in einem System zu haben finde ich problematisch. Stattdessen würde ich eher jedem Mandat eine Instanz bzw. Installation bereitstellen. Unabhängig von meiner Meinung kann es diese Anforderung geben und auch berechtigt sein.

Ist Skalierbarkeit wirklich notwendig?

Skalierbarkeit in einer Anwendung ist eine tolle Sache. Gerade bei SOA (Service orientierten Anwendungen) ist dies oft ohne weiteres möglich. Diese Architekturen haben jedoch Infrastrukturell eine höhere Komplexität, welche Ihr Team handeln können muss. Ebenso muss das Wissen vorhanden sein oder aufgebaut werden. Eine einfache monolithische Anwendung ist hier weitaus einfacher zu administrieren, aber schlechter zu skalieren. Überlegen Sie sich, ob Sie eher 1000 Anwender auf der Anwendung haben, oder 100.000 Anwender. Ein einfaches WordPress ist auch monolithisch und kann tausende Websitebesucher ohne Probleme abfangen. Ist es wirklich notwendig für eine Businessanwendung mit 150 Usern ein SOA oder sogar Microservice Architektur-Muster zu nutzen? Haben Sie einen Kunden oder mehrere? Brauchen Sie mehrere Instanzen der Anwendung oder ist die Anwendung so spezifisch das nur ein Kunde diese benutzt?

Wie wird Authentifizierung / Authorisierung realisiert?

Werden die Benutzer in der Datenbank der Applikation hinterlegt oder gibt es einen Verzeichnisdienst wie Active Directory oder OpenLDAP. Wenn beides möglich sein muss, sollte auch für beides ein Konzept vorliegen. Beim Verzeichnisdienst ergibt es Sinn über die Gruppenzugehörigkeit (Oder OU) die Berechtigungen in der Applikation abzubilden, bei der applikations- basierten Authentifizierung über die Datenbank und den Gruppen in der Applikation.Dies sind zwei komplett unterschiedliche Ansätze. Die Wahl der Methode beeinflusst zum Beispiel die Funktionalität von Passwort zurücksetzen oder Passwort zusenden lassen. Eine gute Lösung ist die Verwendung eines Identity Servers wie Keycloak oder Auth0. Hiermit lassen sich in der Regel alle möglichen Szenarien abbilden.

Verschlüsslung Ja, nein, Vielleicht?

Die Verschlüsslung ist eine Grundsatzentscheidung. Sollen die Daten verschlüsselt abgelegt werden, implementieren Sie diese am besten von Anfang an. Sie möchten nicht hinterher alles verschlüsseln, wenn bereits 50 Kunden Ihre Anwendung nutzen und 100.000 Datensätze unverschlüsselt angelegt sind.

Fazit

Es gibt viele Gründe und viele Entscheidungen, die dazu führen können, das ein Projekt scheitert. Keinen Plan zu haben, wohin die Reise gehen soll verbrennt nur unnötig Geld. Erörtern Sie die Rahmenbedingungen genausten und diskutieren Sie im Vorfeld lieber einmal mehr, als einmal zu wenig. Oft höre ich Leute sagen „Eine Software schreibt man immer zweimal. Beim zweiten Mal weiß man was auf einem zukommt.“ Das mag tatsächlich Alltag sein in vielen Unternehmen, sollte jedoch nicht das Leitbild oder Regel gesehen werden. Eine Software neu zu schreiben kostet enorm viel Geld, frustriert Ihre Entwickler und verärgert Ihre Kunden. In der Regel haben Sie dann noch ein Migrationsprojekt gewonnen und müssen Daten vom alten System ins Neue bringen, verbunden mit Downtime für den Kunden. Der Großteil der Funktionen muss neu geschrieben, neu gestestet, neu Dokumentiert und neu Deployed werden. Machen Sie es von Anfang an richtig, planen Sie mehr Zeit und mehr Budget ein. Sonst fangen Sie zweimal an und das Projekt kostet das doppelte, wenn nicht  noch mehr.