Sprinten oder stolpern? Deutsche Post setzt beim E-Postbrief auf neue agile Entwicklungsmethoden

Die Deutsche Post befördert durchschnittlich 64 Millionen Papierbriefe pro Tag und ist damit weiter unangefochtener Marktführer in Deutschland. Die Gründung der E-Post soll sicherstellen, dass dies auch in Zukunft so bleibt. Zentrales Produkt ist der E-Postbrief. Mit ihm will das Unternehmen unter dem Motto „Mehr als eine E-Mail“ die wichtigsten Vorteile des klassischen Briefs – Sicherheit, Vertraulichkeit und Rechtsverbindlichkeit – auf die digitalen Kanäle übertragen.

„Beim E-Postbrief ist Software unser Produkt“, erläutert Dirk Huberty, Abteilungsleiter Test der Plattformrealisierung der E-Post im Unternehmensbereich BRIEF der Deutschen Post. „Und auf diesem Markt müssen wir auf Kundenbedürfnisse viel schneller als gewohnt reagieren. Da darf zwischen Produktidee und Auslieferung kein halbes Jahr mehr vergehen.“ Kein leichtes Unterfangen – bei einer Produktfamilie, die sowohl für Privat- als auch Geschäftskunden inzwischen mehrere Angebote umfasst, und bei der das Entwicklungsteam rund 250 Mitarbeiter zählt.

Neue Produkte schneller am Markt

Das E-Post-Team rückte deshalb von einem Standardvorgehen ab, das sich bei der Deutschen Post in den vergangenen 20 Jahren herausgebildet hatte und Software-Entwicklung und -Test in aufeinander folgenden Blöcken vorsah: zunächst die Anforderungsdefinition, deren Test, dann die Programmierung und schließlich der umfassende Qualitätscheck der Ergebnisse durch dezidierte Software-Tester. Software-Entwicklung und -Qualitätssicherung (QS) waren grundsätzlich voneinander getrennt. Auf diese Weise war das Team in der Lage, pro Jahr jeweils zwei neue Haupt- und zwei Neben-Releases zu veröffentlichen.

Der Umstieg auf Scrum als neue Methodik der agilen Software-Entwicklung hatte vor allem ein Ziel: neue Releases alle vier Wochen veröffentlichen zu können – und zwar mit mindestens derselben Qualität wie zuvor. Mittlerweile kann die Deutsche Post sogar alle zwei Wochen neue E-Postbrief-Funktionen an die Kunden ausliefern. Die Entwicklung der Systemkomponenten erfolgt dabei in sogenannten „Sprints“, in denen kleine Teams von maximal fünf Mitarbeitern gleichzeitig entwickeln und testen. So durchläuft die Software-Entwicklung heute nicht mehr längere, in sich abgeschlossene Phasen, vielmehr finden die verschiedenen Entwicklungs- und Testschritte in kleinen Teams ständig, simultan und in kontinuierlichen Verbesserungsschleifen statt.

Diese grundlegende Umstellung hatte natürlich auch gravierende Auswirkungen auf die Organisation des Software-Testens, das nun simultan mit der Programmierung in den einzelnen Sprints erfolgt, bevor integrative Tests nach den Sprints das Zusammenspiel der neuentwickelten Komponenten überprüfen. „Die größte Herausforderung bestand darin, das Testen in den parallelen, stets rotierenden Zyklus der agilen Software-Entwicklung einzupassen“, berichtet Huberty. „Deshalb ist ein Mitglied jedes unserer Sprint-Teams ein Testprofi, der längere Erfahrungen in der Qualitätssicherung mitbringt.“ Denn eine gute Methodik des Software-Testen sei im Rahmen von Scrum noch wichtiger als bei herkömmlichen Verfahren. „Ohne professionelles Testvorgehen könnten wir die kurzen Sprint-Zyklen gar nicht realisieren“, so Huberty.

Erfolgsfaktor Software-Testen

Die Basis für eine durchgängige Testmethodik legte beim E-Postbrief unter anderem SQS Software Quality Systems. Die Berater und Tester des Spezialisten für Software-Qualität holte Huberty schon vor dem Einstieg in die agile Welt mit ins Boot. Durch Umstellung des Software-Testens auf eine übergreifende und durchgängige Methodik konnte die Deutsche Post recht schnell sogenannte „Quick Wins“ erzielen: Während Kosten und Zeitaufwand für die QS sanken, stieg die Qualität der Systeme. Der Grund: Mit weniger Testobjekten erreichten die Teams nun eine höhere Testabdeckung. Musste die Deutsche Post zunächst noch rund 9.000 Testfälle pro Release durchspielen, sind es heute nur noch 1.500. Dadurch schaffte SQS beim E-Postbrief-Team auch gute Voraussetzungen für den Umstieg auf Scrum, das auf schlanke und schnelle Testzyklen angewiesen ist.

Huberty widerspricht deshalb auch der oft geäußerten Auffassung, dass in der agilen Welt Software-Tester an Bedeutung verlören, weil die QS von den Entwicklern in den Sprints quasi miterledigt werde. „Wir brauchen in allen Sprints einen Kollegen mit fundiertem Test-Know-how, der nur eben viel enger mit den Programmierern zusammen arbeitet als zuvor. Auch mit Scrum macht nicht jeder alles, ich brauche auch weiterhin zum Beispiel Datenbank- oder Testexperten. Auch wäre es ein Fehler, Tester funktionalen Code schreiben zu lassen, denn dadurch würden wir das für die Qualität sehr wichtige Vier-Augen-Prinzip aufgeben. Wenn die Software-Prüfer Code schreiben, dann nur für den Aufbau von Testsystemen oder die Testautomatisierung.“

