Warum hämmert es in der Dev-Küche statt nur zu köcheln?

Ihr habt euch bestimmt auch schon gefragt, was die Baustellen-Geräusche sind, die aus der Dev-Küche zu hören sind. Wir renovieren im Hintergrund, weil wir große Pläne haben. Und während dieser Arbeit möchten wir trotzdem den Ofen nicht kalt werden lassen, aus dem große und kleine Aufläufe, Braten und Kuchen für euch, unsere Nutzer, kommen!

Wir nehmen euch mit auf einen Einblick: Mit was müssen wir uns dafür beschäftigen? Was hat es für einen Nutzen? Und wie wirkt es sich auf die Planung aus?

Investieren in die Zukunft

Unsere smapOne Plattform wird dieses Jahr 10 (sie werden so schnell groß!!). Klein gestartet, mit Funktionen angewachsen, viel dazugelernt, und verändert hat sich der ein oder andere Einflussfaktor über die Zeit auch noch: Unweigerlich entsteht Bedarf, ein paar Sachen auf Vordermann zu bringen. Unser Produkt ist unter der Haube ziemlich monolithisch aufgebaut, also aus einem Stück. Seine Bestandteile, Bereiche und Funktionen hängen teils eng miteinander zusammen. Und schon hin und wieder haben wir an einer Stelle gearbeitet und konnten Abhängigkeiten zu anderen Stellen nicht vermeiden. Das erfordert Koordination und Vorsicht bei Änderungen, und schränkt auch die Möglichkeit ein, parallel mehrere Features zu entwickeln.

Daran wollen wir arbeiten und damit an der Zukunftsfähigkeit unseres ganzen Produkts: Was bedeutet das?

• Skalieren und ermöglichen, dass mehrere Teams gleichzeitig an Funktionen arbeiten können, ohne sich gegenseitig zu behindern.
• Überschaubare, abgegrenzte Bereiche schaffen, in die man sich leichter einarbeiten und den Überblick besser behalten kann.
• Klare Verantwortlichkeiten, die unsere Kollegen zu Experten in den jeweiligen Bereichen machen.
• Eine bewusste Codestruktur, die ungewollte Seiteneffekte und Fehler bei Änderungen reduziert und Erweiterbarkeit erhöht.
• Eine modernere technische Basis, die uns neue Möglichkeiten eröffnet.
• Und schließlich auch häufigere, kleinere Releases, die uns intern weniger Arbeit machen.

Das Ganze bringt euch – ja euch! – am Ende eine Menge: Wir werden schneller in der Entwicklung und können insgesamt für bessere Qualität sorgen! 😍

Mit Blick auf alle Erweiterungen und Verbesserungen, zu denen ihr uns tagtäglich so inspiriert, sind wir selbst schon ganz ungeduldig, dieses Ziel zu erreichen.

Die Vision von abgegrenzten Modulen

Aber erst haben wir noch Arbeit vor uns. Uns treibt die Vision von einem Produkt an, das in fachliche Teile zerlegt ist, die von autonomen Teams verantwortet und entwickelt werden.

Um das zu erreichen, lassen wir uns von Domain-Driven Design (DDD) leiten. Dieser Ansatz der Softwaremodellierung hebt bewusst die Fachlichkeit, also die Prozesse und Zusammenhänge im abgebildeten Anwendungsbereich, als Treiber für die technische Struktur hervor. Die einzelnen Teile, in die wir das Produkt aufteilen wollen, nennen sich Bounded Contexts und bilden einen klar begrenzten fachlichen Bereich ab. Bei uns kann so ein Bereich zum Beispiel alles rund um die Aufgabenfunktion umfassen, oder die Konfiguration und Erstellung von Berichten. Ein Bounded Context wird zukünftig von genau einem Team betreut, ein Team kann jedoch mehrere Bounded Contexts verantworten.

Schlag für Schlag zum Ziel

Die Ziele, die wir uns gesteckt haben, sind nicht klein. Deshalb können wir uns ihnen nur in Schritten nähern. Und wir fangen nicht erst jetzt damit an:

