Wie geht man mit den Sprint-übergreifenden Task-Abhängigkeiten um?

Geschrieben von Andreas Schliep am 29.12.2014
Dependencies...

"Wie sollen wir mit den Tasks umgehen, die von einander abhängen aber zu verschiedenen Sprints gehören? Betrachtet am Beispiel eines Spiels. Angenommen, wir haben geplant, im Sprint 2 ein Waffen-System zu entwerfen, mit Waffenauswahl, Kugeln und anderen Waffen-Einstellungen. Nach ein paar Sprints fügen wir ein Waffen-Upgrade-System hinzu, das voraussichtlich im Sprint 6 kommt. Während der Implementierung des Upgrade-Systems muss auch das Waffen-System geändert werden. Also müssen wir das Waffen-System im Sprint 6 wieder codieren und testen. Wie können wir mit dieser Art von Situation umgehen?"

Das oben beschriebene Szenario ist üblich für praktisch jede Art von komplexer Entwicklung. Ein guter Weg, diese Art von Abhängigkeit anzugehen, sind Abnahmetests. Ihr könnt 3 Kategorien von Abnahmetests etablieren, die im Wesentlichen gleich sind aber an verschiedenen Entwicklungsstadien verwendet werden.

Stufe 1: Sofortige Abnahmetests

Sofortige Abnahmetests gelten für alle neuen Funktionen, die in einem bestimmten Sprint umgesetzt werden sollen. Die Abnahmetests bei eurem initialen Waffen-System würden in diese Kategorie fallen. Ein typischer Abnahmetest für "Pistole laden" könnte sein "Lade 10 Kugeln in das leere Magazin der Pistole und das Magazin sollte voll sein." Dies ist mit Abstand die einfachste Kategorie, da jeder Test direkt mit einer User Story oder einer bestimmten Funktionalität verbunden ist.

Stufe 2: Regressionstests

Regressionstests sollten einfach sein, wenn ihr eure Abnahmetests aus der Stufe 1 automatisiert habt. Regressionstests werden bei jedem Produktinkrement – potentiell auslieferbarer, integrierter und getesteter Code am Ende jedes Sprints – verwendet. Sie werden in der Regel verwendet, um unerwartete Verhaltensweisen zu erfassen. So soll "lade 10 Kugeln in das leere Magazin der Pistole und das Magazin sollte voll sein" noch funktionieren, sogar wenn ihr im 4. Sprint eine Ladehemmung implementiert habt. Die Ladehemmung darf die Kapazität des Patronenmagazins nicht beeinflussen. Wenn doch, dann habt ihr möglicherweise einen Regressionsfehler entdeckt. Oder ein neues, unerwartetes Feature ;)

Stufe 3: Ineinandergreifende Abnahmetests

Dies ist bei weitem die schwierigste Kategorie. Stufe 1 deckt sofortige funktionelle Veränderungen ab, Stufe 2 fängt unerwünschte Nebeneffekte ab, Stufe 3 soll funktionelle Veränderungen behandeln, die Auswirkungen auf andere funktionelle Veränderungen haben. Mehrere Teams haben mit Abhängigkeitsmatrizen gearbeitet, um die Funktionsbereiche und deren Einfluss aufeinander zu erfassen. In eurem Beispiel wirkt sich das Waffen-Upgrade-System auf den Code des schon existierenden Waffen-Systems aus, wie auch erwartet. Es kommen neue Abnahme- und Regressionstests dazu. "Lade 10 Kugeln in das Magazin und das Magazin sollte voll sein" wird zu "Mache ein Upgrade für das Patronenmagazin und die Kapazität sollte 20 sein" und "Lade 10 Kugeln in die leere Pistole und das Magazin sollte eine verbleibende Kapazität von 10 haben." Diese Vorgehensweise könnte eine ziemlich große Anzahl von Abnahmetests pro neue Funktionalität zur Folge haben. Ihr könnt die Testfälle besser handhaben, wenn ihr einige neue Stories dazunehmt, welche die modifizierte Funktionalität beschreiben – "Upgrade Patronenmagazin ", "Lade das aktualisierte Patronenmagazin" könnte ein solches Story-Paar sein.

Die Abhängigkeitsmatrix hilft die potentiell betroffenen Bereiche im Auge zu behalten. Die Kombination aus Abnahmetests und Abhängigkeitsmatrix bringt Klarheit und Handhabbarkeit.

Andreas Schliep

Andreas „Andy“ Schliep

Andy ist einer der ersten deutschsprachigen Scrum-Trainer und ein Gründungsmitglied von DasScrumTeam. Nach seinem Studium an der Hochschule Bremerhaven begann Andreas seine Karriere zunächst als Softwareentwickler, später dann als Projektleiter, Teamleiter und schließlich als Bereichsleiter. Zu Scrum fand Andreas zwischen 2003 und 2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Implementierung von Scrum bei WEB.DE wechselte Andreas im Jahr 2006 zu SPRiNT iT und entschied sich 2008, als Coach und Trainer selbstständig zu machen. Heute fokussiert er sich neben der Einführung von Scrum vor allem auf agile Führungskompetenzen und die nachhaltige Transformation von Organisationen. Als Co-Autor hat Andy an der Erstellung der Lernziele der Scrum Alliance für Scrum Master, Product Owner und Entwickler mitgewirkt.

Mehr Posts zum Thema

Immer informiert mit dem DasScrumTeam Newsletter

Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.