Gamification als Treiber von Codequalität

Spiele machen Spaß. Dasselbe kann man über die Arbeit leider nicht immer sagen. Warum also nicht Elemente aus Spielen nutzen, um sich im Arbeitsalltag zu motivieren? Genau darum dreht sich der Begriff der Gamification. Wie lässt sich dieser Ansatz im Softwareentwicklungsalltag einsetzen?

In Pocket speichern vorlesen Druckansicht 24 Kommentare lesen
Gamification als Treiber von Codequalität
Lesezeit: 15 Min.
Von
  • Tom Hombergs
  • Thorben Schiller
Inhaltsverzeichnis

Ein Spiel zu spielen, soll in erster Linie Spaß machen und motivieren, bestimmte Ziele zu erreichen. Dabei geht es zumeist um das Spiel selbst, ohne Auswirkungen über dessen Kontext hinaus. Gamification bedeutet, die motivierenden Effekte eines Spiels auf einen nichtspielerischen Kontext zu übertragen. Das soll durch das Anreichern mit spielerischen Elementen beziehungsweise Methoden wie Highscore-Listen oder Punktekonten erreicht werden.

Gamification verfolgt immer ein Ziel. Im einfachsten Fall ist es die Intention, mehr Aktivität in einem bestimmten Kontext zu erzeugen. Ein Beispiel hierfür ist die mobile App "Zombie, Run!", die Läufer zu mehr Leistung motivieren soll. Apps zum Sammeln und Darstellen von Statistiken über absolvierte Trainingseinheiten sind zwar bereits eine gewisse Gamification des Laufens, stellen sich jedoch nicht explizit als solche dar. "Zombie, Run!" hingegen tut das sehr deutlich, indem die App dem Läufer während des Laufens eine interaktive Geschichte erzählt. In ihr gibt es Passagen, in denen man vor imaginären Zombies flüchten muss. Der Läufer soll motiviert werden, mehr und schneller zu laufen. Zusätzlich soll der spielerische Faktor dafür sorgen, dass die "Spieler" mehr Spaß am Laufen haben: So gehen sie öfter laufen und bleiben länger am Ball. Neben der sportlichen Weiterentwicklung des Läufers soll der Motivationsfaktor dafür sorgen, die Anwendung häufiger zu nutzen – ein direkter Einfluss auf den Wettbewerb mit anderen Apps.

Spielemechaniken steigern die Motivation, bestimmte Ziele zu erreichen. Punkte sind ein einfaches Beispiel dafür. Für eine spezielle Aktivität können die Spieler Punkte verdienen. Auch wenn die reine Anzahl von Punkten für manche Spieler bereits motivierend ist, können weitere Ziele, die sich mit den Punkten erreichen lassen, eine breitere Masse begeistern. Ranglisten und Belohnungen bei bestimmten Punktzahlen oder Level-Up-Belohnungen steigern die Motivation deutlich. Wichtig ist dabei, dass die eigenen, erreichten Ziele möglichst auch anderen Mitspielern gegenüber sichtbar sind, sodass sich ein Wettbewerb entwickeln kann.

Dabei sind kleinschrittige Erfolge hilfreich, um Spieler bei der Stange zu halten. Der Nur-noch-ein-Level-Effekt setzt umso schneller ein, je schneller der nächste Erfolg erreicht wird. Dabei handelt es sich um den Effekt, der auftritt, wenn man eigentlich schon aufhören möchte zu spielen, sich aber doch hinreißen lässt, den nächsten Erfolg zu erreichen.

Seit Jahren sammelt man Punkte beim Einkaufen mit Payback-Karten und verdient damit Sachprämien. Entwickler helfen der Community bei Stack Overflow gerne, weil sie unter anderem damit ihre Reputation erhöhen und für alle sichtbar sogenannte Badges sammeln können. Foursquare zeichnet Nutzer mit Titeln aus, wenn er oder sie viel herumkommt und aller Welt zeigt, wo sie wann überall waren.

