Best Practice: So lassen sich kurze Software-Release-Zyklen umsetzen

Neue Software, aber bitte schnell! Unternehmen, die Software-Entwicklung und -Services anbieten, stehen immer häufiger vor dieser Anforderung. Die Art und Weise, wie Software bereitgestellt wird, verändert sich gerade grundlegend. Agile Methoden und Continuous Delivery (CD) haben deren Entwicklungszyklus bereits enorm beschleunigt. Doch es geht noch mehr: Wöchentliche bis hin zu täglichen Software-Releases werden zum Standard. Basierend auf einem Beispielprojekt aus der Automobilindustrie beschreibt der Artikel, wie sich die Softwareentwicklung mit Hilfe von agilen Methoden beschleunigen lässt.

Schnell, schneller, am schnellsten: 17 Full Releases in 8 Wochen

Bei dem Projekt geht es um eine digitale Customer-Experience-Plattform, mit der  Automobilprodukte vermarktet werden. Tausende Nutzer weltweit haben Zugang. Um die vereinbarten Deadlines einzuhalten, mussten wir die kundenspezifische Software mit allen erforderlichen Funktionen schneller bereitstellen. Als sich das Projekt dem Go-live näherte, wurde klar, dass die noch anstehenden Aufgaben nicht innerhalb der regulären dreiwöchigen Software-Release- und Test-Zyklen abgeschlossen werden konnten. Erschwerend kam hinzu, dass die Senior-Projektmitglieder, die das Projekt seit dem Start begleitet hatten, das Unternehmen verließen. Die verbleibenden Teammitglieder standen vor der Herausforderung, sich das notwendige Wissen über das Projekt und die Produkte schnellstmöglich anzueignen. Das ging über die reine Programmierung hinaus und betraf das Unternehmen sowie die Zusammenhänge zwischen den verschiedenen Rollen im Team. Es war klar, dass das eigentlich Zeit brauchen würde, die wir jedoch nicht hatten. Stattdessen forderte der Kunde - und gleichzeitig Product Owner - wöchentliche Software-Releases einschließlich neuer Funktionen. Auf den ersten Blick schien das kaum machbar. Das Team sah es als Herausforderung: Es bedeutete 17 Releases in acht Wochen! Um das zu erreichen, mussten wir einiges ändern.

Konzentration auf vier Schwerpunkte

Die neue Anforderung des Kunden lautete: "Implementieren Sie neue Funktionen, während Sie in der Entwicklungs- und Testphase regelmäßig Rückmeldungen vom Product Owner sowie den Support- und Testteams erhalten."
Um das umzusetzen, identifizierten wir folgende Schwerpunkte, auf die wir uns im weiteren Projektverlauf konzentrierten:

Fokus auf die Entwicklung neuer Funktionen

Kürzere Release-Zyklen betreffen unter anderem das Programmieren. Die Code-Basis war so groß, dass es ein No-Go war, direkt mit dem Programmieren zu beginnen. Die Code-Basis umfasste nicht nur Java, sondern auch die neuesten Frontend-Technologien. In mehreren Brainstorming-Sitzungen haben wir uns die verschiedenen Features zunächst gemeinsam erschlossen.

Dem heutigen Standard entsprechend muss die Plattform von jedem Endgerät zugänglich sein. Nachdem wir uns mit dem Front-End beschäftigt hatten, traten Probleme mit der Darstellung auf. Diese haben wir mit dem beliebten Mobile-First-Front-End-Framework Bootstrap gelöst – und damit zusätzlich unsere Produktivität gesteigert. Eine der besten Entscheidungen in dieser Phase war das „Pair Programming“. So konnten wir den Wissenstransfer im Team sichern.  

Direkte Kommunikation mit dem Kunden

Fragen, fragen und nochmals fragen - das hatte der Product Owner ganz klar verlangt und uns gemeinsam mit dem Scrum Master Unterstützung angeboten. Alle Teams waren aufgefordert, Probleme schnellstmöglich direkt anzusprechen. Dies steht im Gegensatz zur traditionellen Art der Kommunikation, bei der die Teams manchmal zögern, sich mit Fragen direkt an den Kunden oder Product Owner zu wenden. Der Hintergrund ist die geänderte Anforderung, neue Funktionen zu implementieren und gleichzeitig regelmäßige Rückmeldungen zu erhalten. Diese direkte Kommunikation war von großem Vorteil und beschleunigte den Entwicklungsprozess.

Lösungsorientierung

Neben der Entwicklung neuer Features mussten wir uns auch um das bestehende System kümmern. Die anfallenden Fehlermeldungen umfassten somit beides. Wir entschieden uns für folgendes Vorgehen: Wir identifizierten kritische Fehler, bewerteten sie nach Priorität und bearbeiteten sie im Rahmen der laufenden Sprints. Da sich der zusätzliche Aufwand auf die geplanten Sprints auswirkte, informierten wir den Product Owner regelmäßig darüber. Einige Fehler haben wir mit möglichst geringem Zeitaufwand parallel zu den regulären Sprints behoben. Statt dabei zu tief in die technischen Details einzusteigen, konzentrierten wir uns darauf, die anstehenden Aufgaben zu erledigen und Lösungen zu finden.

Kommunikation und Zusammenarbeit zwischen den Teams

Die Interaktion zwischen den verschiedenen Teams stellte sich als grundlegend wichtig heraus. Wir nutzten alle Arten von Kommunikationskanälen, zum Beispiel Messenger-Dienste, E-Mail, Telefon und virtuelle Meetings. Dabei entwickelte sich der Messenger zum primären Kommunikationsmedium zwischen unseren Software- und den L2-Support-Teams. Unklarheiten oder For-Your-Information-Meldungen wurden auf Messenger gepostet, sodass Entwicklungs- und Test-Team sich immer gut erreichen und gegenseitig informieren konnten. Das trug zum schnellen Lösen von Problemen bei.  Zudem hat unser Projektbüro die Zusammenarbeit wesentlich gefördert. Wir konnten konzentriert und gemeinsam in einem Raum an den Problemen arbeiten, alle Experten waren direkt greifbar.

Prozesse optimiert und zukunftsfähig gemacht

Die Forderung nach wöchentlichen Software-Releases bedeutete für uns als Dienstleister, unsere Methoden und Prozesse sehr schnell auf den Prüfstand zu stellen – und einiges zu ändern. So konnten wir den Erwartungen des Kunden gerecht werden und haben gleichzeitig unsere Software-Entwicklungsprozesse optimiert und zukunftsfähig gemacht. Möglich war das, indem wir uns auf vier Bereiche konzentriert haben: Fokus auf die Entwicklung neuer Funktionen, direkte Kommunikation mit dem Kunden, Lösungsorientierung sowie Kommunikation und Zusammenarbeit zwischen den Teams.