Der Enabler Backlog Workshop

Schlaue Köpfe haben schlaue Ideen und wollen daraus eine Lösung entwickeln. Pläne sind geschmiedet. Eventuell gibt es sogar schon ein Backlog voller Epics und Tickets, und den Entwicklern dürstet es nach dem Pushen der ersten Commits!

Halt! Stop! “Wir haben ja gar nichts!?”

Also zurück an den Anfang!

Es steht eine Vision im Raum, die mit Hilfe einer Softwarelösung realisiert werden soll. Damit das Ziel erreicht werden kann, müssen die Anforderungen für die Anwendung als auch für die Umsetzung klar sein. Für Ersteres helfen uns dabei andere Workshopformate, auf die wir später kurz eingehen werden. Mit dem Enabler Backlog Workshop wird ein agiler Weg aufgezeigt, mit dem wir die Software-Architektur planen bzw. organisieren können. Enabler sind wichtig, um strukturiert, effizient und flexibel entwickeln zu können.

Warum brauche ich einen Workshop für meinen Backlog?

Wir sprechen hier vom Enabler oder auch Architectural Enabler Backlog, das Entwicklern und Techies ermöglichen soll, ihre Arbeit zu tun.

Am Anfang eines neuen Projektes gibt es immer sehr viele Fragen. Zum Beispiel: Wer sind meine Kunden? Welche Features werden benötigt? Oder auch, was ich für meine Lösung benötige?

Noch mehr, aber ganz andere Fragen:

• Macht es Sinn, mit 20 Techies zu starten? Oder doch besser erstmal nur mit 5?
• Womit starte ich überhaupt bei der Umsetzung?
• Welche Programmiersprache ist die richtige Wahl?
• Wo will ich meine Lösung am Ende laufen lassen? On-Premise? Cloud?
  • Welche Architekturform benötige ich?
  • Wie sieht mein Deployment aus?
  • Entwickle ich lokal oder in der Cloud?
• Wie bekomme ich mein erstes lauffähiges  “Hallo Welt” hin?
• Macht ein Proof of Concept oder MVP Sinn? 

Überraschung: Der letzte Block ist unser Augenmerk. Für all diese Fragen und mehr benötigt es eine strategische Planung.

Was benötige ich für einen Enabler Backlog Workshop?

Die sinnvolle Workshop-Durchführung erfordert vorab, dass mehrere Themen – und damit auch alle beteiligten Personen (Management als auch Entwickler) – abgeholt wurden. Das beinhaltet:

• Einen Business Driver Workshop
• Eine ausgearbeitete Detail-Architektur
• Eine Prise bereits beschriebene Lösungsarchitektur
• Zum Schluss müssen die Plattform- & Fitness-Funktionen bekannt sein

Danach stehen uns hoffentlich alle Informationen zum Aufbau unseres Workshops zur Verfügung.

Der Mix macht’s

In der agilen Softwareentwicklung ging man in der Vergangenheit den Weg des emergenten Designs. Komplexe Lösungen, mit z. B. einer Microservice-Architektur, können aber mit dem Prinzip alleine nicht erfolgreich umgesetzt werden.

Helfen kann eine gesunde Mischung aus „Emergent Design“ und „Intentional Architecture“. Dabei muss im Workshop entschieden werden, welche Bereiche der Architektur unbedingt klar definiert sein müssen, um eine solide Basis für den Fortschritt zu schaffen. An anderen Stellen kann und sollte weiterhin klassisch explorativ und experimentierend entwickelt werden.

Am Ende ist das Ziel natürlich, schnell auf Anforderungsänderungen reagieren zu können, ohne die Stabilität des Gesamtsystems zu gefährden. Es benötigt eine solide Grundarchitektur, an der ich meine Features ausprobieren, entwickeln und testen kann. Bei Enablern geht es nicht darum, End-User-Features zu entwickeln. Es geht um die Befähigung der Entwickler zum Bau einer Anwendung, die das Entwickeln von Stakeholder-Features robust und produktiv ermöglicht.

Doch wie schafft man das?

Walking Skeleton

Man stelle sich ein wandelndes Skelett vor, an dem ich ein Bein fertigstellen kann, in dem ich Muskeln, dann Sehnen und dann die Haut aufbringe. Zunächst einmal müssen aber alle Knochen miteinander verbunden sein, damit ich überhaupt ein Skelett habe, an dem ich etwas anbringen kann.

