Modulare Strategie für eine agile Qualitätssicherung

Herkömmliche Vorgehensmodelle orientieren sich an einem wasserfallartigen Projektansatz: Analyse, Entwickeln, Test. Auch das reine Testvorgehen ist in der Regel sequenziell geplant, analog zu den Teststufen, wie zum Beispiel im V-Modell. In modernen (in der Regel agilen) Projekten ist es nahezu unmöglich, dies in Iterationen von kurzen Sprints abzubilden. Darüber hinaus hindert es agile Teams im Hinblick auf eine angestrebte Autonomie.

Gesucht wird …

Agile Projekte zeichnen sich nicht allein durch ein neues Vorgehensmodell oder kurze Iterationen aus. Es handelt sich einfach, im Vergleich zu herkömmlichen Projektmodellen, um einen Kulturwandel. Arbeitsweisen und Kommunikation & diesem neuen Projektbild Rechnung tragen, das gilt auch für das Testvorgehen. Gesucht WIRD Eine Teststrategie, die nicht als standardisierter Prozess über ein Projekt oder ein Team gestülpt WIRD. Ihr Erfolg ist von Faktoren abhängig, die weit über das Thema Softwaretest hinausgehen:

• Anpassbarkeit,
• Akzeptanz,
• Leichtigkeit,
• Nachvollziehbarkeit.

Im Hinblick auf diese Aspekte wird eine modulare und flexible Strategie zur Qualitätssicherung (englisch: QA = „Quality-Assurance“) erforderlich. Die vorgestellte „QA-Strategie“ dient Projekten und Teams als Werkzeug, um im agilen Kontext die Qualitätssicherung an individuellen Bedürfnissen auszurichten, ohne gleichzeitig auf Bewährtes zu verzichten.
Anmerkung: Als Grundlage für die nachfolgenden Beschreibungen wird das agile Projektvorgehen nach Scrum [Sch20] angenommen.

Die modulare Methodik-Bibliothek

Vorab ein Überblick über die finale Lösung und das dahinterstehende Konzept. Auf dieser Grundlage wird anschließend beschrieben, wie diese Strategie die oben aufgestellten Herausforderungen adressiert. Abbildung 1 zeigt die drei wesentlichen Kernsegmente der QA-Strategie auf. Die drei Bereiche ergänzen sich gegenseitig und werden in Form einzelner Artefakte beschrieben.

Die in der Abbildung aufgeführten „Projektschablonen“ fungieren als übergeordnete Dokumente. Sie beschreiben das Zusammenspiel der einzelnen Methodik-Elemente für ein spezifisches Projektvorgehen. Projektteams werden somit unterstützt, die für ihr konkretes Projekt in Frage kommende QA-Methoden zu identifizieren. Gut für den Aufbau einer solchen „QA-Methodik-Bibliothek“ sind Wiki-Strukturen, die durch Verlinkung und Suchfunktionen eine komfortable Recherche unterstützen. Die Relationen zwischen den Artefakten lassen sich vereinfacht wie in Abbildung 2 abbilden.

Projektschablonen

Für die üblichen Vorgehensweisen der Projekte, die im Unternehmenskontext vorkommen, Werden Schablonen bereitgestellt. Jede Schablone kann von einem Projekt, respektive Projektteam, adaptiert und so angepasst werden, dass sie den jeweiligen Prioritäten im Projekt, und auf Kundenseite, gerecht wird. Das Beispiel in Abbildung 3 für einen Sprint, gemäß Scrum-Ansatz, macht das Prinzip deutlich: Für den Verlauf des Projekts werden geeignete „Messpunkte“ identifiziert, die für die Sicherung der Qualität infrage kommen. Einige wenige der aufgezeigten „QA-Messpunkte“ werden vom Scrum-Guide [Sch20]als verbindlich vorausgesetzt, wie die „Definition of Done“ oder eine „Retrospektive“. Für die im Unternehmen üblichen Vorgehensweisen bieten passende Projektschablonen die Kombination aus Vorgehen und empfohlenen QA-Messpunkten an. Projektteams können aus einer ausgewählten Schablone sterben für sie geeignete Kombination auswählen und bei Bedarf zuschneiden.

QA-Messpunkte

