Software­projekt FINAS Quick-Check ÖD Teil 1: Foundation Phase

Was der FINAS Quick-Check ÖD ist? Eine responsive Web-App, die schnell und unkompliziert das Ruhegehalt von Beamten im Öffentlichen Dienst (ÖD) berechnet. Die Anwendung läuft in der Cloud und lässt sich einfach in eine Webseite integrieren. Fünf Kollegen und Kolleginnen haben an der Entstehung mitgearbeitet – drei davon sind Martin, Philipp und Peter. In diesem und den folgenden Artikeln geben die Drei nähere Einblicke, wie sie dabei vorgegangen sind, welche Tools sie genutzt haben und was sonst noch wichtig war. 

Erst mal eine ordentliche Grundlage schaffen

Wir arbeiten agil. In unserer Digital Factory entwickeln die Teams selbstorganisiert funktionierende Software, die die Kundenanforderungen mit technischer Exzellenz und in gutem Design erfüllt. Dafür arbeiten Fachbereich und Technik täglich eng zusammen. Auch ein guter Start in ein agiles Projekt bringt zu Beginn alle Beteiligten zusammen und lässt sie gemeinsam die Grundlagen des Projektes festlegen. Diesen Start nennen wir Foundation Phase. Wie der Name schon andeutet, bildet sie das Fundament des Softwareentwicklungsprojektes. In einem Workshop erarbeiten Business, Fachbereich und Entwicklung hier miteinander einen Überblick über die Ziele des Auftraggebers, die fachlichen sowie weiteren Anforderungen, die Architektur und das Ökosystem der geplanten Applikation, um daraus ein grobes Backlog mit Meilensteinplan sowie eine Aufwandsindikation ableiten zu können. Inhaltlich orientiert sich die Foundation Phase an den sieben Produktdimensionen von Ellen Gottesdiener¹: Nutzer, Schnittstellen, Aktionen, Daten, Kontrolle, Umwelt und Qualität.

Dauert die Foundation Phase länger als einen Tag, wird sie durchgehend in ein und demselben Raum durchgeführt. Um die verschiedenen Ziele zu erreichen, stehen jeweils unterschiedliche Methoden zur Verfügung. Sämtliche Ergebnisse werden während der Durchführung durch die Teilnehmenden visualisiert und sind so für alle jederzeit ersichtlich. Im weiteren Projektverlauf sind die Visualisierungen aus der Foundation Phase zudem ein guter Erinnerungsanker für das Entwicklungsteam.

Bei unserem Projekt FINAS Quick-Check ÖD sind wir natürlich ebenfalls mit einer Foundation Phase gestartet, die ich als Agile Coach und Facilitator durchführen durfte. Dabei wurde ich aufgrund der Projektgröße jedoch vor eine besondere Herausforderung gestellt. Welche das war? Die Zeit.

Grundsätzlich gilt: Der Aufwand für eine Foundation Phase sollte in einem angemessenen Verhältnis zum erwarteten Projektaufwand stehen. Geht es um ein komplexes Projekt mit langer Umsetzungsdauer, wie z.B. die Entwicklung einer neuen Vertriebsplattform, kann die Foundation Phase durchaus mal bis zu zwei, drei Wochen dauern. Im Fall unseres FINAS Quick-Check ÖD standen uns zwei Stunden zur Verfügung. Das bedeutete, wir mussten den Workshop auf das wirklich Allernotwendigste reduzieren und eine extrem fokussierte Zusammenarbeit sicherstellen (da alle Beteiligten sich bereits gut kannten, war letzteres kein Problem).

Ohne die geht es nicht

Einige Eckpfeiler sind zwingend erforderlich, um das angestrebte Ziel der Foundation Phase zu erreichen – im Team passende technische Lösungen zu finden und, dezentral und schnell, gute Entscheidungen treffen zu können:

1. Die Business-Treiber: Die Geschäftsziele des Auftraggebers sind die Basis für gute Entscheidungen im Team
2. Der fachliche Funktionsumfang: Was muss die Anwendung können?
3. Die Umwelt/das Ökosystem: Wichtig für die Entwicklung der technischen Lösung/Architektur im Team
4. Nicht funktionale Anforderungen: Alles, was neben Fachlichkeit und Technik noch eine Rolle spielt
5. Story Map: Grobes Backlog mit Meilensteinplan
   

Am Ende sah die finale Agenda für die Foundation Phase des FINAS Quick-Check ÖD so aus:

Hier die einzelnen Schritte im Detail:

Schritt 1: Projektziele  Zu Beginn stellte unser Product Owner die Produktziele auf einem vorbereiteten Board vor und besprach sie mit dem Entwicklungsteam.	Schritt 2: Akteure Danach ging unser Product Owner näher darauf ein, wer das System nutzen wird und was die jeweiligen Aktivitäten sind.
Schritt 3: Systemkontext Auf einem vorbereiteten Board mit den Akteuren erarbeitete das Team nun die Umwelt, mit der das neue System interagiert. Dies wurde zunächst aus einer hohen Flughöhe gemacht. Üblicherweise wird noch weiter in das neue System und die Schnittstellen zur Umwelt hineingezoomt. Für den FINAS Quick-Check ÖD reichte es aber fürs Erste aus, ein gemeinsames Verständnis vom Ökosystem zu gewinnen.	Schritt 4: Nicht funktionale Anforderungen Auch bei den nicht funktionalen Anforderungen hat das Team mit einem vorbereiteten Board gearbeitet. Solche nicht funktionalen Anforderungen betreffen z.B. die Performance, Security oder rechtliche Vorgaben. Product Owner und Entwicklungsteam notierten jeweils ihre Stichpunkte, stellten diese kurz vor und sammelten sie. Anschließend wurden die Themen geclustert, diskutiert und weiter ergänzt.

Schritt 5: Story Map
Den größten Teil des Workshops nahm die Erarbeitung einer Story Map ein. Der Begriff 'Story Map' bezieht sich auf die Darstellung und Technik von Jeff Patton². Als Grundgerüst für die Story Map haben Product Owner und Fachbereich im Vorfeld des Workshops ein initiales Backbone für den FINAS Quick-Check ÖD erarbeitet. Mit dem initialen Backbone sowie den bisher gewonnenen Erkenntnissen als Basis, haben alle Beteiligten Feature-Überschriften notiert und auf das vorbereitete Board gebracht. Im Dialog zwischen Business, Fachbereich und Entwicklungsteam wurde das initiale Backbone so sukzessive erweitert.

Darauf aufsetzend erfolgte dann die Planung des Minimum Viable Product (MVP) sowie von zwei Releases. Fachbereich, Business und Entwicklungsteam haben hier wieder eng zusammengearbeitet, da bereits Abhängigkeiten zwischen den Features erkannt und berücksichtigt wurden. Zum Schluss erstellte das Team aus den Feature-Überschriften der Story Map die ersten User Stories für das Backlog.

Zugegeben, das Ganze war schon eine sehr sportliche Angelegenheit aufgrund der knappen Zeit. Dennoch haben wir es gemeinsam geschafft, eine ordentliche Grundlage für unser Projekt zu erstellen. Und damit konnte es dann auch so richtig losgehen.

Aber mehr dazu demnächst im Artikel von Philipp.

¹ Weitere Informationen zu den 7 Produktdimensionen von Ellen Gottesdiener unter: https://www.ebgconsulting.com/agile-resources/agile-books/ 

² Weitere Informationen zum Thema Story Map von Jeff Patton unter: https://www.jpattonassociates.com/story-mapping/