Qualität = gutes Handwerk + viel Fleiß?

Software ist gut, wenn der Kunde keine Hotline benötigt. Worum es in diesem Artikel geht, ist zu vermitteln, dass Qualität ein aufwändiges Handwerk ist. Gute Qualität basiert auf handwerklichem Fleiß und guten Methoden und Werkzeugen. Der nachfolgende BLOG-Beitrag gibt einige Eindrücke, was eine zeitgemäße Qualitätssicherung in der Softwareentwicklung in der Praxis leisten muss.

Bereits in den 1990er Jahren wurde bei BMW in Regensburg aus der Qualitätssicherung allen Mitarbeitern bewusst gemacht, dass Qualität beim Forschungs- und Entwicklungsingenieur beginnt, in der Produktion fortgeführt werden muss und nicht alleine in der QS-Abteilung am Ende der Leistungskette erzielt wird. Je später ein Fehler erkannt wird, umso teurer ist es, diesen Fehler zu beseitigen. Je komplexer die Lösung, desto unwahrscheinlicher, dass ein System fehlerfrei ist. Was kann man gegen Fehler tun?

Auch in der Softwareentwicklung setzt man auf eine Qualitäts-Kultur und ein durchgängiges QS-Konzept. Agile Entwicklung gibt Methoden und Werkzeuge vor, mit denen eine hohe Qualität sichergestellt werden soll und kann. Als wichtiger Bestandteil von Qualität in der Softwareentwicklung hat sich mit den agilen Methoden UX (User eXperience) etabliert. Dabei geht es darum die (potenziellen) Nutzer der Software und Ihre Nutzungseindrücke bei der Bedienung der Software bereits im Designprozess zu berücksichtigen und Kunden hierzu frühzeitig in den Produktionsprozess (Software-Entwicklungsprozess) einzubinden. Dies macht man u.a. mit sogenannten User Journeys. Dabei werden (auch bereits mit Prototypen) Nutzer mit der „Anwendung konfrontiert“ und Ihre Reaktion zur Anwendung erfasst und für die weitere Entwicklung ausgewertet. Gemeinsam mit dem Entwicklerteam diskutiert und für die beste Lösung in User Stories (die Tickets, in denen für die Entwickler beschrieben wir, was die Software wie zum User darstellen soll und was im Hintergrund dazu zu verarbeiten ist) umgesetzt und implementiert. Ziel ist, aus Sicht des Kunden (und nicht aus Sicht des Entwicklers!) eine möglichst einfach, intuitiv bedienbare Software zu gestalten.

So arbeitet tuesday.sport für die digitale Vereinsverwaltung. Ferner wird ein Modul erst nach einem dreistufigen QS-Verfahren für den Echtbetrieb (live) freigegeben. In der ersten Stufe gibt das Entwicklerteam nach (Großteils automatisierten) Tests auf dem Entwicklungsserver frei. Anschließend wird die Anwendung auf einem Testsystem für die Tests durch die sogenannten Product Owner (PO) überspielt.

Wenn die PO zum Abschluss des Entwicklungsprozess die Tests erfolgreich beendet haben, wird die Anwendung mit dem Service „verprobt“, um sicherzustellen, dass keine „Servicefallen“ zu unnötig vielen oder komplexen Servicefällen und damit zu unzufriedenen Kunden führen. Im tuesday-Modell zur Qualitätssicherung werden in dieser Phase auch erste „entwicklungsnahe“ Vereine eingebunden, um ein Feedback aus der Praxis zu erhalten. Erst wenn dieser Schritt positiv durchlaufen ist, dann wir die Anwendung für alle Kunden zur Nutzung freigegeben.

Einfache Bedienbarkeit, Komplexität vor dem Anwender – so weit es geht – zu verstecken und Vereinsfunktionäre und Mitarbeiter zu entlasten steht im Vordergrund der QS-Kultur und -Bemühungen. Das Zielbild dieses Aufwands ist ein zufriedener Anwender.

Ob das klappt, stellt sich nach der Freigabe an Hand des tatsächlichen Servicebedarfs heraus. Was hier wirklich hilft, ist, wenn die Anwender die bereitgestellten Hilfestellungen zur Anwendung und das Serviceangebot zur Anwendung nutzen. Aber das ist eine andere, eine neue Geschichte für den BLOG… ein anderes mal.

Danke für die Aufmerksamkeit und viel Spaß bei der hoffentlich zufriedenen Anwendung von SportStart. ..

mit sportlichen Grüßen
Euer

tuesday.sport Entwicklerteam