Was haben ein Maintenance-Projekt und ein Märchen gemeinsam? Vermutlich nicht viel, möchte man meinen. Allerdings ist die romantische Metapher des hässlichen Entleins, das sich am Ende zu einem schönen Schwan mausert, durchaus mit einem unserer Projekte vergleichbar.
Das Projektteam hat sich im Laufe der Jahre immer wieder einer Wandlung durchzogen. Das bedeutet, das mehrere Kollegen von Mayflower und des Kunden an dem Erfolg der stetigen Modernisierung teilhaben, von der ich nun erzähle.
Das hässliche Entlein
Das hässliche Entlein ist eigentlich ein Schwanenjunges, dessen Ei im Nest einer Ente gelandet ist. Es wird von der Ente aufgezogen, ist anders und passt somit nicht in sein Umfeld. Es bemüht sich so zu sein wie die anderen jungen Entlein, doch es scheitert und wird daher von den anderen Tieren verspottet. Es beschließt davonzulaufen und wird von einer Bäuerin für einige Zeit eingesperrt. Kurz darauf gelingt es dem Entlein zu fliehen.
Es versteckt sich im Schilf und beobachtet von dort aus die stolzen Schwäne. Als der Winter über das Land kommt, muss das Entlein sein Versteck verlassen, um Nahrung zu suchen. Dabei friert es eines Nachts in einem See fest.
Doch es hat Glück: ein Bauer sieht es, befreit das Entlein und nimmt es mit. Es flieht erneut und erkennt sein Spiegelbild im Wasser kaum wieder: Es ist zu einem erwachsenen, stolzen Schwan geworden.
Archetyp eines Außenseiters
Der Archetyp des Außenseiters bezeichnet hier einen selbstgebauten Shop: Altcode mit 18-jährigem Jubiläum, knapp dreißig selbst- oder im Auftrag entwickelte Tools, keine Tests, manuelles Deployment, dreifaltige Versionierung u. v. m.
Als der Kunde zu uns kam, war zunächst ein Serverumzug vonnöten. In diesem Zuge wurde das manuelle Deployment durch ein automatisierteres Deployment mit manuellem Anstoß mithilfe von Capistrano sowie ein einheitliches Versionierungssystem aufgesetzt.
Die Ausgangslage: Ein funktionierender Shop, der Umsatz generierte und performant lief.
Trotz seiner Irrungen und Wirrungen funktionierte der Shop erstaunlich gut. Funktionieren in dem Sinn, dass mit ihm viel Umsatz generiert wurde und er trotz der Umstände performant lief. Allerdings konnte man dem Shop das Alter ansehen und er war nur schwer wart- sowie erweiterbar.
Rebrush & Mandantenfähigkeit
Im Vergleich mit neuen E-Commerce-Systemen musste als nächstes ein neuer Anstrich her. Denn – um die Metapher wieder aufzugreifen – das Entlein fühlte sich hässlich im Vergleich mit neuen, modernen E-Commerce-Systemen.
Daher fand ein Rebrush statt, in dessen Zuge das Frontend auf eine modernere Ebene gehoben wurde, unter anderem mit Compass und Sass (wir reden hier von einem Zeitpunkt im Jahr 2014).
Ungefähr zur selben Zeit kam ein zusätzlicher Mandant für den Shop hinzu. Das hatte zur Folge, dass der bestehende selbstgebaute Monolith mandantenfähig aufgebaut werden musste; hinsichtlich der Datenstruktur als auch im Frontend. In enger Zusammenarbeit mit dem Kunden und dessen Entwicklern wurde auch diese Hürde genommen. Teilweise nutzten am Ende beide Mandanten dieselben Templates im Frontend, teilweise war es nicht möglich, Dinge zusammenzuführen.
Die erste Phase
In diesem Zustand wurde in der Zeitachse der nächsten Jahre vorerst weiterentwickelt: Es wurden neue Features gebaut, um dem Kunden zum einen zu ermöglichen mit der Konkurrenz mitzuhalten, und zum anderen bei bestimmten Themen Vorreiter zu sein.
Diese Ziele sind allerdings nicht trivial zu erreichen. Denn wenn man mit Altcode ohne ein bestehendes Testsystem arbeitet, ist es natürlich eine Gratwanderung, ein kleines Refactoring zu betreiben oder ein Feature einzubauen und dabei andere Bereiche nicht zu beeinträchtigen.
Unsere Learnings in Bezug auf das Entwickeln mit Altcode
Wir haben mit hohem technischen Wissen und übergreifendem Fachwissen versucht, möglichst keine anderen Features kaputtzumachen. Daneben wurde in Zusammenarbeit mit dem Kunden sichergestellt, dass alle Features fachlich durchgetestet wurden. Es ging kein Feature live, das nicht fachlich abgenommen wurde.
Darüber hinaus hatten wir den Vorteil, dass ein paar Produktmanager früher selbst Entwickler waren und somit genau wussten, welche Bereiche abzutesten waren, was unter Anderem grobe Fehler verhindert hat.
Die „reaktive Depression“
Im Laufe der Zeit hat sich die Wasserfall-Methode des Proof of Concept (POC) etabliert. Dieser Umstand hat dazu geführt, dass neue Features als Prototypen in relativ kurzer Zeit produktiv gestellt wurden.
Das hatte zum einen gewisse Vorteile. Gerade im E-Commerce-Bereich will man immer wieder Neues ausprobieren und schauen, welche UX-Methode beispielsweise den Kunden eher anspricht und mehr Umsatz generiert. Leider wurden dabei einige Features ein-, aber seltener ausgebaut … Das hatte natürlich zur Folge, dass der Code noch schwerer wart- und erweiterbar wurde.
Die Methode des PoC brachte auch viele Nachteile mit sich.
Darüber hinaus ist diese Art und Weise keine iterative Methode. Das führt im Umkehrschluss zum einen dazu, dass teilweise am Benutzer vorbei entwickelt wird. Zum anderen, dass der schnell gebaute Prototyp für die Weiterentwicklung verwendet werden muss.
Die gefrorene Eisdecke
Die Metapher des Zufrierens der Eisdecke im Märchen kann man hierbei wie folgt beschreiben: Der Kunde hat zwar nach Scrum arbeiten wollen, in das bestehende hierarchische System hat sich das jedoch nicht so recht einfügen wollen.
Das Outcome an der Stelle war ein Prozess, der sowohl dem Kunden als auch dem Entwicklungsteam nicht viel Mehrwert brachte und beiderseits Schmerzen verursachte. Beim Kunden, weil er in den schnellen Marktveränderungen beispielsweise kein „Deep Backlog“ erstellen konnte und sich Anforderungen in der Zeit einfach wieder änderten. Und bei den Entwicklern, da das Sprint-Ziel durch ebendiese Änderungen niemals erreicht werden konnte.
Ein anderer Aspekt der zu einer Art reaktiven Depression geführt hatte war schlicht Zeit. Der Scrum-Prozess erfordert regelmäßige Meetings. Da es viele Stakeholder gibt und in Hochzeiten insgesamt 14 Entwickler, arteten diese Regelmeetings zu Vor-Ort-Treffen aus, die schlicht und ergreifend Zeit fraßen. Zeit, die eigentlich in die Entwicklung hätte einfließen können. Denn – wir erinnern uns – der gesamte Code war nicht testbar und das Entwickeln selbst trivialer Features fraß diese wertvolle Zeit.
Es gibt kein richtig oder falsch, nicht den “einen guten Weg” für alle
Bis man an den Punkt kommt, an dem es nicht mehr weitergeht, geht man manchmal mehrere Wege, die einem in dem Moment zwar richtig erscheinen, die reflektiert betrachtet jedoch nicht von Erfolg gekrönt waren. Auch im Projekt mit diesem Kunden haben wir gemeinsam mehrere Wege bestritten, die manchmal mehr, manchmal aber auch weniger beschwerlich waren.
Wir – das Team bei Mayflower und die Kollegen beim Kunden – haben allerdings schon immer eng zusammengearbeitet. Wir wussten, dass das nicht die Art und Weise ist, wie wir das Projekt zum Fliegen bringen. Nur das „wie“ war uns allen noch nicht ganz klar.
Modernisierung als Chance
Eine Möglichkeit hat sich aufgetan, als aus der Managementebene vom Kunden Budget zur Modernisierung des Shops freigemacht wurde. Unser Weg war, zuerst die Manpower im Dev-Team herzustellen, damit die Modernisierung in großen Schritten voranschreiten konnte.
Womit wir allerdings mit einer neuen Herausforderung konfrontiert waren: Unser Entwicklungsteam war mit 14 Entwicklern definitiv zu groß für den Scrum-Prozess.
Kurze Zusammenfassung:
- Wir haben einen Scrum-Prozess, der nicht den Mehrwert bringt, den wir uns alle erhoffen
- Wir wollen modernisieren
- Wir wollen den Code testbar bekommen
- … und wir wollen mehr Zeit für die Entwicklung.
Hint: Wir haben das alles geschafft und das Projekt zum Fliegen gebracht.
Die Rettung aus dem Eis
In dem Märchen kommt ein Bauer und befreit das hässliche Entlein aus dem Eis. Unsere Befreiung war tatsächlich die Lösung des Problems, wie wir mit 14 Entwicklern, der Featureentwicklung und der Modernisierung gleichzeitig zu Rande kommen.
Wir haben zwei Teams gebildet. Eines, das sich nach einem für den Kunden neu eingeführten Prozess – Kanban – um die Modernisierung des bestehenden Shops kümmert. Und das Zweite, das fleißig die weitergehenden Features der Stakeholder abarbeitet und Bugs behebt – immer noch nach Scrum.
Die agile Modernisierung
Die Kanban-Methode im Modernisierungsteam lief sehr gut: Der Kunde hat erkannt, dass er auf diese Art und Weise unter Anderem mehr Durchsatz erhält. Die Umstellung auf Kanban im Feature-Team ließ daher nicht mehr lange auf sich warten; somit haben nach einiger Zeit beide Teams nach Kanban gearbeitet. Doch was hat sich genau verändert?
Die Modernisierung besteht aus zwei Teilen: Zum einen aus der agilen Modernisierung …
Einer der entscheidenden Faktoren war die Abschaffung, Kürzung und Umstrukturierung der Meetings, was am Ende zu einem enormen Zeitgewinn führte. Zeit, die nun in die Entwicklung geflossen ist.
Außerdem wurden Meetings auf Remote umgestellt, was wiederum den gerade genannten Faktor Zeit (die man sonst auf der Straße verbringt) verkürzte und überdies den Kostenfaktor für diese Besprechungen erheblich gesenkt hat.
Von PoC zu MVP
Ein weiterer agiler Meilenstein im Projekt war die Einführung des Minimum Viable Product (MVP) im Gegensatz zum beereits erwähnten Proof-Of-Concept (POC). Durch den iterativen Ansatz dieser Methodik wurde sichergestellt, dass User-Feedback direkt in die Entwicklung mit einfliessen konnte und somit am Ende ein höherer Mehrwert für den Kunden heraussprang.
Das Ergebnis dieser Umstellung ist die Aushebelung der Wasserfall-Methodik, eine höhere Planbarkeit innerhalb des Projekts (um schnell auf den Markt reagieren können) und die Steigerung der Zufriedenheit im kompletten Team.
Das Ergebnis leitet automatisch zur Frage, welche Meetings denn jetzt stattfinden.
Review und Stakeholder-Refinement
Belassen haben wir das Review für die Stakeholder, das alle zwei Wochen stattfindet. Dort stellt ein Entwickler die Features vor, die in diesem Zeitraum produktiv gegangen sind. Darüber hinaus gibt es zwei Arten von Refinements: eines für die Stakeholder und eines für die Entwickler.
Das Refinement für die Produktmanager hat wie bereits erwähnt den Hintergrund, dass es nicht nur einer sondern insgesamt circa 15 verschiedene Personen sind und wir auf Kundenseite bis heute keinen Product Owner etablieren konnten.
Diese Art des Refinements ist dazu da, diese Lücke zu füllen und die diversen Stakeholder beim Schreiben der Tickets für ihre fachlichen Anforderungen zu unterstützen. Welches Feature kann man schneiden, was kann oder muss vorher auf technischer Seite erledigt werden und weitere Dinge.
Hierbei sind immer zwei Entwickler von unserer Seite anwesend. Im wöchentlichen Stakeholder-Meeting werden die Tickets dann entsprechend ihrer Priorisierung in die ToDo-Spalte geschoben, beziehungsweise wird daneben auch die aktuelle Priorisierung überprüft und dementsprechend gehandelt.
Technisches Refinement
Das technische Refinement der Developer hat den Vorteil, dass diese das Mandat haben zu entscheiden, welche Teile des Codes als nächstes modernisiert werden.
Zusammen mit den Entwicklern des Kunden und dessen technischem Leiter werden die aus diesem Meeting herausgepurzelten Tickets letztlich in die Bearbeitung verschoben. Die Tickets, die dort besprochen werden, werden von allen Entwicklern geschrieben und von vier „Refinees“ geprüft, teilweise überarbeitet und einpriorisiert.
Darüber hinaus haben wir noch unsere zweiwöchige Iteration, bei der wir die Zahlen aus dem Board besprechen und uns in der Retrospektive Handlungsoptionen überlegen, wie wir unsere Zusammenarbeit verbessern können.
Überdies findet in regelmäßigen Abständen ein CFQ mit dem Kunden statt, bei dem unser Agilist das Feedback vom Kunden einholt. Anschließend wird über das Feedback mit dem Team gesprochen und nach Lösungen für etwaig geäußerte Kritik gesucht.
Die technische Modernisierung
Angefangen hat alles mit der Einführung von GitLab CI und Codequalitätstools wie phpstan und phpcs. Nach und nach wurden die Pipelines verbessert, es wurden zusätzlich PHPUnit und ESLint eingeführt. Von allen Entwicklern wurde die Entscheidung getragen, dass neuer Code immer mit Tests abgedeckt wird.
… und auf der anderen Seite natürlich die technische Modernisierung.
Auf einmal ging alles ganz schnell: Die Einführung von Type Hints, ein Upgrade auf PHP 7.2, die Einbettung von Symfony. Aktuell ist gerade die Einführung einer Queue für die Jobs in Arbeit. So viel zum Altcode, der jedoch immer weniger wird.
Review-Umgebung
Ein richtiger Meilenstein ist dem Team jedoch mit der Einführung der Review-Umgebung gelungen.
Wie es vorher war
Wie es vorher war: Wir haben eine Testumgebung, die natürlich nicht identisch zu Prod war, auf der jedoch trotzdem viele Tickets getestet werden mussten. Dieses Testing der Tickets musste natürlich gemanaged werden, denn nicht jeder Produktmanager konnte zu jeder x-beliebigen Zeit sein Ticket testen.
Was war die Folge? Ticket-Stau in der „Bereit für fachliches Review“-Spalte. Und es brauchte natürlich immer einen Dev, der dem Stakeholder zu gegebener Zeit das Ticket zum Testen bereitstellte.
Was wir schon für das Backoffice (siehe unten) nutzten, wurde nun auch für die Review-Umgebung des Shops eingebaut: Dieser läuft nun ebenfalls in Docker und Kubernetes mit einem MySQL dahinter und kann in der GitLab CI mit einem entsprechenden Knopf getriggert werden.
Der Mehrwert liegt auf der Hand. Wir brauchen die kleine Hardwarekiste bald nicht mehr, denn durch entsprechende Testdaten ist mittlerweile sogar ein kompletter Checkout-Prozess in der Review-Umgebung möglich.
Das wiederum heißt, dass Stakeholder nur noch auf einen Link klicken und ihr entwickeltes Feature zum Testen bereitgestellt bekommen. Es ist kein kompliziertes Testmaschinen-Deployment-Management mehr nötig und Entwicklerressourcen werden dafür zumindest immer weniger herangezogen.
Die Migration der selbstgebauten Tools in modern
Der Kunde hat wie Anfangs erwähnt über die Jahre dreißig selbst- oder im Auftrag entwickelte Tools zu seinem Monolithen gebaut, die entweder via CLI oder wenig performant durch den Browser aufrufbar sind. Das Team hatte den Auftrag, die verwendeten Tools an einem Ort zu sammeln und in schön verfügbar zu machen – und bei einigen dieser Werkzeuge können wir nun vermelden, dass sie nun umgezogen wurden. Selbstverständlich in neu, modern und performant. Das moderne Konglomerat der Tools wurde auf den Namen „Backoffice“ getauft.
Für jedes Land und für diverse Aktionen werden vom Kunden Schlüssel zur Identifizierung von Werbekanälen verteilt. Gutscheine werden ebenfalls über das Tool behandelt. Des Weiteren können Servlet-Abfragen an den Host geschickt werden, der Informationen über Kunden, Artikel, Bestellungen und vieles mehr zurück liefert.
Ebenso ist es nun möglich, Artikelattribute des Shopsystems per Dateiupload zu pflegen. Weiterentwicklungen der vorhandenen Tools sind in Arbeit oder in Planung. Künftig werden noch mehr Tools der Produktmanager in das neue Konstrukt umgezogen.
Der Tech-Stack
Backend: ApiPlatform, Symfony5, PHP7.3, MySQL
Tests: PHPUnit
QA: PHPStan, PHPCS
Frontend: React 16.9 mit TypeScript und Hooks, Ant Design, emotion, Formik + Yup, Luxon
Tests: jest, Faber
QA: ESLint
DevOps: Docker, Kubernetes, GitLab CI
Entwicklungsumgebung: Visual Studio Code, Bracket Pair Colorizer, Import Sorter, Live Share, Prettier
Das Entlein erkennt seine eigene Schönheit
Um wieder mit der Metapher des Märchens etwas zu spielen: Das Entlein erkennt sein eigenes Spiegelbild und findet sich schön. Im Projektkontext bedeutet das, dass wir dem Kunden nun topmoderne Features liefern können, die vorher mit dem Altcode nicht möglich waren. Das Team ist auf der sicheren Seite, wenn es vorhandenen Code in neuen Code umwandelt.
Die Modernisierung eines Maintenance-Projekts kann nicht nur auf einer Ebene stattfinden.
Wir haben das Bottleneck der einzigen Testmaschine mit Ausnahme einiger Testdaten, die fehlen, um die Testkiste vollends abzulösen, fast eliminiert. Außerdem haben wir moderne Tools, die unter anderem kundenseitig neue Entwickler anlocken.
Und wir haben ein System gefunden, welches für die Stakeholder und die Entwickler funktioniert und darüber hinaus eine überaus kollegiale Kundenbeziehung geschaffen.
Wir haben viel geschafft, aber auch noch viel vor uns. Es bleibt also trotz allem spannend. Unsere Mission ist, die Kundenzufriedenheit hoch zu halten, Spaß sowohl bei der Arbeit als auch mit dem Kunden zu haben und mit Herz und Verstand dem Kunden das zu geben, was er braucht.
Und die Geschichte geht weiter.
Schreibe einen Kommentar