Phasenagiles Vorgehensmodell

Das phasenagile Vorgehensmodell ist ein agiles Vorgehensmodell des Projekt- und Produktmanagements für die Entwicklung kundenspezifischer Fachanwendungen, welches die Vorteile des klassischen Wasserfallmodells mit denen agiler Softwareentwicklung (nach Scrum) kombiniert und agile Festpreise ermöglicht. Kennzeichnend ist dabei, dass zu Beginn eines jeden Projektes aufeinanderfolgende Projektphasen definiert werden, ähnlich wie im Wasserfallmodell. Dabei ist es jedoch möglich, dass jede Projektphase in sich agil und flexibel bearbeitet werden kann, ohne dass sich die Agilität auf bereits abgeschlossene Phasen auswirkt. Methodisch lehnt sich die Arbeit stark an die Prinzipien des Design Thinkings an, und das über alle Phasen eines Projektes hinweg. ^[1]

Phasenstruktur[Bearbeiten]

Ein typisches Projekt nach dem phasenagilen Vorgehensmodell kann wie folgt aussehen :

Phase 1: Projektstart

In der ersten Phase wird, wie üblich, ein Pflichtenheft erstellt, in dem die Anforderungen des Auftraggebers vom Auftragnehmer erarbeitet und deren Realisierungsvorhaben zusammengefasst werden. Ziel dieser Phase ist es, ein Grundgerüst für die entstehende Softwareanwendung zusammen mit den künftigen Anwendern zu erstellen, besondere Herausforderungen zu identifizieren und eventuelle langlaufende Prozesse (wie z. B. erforderliche Anpassungen in zu verwendenden Softwarekomponenten) rechtzeitig zu initiieren.

Phase 2: Datenbasis

In dieser Phase steht, in enger Zusammenarbeit mit den Anwendern, die systematische Erarbeitung der gesamten datentechnischen Grundlage der entstehenden Anwendung im Mittelpunkt, wie beispielsweise ein übergreifendes Daten- bzw. Objektmodell für die gesamte Anwendung, Ausprägungen von Datenschnittstellen o.ä. Soweit möglich, sollte bereits in dieser Projektphase eine erste (ggf. anonymisierte) Übernahme von Altdaten erfolgen, um auf diese Weise den nachfolgenden Projektphasen mehr Realitätsnähe zu geben, und um unter Last entwickeln zu können.

Phase 3: Programmrahmen

Hier steht die Entwicklung eines globalen Programmrahmes im Vordergrund. Dieser Rahmen kann unter Anderem gemäß Corporate Design Corporate Design das Menüdesign und -struktur, Benutzerverwaltungsmenüs oder Schnittstellen beinhalten. Der entstehende Programmrahmen sollte dabei funktional weitestgehend unabhängig von den konkreten fachlichen Inhalten sein und kann, je nach verwendeter Technologie, auch für mehrere einzelne Anwendungen übergreifend benutzt werden.

Phase 4: Fachmodule implementieren

In der vierten Phase werden nun die eigentlichen fachlichen Inhalte, deren Erscheinungsbild und die konkrete Bedienführung innerhalb der Bedienfelder implementiert. Sollte es sich um große Softwareanwendungen handeln kann die Implementierung einzelne Fachmodule getrennt und wahlweise parallel oder nacheinander oder überlappend erfolgen, zumindest sofern diese nicht allzu sehr miteinander vernetzt sind. Auch in dieser Phase sollte es, ähnlich wie bei Scrum, regelmäßige Absprachen mit dem Anwender geben, in denen einzelne Funktionen der kommenden Endanwendung besprochen und ggf. noch geändert werden können. Anders als bei Scrum werden aber nicht turnusmäßig vollständige, getestete Versionen bereitgestellt (Scrum Sprints), sondern ungetestete und unfertige Arbeitsstände, anhand derer das Aussehen, die Funktionalität und die Bedienabläufe gemeinsam mit den Anwendern diskutiert und abgerundet werden.

Phase 5: Finalisierung

In der letzten Phase findet eine abschließende Vollendung des Gesamtsystems und eine komplette Qualitätssicherung der Endanwendung statt, sowie die Inbetriebnahme der Software(Abnahme, Entwicklung und finale Datenübernahme).

Design Thinking im phasenagilen Vorgehensmodell[Bearbeiten]

Alle Workshop-Runden im phasenagilen Vorgehensmodell werden nach dem sogenannten Design-Thinking-Prinzip mit den Benutzern den einzelnen Phasen agil durchgeführt. Anders als der Name es vermuten lässt, geht es dabei nicht vorrangig um das Design, sondern darum, in interdisziplinären Teams von Auftraggeber und Auftragnehmer optimale Lösungen gemeinsam zu erarbeiten. Dabei steht die Steigerung der Usability im Vordergrund und nicht zwangsläufig die Qualität des Quellcodes. Idealerweise geht man dabei in kurzen Zyklen voran (z. B. je Fachmodul ein Workshop wöchentlich oder zweiwöchentlich) und in jeweils kurzen Absprachen werden die jeweiligen Arbeitsstände mit allen jeweils relevanten Projektbeteiligten besprochen. Je nach Thema und Projektphase werden aber unterschiedliche Personen in die Diskussionen mit einbezogen, z. B. auch mal Webdesigner, Datenbankadministratoren, Datenschutzbeauftragte oder sonstige Fachspezialisten. Auf jeden Fall sollten sowohl die Anwendervertreter des Auftraggebers als auch die eigentlichen Entwickler des Auftragnehmers involviert sein. Bei den Design-Thinking-Treffen findet üblicherweise ein Brainstorming aller Teilnehmer statt, in dem jede/r gleichberechtigte Idee zu dem aktuellen Projekt dazugeben kann. Das Phasenagile Vorgehensmodell ist dadurch optimal zugeschnitten auf Projekte, die mit Rapid Development-Tools, bzw. mit Low-Code-Plattformen entwickelt werden, weil der Aufwand für die eigentliche Entwicklung der Fachmodule und für die zugehörige Qualitätssicherung stark minimiert werden, so dass die anderen Projekttätigkeiten, wie z. B. Daten - und Schnittstellenmodellierung einen wesentlich größeren Raum einnehmen. ^[2]