Spiele entwickeln auf Discord? Ja, das geht. In dieser Folge programmier.bar sprechen Dennis Becker und David Koschitzki mit Lisa Mertins, Spieleentwicklerin bei Lotum, über die Entwicklung von Discord-Aktivitäten. So nennt Discord die Apps, die direkt in Sprachkanälen gespielt oder genutzt werden können.

Lisa Mertins war maßgeblich daran beteiligt, das Lotum-Spiel „Quiz Planet“ im November 2024 als Aktivität auf Discord zu bringen – ein spannender technischer und konzeptioneller Prozess mit vielen Learnings. Sie berichtet, was bei der Entwicklung innerhalb der Plattform zu beachten ist, welche technischen Hürden und Limitierungen es gab, und wie sich die Plattform seitdem verändert hat.

Wer schon mal überlegt hat, eine App oder ein Spiel auf Discord zu bringen, bekommt hier echte Einblicke in den Prozess. Alle anderen erfahren, wie viel Potenzial in der Plattform steckt. Lisa Mertins teilt ihre Erfahrungen aus erster Hand und nimmt uns mit hinter die Kulissen der Entwicklung.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Spieleentwicklung auf Discord mit Lisa Mertins„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.

(mdo)

In dieser Folge spricht Richard Seidl in seinem Podcast Software Testing mit Benjamin Hummel über den Einsatz von künstlicher Intelligenz bei der Behebung von Qualitätsproblemen in bestehender Software. Die beiden schauen dabei in die Welt der statischen Codeanalyse und diskutieren, wie KI helfen kann, Fehler schneller zu erkennen und gezielt zu beheben.

Benjamin Hummel teilt aus erster Hand Erfahrungen über Chancen und Grenzen aktueller KI-Modelle beim Refactoring. Es geht um typische Herausforderungen in gewachsenen Softwaresystemen, um die Balance zwischen Effizienz und Sicherheit, und um die Frage, wo KI echtes Potenzial hat – und wo der Mensch weiterhin gebraucht wird.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Qualitätsprobleme in bestehender Software mit KI beheben – Benjamin Hummel“ und steht auf YouTube bereit.

(mdo)

Moin.

Ich vermute, dass es in der Softwareentwicklung unvermeidlich ist, sich kontinuierlich weiterzuentwickeln. Als Developer arbeitet man in komplexen Aufgabenstellungen. Das erfordert neue Ansätze und Vorgehensweisen. Gleichzeitig besteht bei jedem Menschen die Gefahr, dass er eine Aufgabe auf die altbekannte Weise löst, die für neue Probleme vielleicht nicht die richtige ist. Das Gegenmittel ist klar: Fortbildung. In vielen Unternehmen, mit denen ich mit meinen Kolleginnen und Kollegen arbeite, gibt es interne Fortbildungsmöglichkeiten und gelegentlich eine externe Schulung. Das ist für den oder die Einzelne eine gute Sache. Eine Frage fehlt mir dabei ziemlich oft: Wie ist es um die Kompetenz des Teams bestellt?

Die Frage gehört für mich zur Teamführung, aber Vorgesetzte braucht das Team für den wesentlichen Schritt nicht: Wie stellen wir fest, ob das Team die richtigen Kompetenzen besitzt und an welchen Stellen eine Verbesserung erforderlich ist?

Im ersten Schritt erstellt das Team eine Liste derjenigen Kompetenzen, die erforderlich sind, um die Aufgaben des Teams zu erfüllen oder die Ziele des Teams zu erreichen. Meist ist die Liste so lang, dass eine Betrachtung aller Kompetenzen den zeitlichen Rahmen eines Meetings sprengen kann. Deshalb stimmt das Team im zweiten Schritt ab, welche Kompetenzen es näher betrachten möchte.

Für den weiteren Verlauf kann man gut mit einer Tabelle arbeiten. Die kurze Kompetenzliste steht in der ersten Spalte – in jeder Zeile eine Kompetenz. Als Beispiel für eine Liste: Java-Programmierung, git-Bedienung, Kommunikation mit Stakeholdern.

Im dritten Schritt spricht das Team darüber, wie viele Teammitglieder die jeweilige Kompetenz auf welchem Niveau (Grundkenntnisse, fortgeschrittene Kenntnisse, Expertenkenntnisse) beherrschen sollen. Auf einem Flipchart oder Whiteboard bietet es sich an, das Niveau durch Farben zu kennzeichnen (etwa Rot, Gelb, Grün). Bei einem Team, das in Java entwickelt, dürften Grundkenntnisse in der Sprache auf Dauer nicht ausreichen. Bei einem Fünfpersonenteam darf man hier das Votum „fünfmal Expertenkenntnisse“ als Zielvorstellung erwarten. Bei der git-Bedienung sind möglicherweise zweimal Experten- und dreimal fortgeschrittene Kenntnisse ausreichend. Und die Kommunikation mit Stakeholdern übernimmt vielleicht regelmäßig eine Person im Team, sodass für die vier anderen die Grundkenntnisse ausreichend sind. Diese Aufstellung der erforderlichen Kompetenzen gehört in die zweite Spalte der Tabelle.

Die restlichen Spalten sind jeweils einem Teammitglied vorbehalten. Hier trägt jede Person in einer Selbsteinschätzung ihr Kompetenzniveau ein. Die fertige Tabelle zeigt dann unmittelbar, wo das Team Defizite besitzt. Im Beispiel: Haben nur drei Personen Expertenkenntnisse in Java und nur ein Teammitglied sieht sich als git-Experte, gibt es Nachholbedarf.

Wie die Kompetenzsteigerung zu erreichen ist, kann das Team in vielen Fällen autonom besprechen und umsetzen. Für eine Weiterbildung in Java braucht es keine externe Schulung, wenn drei Experten im Team vorhanden sind. Hier können teaminterne Schulungen, aber auch Pair Programming weiterhelfen. Erst wenn ein Bedarf auftritt, den niemand im Team abdecken kann, braucht es Unterstützung von außen.

Diese strukturierte Erfassung vorhandener und erforderlicher Kompetenz führe ich mit Teams in größeren Abständen von beispielsweise einem Jahr durch. Die Tabelle ist auch als Teamkompetenzmatrix bekannt. Wenn ein Team eine solche Matrix erstellt hat, lasse ich das Team in Retrospektiven im Laufe des Jahres immer wieder mal prüfen, ob es sich in die (selbst-)gewünschte Richtung entwickelt.

Für mich ist ein wesentlicher Aspekt, dass es sich hier um Teamführung handelt und keine Vorgesetzten beteiligt sind. Das Beispiel zeigt, dass Führung nicht an eine bestimmte Position oder Funktion gekoppelt ist.

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn du auch daran interessiert bist, findest du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn du die Themen, die ich im Blog anspreche, in deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)