Shift left, build right: Der Erfolgsfaktor im Einbindung von Qualität im Software Entwicklungsprozess

Die „Shift-Left“-Revolution in der Softwareentwicklung um Bugs frühzeitig zu erkennen und verhindern geht nur langsam voran und dauert inzwischen fast 20 Jahre. Dieser „Schritt nach links“ meint die frühzeitige Einbindung bestimmter Teammitglieder in die Entwicklung, um die sonst lineare Entwicklung zu einem iterativen Prozess zu machen und zu verhindern, dass Fehler erst am Ende entdeckt werden und den Release Zyklus verlangsamen. Wie dies in der Praxis aussieht, kann sich jedoch von Unternehmen zu Unternehmen oder sogar von Team zu Team sehr stark unterscheiden.

Um zu erfahren, was „Shift Left“ bei Zühlke bedeutet, haben wir mit zwei Befürwortern gesprochen: Lead BA Matt Moores und Lead QA Consultant Paul Carey.

Shift left - Den Entwicklungszyklus neu denken

Aus Sicht des Business Analyst (BA) kann das Shift Left von großem Nutzen sein: „Wir sind so etwas wie der Klebstoff, der das Team zusammenhält, und wir müssen dafür sorgen, dass alle genug Informationen haben, um ihre Arbeit zielgerichtet fortsetzen zu können“, meint Matt. Wenn das Team isoliert arbeitet und nicht von Anfang an weiß, warum und woran es arbeitet, können wichtige Informationen verloren gehen oder an Wert einbüßen. „Früher näherte man sich dem Projektende und war durch viele, eigentlich wichtige, aber unterbliebene, Gespräche immer weiter vom Kurs abgekommen. Die Probleme traten dann erst bei der Qualitätsanalyse (QA) zutage“, fährt Matt fort. „Für mich als BA bedeutet Shift Left, dass alle Beteiligten auf demselben Stand sind, das Gesamtbild sehen und sich nicht auf bloße Annahmen verlassen müssen, wenn wir mit der Entwicklung beginnen.“

Bei Zühlke bedeutet Shift Left die frühzeitige Einbindung der Engineers, damit sie direkt vom Kunden erfahren, was dieser wünscht und welche Funktionen erwartet werden. Durch diesen Gesamtüberblick ist das ganze Team von Anfang an an der Lösungsfindung beteiligt. Weil die Teammitglieder während des gesamten Projektlebenszyklus involviert sind, haben sie mehr Kontext und ein besseres Verständnis der Materie. Dies erleichtert es ihnen, Innovationen zu schaffen und zu erproben, wenn es in die Entwicklungsphase geht. „In unserer Branche gilt das „Fail-Fast“-Prinzip, d. h. Scheitern ist OK, und man lernt umso mehr. Aber wenn man auf dem Holzweg ist, muss man das so schnell wie möglich akzeptieren und korrigieren. Je früher im Prozess die Qualitätsanalyse greift, desto besser gelingt uns das“, erklärt Matt.

Für ein erfolgreiches Software Engineering gilt: Dieselbe Sprache sprechen

Für diese Arbeitsweise ist eines unerlässlich: eine klare Kommunikation. Schon beim alten Modell gab es mehr als genug Potenzial für Missverständnisse, wenn ein Projekt von Team zu Team und von Phase zu Phase weitergegeben wurde. Wenn nun beim Shift Left alle gleichzeitig Input geben, kann sich ohne gemeinsamen Bezugsrahmen die Situation sogar noch verschlechtern. Hier kommt die durchgängige Sprache oder „Ubiquitous Language“ ins Spiel. Wenn es möglich ist, Systeme und Probleme einheitlich zu beschreiben, lassen sich Informationen austauschen, auf die leicht reagiert werden kann.

In der Praxis bedeutet das einfach, dass man eine bestimmte Art und Weise festlegt, in der über das Projekt kommuniziert wird. „Wenn wir eine Ubiquitous Language wie Gherkin verwenden, kann Matt so schreiben, dass es das Team und das Unternehmen versteht. Und sie lässt sich in das übertragen, was das Delivery Team implementiert und testet“, meint Paul. Beide weisen darauf hin, dass die Ubiquitous Language zwar von Team zu Team variieren kann, aber im Wesentlichen von allen verstanden wird und immer dasselbe Ziel verfolgt.

Linksruck und Trägheitsmoment

Es stellt sich die Frage, warum Shift Left noch nicht überall Standard ist. Zunächst einmal können größere Teams im Vorfeld Mehrkosten bedeuten, und natürlich sind auch manche Menschen nicht bereit, sich außerhalb ihres gewohnten Gebiets zu engagieren. „Viele wollen auf eine bestimmte Art und Weise arbeiten, weil sie es so gewohnt sind“, erklärt Paul. Shift Left bedeutet zum Teil auch das Überwinden von Trägheit und das Verlassen der eigenen Komfortzone.

Darüber hinaus gibt es ein paar Hindernisse theoretischer Natur. Manche vertreten zum Beispiel die Ansicht, dass die QAs den Code vorher nicht sehen sollen, damit sie ihn unvoreingenommen betrachten können, wenn sie mit ihrer Arbeit an der Reihe sind. „Ich verstehe das Argument, aber meines Erachtens geht es weniger darum, „jungfräulich“ an die Sache heranzugehen, als in den richtigen Phasen objektiv zu sein“, sagt Paul.

Neue Blickwinkel auf die Sache sind jedoch nicht alles. Es geht vielmehr darum, wie Du Deine Rolle im Projekt insgesamt siehst. Paul hat hier in den vergangenen Jahren einen Sinneswandel beobachtet: „Jetzt höre ich die Software Engineers sagen, dass sie nicht nur dafür bezahlt werden, Code zu produzieren, sondern dafür, ein Objekt mit einem Wert zu liefern“, berichtet er. Man scheint sich darin einig zu sein, dass das Programmieren im Grunde der einfachere Teil ist. Die Herausforderung besteht darin, das Richtige zu erschaffen und das Team frühzeitig in den Lebenszyklus einzubinden, damit dies auf optimale Weise geschieht – genau das kannst Du mit Shift Left erreichen.