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

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.