Qualitätssicherung in verteilten Entwicklungsprojekten

Qualitätsprobleme bei verteilter Lieferung werden meist der Distanz zugeschrieben. Die Distanz ist selten die Ursache. Was Distanz tut, ist Lücken sichtbar machen, die ein Team am selben Ort mit informellen Gesprächen überdeckt hat.

Wurde «fertig» nie aufgeschrieben, verhandelt ein Team am selben Ort es an einem Schreibtisch. Ein verteiltes Team kann das nicht, also wird aus der Unschärfe ein Fehler. Die Abhilfe ist, die Lücke zu schliessen — nicht, die Distanz zu verkürzen.

«Fertig» vor Arbeitsbeginn definieren, nicht im Review

Das ist die ertragreichste Praxis und die am häufigsten übersprungene — weil sie nach Bürokratie aussieht, bis zur ersten Diskussion darüber, ob etwas abgeschlossen ist.

Eine brauchbare Definition of Done ist konkret und prüfbar:

• Abnahmekriterien als Szenarien formuliert, nicht als Adjektive — «das System geht mit ungültigen Eingaben angemessen um» ist nicht prüfbar
• In welchen Umgebungen es funktionieren muss, einschliesslich der Sonderfälle, die für Ihr Geschäft zählen
• Nicht-funktionale Erwartungen genannt: Antwortzeit, gleichzeitige Nutzende, Datenmengen
• Dokumentation und Testnachweise enthalten, nicht mitgemeint

Die Prüfung: Könnte jemand, der nicht im Gespräch war, es verifizieren? Wenn nein, haben Sie eine geteilte Annahme statt einer Spezifikation — und geteilte Annahmen überstehen keine Zeitzonengrenze.

Qualitätsverantwortung liegt beim bauenden Team

Das zuverlässig scheiternde Muster ist eine getrennte QA-Funktion, die fertige Arbeit entgegennimmt und darin Probleme findet. Sie erzeugt eine Warteschlange, verzögert die Rückmeldung und lädt das bauende Team ein, Qualität als fremde Zuständigkeit zu behandeln.

Was funktioniert: Qualität dort verantwortet, wo die Arbeit entsteht, mit einer Fachrolle, die die Fähigkeit des Teams hebt statt dessen Ergebnis zu inspizieren — Teststrategie entwerfen, Automatisierung bauen, exploratives Testen übernehmen, das Automatisierung nicht kann.

Für ein verteiltes Team hat das eine strukturelle Voraussetzung: Das Team muss die Folgen seiner Arbeit sehen können. Zugang zu Produktionsdaten, zur Ticket-Warteschlange, zum realen Nutzungsverhalten. Ein Team, das nicht sieht, was bricht, kann Qualität nicht verantworten — was auch immer im Vertrag steht. Dieselbe Dynamik steht in Ein Global Capability Center nach Schweizer Massstab.

Wo Automatisierung zahlt — und wo nicht

Automatisierung wiegt bei verteilter Lieferung schwerer, weil die Rückmeldeschleife länger ist. Ein Fehler, den eine Pipeline in zehn Minuten findet, kostet fast nichts; derselbe Fehler im Review am nächsten Morgen kostet einen Tag.

Automatisieren: Regressionstests für alles, was schon einmal gebrochen ist, den Auslieferungsweg, die Umgebungsbereitstellung, Sicherheits- und Abhängigkeitsprüfungen sowie die Prüfungen vor einer Übernahme.

Nicht automatisieren: exploratives Testen, Urteil über Bedienbarkeit und alles, dessen erwartetes Ergebnis sich häufig ändert. Eine brüchige Testsuite, die zufällig fehlschlägt, ist schlechter als keine — Teams lernen, sie zu ignorieren, und ignorieren dann den echten Fehlschlag.

Eine nützliche Reihenfolge: zuerst den Auslieferungsweg automatisieren, dann Regression, dann Breite. Teams machen das meist umgekehrt und enden mit breiter Abdeckung, die sie nicht verlässlich ausführen können.

