Softwareentwicklungsprojekte verlaufen in Zeiten digitaler Märkte selten gradlinig. Umso wichtiger, klassische und agile Entwicklungsmethoden gleichermaßen zu beherrschen und sie passgenau einsetzen zu können – etwa, wenn nach der Entwicklung eines Portals plötzlich auch eine App entstehen soll.
Im umkämpften Consulting-Geschäft entscheiden mehr denn je zeitgemäße Dienstleistungen und Services über den langfristigen Erfolg von Beratungshäusern – gerade auch im mittelständischen Umfeld. Nicht zuletzt im Zeitalter der voranschreitenden Digitalisierung geht es darum, kundenspezifische Angebote zu schaffen, die auch langfristig die nötige Flexibilität und Offenheit für weitere Veränderungen bieten. Bei der Umsetzung dieser Lösungen helfen Beratungshäusern in der Regel IT-Partner, die über eine entsprechende Expertise in der Softwareentwicklung verfügen. Sie gehen gemeinsam mit dem Auftraggeber den Weg zur kundenindividuellen Lösung – von der Entwicklung einer ersten Produktidee bis zur vollständigen Dienstleistung. Auf diesem Weg läuft bekanntlich nicht immer alles nach Plan. So entstehen nicht selten noch während des Projektes zusätzliche Ideen oder kundenseitige Anforderungen, die erst mit zunehmendem Fortschritt der Entwicklung durchdacht und umgesetzt werden können.
Spätestens jetzt weiß jeder einen IT-Dienstleister als Partner zu schätzen, der das typische Korsett an Anforderungen zu durchbrechen weiß und verschiedene, ergebnisorientierte Entwicklungsmethoden beherrscht. Einen solchen Fall hat beispielsweise ein Consulting-Unternehmen erlebt, das für die Entwicklung und Realisierung eines webbasierten Portals für das Mängel- und Gewährleistungsmanagement mit dem IT-Dienstleister New Frontiers Software zusammenarbeitete. Erst während des Projekts kristallisierte sich die Notwendigkeit und der Wunsch nach einer passenden App heraus, deren anschließende Umsetzung dank flexibler Methodik und Technologie schließlich unproblematisch war.
Flexibilität auf allen Ebenen
Für die Entwicklung des Webportals setzten die beiden Partner zunächst auf die Wasserfallmethode – ein klassischer Ansatz, der sich für gut abgrenzbare, eingliedrige Projekte empfiehlt. Dementsprechend wurden im Pflichtenheft der genaue Zeitverlauf und die Phasen des Projektes festgelegt und im Rahmen einer konkreten Ergebnisbeschreibung festgehalten. Da diese Schritte nicht immer möglich sind, war es in diesem speziellen Fall umso wertvoller, dass Nutzerszenarien und der Umfang der Funktionen im Vorfeld sehr ausführlich definiert werden konnten. So war eine Anpassung der Ausrichtung auch nach weiteren Änderungen in Form von sogenannten Change Requests nach Projektbeginn nicht notwendig. Zudem ließen sich dank der vorhandenen Flexibilität auch Teile der Projektaufgaben in der Frühphase unabhängig voneinander entwerfen und später dann trotzdem zusammenfügen. Auch wenn das Unternehmen zu Beginn des Projekts keine Ausbaustufen des Portals plante, achtete das Entwicklungsteam vor allem auch auf die weitgehende Trennung von Frontend und Businesslogik und setzte von Anfang an Ansatzpunkte für API-Calls. Schließlich gelten Funktionsschnittstellen heute als Basis für integrierte, durchgehende IT-Systeme.
Nach dem Go-Live des Webportals bestand schnell Konsens über die Notwendigkeit einer ergänzenden, mobilen App – aufgrund der offenen technologischen Basis kein Problem. Die Verzahnung der entstehenden App und des vorhandenen Portals mit Online- und Offlinemodus erforderte aber auch Erweiterungen des Webportals. Gleichzeitig standen bereits neue Funktionsanforderungen für das Portal auf der Agenda. In der Folge mussten zwei Handlungsstränge parallel verfolgt werden: Auf der einen Seite für die Entwicklung der mobilen App einschließlich den Anpassungen am Portal, auf der anderen Seite für die Weiterentwicklung des Portals an sich – wiederum mit Auswirkungen auf die App.
Um zu verhindern, dass sich die Projekte gegenseitig behindern und ausbremsen, entschied sich das Team in einer kurzen Phase zunächst die notwendigen Anpassungen am Webportal zur Anbindung der mobilen App umzusetzen und im Anschluss zum agilen Verfahren zu wechseln. Dabei stimmen sich die Teams so aufeinander ab, dass möglichst schnell eine mobile App entstehen kann, die den Anforderungen eines Minimal Viable Products (MVP) gerecht wird.