In anderen Blogbeiträgen war schon häufiger die Rede von Vertikalisierung, allerdings eher aus der Perspektive von Architekten und Projektleitenden. In diesem Beitrag soll es darum gehen, was Vertikalisierung für die Entwickelnden bedeutet, die in den jeweiligen Teams arbeiten.
Die offensichtlichste Folge einer Vertikalisierung für Entwickelnde ist, dass sie sich nur um einen begrenzten Teilbereich des Gesamtshopsystems kümmern müssen, z.B. um die Artikelsuche oder um den Kaufvorgang. Was bedeutet das aber für die Arbeit an diesen Teilsystemen, und welche Vorteile bringt Vertikalisierung auch auf dieser Ebene?
Was im System hinterher eng zusammenspielt, wird auch eng zusammen entwickelt. Für die einzelnen Entwickelnden ist eine Vertikale leichter zu überblicken als das komplette Konstrukt des ganzen Shops.
In großen Teams mit großen monolithischen Systemen bildet sich hingegen schnell ein Patchwork von Wissensinseln heraus, indem jeder sich nur mit "seinem" Teilbereich auskennt und sich im schlimmsten Fall auch niemand an den Zuständigkeitsbereich eines anderen wagt. Statt dieser Aufteilung des Gesamtshops in implizite Teilbereiche, definiert durch Zufall und Vorlieben, ermöglicht es die Arbeit in einem vertikalisierten Projekt, sich in der eigenen Vertikalen quasi überall auszukennen. Und das machen wiederum alle Entwickelnden im Team, so dass sich letztlich alle mit dem gleichen Code auskennen. Fortan bewohnen alle die gleiche Wissensinsel, was die Koordination und Urlaubsvertretungen einfacher macht.
Die Aufteilung des Shops in Vertikalen nach der Customer Journey und nicht nach der jeweils betreuten Technik wie Backend, Datenbank oder Frontend hält Reibungsverluste zwischen den Datenbank-, den Backend- und den Frontendentwickelnden gering, weil alle zu einem Team gehören und bei jeder Besprechung und jedem Konzept alle drei Komponenten berücksichtigt werden. Die Vertrautheit mit den vom eigenen Team betreuten Use Cases ermutigt auch eher zu einem "Blick über den Tellerrand" und ins Backend bzw. Frontend. Irgendwer, der einem dabei helfen kann, ist ja sowieso immer im Team.
Die Schnittstellen zur anderen Vertikalen sind begrenzt. Sie sollten aber sorgfältig entworfen sein, um die Wahrscheinlichkeit für Änderungen gering zu halten. Die Schnittstellen sind gleichzeitig das, was die eigene Vertikale definiert - wiederum anders als bei einem einzigen großen Shopsystem sorgt das für Überblick. Da die Schnittstellen sich gut als Ausgangspunkt für Tests eignen und jedes Team alles "dahinter" autonom entwickelt, kann ein einzelner fehlerhafter Commit in der Regel auch nicht mehr als die eigene Vertikale betreffen. Das macht das gesamte System beweglicher und verhindert allzu große Risiken, wenn mal etwas schnell gefixt werden muss. Der Heuhaufen, in dem die Nadel liegen kann, ist einfach nicht ganz so groß, und die Auswirkungen eines fehlerhaften "Fixes" halten sich in Grenzen.
Fazit: Arbeit in einer Vertikalen macht Spaß, weil ich als Backendentwicklerin direkt mit meinen Frontendkollegen zusammenarbeite. Sie macht Spaß, weil wir uns im Team nicht um alle Aspekte eines Onlineshops kümmern müssen, sondern nur um ein paar - aber für die haben wir Zeit. Die Prozesse sind leichter zu überblicken, weil sie alle zu einem Thema gehören. Dafür haben wir "unsere Prozesse" vom Browser bis zur Datenbank oder dem Bestellsystem des Kunden komplett selbst in der Hand. Was wir machen, machen wir komplett. Und wenn ich Fragen zu einer bestimmten Implementierung habe, gibt es auch jemanden, der sie mir beantworten kann, in meinem Team.
Ein bisschen "ein Team" sind die Vertikalen immer noch - es gibt Schnittstellen, die geplant und umgesetzt werden müssen, ebenso wie es Änderungen an diesen Schnittstellen gibt. Wir sitzen immer noch zusammen in einem Loft, wir bekommen beim Release Meeting mit, was in der anderen Vertikale gerade ansteht, und wir freuen uns alle, wenn eines der Teams ein wichtiges Feature live gebracht hat. Wir haben quasi da ein großes Team, wo das große Team Vorteile hat. In vielen Fällen haben große Teams aber Nachteile. Und in allen diesen Fällen haben wir ein kleines Team.
