Alles im Fluss

Immer komplexere Anforderungen an die Entwicklung spezifischer Software haben den Wunsch nach flexibleren Vertragsgestaltungen entstehen lassen. Die klassische Vorgehensweise bislang ist das sogenannte "Wasserfallmodell". Dieses zeichnet sich dadurch aus, dass die verschiedenen Entwicklungsstufen hintereinander abgearbeitet werden, wobei ein Rücksprung auf die vorherige Stufe nicht vorgesehen ist. Demnach folgt auf die Planung des Softwareprojekts die Anforderungsanalyse, danach der Entwurf, dem sich die Implementierung anschließt. Nachdem wiederum der Test und die Integration der Software abgeschlossen sind, endet die Entwicklung mit dem Übergang in die laufende Wartung und Pflege der betriebsbereiten Software.

Als Probleme dieser klassischen Softwareentwicklung gelten dabei insbesondere die starke Regulierung und Reglementierung, da sämtliche oben skizzierten Schritte im Detail durchorganisiert und (schriftlich) festgehalten sein müssen, um die Überwachung des Entwicklungsstandes und des Projektfortschritts zu ermöglichen. Dies führt naturgemäß insbesondere zu einem ganz erheblichen Dokumentationsaufwand. Hinzukommen als weitere Schwierigkeiten die eingangs angeführten komplexen Anforderungen, die mit sich schnell ändernden spezifischen Anforderungen einhergehen, vor allem dann, wenn zahlreiche Anwender mit dem Programm arbeiten, die ihrerseits die unterschiedlichsten Erwartungen an das Projekt stellen.

Die Idee hinter der agilen Softwareentwicklung ist demgegenüber, möglichst einfache und bewegliche Teilprozesse zu schaffen, um einerseits den Abnehmer der Software intensiver in das Projekt einzubinden, zum anderen aber vor allem um einen schnelleren Einsatz der Entwicklung zu gewährleisten. Als Grundlagen der agilen Entwicklung lassen sich dabei folgende Grundsätze festhalten:

• die funktionierende Software ist wichtiger als eine umfassende Dokumentation,
• die Zusammenarbeit mit dem Kunden steht über Vertragsverhandlungen und
• das Reagieren auf Veränderungen hat größere Bedeutung als das Befolgen eines vorgegebenen Plans.

Hierzu soll selbstorganisierten Teams vertraut werden, die eine intensivere Zusammenarbeit von Experten und Entwicklern ermöglicht und den Informationsaustausch durch persönliche Absprachen fördert.

Wesentlich ist dieser Art der Programmentwicklung demnach, dass die Anforderungen und Vorgaben zunächst unvollständig sind und sich während des Projekts darüber hinaus auch ändern können.

Der gesamte Prozess der Softwareentwicklung verläuft dabei nicht linear, sondern iterativ, indem man also versucht, sich der Lösung schrittweise anzunähern. Es ist offensichtlich, dass dies wiederum nur gelingen kann, wenn neben der bereits angesprochenen engen und ständigen Abstimmung der beteiligten Personen bzw. Teams insbesondere auf Seiten der Entwickler die Bereitschaft vorhanden ist, auf sich – auch kurzfristig – verändernde Kundenanforderungen einzugehen, mag dies auch wiederholt geschehen. Zugleich verdeutlicht dies, dass die enge Abstimmung und der ständige Kontakt zwischen den beteiligten Personen unumgängliche Mindestvoraussetzungen sind, da nur so der Entwicklungsprozess überhaupt erst möglich ist. Damit verbunden wiederum ist notwendigerweise die räumliche Nähe der Entwickler zum Kunden, um den intensiven und direkten Informationsaustausch sicherzustellen.

Für den Kenner klassischer Entwicklungsprozesse offenbart sich hier ein potenzieller Konflikt auf Seiten des Entwicklers: Es wird nahezu unmöglich sein, für ein agiles Projekt eine feste Preisgrenze zu benennen, geschweige denn gar einen Festpreis zu vereinbaren. Das Grundprinzip der agilen Softwareentwicklung, auch kurzfristige Änderungswünsche unmittelbar umzusetzen, führt konsequenterweise dazu, dass selbstverständlich der Entwicklungsaufwand und die notwendige Manpower wesentlich höher ist, da Programmierleistungen nicht nur ausreichend vorgehalten werden müssen, sondern diese auch individuell für kurzfristige Anforderungen einsetzbar sein müssen. Auch eine Gesamtdauer des Entwicklungsprozesses wird sich zu Beginn des Projekts nicht abschätzen lassen, wie erst recht ein konkretes Fertigstellungsdatum schon aus rein praktischen Gründen nicht genannt werden kann. Vor diesem Hintergrund wird deutlich, dass die agile Programmierung überhaupt nur für ausgewählte Projekte infrage kommt und auf beiden Seiten zudem die Bereitschaft bestehen muss, die bisherigen klassischen Vorgaben der Programmentwicklung zu verlassen.

Die Nutzungsrechte wurden The Property Post zur Verfügung gestellt von Wiedorfer Rechtsanwälte GbR
Erstveröffentlichung: Informationstechnologie und Immobilien, März 2018