Spielablauf

Ein Kartenstapel symbolisiert ein beliebiges Softwareprojekt. Die einzelnen Karten stehen dabei für die zu entwickelnden Features.
Die Spieler wählen entweder die Rolle des Developers oder der Quality Assurance und durchlaufen nacheinander die verschiedene Phasen der Softwareentwicklung.

In der Develop-Phase müssen alle Karten vom Stapel in möglichst kurzer Zeit auf der Game Area platziert werden. Eine gelegte Karte darf nicht mehr angefasst werden, so wie auch ein fertiges Feature in der Programmierung oft nicht mehr bearbeitet wird. Da jede Funktion nur einmal existieren darf, sollen Dubletten entfernt werden.

In der Deploy-Phase muss ein zufällig ausgewählter Developer alle Karten von der Gamearea in absteigender Reihenfolge einsammeln. Dabei dürfen immer nur die Karten aufgenommen werden, die von keiner anderen Karte (teilweise) überdeckt werden.
Auch hier sollen eventuelle Duplikate gelöscht werden.

Anschließend bekommt der QA den erstellten Kartenstapel und hat noch ein letztes Mal die Möglichkeit Karten umzusortieren oder zu entfernen, bevor der finale Stapel, also das finale Produkt, an den Kunden übergeben wird.
Nur wenn der Stapel komplett ohne Fehler ist, läuft die erstellte Software wie gewünscht.

Im Anschluss sehen die Spieler eine ausführliche Aufstellung ihrer Ergebnisse. Hier werden die beiden Faktoren Zeit und Fehler dargestellt, die bei der Softwareentwicklung eine wichtige Rolle spielen.

Danach spielen die Spieler eine zweite Runde mit fast den gleichen Regeln. Der einzige Unterschied: die Developer dürfen in der ersten Phase die Karten auf der Gamearea nach dem Legen beliebig oft verschieben. Eine Vorsortierung wird dadurch deutlich einfacher und der ausgewählte Dev wird sich bei der Erstellung des finalen Kartenstapels leichter tun.
Nach der zweiten Runde werden die Ergebnisse aus beiden Runden vergleichend dargestellt und die Spieler werden sehen, dass sie ein besseres Endergebnis erzielen, wenn sie Zeit in das Refactoring investieren und dass sich technische Schulden negativ auf das Endprodukt auswirken.

Voraussetzungen
Um das Technical Debt Game spielen zu können, werden drei bis vier Spieler benötigt.
Die Website ist nur über das Hochschulnetzwerk erreichbar.
Das Spiel ist nicht für Smartphones ausgelegt.

Ausblick
Das Spiel soll in Zukunft vom HSA_innolab betreut und in Lehrveranstaltungen an der Hochschule genutzt werden, um Studierende auf spaßige Art zu unterrichten. In Zukunft sollen in anderen Projekten weitere Agile Games umgesetzt werden.

Studierende:

• Samir Akhundov
• Judith Saul
• Omar Yacine