Bei allen drei Beispielen lassen sich die Spieler durch die Mechaniken und zu erreichenden Ziele motivieren, aktiver in den jeweiligen Kontexten zu agieren. Bei Payback kaufen sie mehr, weil es gerade doppelte Punkte für einen Einkauf gibt. Bei Stack Overflow investieren sie mehr Arbeit in eine Antwort, denn je besser sie ist, desto bessere Bewertungen bekommen User von der Community. Und bei Foursquare gehen die Anwender öfter in ein bestimmtes Café, denn bei der 30-Besuche-pro-Monat-Marke erhalten sie einen besonderen Status.

Bei all dem stehen jedoch für die Betreiber keineswegs die individuellen Ziele der einzelnen Spieler im Vordergrund. Alle drei verfolgen ihre eigenen Ziele, die von außen betrachtet vielleicht gar nicht alle erkennbar sind. Man kann jedoch davon ausgehen, dass sie von den gesteigerten Aktivitäten der Benutzer profitieren.

Da sich das Gamification-Konzept in so gut wie jede Arbeitsumgebung übertragen lässt, kann man es auch in der Softwareentwicklung anwenden. Zunächst muss man sich aber überlegen, welche Ziele man damit verfolgen möchte und mithilfe welcher Gamification-Mechaniken sich Anreize schaffen lassen, um ein Entwicklerteam zu motivieren, diese Ziele anzustreben.

Hier gibt es verschiedene Möglichkeiten. Beispielsweise ist es denkbar, Metriken wie Antwortzeiten oder Downtimes der entwickelten Software zu erfassen. Diese bewerten, wie performant oder stabil eine Anwendung im laufenden Betrieb ist. Das Entwicklerteam ließe sich dann durch Punktelisten, die darstellen, welche Entwickler die Metriken am positivsten beeinflusst haben, anspornen. Hierzu ist die Infrastruktur der Software im Produktionsbetrieb entsprechend aufzubauen, sodass die erforderlichen Metriken erfasst und transparent gemacht werden (was aber auch ohne Gamification eine gute Idee ist).

In einem ähnlichen Szenario ließen sich Metriken erfassen, die den (monetären) Durchsatz der entwickelten Anwendung messen und das Team entsprechend anspornen. Solche Metriken sind zum Beispiel die Anzahl der abgeschlossenen Transaktionen in einem Web-Shop oder Klicks auf bestimmten Seiten der Anwendung. Auch hier müsste die Software die relevanten Metriken transparent machen.

Die beiden genannten Szenarien sind am besten geeignet für Anwendungen in einer Infrastruktur mit einem hochautomatisierten Deployment-Prozess. Erst diese Automatisierung ermöglicht es Entwicklern, ihre Änderungen schnell in Produktion zu bringen und die Auswirkungen ihrer Änderungen im Live-Betrieb direkt zu beobachten und zur Not rückgängig zu machen.

Neben diesen Business-Metriken kann man im Rahmen eines Softwareprojekts aber auch auf technischer Ebene eine Vielzahl von Metriken erfassen, die sich mehr oder weniger gut für Gamification-Mechaniken eignen. Aus einem Versionskontrollsystem wie Subversion oder Git lassen sich zum Beispiel Metriken wie Anzahl, Umfang oder Zeitpunkt der Check-ins jeweils pro Entwickler oder pro Team gewinnen. Man kann argumentieren, dass umfangreiche Check-ins schlechter sind als solche, die weniger Dateien berührt haben, oder dass Check-ins mitten in der Nacht aufgrund von Müdigkeit tendenziell negativer zu bewerten sind, und anhand dieser Metriken Gamification-Mechaniken aufsetzen. Allerdings lassen sich diese Metriken nicht objektiv als "gut" oder "schlecht" bewerten, weshalb sie sich nur mäßig dafür eignen.