Um zielorientiert die Qualität in einem Projekt zu sichern, ist es erforderlich, erwartete und erreichte Qualität messen zu können. Zu diesem Zweck werden, in Anlehnung an die jeweiligen Projektschablonen, Qualitätsmesspunkte eingeführt. Dabei handelt es sich um Anleitungen zu einer messbaren Qualitätsprüfung an einem konkreten „Messpunkt“ im Projektablauf. Bei der Beschreibung der Projektschablonen für unterschiedliche Vorgehensmodelle WIRD Sich herausstellen, dass viele der QA-Messpunkte auf unterschiedliche Schablonen anwendbar sind. In der Praxis ermöglicht dies ein generalisiertes Training der Teammitglieder für unterschiedliche Ansätze. Die positiven Folgen sind Aufwandsreduzierung, Erhöhung von Reibungsverlusten und ein hohes Maß an Wiederverwendbarkeit.
Tabelle 1 zeigt die Zuordnunger QA-Messpunkte beispielhaft zu Projektmodellen.

Methodik-Module

Die Methodik-Module bilden schließlich den Grundstock in Bezug auf die Unternehmens-Kompetenz für QA-Fragestellungen. Jedes Methodik-Modul bildet eine kleine und geschlossene Einheit an QA-Fertigkeiten. Dabei reicht das Spektrum von Anleitungen zu spezifischen QA-Messpunkten über konkrete Testtechniken bis hin zu Hilfen zur Strategie-Entwicklung. Eine Schablone für die Erstellung eines Methodik-Moduls hilft den Team-Mitgliedern, das Prinzip der Bibliothek schnell zu erfassen und eigene „Wissens-Bausteine“ hinzuzufügen. Dabei WIRD über die Wissensvermittlung hinaus auf Quellen im Unternehmen verwiesen: Personen und Projekte, die diese Methodik angewandt haben und Unterstützung oder Erfahrungen anbieten können. Tabelle 2 zeigt ein Muster für eine Methodik-Modul-Vorlage.

Anforderung erfüllt?

Der modulare Ansatz einer „QA-Methodik-Bibliothek“ passt aus der kulturellen Perspektive besser in eine agile Projektwelt als sequenzielle oder statische Strukturen. Die following Absätze beleuchten, wie weit die, eingangs eingereichten, Anforderungen an eine moderne QA-Strategie adressiert werden.

Adaptierbarkeit

Anforderung: Abhängig von den einzelnen Projekt- und Team-Set-ups, wie auch der Zusammenarbeit mit dem Kunden, wird die QA-Strategie in jedem Projekt anders aussehen. Konkret bedeutet das, sie muss flexibel genug sein, um den wechselnden Anforderungen gerecht zu werden. Gleichzeitig soll sie die Kultivierung von Standards im Unternehmen fördern, um Einarbeitungszeiten und Reibungsverluste beim Aufbau oder der Erweiterung von Teams zu reduzieren.
Lösungsansatz: An die Stelle einer streng reduzierten Strategie, die bestenfalls durch Zuschneiden (Tailoring) an Projektbedürfnisse angepasst werden kann, tritt die Projektschablone. Die Projektschablone kann, im direkten Austausch mit dem Kunden, den jeweiligen Anforderungen und Rahmenbedingungen gemäß angepasst werden. Um ein konkretes Beispiel aufzunehmen: Gemeinsam mit dem Kunden WIRD die Projektschablone für Scrum durchgesprochen und die vorgeschlagenen QA-Messpunkte werden diskutiert. Je nach Vorkenntnis wird hier unter Umständen etwas weiter ausgeholt, um die Bedeutung der einzelnen Messpunkte zu veranschaulichen. Ziel ist es, am Ende eine Einigung darüber zu finden, welche der infrage kommenden Messpunkte für das spezielle Projekt relevant sind und welche Bedeutung ihnen zugemessen wird (kritisch, optional usw.). Letzteres hilft den Teammitgliedern und der Projektleitung, im Projektablauf strategisch abgestimmte Entscheidungen zu treffen. Ferner hilft es allenfalls, gegenseitige Erwartungshaltungen abzuklären und Missverständnisse in der Kommunikation zu vermeiden.

