Agile darf keine Ausrede für fehlende Projektplanung sein!

Agile darf keine Ausrede für fehlende Projektplanung sein!
Bildrechte: Photo by George Becker from Pexels

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.


Was ist agile Projektplanung oder agile Produktentwicklung überhaupt? Agile 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 den möchte ich auch gar nicht schlecht reden. 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.

Der Softwarearchitekt der sich Gedanken um Systemarchitektur, Services, Komponenten etc. machen muss, 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. 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.

Wichtige Punkte die vorab geklärt sein sollten

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

Wo läuft die Software? On-Premise oder Cloud?

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.

Ist die Anwendung Multimandantenfähig, oder nicht?

Vorab: Mehrere Mandanten in einem System zu haben finde ich nicht gut. 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 in Ihrem Fall wirklich kritisch oder nur ein Aushängeschild für das Projekt?

Skalierbarkeit in einer Anwendung ist eine tolle Sache. Gerade bei SOA (Service orientierten Anwendungen) ist dies 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 ASP.MVC Anwendung (oder Laravel) 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 sich Authentifizierung / Autorisiert?

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.

Soll eine App zukünftig angebunden werden können?

Diese Entscheidung ist nicht zwangsläufig in Stein gemeißelt und kann hinterher auch noch einfach implementiert werden. Jedoch kann diese Entscheidung einen hohen Anteil an Kosten ausmachen. Soll definitiv eine App später angebunden werden entscheiden Sie sich am besten direkt dafür auf eine REST Schnittstelle zu programmieren, sonst müssen Sie evtl. später jede Logik doppelt pflegen? Einmal über den normalen Controller vom alten Backend und einmal über den API-Controller. Im Jahr 2021 würde ich grundsätzlich nur noch auf REST-APIs entwickeln wollen. Je nach Budget kann diese Option vielleicht aber wegfallen.

Verschlüsslung Ja / Nein – und wenn ja, was wird verschlüsselt

Grundsatzentscheidung was Datenschutz angeht. Sie möchten nicht hinterher alles verschlüsseln, wenn bereits 50 Kunden Ihre Anwendung nutzen und 100.000 Datensätze unverschlüsselt angelegt sind. Sowas entscheiden Sie am besten vorher.

Auf welchem Betriebssystem soll die Anwendung laufen

Diese Entscheidung kann das komplette Projekt boykottieren. Wenn Ihr anfängt Eure Webapplikation für IIS (Windows Server) zu schreiben und es stellt sich heraus das Sie genauso auf einem Linux Server laufen soll, habt Ihr evtl. ein Problem, wenn das Framework nicht auf Linux lauffähig ist. Gleiches gilt für Desktop und Mobile Applikationen. Schreibt Ihr Eure Android App mit Kotlin aber all Eure Kunden setzen primär iOS ein war der Geldverbrennung. Macht Euch erst Gedanken über die Plattform, dann über das Framework. Oder Ihr entscheidet Euch direkt für Plattformunabhängige Technologien wie z. B. Ionic oder Flutter.

Welche Frameworks werden verwendet

Da Frameworks für viele Problemstellungen in der Entwicklung bereits eine Lösung implementiert haben lassen diese sich schwer einfach austauschen. Ihr könnt nicht einfach von ASP.MVC auf Flask wechseln, das sind zu krasse Unterscheidungen. Ebenso könnt Ihr mitten im Projekt nicht von Angular auf VueJS switchen. Entscheidet Euch für Euren Technologie-Stack und bleibt dabei. Ansonsten endet das in einer Neuentwicklung. Wenn Ihr Euch über ein Framework nicht sicher seit, macht einen Prototyp und prüft, ob Ihr die wichtigsten Anforderungen damit umgesetzt bekommt. Jede Technologie hat Ihre Vor- und Nachteile. Prüft was benötigt wird und entscheidet euch dann für einen Technologiestack.

Was kann meiner Meinung nach, in Agilität, flexibel verändert werden

  • 2-Faktor Authentifizierung nach implementieren
  • Formularänderungen
  • Hinzufügen von SMS Gateway, Push Notifikation, E-Mail Benachrichtigungen
  • Pflichtfelder / keine Pflichtfelder
  • Änderungen an Models und/oder DTOs
  • Logik Änderungen in “Create, Read, Update, Delete” (CRUD)
  • Relationen zwischen Datenbanktabellen. Zumindest wenn hier auf Normalisierung geachtet wird, ist das eher Fleißarbeit als ein echtes Problem
  • Alles was Design angeht: Menüstrukturen, Farben, Schatten, Schriftarten, Bilder, Icons etc.
  • Gruppen und Rollen Mitgliedschaften von Benutzern.

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.