Etwas besser gestalten sich Metriken, die sich beispielsweise aus Continuous-Integration-Systemen (CI) gewinnen lassen. Misst man etwa die Dauer der Builds, die auf einem CI-System laufen, könnte man das Team dazu motivieren, monolithische Anwendungen in kleinere Artefakte aufzuteilen, die sich jeweils schneller bauen lassen. Auch kann man mitzählen, wie oft ein Build fehlgeschlagen ist, und die "Build Breaker"-Quote pro Entwickler oder Team mit einer Spielemechanik versehen, um die Stabilität des Builds zu verbessern. Hier muss man aber auf die Teamdynamik achten, sodass keine einzelnen Personen als Build Breaker an den Pranger gestellt werden.

Ein größeres Potenzial für Gamification als die bisher genannten Metriken bieten solche, die Codequalität messen. Metriken wie die zyklomatische Komplexität messen die Anzahl der möglichen Pfade durch den Quellcode. Je niedriger die Komplexität eines Stücks Code, desto besser. Andere Metriken messen, wie viele Abhängigkeiten eine Komponente zu anderen Komponenten hat. Je weniger, desto besser isoliert und testbar sind die Funktionen der einzelnen Komponenten.

Neben solchen Metriken, die das Ergebnis einer statischen Codeanalyse sind, gibt es weitere, die sich zur Laufzeit ermitteln lassen, etwa die Testabdeckung. Hierfür werden die (hoffentlich vorhandenen) Unit- oder Integrationstests aufgerufen und ermittelt, wie viele Zeilen und Pfade durch den Code dabei durchlaufen werden.

Diese und andere Metriken zur Messung der Codequalität eignen sich für Gamification. Sie sind einfach zu berechnen, da es für so gut wie jede Programmiersprache Tools zur Berechnung der Metriken gibt. Mit SonarQube gibt es einen Codequalitäts-Server, der die Veränderungen diverser Metriken visualisiert. Um Mechaniken wie Punktelisten zu generieren, müssen sich die Veränderungen an den Metriken allerdings den einzelnen Entwicklern zuordnen lassen. Es ist also zusätzlich zur Analyse des Quellcodes ein Zugriff auf das Versionskontrollsystem notwendig, in dem die Informationen der Veränderungen enthalten sind.

Ein weiterer Faktor, warum Codequalitätsmetriken für Gamification geeignet sind, ist die Tatsache, dass die meisten mittlerweile lange bekannt und unter Entwicklern respektiert sind. Es gibt aber auch Metriken, die je nach Kontext mehr oder weniger Sinn machen. Eine hohe Testabdeckung in einer Domänen-Klasse, die hauptsächlich Getter- und Setter-Methoden umfasst, ist beispielsweise nicht so wichtig wie in einer lebenswichtigen Steuerungskomponente für eine Marssonde. Ein Team sollte sich deshalb auf ein Set von Codemetriken einigen, das als Definition der Codequalität dient.

Mit jeder Änderung am Code sind die Änderungen an den ausgewählten Metriken zu erfassen und den jeweiligen Entwicklern zuzuordnen. Über eine Formel werden die ausgewählten Metriken in einen Qualitätsindex pro Entwickler zusammengerechnet, der aussagt, wie viel diese zur Codequalität beigetragen haben. In regelmäßigen Abständen können dann zum Beispiel die Entwickler mit dem größten Beitrag zur Codequalität ausgezeichnet werden. Danach setzt man die Werte wieder zurück, und der Wettbewerb beginnt von vorn, um allen Entwicklern eine neue Chance zu geben.

