Die Handbremse im Development-Prozess lösen Wie sich die Softwareentwicklung beschleunigen lässt

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

Rittal GmbH & Co. KG

VON ZUR MÜHLEN'SCHE GmbH

Kentix GmbH

In die Software-Entwicklung schleichen sich auf Dauer hinderliche Faktoren ein, die Entwicklungszyklen hinauszögern. Um diese „Developer Toil“, wie sich dieses Phänomen nennt, loszuwerden, müssen Organisationen auf ihre Entwickler hören.

Der Need for Speed in der Digitalisierung

Apps sind der Motor vieler Digitalisierungsinitiativen. Egal ob sie interne Prozesse effizienter gestalten oder die Customer Journey des Endnutzers begleiten: wer sein Unternehmen für das digitale Zeitalter bereit machen möchte, setzt meist auf die Vorteile von Anwendungen.

Doch Apps müssen heutzutage andere Herausforderungen bewältigen, als es noch vor einigen Jahren der Fall war. Sie sind sie heute oft eingebettet in ein Portfolio zahlreicher weiterer Apps, was die Komplexität und mögliche Angriffsflächen erhöht.

Mögliche Fehlerquellen müssen also in Rekordzeit beseitigt werden, um das Vertrauen der Kunden und den Erfolg des eigenen Geschäftsmodelles zu gewährleisten. Dafür reicht es nicht, einige wenige Updates pro Jahr auszurollen. Wer die Stabilität der eigenen Apps gewährleisten möchte, muss reaktionsschnell und agil handeln.

Software-Entwicklung im ersten Gang?

Doch auch, wenn sich immer mehr Unternehmen der Bedeutung von schnellem Handeln bewusst sind, bleiben die Entwicklungsprozesse oft schwerfällig. Dies belegt ebenfalls eine Studie von Forrester Consulting, wonach 48 Prozent der Führungskräfte angeben, dass sie ihre Apps seit mindestens einem Jahr nicht mehr geupdatet haben. Dabei sind die technischen Voraussetzungen in den meisten Fällen gegeben.

Woran liegt es also, dass die App-Entwicklung hinter ihrer möglichen Bestzeit zurückbleibt? Häufig liegt der Grund für die gedrosselte Geschwindigkeit im Entwicklungsprozess selbst. Denn dieser besteht nicht nur aus der eigentlichen Softwareentwicklung selbst, sondern geht mit vielen sich wiederholenden Aufgaben einher.

Diese redundanten Aktivitäten werden unter dem Begriff „Developer Toil“ zusammengefasst und unterstützen zwar den Ablauf, schaffen jedoch keinen eigentlichen Mehrwert. Mit der Zeit wächst die Zahl dieser Aufgaben und sie binden immer mehr Ressourcen. Darunter leidet die Agilität der Apps, da jedes Update in die Länge gezogen wird.

Boxenstopp im Entwicklungszyklus

Wer seine „Toil“ reduzieren möchte, kann auf ein Developer Toil Audit zurückgreifen. Dieses hilft dabei, mögliche Altlast zu identifizieren und zu priorisieren. Viele dieser Aufgaben können entweder automatisiert oder sogar in Gänze gestrichen werden. Ein solches Audit basiert dabei auf einer Befragung derjenigen, die am besten wissen, an welchen Stellen es hakt: den Entwicklern.

1. Die Fragen

Für den Fragebogen in einem solchen Audit gibt es keine einheitliche Blaupause, da die verzögernden Faktoren in jeder Organisation an unterschiedlichen Stellen zu finden sind. Die Befragung sollte aus allgemeinen und unternehmensspezifischen Fragen bestehen, die auf die Situation der eigenen Organisation zugeschnitten sind.

Die Developer Toil kann von vielen Faktoren beeinflusst werden, daher sollten die Fragen diese Faktoren abbilden: Vorschriften, die Zusammenarbeit mit anderen Teams oder die Analyse und die Beseitigung von Fehlerquellen. All diese Aspekte sollten bei der Befragung berücksichtigt werden.

Auch offene Fragen, beispielsweise nach Verbesserungsvorschlägen oder anderen Ideen, sollten den Entwicklern gestellt werden. Auf Basis dieser Fragen können dann Faktoren, die den Entwicklungsablauf in die Länge ziehen, analysiert werden.

2. Die Metriken

Um die richtigen Schritte aus den Antworten der Entwickler abzuleiten, müssen nun Metriken erstellt werden, anhand dieser sich der aktuelle Stand der „Toil“ ablesen lässt. Dabei kann es hilfreich sein, die Fragen an bereits in einem numerischen System, zum Beispiel einer Skala, einzuordnen. So entstehen vergleichbare Werte darüber, wie die Kommunikation zwischen den Teams funktioniert oder welchen Einfluss Regularien auf den Entwicklungszyklus haben. Entscheidend ist dabei die Vergleichbarkeit der Werte.

3. Der Mehrwert

Diese Vergleichbarkeit ist Grundlage für die nun folgende Priorisierung. Denn um das Verkehrsaufkommen im Entwicklungsablauf zu verringen, gilt es, die größten Hindernisse zuerst aus dem Weg zu räumen. Dazu muss auch ins Auge gefasst werden, welchen geschäftlichen Mehrwert die Apps bringen.

Mit etwas Geduld auf die Überholspur

Wer also einen agilen Entwicklungsprozess für die eigenen Apps weiter ausbauen möchte, sollte auf seine Entwickler hören. Ein Developer Toil Audit ist eine hilfreiche Methode, um die Erfahrungen der Entwickler strukturiert zu erheben, zu bündeln und die eigene Effizienz zu erhöhen.

Natürlich braucht dieser Prozess Zeit und es werden nicht alle Hindernisse auf einmal aus dem Weg geräumt. Daher gilt, es zu priorisieren und sich zuerst um diejenigen zu kümmern, die den schlussendlichen Mehrwert am meisten beeinträchtigen. Und durch die festgelegten Metriken kann stets evaluiert werden, ob die Änderungen den gewünschten Effekt erzielt haben. Daher sollte auch von Produktseite das Gaspedal nicht sofort voll durchgedrückt werden, da es im schlimmsten Fall sonst zu einem Crash kommen kann.

Wer jedoch die nötige Zeit investiert, um den eigenen Entwicklungsprozess in einem Developer Toil Audit unter die Lupe zu nehmen, profitiert am Ende. Denn die schlanken und flexiblen Apps, lassen sich in rasantem Tempo an die neuen User- und Marktanforderungen anpassen.

* Björn Brundert ist seit September 2008 bei VMware beschäftigt. In seiner aktuellen Rolle als Principal Technologist im Office of the CTO, Global Field, ist er bei VMware Teil des CEMEA-Führungsteams. Brundert soll die regionale Strategie vorantreiben und die Märkte erschließen. Er bringt Kunden und Partnern die Technologievision von VMware näher und unterstützt sie dabei, VMware-Lösungen auf ihre jeweiligen Geschäftsanforderungen abzustimmen. Zuvor war Björn Brundert als Principal Specialist Systems Engineer für die Themen Application Transformation und Cloud-Native zuständig.

(ID:48633125)