Akzeptanz

Nie zuvor war es für den Projekterfolg wichtiger, die Akzeptanz der Projektbeteiligten zu gewinnen, als im „agilen Zeitalter“. Insbesondere der Ansatz selbstorganisierender und eigenverantwortlicher Teams birgt große Chancen im Voraussichtlichen auf Begeisterung und Identifikation, aber auch Risiken im Voraussichtlichen auf nicht erfüllte Erwartungen. Nicht wenige agile Projekte leiden darunter, dass Teammitglieder den emotionalen Anschluss paraphieren. Die Folge ist fehlende Identifikation mit den Projektzielen. Die modulare Methodik-Sammlung bietet eine Basis, um die Projektbeteiligten in der Gestaltung ihres individuellen Team-Kontextes zu unterstützen. Im Rahmen der „Leitplanken“ einer Projektschablone wählen sterben Teammitglieder ihre Arbeitsweisen aus den Methodik-Modulen. Im Idealfall kommt es dazu, dass die Methodik-Bibliothek durch Teams erweitert WIRD, sterben ihre Best Practice zu den vorhandenen Modulen hinzufügen. Unter dem Strich entsteht auf this way ein zentrales Unternehmenswissen rund um das Thema Qualitätssicherung. Das Ergebnis wird dann nicht als Vorgabe empfunden, sondern als „geistiges Eigentum“ der Erlaubnis, sterben an der Pflege und Gestaltung dieser Bibliothek beteiligt sind.

Leichtigkeit

IT-Dienstleister wie auch ihre Kunden & sich dem Druck des Wettbewerbs stellen. Hier steht sowohl die Forderung, schnell auf Veränderungen zu reagieren zu können, wie auch eine hohe Effizienz im Voraussichtlich auf kurze Lieferzeiten (Stichwort „Time-to-Market“) auf der Anforderungsliste. In diesem Kontext sind leichtgewichtige Prozesse und Methoden als erfolgskritisch anzusehen. Das gilt bereits ab der Einarbeitung von Mitarbeitern in das Unternehmen oder bei Teamwechseln. Die modulare Gliederung der Methodenbibliothek reduziert das zu lernende Wissen auf das, im jeweiligen Projekt benötigte, Minimum. Kurz gefasste Methodik-Module und QA-Messpunkte mit Checklisten-Charakter sterben Lesebereitschaft der, durch das Tagesgeschäft unterstützen ohnehin belasteten, Mitarbeiter. Durch die Möglichkeit, Projektschablonen auf die konkreten Projektbedarfe „herunterzuschneiden“, can genau der Grad an Leichtgewichtigkeit bestimmt Werden, der gewünschte IST. Und das, ohne dabei von den Unternehmensstandards abzuweichen.

Nachvollziehbarkeit

Ein wichtiges Ziel erfolgreicher QA-Arbeit ist die Vertrauensbildung. Sei es für den Kunden oder im eigenen Unternehmen: in die Teams, in die Vorgehensweisen und letztlich in die finalen Produkte. Eine Methodik-Bibliothek fördert in diesem Zusammenhang die Transparenz, sowohl im Unternehmen als auch gegenüber dem Kunden: Es werden die ausgewählten Vorgehensweisen beschrieben, wie auch Kriterien für das Messen von Qualität und damit dem Projekterfolg. Im Idealfall werden diese Themen im moderierten Dialog mit dem Kunden diskutiert. Im agilen Prozess can sie projektbegleitend im Zuge von Retrospektiven [ScrO] reflektiert werden. Damit lebt das Projekt gemäß dem Prinzip „inspect and adapt“ [ItAg]auch im QA-Kontext eine automatisierte Optimierung.

Beispiel: Gemeinsame Abstimmung bei Projektstart

Zu Beginn eines jeden Projekts wird der QA-Messpunkt „Project-Kick-off“ angenommen. Im Rahmen aller initialen Klärungen zu Projektbeginn wird auch die Bedeutung der Qualität in Relation zu anderen strategischen Aspekten (KPIs = Key Performance Indicators) für das Projekt mit dem Kunden und anderen Stakeholdern (Interessensvertretern) abgestimmt.