Um Gamification im Rahmen eines Softwareentwicklungsprojekts einzusetzen, sind diverse Metriken zu erfassen und in Spielemechaniken einzubetten. Solche Metriken manuell zu erheben und in Spielemechaniken zu überführen, ist kaum möglich. Man sollte also meinen, dass es eine Reihe Tools gibt, die Entwickler dabei unterstützen. Tatsächlich fördert eine Recherche im Internet aber kein Werkzeug zu Tage, das es ermöglicht, Metriken aus diversen Datenquellen zusammenzuführen und Spielemechaniken wie Ranglisten, Awards, Badges oder Level-Ups um diese Metriken herum zu definieren. Im Folgenden wird deshalb beschrieben, welche Eigenschaften ein solches Gamification-Tool haben müsste.

Zunächst muss ein solcher Gamification-Server Metriken aus diversen Quellen einsammeln können
(s. Abb. 1).

Ein Gamification-Server greift auf Systeme des Softwareentwicklungsalltags zu, um Metriken zu sammeln und sie verschiedenen Spielemechaniken zuzuführen (Abb. 1).

Die Metriken werden von Fremdsystemen wie einem Codequalitäts-Server eingesammelt und über den Zugriff auf das Versionskontrollsystem den einzelnen Entwicklern zugeordnet. Die meisten Systeme dieser Art bieten APIs an, über die sich bestimmte Metriken abfragen lassen. Auf Seiten der Fremdsysteme ist somit keine Anpassung nötig, lediglich die Abfragen der Metriken sind innerhalb des Gamification-Servers zu implementieren.

Alternativ bieten manche Systeme die Möglichkeit, sogenannte Hooks einzurichten, die bei bestimmten Aktivitäten ausgelöst werden und aktiv Daten zum Gamification-Server übertragen können. Dafür muss der Server stets verfügbar sein, da die Hooks ansonsten ins Leere laufen. Weiterhin muss er die Möglichkeit bieten, die eingesammelten Metriken zu Spielemechaniken wie den erwähnten Ranglisten zu konfigurieren. Diese Konfiguration findet in einer Administrationsoberfläche statt. Die dort konfigurierten Spielemechaniken lassen sich dann den Teilnehmern zur Verfügung stellen.

Die Teilnehmer selbst greifen über eine weitere Weboberfläche auf den Gamification-Server zu. Für diese sind kreative Ideen zur ansprechenden Gestaltung gefragt, da sie aktiv dazu beiträgt, ob die angebotenen Spielemechaniken angenommen werden oder nicht. Jeder Teilnehmer sollte dabei selbst entscheiden können, welche Daten und Erfolge er mit den anderen Teilnehmern teilen möchte. Hat er diese Wahlfreiheit nicht, besteht die Gefahr des Vertrauensverlusts.

Beim Einsatz von Gamification muss man sich auch der potenziellen Gefahren bewusst sein. Sobald bestimmte Metriken einer konkreten Person zugeordnet und diese Werte von Teilnehmern gegenübergestellt werden, gibt es nicht nur diejenigen, die ganz oben stehen, sondern zwangsläufig auch jene, die in einer Punkteliste am unteren Ende stehen. Bei einer nicht eingeschränkten Gegenüberstellung besteht die Gefahr, dass alle Mitspieler sehen können, wer schlecht abschneidet. Das kann schnell negative Folgen haben, zum Beispiel ein sinkendes Ansehen bei den Kollegen oder die Schwächung des Selbstvertrauens. Ebenso gefährlich ist es, wenn Vorgesetzte die für die Gamification gedachten Metriken zur Messung der Arbeitsleistung der Mitarbeiter heranziehen. Da sie aber nie ein vollständiges Bild der Leistung einer Person darstellen, sollten Verantwortliche nicht vorschnell falsche Schlüsse ziehen.

Eine weitere Gefahr besteht bei der Verwendung falscher Mechaniken oder Ziele und bei Teilnehmern, die der Gamification eine unverhältnismäßig hohe Bedeutung beimessen. Fokussiert sich der Mitarbeiter zu sehr auf das strikte Erreichen seiner Ziele, gerät möglicherweise der Sinn der Gamification (die Förderung der Arbeitsqualität) in den Hintergrund.