• Wir haben unser Produkt analysiert und einen Plan gemacht, welche Bounded Contexts wir bilden wollen. Daraus ist eine Context Map entstanden, welche die gesamte Funktionalität der smapOne-Plattform in abgegrenzte Bereiche aufteilt. Sie ist ein lebendiges Dokument und wird andauernd verfeinert und erweitert, je weiter wir kommen.
• Die geplanten Bounded Contexts haben wir geclustert, um sie auf vier zukünftig vorgesehene Entwicklungsteams aufzuteilen. Jedes der Teams wird mehrere zusammenpassende Contexts verantworten.
• Und wir haben uns einen Plan gemacht, wie wir den geplanten Zustand, also Teams und Bounded Contexts im Produkt, in die Tat umsetzen.

Jetzt steht an, dass wir die geplanten Teams nacheinander ausgründen (denn aktuell haben wir eine ganz andere Teamstruktur!). Jedes gegründete Team wird dann seinen jeweiligen Bereich aus dem bestehenden Produkt herauslösen, denn noch existieren die Bounded Contexts ja nur als Zielbild.

Dazu planen wir nun, zuerst mit einem Team zu beginnen und etwas versetzt die anderen nacheinander folgen zu lassen. So können wir auf dem Weg von den gemachten Erfahrungen profitieren.
Losgehen soll es schon im Mai 2024 mit dem ersten Team.

Während wir von unserer aktuellen zur geplanten Teamstruktur übergehen und dafür sorgen, dass die Teams einen abgetrennten Bereich betreuen und unabhängig arbeiten können, stehen andere Arbeiten nicht still:

• Unsere neue Web-App wird immer weiter mit Funktionen angereichert, sodass sie schließlich uneingeschränkt mit ihren Vorteilen glänzen kann.
• Was für euch Browserfähigkeit und einige Vorteile wie Tastaturnavigation durch Formulare oder Links zu smaps mit sich bringt, hat für uns und unsere Modernisierungsbestrebungen noch eine große weitere Bedeutung: Wir werden auch die bestehenden Varianten der smapOne App in den Stores auf eine neue technologische Basis bringen – und außerdem auf die gleiche Technologie (Stichwort für Nerds: Blazor): Für die Zukunft steht dann ein reduzierter Aufwand bei Anpassungen in Aussicht, der wunderbar auf unser Ziel der schnelleren Entwicklungsgeschwindigkeit einzahlt. Hier passiert also weit mehr als Browserfähigkeit!
• Und was neben der Modernisierung und Modularisierung noch an neuen Funktionen und Verbesserungen verwirklicht wird, begrenzt sich bei weitem nicht nur auf die Web-App. Mehr dazu im Artikel “Das Haus, in dem die Dev-Küche steht“.

Alles zusammen erfordert, wenig überraschend, Koordination und Offenheit für ständiges Lernen. Das ist es aber mit Blick auf die Resultate wirklich wert!

Es hämmert im Hintergrund

Wenn wir also sagen, wir modernisieren, dann wisst ihr jetzt, was dahintersteckt. Und wundert euch nicht, falls bei uns im Hintergrund mal Hämmern zu hören ist: Daran hört ihr, dass wir jetzt in die Zukunft investieren.

Vielleicht müssen wir auf dem Weg zur modernen Dev-Küche das Vorbereiten der nächsten Torte timen, damit es nicht gerade mit dem Zeitraum zusammenfällt, wo der Kühlschrank ersetzt werden soll… Bestimmte Gerichte müssen wir aufschieben, auch wenn sie uns wichtig sind, während unsere Mannschaft sich aufs Kochen und Installieren neuer Küchenschränke gleichzeitig aufteilt. Langfristig werden unsere Köche dann viel besser parallel zubereiten können, Kochutensilien viel schneller griffbereit haben und wir uns an bisher unangetastete Dessertideen wagen können.

Wir für unseren Teil freuen uns schon riesig darauf!