Die Prüfschleife, die tatsächlich etwas findet

Drei Ebenen, jede fängt, was die vorherige übersieht:

• Automatische Prüfungen bei jeder Änderung — schnell, objektiv, ohne Personenzeit
• Code-Review durch jemanden, der es pflegen wird — findet Entwurfsprobleme, die Tests nicht sehen
• Abnahme gegen die schriftlichen Kriterien — durch die Person, die sie geschrieben hat

Die zweite Ebene schwächelt in verteilten Teams am häufigsten. Ein Review durch die gerade verfügbare Person erzeugt Freigaben statt Prüfung. Ein Review durch jemanden, der mit dem Code leben wird, erzeugt Fragen.

Eine Praxis, auf der es zu bestehen lohnt: Die prüfende Person führt es aus. Eine Freigabe aufgrund des gelesenen Diffs findet weniger als die Hälfte dessen, was Ausführen findet.

Kommunikation, die die Schleife kurz hält

Der verteilungsspezifische Teil — und überwiegend keine Werkzeugfrage.

Überlappungsstunden zählen mehr als der Ort. Abstimmung, Review und Demo am selben Tag sind der Unterschied zwischen einem Team und einer Warteschlange. Ein 24-Stunden-Umlauf pro Frage macht aus einer Zweitagesaufgabe eine Woche. Deshalb ist die Überlappung zur MEZ das relevante Kriterium, nicht die Entfernung.

Entscheidungen aufschreiben. In einem Team am selben Ort lebt die Entscheidung im Raum; in einem verteilten muss sie auffindbar liegen, sonst wird sie neu verhandelt.

Widerspruch günstig machen. Das teuerste Fehlerbild verteilter Lieferung ist ein Team, das etwas baut, das es für falsch hielt, weil Widerspruch aufwendig schien. Das ist eine Kultureigenschaft — sichtbar daran, ob kürzlich jemand widersprochen hat.

Was zu messen ist

Vier Zahlen zeigen, ob die Qualität hält:

• Nach dem Release gefundene Fehler, als Anteil der vorher gefundenen — das aussagekräftigste Qualitätssignal
• Fehlerquote von Änderungen — Releases, die eine Korrektur brauchen
• Zeit bis zur Wiederherstellung — weil Ausfälle vorkommen und die Erholung der steuerbare Teil ist
• Nacharbeitsquote — als nicht-fertig zurückgegebene Arbeit, meist ein Spezifikations- und kein Könnensproblem

Der letzte Punkt ist die verteilungsspezifische Diagnose. Hohe Nacharbeit heisst fast immer, dass «fertig» nicht klar genug definiert war — und die Abhilfe liegt am Anfang des Prozesses, nicht am Ende.

Die Schweizer Dimension

Zwei Dinge gehören bewusst geplant.

Dokumentation und Testnachweise sind Teil der Lieferung in jedem regulierten Umfeld — nach revDSG/nDSG, DSGVO, IEC 62304 für Medizinsoftware oder FINMA-Erwartungen. Sie als Overhead zu behandeln erzeugt später ein Prüfungsproblem. Aus der Pipeline erzeugt kosten sie fast nichts.

Datenzugriff für das verteilte Team. Engineers in einer anderen Rechtsordnung, die Personendaten berühren, sind eine echte Frage; die Antworten sind pseudonymisierte Testdaten, dokumentierte Zugriffskontrollen und Nachweise zur Unterauftragsverarbeitung. Lösbar — aber nicht rückwirkend, also vor dem Start klären.

Weiterführend

• Den richtigen Softwareentwicklungspartner auswählen
• Ein Global Capability Center nach Schweizer Massstab
• Dedizierte Entwicklungsteams

Wenn die Qualität nachlässt und Sie wissen möchten, wo die Schleife bricht, vereinbaren Sie ein Gespräch. Unverbindlich.