Qualitätssicherung – Umdenken für Scrum

(Kommentare: 0)

Chopins Beitrag zum gelungenen Abend)
Chopins Beitrag zum gelungenen Abend

Der Graugussrahmen eines handelsüblichen Klaviers muss Zugkräften von zwölf bis sechzehn Tonnen standhalten. In früheren Bauweisen nahm zuvor der hölzerne Stimmstock diese Kräfte von den über 200 Stimmwirbeln auf, an welchen je eine Saite aufgespannt und gestimmt ist, und gab sie an Rahmen und Rast weiter. Das barg ein gewisses Risiko: Löste sich die Verleimung, konnte sich das Instrument abrupt in einen Trümmerhaufen verwandeln. Erst Anfang des letzten Jahrhunderts setzte sich eine Bauweise durch, in der jeder einzelne Stimmwirbel in einen Holzdübel gefasst und direkt im Grauguss verankert wird. Bemerkenswert ist dabei, dass diese Konstruktion bereits 1866 entwickelt und verwirklicht wurde.
Es muss also nicht verwundern, dass auch Scrum, dessen Grundkonzepte schließlich vor über dreißig Jahren vorgestellt wurden, in größeren Unternehmen erst seit wenigen Jahren die wohlverdiente Aufmerksamkeit erhält, und die Umsetzung komplexer Vorhaben häufiger ausdrücklich für agile Methoden beauftragt wird.

Alte Faustregeln passen nicht

Während das Kaufmännische eines in Auftrag gegebenen Scrum-Projektes schon eine Herausforderung für sich darstellt, erfordert die Software-Qualität vom Lieferanten – welcher die Wirtschaftlichkeit und damit unter anderem die Teamgröße veranschlagt und verantwortet – zumindest Umdenken. Denn in typischen V-Modell-Projekten konnte man der Faustregel „Qualitätssicherung ist 50 Prozent der Entwicklung“ mit einer personellen Entsprechung unkompliziert begegnen. Bestmögliche Effizienz eines Scrum-Projektes hingegen erfordert einerseits, dass das Team groß genug ist, um hinreichend verschiedene Ansichten zu einer Fragestellung generieren zu können (Minimum drei Personen) und um alle zur erfolgreichen Umsetzung nötigen Fertigkeiten mitzubringen; andererseits soll es möglichst klein gehalten sein. Ist der zeitliche Rahmen des Projektes enger, mag von Seiten des Auftraggebers zwar zur Doppelbesetzung einzelner Bereiche, wie gerade der Qualitätssicherung, gedrängt werden; die Effizienz nimmt aber mit jeder nicht zwingend im Entwicklungsteam benötigten Person ab.

Der Verantwortung im Team gerecht werden

Warum das so ist: Für alles, und damit auch für die Qualität des Produkts, ist das Team als Ganzes verantwortlich – und nicht etwa allein das Teammitglied, dessen Spezialgebiet die Qualitätssicherung ist. Jedes Mitglied vermittelt dem Team einen Teil des eigenen Fachwissens. Auf diesem Weg kann sich jedes Teammitglied so weit in andere Gebiete einarbeiten, dass es dort unterstützen kann (T-shaped Skills). In größeren Teams lässt sich damit das Projektrisiko bei Ausfall der Fachkraft begrenzen. Vor allem aber wird vermieden, dass ein Teammitglied für sein Spezialthema als alleinverantwortlich empfunden wird oder während einer Umsetzungsphase (Sprint) aus Mangel an geeigneten Aufgaben nicht weiter zum Ergebnis beitragen kann. Die übliche anfängliche Steigerung der Teamleistung (Velocity) ist zu einem guten Teil darauf zurückzuführen, dass die Teammitglieder sich an die Projektbedürfnisse anpassen und Fertigkeiten außerhalb ihrer jeweiligen Kernkompetenz aufbauen und anwenden.

Die gemeinsame Verantwortung schwächt allerdings auch ein elementares Merkmal guter Qualitätssicherung: ihre Unabhängigkeit. Durch die Integration des Tests in das Entwicklungsteam sinkt unvermeidbar dessen Immunität gegen Betriebsblindheit bis hin zur Bereitschaft, über riskante Abkürzungen hinwegzusehen (oder sie gar selbst vorzuschlagen!). Hier kann das Risiko mit einer konsequenten Anwendung des Vier-Augen-Prinzips deutlich verringert werden: Kein Teammitglied spezifiziert Tests für den eigenen Code, und keines implementiert Tests, die es selbst spezifiziert hat.

Im und am Team arbeiten

In der Folge findet auch ein Umdenken im Team selbst statt: Bei entwickelnden Teammitgliedern ist die Tätigkeit, Testfälle zu implementieren oder gar Testfallkataloge zu erstellen, zwar eher unbeliebt; es hat sich in unserem Haus aber auch herausgestellt, dass durch die interdisziplinäre Verflechtung das gegenseitige Verständnis der Teammitglieder zunimmt. Das Miteinander der Kolleginnen und Kollegen der Bereiche Test und Entwicklung, deren weitläufig bekannter Beziehungsstatus in vielen Wasserfallprojekten mit „It's complicated“ allzu harmlos umschrieben wäre, profitiert beträchtlich vom neu gewonnenen Respekt und Einfühlungsvermögen.

Ein Selbstläufer ist das gemeinsame Erforschen, Verbessern und Aufrechterhalten der Produktqualität nicht; Scrum Master stehen regelmäßig vor der schwierigen Aufgabe, ein Projektklima zu kultivieren, das jedem Teammitglied ermöglicht, sich für alle Ergebnisse, und eben auch die Qualität derselben, verantwortlich zu fühlen. Für einige Entwicklungsteams schafft die Projekt-Infrastruktur einen engeren Zusammenhalt: Das Verweben der  Fertigungskette mit automatisierten Tests, statischen Analysen und verschiedenen Testumgebungen erfordert die Expertise beider klassischer Lager – und kommt auch beiden zu Gute.

Strategie: 10 %, …

Schlussendlich aber garantiert auch ein vollständig bedeckter Stimmstock Carl Rönischs keinen wohlklingenden Chopin, ebenso wenig wie der jährlich von Ken Schwaber aktualisierte Scrum Guide die herausragende Zusammenarbeit von Entwicklungsteams sicherstellt: Der Anklang, den Klavierspiel oder Qualitätssicherung in Scrum-Projekten finden, hängt nicht maßgeblich von der Perfektion des handwerklichen Unterbaus ab, sondern von dessen gekonntem und leidenschaftlichem Gebrauch.

Und das ganz unabhängig von Alter und Verbreitung.

Autor:

Adrian Holzwarth
Competence Lead Software Quality

 

Bildrechte: © Adrian Holzwarth

Zurück

Kommentare

Einen Kommentar schreiben