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

Dependencies...
Geschrieben von Andreas Schliep am 29.12.2014

"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

Über den Autor

Andreas Schliep

Andreas Schliep ist ein Gründungsmitglied von DasScrumTeam AG. Er arbeitet als Scrum Coach und Trainer. Nach seinem Besuch der Hochschule Bremerhaven arbeitete Andreas zunächst als Softwareentwickler, Projektleiter, Teamleiter und später auch Bereichsleiter. Zu Scrum kam Andreas 2003-2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Scrum Implementierung dort wechselte Andreas 2006 zur SPRiNT iT und machte sich 2008 als Coach und Trainer selbständig. Heute liegen seine Schwerpunkte neben der Einführung und dem Ausbau von Scrum insbesondere beim Qualitätsmanagement und der nachhaltigen Verbesserung von Entwicklungsteams.

  • Erfahrung mit Scrum seit Frühjahr 2004 als Scrum Master, Product Owner, Teammitglied, Coach und Trainer.
  • Einführung von Scrum bei der WEB.DE AG und ComBOTS AG
  • Betreuung von international verteilten Scrum Teams bei BenQ-Siemens
  • Betreuung von Scrum Teams bei bwin Wien Unterstützung des Übergangs von RUP zu Scrum bei UOL Brasilien
  • Weitere Scrum-Implementierungen in D/A/CH
  • Besondere Interessen: Skalierung und Verbesserungsprozesse
Tags