Requirements Engineering Game - Theorie ist tot, es lebe das Spiel!
Anfrage übers Webformular: Halbtägiger Workshop zum Thema ‘Requirements Engineering’
Ich: Hörer in die Hand genommen und Barbara von Techface angerufen. Schliesslich bin ich ein Vollblut Requirements Engineer und muss auch hier den Anforderungen ganz genau auf den Grund gehen.
Barbara: Wir bauen ein neues Konzept für Frauen auf, die in die IT wechseln möchten. Könnt ihr denn den eher theorielastigen und langweiligen Stoff des Requirements Engineerings auch so vermitteln, dass es Spass macht?
Ich (masslos empört!): Langweilig?!?! Herausforderung angenommen!
Zusammen mit Stefan Böhni und Patrick Steiger von der Infometis habe ich mich auf die Suche nach dem heiligen Gral des spielerischen Lernens begeben. Jeder von uns hat wie Sherlock Holmes recherchiert, wie Wickie Ideen entwickelt und wie Lancelot für seine Ideen gekämpft. Schliesslich wurde das Brettspiel zum Siegerprojekt gekürt und zum ersten Spielen innerhalb der Gruppe freigegeben.
Leider hat das Brettspiel Schiffbruch erlitten und ist wie die Titanic in den Tiefen der verworfenen Ideen verschwunden. Da uns der Zeitumkehrer von Hermine Granger fehlte, überstieg die Konzeption eines funktionierenden Brettspiels unsere zeitlichen Möglichkeiten.
Aber wir wären keine Infometen, wenn wir uns geschlagen gegeben oder von Null gestartet hätten. Wir lösten listig wie ein Fuchs und in solider RE-Arbeit das Ziehen von Karten aus dem Brettspiel heraus und funktionierten das Konzept zu einem Kartenspiel um.
Auf dem Prototypen aufbauend und voller Elan habe ich alsdann drei Varianten auf einen Streich entwickelt, da mir die zuerst entwickelte Spielvariante ohne Zufallsfaktoren zu wenige spielerische Aspekte hatte.
Was alle Spielvarianten gemeinsam haben?
- Sie folgen dem typischen RE-Lifecycle: ‘Kontext’, ‘Anforderungen definieren’, ‘Visualisieren/Prototyp bauen’, ‘Validieren’
- In allen Spielen muss man die Interessen der Stakeholder berücksichtigen.
- Es können 4 bis n Spielrunden gespielt werden.
- Die Komplexität des Kontextes, der Anforderungen und der Methoden wird von Runde zu Runde erhöht.
- Es gibt drei Stapel mit Stakeholdern.
- Es gibt Aktionskarten.
- Die Aktionskarten lösen das Ziehen von Methodenkarten aus.
Was die Spielvarianten unterscheidet?
Spielvariante 1: Funktioniert ganz ohne Zufallsfaktoren, es werden nur Karten gezogen.
Spielvariante 2: Es wird zusätzlich gewürfelt, es ist also auch ein wenig Glück im Spiel.
Spielvariante 3: Es wird an verschiedenen Stellen gewürfelt, der Zufallsfaktor kann aber durch strategisches Vorgehen wieder wettgemacht werden.
Nun musste ich nur noch die Spielkarten entwickeln und dann Simsalabim, konnte Stefan Böhni diese in Adobe InDesign gestalten. Und das ist das Resultat:
An unserem nächsten Treffen mit allen Infometen hat Patrick Steiger unerschrocken die drei Spielvarianten mit unseren Infometis-Versuchskaninchen getestet.
Und welche Variante hat nun das Rennen gemacht? Das kann nicht ganz so klar beantwort werden!
Grundsätzlich funktionieren alle drei Varianten. Aber: Welche Spielvariante wann eingesetzt wird, hängt vor allem von den teilnehmenden Personen ab. Haben die Spielenden wenig bis gar keine Vorkenntnisse, reicht die Komplexität der Spielvariante 1 (ohne Zufallsfaktoren). Sind auch Spieler dabei, die mehr Kenntnisse haben, oder bei einer Mischung aus Spielenden mit und ohne Vorkenntnisse, kann gut Variante 2 gespielt werden. Variante 3 sollte nur von Spielenden gespielt werden, die auch gut mal verlieren können und bereits Vorkenntnisse im Requirments Engineering mitbringen.
Jetzt habe ich sicher eure Neugier geweckt! Let’s play together!
Du bist noch nicht sicher, ob das was für dich ist? Dann lies meinen nächsten Blogartikel zum Thema ‘Requirements Engineering Game in Action’