Durch die enge Kooperation in den Scrum-Teams ist laut Huberty das Software-Testen zum integralen Bestandteil der Software-Entwicklung geworden und nicht mehr nur ein nachgeschobenes Kontrollgremium. Software-Qualität sei nun von Anfang an mit eingebaut. „Diese frühe und vorbeugende Qualitätssicherung ist bares Geld wert“, ist sich der Projektleiter sicher. „Alle Lehrbücher sagen, dass 60 Prozent der Software-Fehler auf inkonsistenten Anforderungen am Anfang der Entwicklung beruhen. Heute bauen wir diese Fehler durch die intensive Zusammenarbeit zwischen Entwicklern und Testern in den Sprints erst gar nicht mehr ein. So müssen wir sie später auch nicht mehr mit großem Aufwand ausbauen.“

Testen von Anfang an

Heute kommen auf vier Entwickler in den einzelnen Sprints ein Tester, ein „Product Owner“ sowie ein „Scrum Master“. Neben den Entwickler- und Funktionstests laufen zum Beispiel auch Performance-Tests parallel zur Entwicklung, wenn auch nicht komplett. Abschließende Ende-zu-Ende-Tests sind auch beim agilen Vorgehen unverzichtbar. Doch die wichtigsten Aussagen lassen sich auch schon mit Metriken aus der Entwicklung ableiten – wie bei einem neuen Automodell: Abschließende Tests des zusammengebauten Wagens sind ein Muss, erste Vorabmodelle lassen sich aber auch schon in den Windkanal stellen. Die daraus abgeleiteten Ergebnisse bewahren die Entwickler schon früh vor vielen teuren Irrwegen. Auf diese Weise ist es möglich, dass das Team des E-Postbriefs die abschließenden Integrationstests heute innerhalb von fünf Tagen durchführt.

Als größte Herausforderung beim Übergang von traditionellen zu den agilen Entwicklungsmethoden von Scrum erwies sich am Ende das Überführen der Teammitglieder in die neue Welt. An den Mitarbeitern entschied sich, ob das agile Vorgehen zu einem Sprint oder einem Stolpern werden würde. Die Programmierer, Fachexperten und Software-Tester hatten es schließlich nicht nur mit neuen Methoden und anders organisierten Arbeitsprozessen zu tun. Vielmehr änderte sich ihr tagtägliches Tun, ihre neuen Rollen verlangten veränderte Fähigkeiten und zusätzliches Know-how. Beispiel Software-Tester: Bislang gab es einen Testmanager, der vonseiten der Qualitätssicherung mit den anderen Projektbeteiligten kommunizierte, sowie sein Team aus funktionalen und technischen Testern. Heute müssen die Tester in den Sprint-Teams all diese Aufgaben alleine erledigen und brauchen darüber hinaus noch mehr Entwicklungs-Know-how als bisher.

„Software-Tester mit solch vielfältigen Fähigkeiten sind nur sehr schwer am Markt zu finden“, berichtet Dirk Huberty, „das bekommen Sie nur mit Ausbildung hin.“ Gleiches galt für den Testdienstleister SQS, der bei der Umstellung auf Scrum seine Testmanager und spezialisierten Fachtester auf agile Vorgehensweisen schulte – zum Teil durch SQS-interne Trainings, überwiegend jedoch im gemeinsamen Schulungsprogramm mit der Deutschen Post. Dies hatte den Vorteil, dass jene Fachkräfte, die heute in den Sprints zusammen arbeiten, sich schon beim gemeinsamen Lernen kennenlernen und aufeinander einstellen konnten. „Darüber hinaus ist zum Teil auch eine individuelle Begleitung der so geschulten Tester notwendig“, ergänzt Petra Bukowski als SQS-Projektverantwortliche bei der Deutschen Post, „denn die Veränderung der Rollen gerade in punkto Kommunikation und Verantwortung sind schon beträchtlich.“ Eine weitere Erfahrung sei es, fünf auch einmal gerade sein zu lassen: „Die Lehre der agile Software-Entwicklung ist wichtig und hat bei der Deutschen Post zu einem großen Produktivitätsplus geführt. Da Scrum aber vor allem in Kleinprojekten entstand und Großprojekte zum Teil ganz anders ticken, muss man manchmal auch ganz bewusst und pragmatisch von der reinen agilen Lehre abweichen.“

Die heute viel schnelleren Produktzyklen bei weiterhin hoher Software-Qualität haben Dirk Huberty zu einem überzeugten Vertreter agiler Methoden gemacht. Zu Beginn des Umstiegs hatte er häufiger Zweifel. So hielt er zum Beispiel den hohen Testautomatisierungsgrad von heute über 90 Prozent  zunächst für nicht möglich. Noch vor zwei Jahren galten im Entwicklungsteam des E-Postbriefs 65 Prozent als sehr guter Wert. „Das Prinzip von Scrum ist es letztlich, Dinge in Frage zu stellen und gemeinsam nach der besten Lösung zu suchen“, fasst Huberty zusammen. „Endgültige Wahrheiten und Regeln gibt es nicht mehr. Auf diese Weise kann das, was heute gut ist, morgen noch besser werden.“

Der E-POSTBRIEF: Mit dem E-Postbrief ermöglicht es die Deutsche Post Privatkunden, Unternehmen und Verwaltungen, zuverlässig, vertraulich und rechtsverbindlich elektronisch zu kommunizieren. Die Kunden des E-Postbriefs können untereinander über ein verschlüsseltes Webportal elektronische Nachrichten als Online-Brief versenden. Ist der Empfänger eines E-Postbriefs kein Kunde des Dienstes, wird die Nachricht von der Deutschen Post ausgedruckt, kuvertiert und per Postbote zugestellt. 

 

 

 

 

RSS Feed

Entdecken Sie die Printmagazine des WIN-Verlags