In der agilen Softwareentwicklung spricht man vom Prinzip des „Walking Skeleton“. Die Idee dabei ist die Schaffung einer grundlegenden Architektur, die das Minimum an benötigten Komponenten bzw. Services verbindet.

Hinzu kommen dann auch schon die Themen DevOps und CI/CD. Testing und Logging sollten zu dem Zeitpunkt bereits implementiert sein.

Ein simples Beispiel für Microservices:

• Wir benötigen ein Backend, Frontend und eine Middleware
• Eine Datenbank zur Speicherung von Informationen
• Eine Message Queue, damit die Services miteinander kommunizieren können
• Ein Logging, um Fehler sehen/debuggen zu können
• Etc.

… der einfachste Fall

Gehen wir vom einfachsten Fall aus: Damit die Komponenten miteinander reden können, wird ein Message Bus implementiert. Nun kann das Frontend z. B. eine Anfrage an die Middleware schicken und sagen „Speichere mir die Informationen mit dem passenden Service (im Beispiel hier gibt es nur einen)“. Die Middleware übergibt die Daten an das Backend, welches dann die eigentliche Speicherung in der Datenbank ausführt.

So haben wir einen Durchstich geschafft, der Message Broker und die Middleware könnten nun als Basis für die Anbindung weiterer Services dienen.

Im Detail kämen dann noch weitere Themen dazu, wie:

Es klappert schon, läuft aber noch nicht

Es ist an der Zeit, unser obiges Beispiel in einzelne Enablers zu zerlegen.

Der Sinn von Enablern

Das ist nur die Spitze des Eisberges und nicht mal ein vollständig ausgearbeitetes Beispiel. Die anfallende Arbeit, die noch nichts mit der Programmierung zu tun hat, ist schon einiges.

Als Nächstes müssen die Epics geplant werden. Für eine erste grobe Schätzung kann z. B. in T-Shirt-Größen gearbeitet werden. Anschließend werden die Epics dann nach Sinnhaftigkeit im Backlog priorisiert und eingeordnet.

Nicht selten passiert es, dass sich während der letzten Planung Themen oder Technologien ändern. Als Beispiel könnte man hier den Cloud-Provider nennen: Ursprünglich sollte es Microsoft Azure sein. Dann hat aber jemand entschieden, dass Amazon AWS sinnvoller wäre, obwohl niemand aus dem Team Erfahrung mit dem Provider hat.

Auch darum geht es bei den Enablern: Rechtzeitig Themen im Visier haben, die dem Team ermöglichen, weitermachen zu können. Dazu gehört auch, sich zu überlegen, fehlendes Wissen reinzuholen oder aufzubauen. 

Enabler sind keine einmalige Planung, sondern ein sich wiederholender Prozess. Die Verantwortlichen für die Architektur müssen also auf Veränderungen reagieren und immer wieder rekapitulieren, ob der aktuelle Weg noch der richtige ist. Der Begriff Intentional Design sei hier noch einmal in Erinnerung gerufen.

Schritt für Schritt

Alle erarbeiteten Informationen müssen noch einmal betrachtet werden, um daraus Enabler Epics zu generieren. Darum ist es auch in dieser Phase wichtig, die Techies dabei zu haben. 

Eine mögliche Blaupause für ein Epic für Service X könnte etwa so aussehen:

• Überlegungen
  • Für welche User Story wird er wann benötigt?
  • Wie viel Aufwand ist es, ihn zu integrieren?
  • Wird der Service selbst entwickelt?
  • Müssen weitere Abhängigkeiten aufgelöst werden?
  • Wird er in die bestehende Infrastruktur oder als SaaS eingebunden?
• Tasks:
  • Konfigurieren des Services
  • Als Container für die Entwickler und verschiedenen Umgebungen verfügbar machen
  • Einbinden in bestehende Monitoring-/Logging-Struktur
  • CI/CD
  • Einbinden in die Kostenstelle

Nun wird anhand von Stakeholder-Featuren geplant und priorisiert, wann und welche Enabler zur Implementierung der Anforderungen umgesetzt sein müssen.

Noch einmal sei an dieser Stelle jedoch darauf hingewiesen: 
Diese Planung passiert stetig! Nicht einmalig! 

Ist das erst einmal etabliert, macht man sich das Leben auf lange Sicht deutlich leichter. In diesem Sinne: Happy Enabling!