Nachfolgend ein Beispiel für eine falsche Motivation dieser Art: Eine Stadt hat ein Rattenproblem. Der Bürgermeister entscheidet, die Bürger für jede gefangene Ratte mit einem Kopfgeld zu belohnen. Einige Bürger sehen jedoch das Ziel nicht darin, die Stadt zu säubern, sondern ausschließlich die winkende Prämie, die sie mit steigender Zahl gefangener Ratten erhöhen können. Sie entschließen sich, selbst Ratten zu züchten, die sie zum Bürgermeister bringen, um die Prämie zu kassieren.

Potenzielle Gefahren sollten deshalb insbesondere beim Einsatz von Gamification im Arbeitsumfeld von den Beteiligten im Vorhinein analysiert und diskutiert werden. Es wäre zum Beispiel ausreichend, Ranglisten auf die ersten drei Plätze zu beschränken, sodass lediglich die besten Plätze hervorgehoben sind, nicht jedoch die schlechtesten. Weiterhin gilt es, Vorgesetzte dahingehend zu sensibilisieren, dass die Ergebnisse nicht in Bezug auf die Gesamtleistung der Mitarbeiter aussagekräftig sind. Am besten sorgt man mit technischen Mitteln wie einem erforderlichen Login dafür, dass Vorgesetzte gar keinen Zugriff auf die Daten haben.

Um die Teilnehmer nicht in eine falsche Richtung zu motivieren, ist es wichtig, die Zweckmäßigkeit der Mechaniken und Ziele zu prüfen. Statt einer Prämie pro Ratte hätte der Bürgermeister aus dem Beispiel vielleicht erst bei Erreichen des Ziels "rattenfreie Stadt" eine Prämie ausloben sollen, zum Beispiel ein großes Bürgerfest auf Kosten der Stadt. Auch wenn es sich dabei um ein vermeintlich weniger motivierendes Kollektivziel handelt, kann es besser geeignet sein als ein falsch gesetztes Einzelziel. Ein Beispiel für den Erfolg von Kollektivzielen sind zum Beispiel Crowdfunding-Kampagnen, bei denen viele Teilnehmer jeweils wenig Geld beisteuern, um sogenannte "Stretch Goals" zu erreichen, die jeweils ein weiteres Feature des Produkts für alle Teilnehmer freischalten.

Gamification kann ein Mittel sein, Spaß in den Arbeitsalltag im Allgemeinen und in die Softwareentwicklung im Speziellen zu bringen. Gleichzeitig kann sie dazu beitragen, die Arbeitsqualität zu verbessern. Insbesondere Metriken, die sich aus einer statischen Codeanalyse gewinnen lassen, eignen sich zum Erstellen von Spielemechaniken, da sie einfach zu gewinnen und meistens objektiv bewertbar sind.

Bei der Einführung von Gamification muss man sich aber stets der damit einhergehenden Gefahren bewusst sein, um negative Auswirkungen auf die Arbeit zu verhindern. Zur Unterstützung von Gamification in der Softwareentwicklung gibt es leider noch keine ausgereiften Werkzeuge, sodass sich hier erst eine Community finden muss, aus der diese Werkzeuge hervorgehen.

Tom Hombergs
ist Softwarearchitekt bei der adesso AG und trägt dort die technische Verantwortung in Softwareentwicklungsprojekten. Nebenbei ist er auf GitHub aktiv und entwickelt unter anderem ein Werkzeug zur Gamification von Codequalität.

Thorben Schiller
ist Software Engineer bei der adesso AG und engagiert sich neben dem Projektgeschäft im Hochschulumfeld, um Studenten auf den Softwareentwicklungsalltag vorzubereiten. Das Thema Gamification in der Softwareentwicklung war bereits das Thema seiner akademischen Abschlussarbeit.
(ane)