Shift left approach

Shift left approach

Eine neue Software steht vermeintlich kurz vor ihrem Roll-Out. Ein ganzes Jahr lang wurden die Anwender in den Fachbereichen nach ihren Anforderungen an die Software befragt. Zahlreiche Anforderungs-Workshops sind ins Land gezogen, Konflikte wurden aufgelöst und Klärungen durchgeführt. Penibel wurde die Anforderungen zunächst in ein Lastenheft und später in ein Pflichtenheft gegossen, sowie ein detaillierter Zeitplan erstellt. Mann sollte meinen: Es kann nichts mehr schief gehen.

Doch leider kommt es wie so oft: Bei der Software-Entwicklung hat es Verzögerungen gegeben, Anforderungen können teilweise nicht umgesetzt werden oder werden auf das nächste Release verschoben. Budgettechnisch wird das Geld auch langsam knapp und der Zeitplan ist stark bedroht. Der Roll-Out-Termin wurde bereits groß kommuniziert und wird mit Spannung erwartet. Doch der Zeitrahmen für die Testphase hat sich durch die Verzögerungen drastisch verkürzt, so dass eine vollständige Testabdeckung nicht mehr realistisch ist. Bereits mit den ersten Testfällen lässt sich der Trend ableiten, dass die Software-Lieferung nicht der gewünschten Qualität entspricht…

Was hier wie die Einleitung eines mehr oder weniger spannenden Romans über Software-Entwicklung klingt, ist leider in vielen Unternehmen ein durchaus realistisches Szenario und bittere Realität. Aus der Beschreibung heraus sollte klar sein, dass das Projekt nicht nach agilen Methoden arbeitet, sondern das klassische Wasserfall-Modell verwendet wurde. Doch, wie bereits in vergangenen Artikeln angedeutet, gibt es auch nicht „die“ agile Vorgehensweise. Teilweise gibt es, bspw. im Bankenumfeld, Restriktionen, die ein anderes Vorgehen zumindest erschweren. Dennoch kein Grund, gänzlich auf agile Methoden zu verzichten. Jede Organisation und jedes Projekt muss sich im Ausprägungsgrad der agilen Arbeitsweise an die jeweiligen Rahmenbedingungen anpassen. So arbeiten manchmal eben nur Teilbereiche nach agilen Methoden, während andere Bereich sich an klassischen Methoden orientieren.

Doch was hat dieses Szenario nun mit dem in der Überschrift titulierten „Shift left approach“ zu tun? Von der reinen Wortbedeutung her, wird etwas nach links verschoben. Mit diesem „Etwas“ sind einzelne Aktivitäten oder Phasen in einem Prozess/ Projekt gemeint. Auf die Software-Entwicklung bezogen, bspw. im DevOps-Ansatz, versteht man darunter, dass die Test-Phase in der Prozesskette weiter nach links verschoben oder in andere Aktivitäten integriert wird. So lassen sich bspw. Qualitätsdefizite bei der Software frühzeitig erkennen und nicht erst am Ende, wenn es viel zu spät ist. Und genau durch diese Vorgehensweise hätte, in der oben beschriebenen Situation, die böse Überraschung frühzeitig erkannt und rechtzeitig gegengesteuert werden können.

Allerdings wird diese Vorgehensweise nicht nur im Kontext der Softwareentwicklung angewendet, um frühzeitig gegen spätere Nachteile gegenzusteuern. Im Privaten wenden Sie diese Methodik unbewusst in unterschiedlichsten Bereichen an. Sei es eine Fassadenrenovierung, bei der Sie sich zu Beginn anhand eines kleinen Stückes erstmal das mögliche Endergebnis zeigen lassen oder beim Kochen, wenn Sie das Essen bereits während der Zubereitung abschmecken.

Doch wie lässt sich diese Methodik auch in den Arbeitsalltag integrieren? Einerseits gibt es bereits etablierte Verfahrensweisen, wie Pilot-Programme, in denen dieser Ansatz im großen Stil angewendet wird. Doch oftmals ist es eben nicht das große Ganze, bei dem es hakt, sondern die Feinheiten, die Probleme bereiten.
Entwickeln Sie Lösungen immer basierend auf einem (eingeschränkt) funktionsfähigem Produkt und binden Sie frühzeitig die Kunden für diese Produkte mit ein. Ob dieses Produkt nun eine visualisierte Darstellung einer Vorgehensweise, ein Stück Software oder ein physisches Objekt ist, spielt dabei keine Rolle. Frühzeitiger Austausch und Feedbackschliefen unterstützen Sie dabei, nicht an den Kundenvorstellungen vorbei zu entwickeln.

Menü