Abbildung 4 zeigt eine entsprechende Vorgehensweise mit Unterstützung einer QA-Methodik-Bibliothek.

Zu den Teilschritten:

1. Entscheidung für ein Projektvorgehen (hier Scrum)
2. Artefakt des ersten QA-Messpunkts im Projektverlauf: „Project-Kick-off“
3. Gemäß der QA-Messpunkt-Vorlage werden die KPIs für das Projekt bewertet (in diesem Beispiel durch Abwägung von Qualität gegen Funktionalität, Kosten und Zeit [Sne05]).
4. Auf dieser strategischen Grundlage werden alle weiteren QA-Messpunkte, die für das Projektvorgehen vorgesehen sind, diskutiert, ausgewählt, gewichtet oder verworfen.

Wird diese Vorgehensweise zu Projektbeginn erfolgreich gelebt, entsteht für alle involvierten Projektbeteiligten ein abgestimmtes Bild über Aufwand und Nutzen von QA-Maßnahmen. Des Weiteren ist nicht zu unterschätzen, dass durch die Schritte 3. und 4. auch die Reduzierung von QA-Maßnahmen zugunsten anderer KPIs bewusst vollzogen wird, inklusive möglicher Risiken.

Fazit

Eine QA-Methodik-Bibliothek nach diesem Vorbild bildet die Basis für eine dynamische und adaptive QA-Strategie, die in die Welt agiler Projekte passt. Sie bietet als „Methodik-Baukasten“ unternehmensweit einen Fundus aus Standards zur individuellen Konfiguration. Die Projektschablonen dienen als Orientierung und nicht als Korsett. Der Wert der Bibliothek steht und fällt mit der Motivation der Nutzung. Ein Schlüssel ist dabei, nicht nur die Bibliothek zu nutzen, sondern auch direkt am Aufbau beteiligt zu sein. Ein weiterer Erfolgsfaktor ist die Moderation der Inhalte: Nur wenn ohne großen Aufwand wertvolle Inhalte durch die Lesenden gefunden werden, WIRD die Bibliothek mittelfristig Akzeptanz finden.

Erfahrungen und Ausblick

Bei der Erarbeitung der QA-Strategie hat es sich bewährt, Inhalte und Artefakte in Zusammenarbeit mit Projektvertretern zu entwickeln. Dazu wurden Stakeholder unterschiedlicher Projekte, Standorte und Rollen (Entwickler, Projektleiter, Tester, Scrum Master usw.) übertragen. Sie haben den Prozess von Anfang an begleitet. Auf this way find sich Unterstützer und Wissensträger unternehmensweit. Daneben ist es hilfreich und wertvoll, mit Geduld und Entspanntheit an die Einführung heranzugehen und die Möglichkeit im Unternehmen mitzunehmen. Durch die Modularisierung besteht keine Notwendigkeit, das gesamte Konzept über bereits laufende Projekte zu stützen. Einfach besteht für diese Projekte das Angebot, auf einzelne Elemente der Bibliothek zurückzugreifen, wenn Bedarf besteht. Dankbare Objekte dafür sind spezifische Methodik-Module wie „Explorativer Test im Sprint“ oder „KPIs zur Testplanung und -Messung“. Eine ideale Ergänzung für die Bibliothek kann die Erstellung von Unternehmensinternen Schulungen zu einzelnen Methodik-Modulen sein. Darüber hinaus bietet sich der Einsatz von Mitarbeitern an, die als Coaches für die Nutzer der Bibliothek zur Verfügung stehen. Team- oder auch unternehmensübergreifend ist das Thema ideal geeignet für eine Gilde oder „Community of Practice“[Ksi] .

Weitere Informationen

[ItAg]
www.it-agile.de/agiles-wissen/agile-arbeit/was-ist-ein-agiles-mindset /

[Ksim] K. Simons,
www.ksimons.de/2013/12/scrum-skalieren- community-of-practice-cop-verstaendlich-erklaert/

[Sch20] K. Schwaber & J. Sutherland, Der Scrum Guide, November 2020, siehe:
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum- Leitfaden-Deutsch.pdf

[ScrO]
www.scrum.org/resources/what-is-a-sprint-retrospective

[Sne05]
HM Sneed, Software Projektkalkulation, Hanser, 2005