Gamification bringt Spaß in den Projektalltag. Aber lohnt es sich überhaupt?
Um dies einschätzen zu können, geben wir einen Überblick über verschiedene spielerische Ansätze, die auf die Qualitätssicherung von Software fokussieren.
Wir gehen darauf ein, wie man Gamification gezielt und im richtigen Maß in Projekte einführt, welche Schwerpunkte gesetzt werden sollten und wie skeptische Kollegen überzeugt werden können.
Damit kann der Vortrag als Entscheidungsgrundlage dienen. Richtig eingesetzt, lohnt sich Gamification!

Zielpublikum: Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Spielerische Ansätze in der Software-Entwicklung sind nicht neu und finden immer häufiger ihren Platz im Projektalltag. Doch kosten diese nicht einfach nur Zeit und Geld? Bringt es überhaupt Vorteile, das Team „spielen“ zu lassen? Und wie misst man Erfolg oder auch das Scheitern einer Spielidee?
Wir zeigen am Beispiel von Gamification-Ansätzen in der Qualitätssicherung, dass diese das Potenzial haben, nicht nur den Projektalltag aufzulockern und den Teamzusammenhalt zu stärken, sondern auch die Softwarequalität spielend zu verbessern. Gezielte Produktverbesserung, z. B. durch Bug-Hunting, wird ebenso adressiert wie systematische Prozessverbesserung, z. B. durch Maturity Poker.
Voraussetzung ist, dass Gamification gezielt eingesetzt wird, um effizient zu sein. Der spielerische Ansatz muss zum Team und zum Projekt passen, Schwächen beheben und auf Lösungen für bestehende Probleme fokussieren.
Der Vortrag will eine Entscheidungshilfe geben, wann sich spielerische Ansätze lohnen und wann man eher auf sie verzichten sollte. Denn nur, wenn sich Erfolge einstellen und Gamification das Projekt voranbringt, stehen alle Beteiligten hinter dem Vorgehen, und die investierte Zeit ist nicht „verspielt".

Schon von Quarkus gehört, dem neuen und effizienten JVM-Framework? Das - nicht unerfolgreich - etablierten Frameworks wie Spring Boot Konkurrenz macht?
Und bist Du daran interessiert, wie man eine Quarkus-App erstellt und - noch wichtiger - Teile davon isoliert testet?
Interessiert? Dann lass mich von unseren Erfahrungen berichten, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

Zielpublikum: Developers
Voraussetzungen: Basic knowledge about JVM languages, JVM frameworks and the microservice architecture pattern
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das relativ junge Quarkus konnte sich zu einem ernst zu nehmenden Konkurrenten für etablierte Microservice-Frameworks wie Spring Boot entwickeln. Das liegt insbesondere daran, dass das leistungsfähige und dennoch leichtgewichtige JVM-Framework es schafft, Startzeiten und Speicherverbrauch von Anwendungen erheblich zu reduzieren. Damit ist es nicht nur für die Entwicklung von Microservices in containerisierten Cloud-Plattformen wie Kubernetes interessant, sondern auch für Serverless Computing.
Und es unterstützt meine Lieblings-Programmiersprache: Kotlin!
Wenn man eine Anwendung mit Quarkus und Kotlin entwickelt, kommt man früher oder später (hoffentlich früher ;-) ) nicht umhin, isolierte Tests zu schreiben. Nur so lässt sich bekanntermaßen automatisiert feststellen, ob sich der Anwendungscode wie erwartet verhält. Und als Kotlin-Entwickler will man dazu bekannte Technologien wie z. B. JUnit und MockK nutzen. Es gibt dabei aber einige wesentliche Aspekte, die beim Testen und Mocking von CDI-Beans in Quarkus beachtet werden müssen.
Interessiert? Dann habt teil an unseren Erfahrungen, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!