Das Thema war sogar mal vor 17-18 Jahren bei Sacred ein Thema. Die besten Fehler in einer Ruhmeshalle auszustellen (sogar Ingame). Sozusagen war es auch ein wenig Frustabbau im Team, und auch Anreiz für das damalige Open-Beta Team welches wir etabliert hatten. Keine Frage Sacred war nach der Veröffentlichung sagen wir mal “sehr verbuggt”, man würde ja schlichtweg lügen, wenn man es nicht so deutlich sagen würde. Ich bin im November 2004 in Aachen bei Studio II angefangen und hatte eigentlich schon im Dezember eigentlich die Faxen dicke.
Aber nach Unterstützung durch die Sacred Beta-Test Community, der Organisation im damaligen Sacred Beta IRC Channel, und aufbauenden Worten sowohl aus dem Team, als eben auch aus der Community war ich sehr schnell wieder motiviert.
Ich habe darüber nachgedacht, unsere Testzyklen zu gamifizieren und einige “Wettbewerbe” mit Abzeichen und Auszeichnungen zu veranstalten, hier einige Ideen:
- Anzahl der Bugs pro Testmarathon – Wettbewerb um die Anzahl der entdeckten Bugs in einer begrenzten Zeitspanne (z.B. pro Testsprint-Iteration). Bugs können Schwerekoeffizienten haben, um eine gewichtete Anzahl von Punkten pro Bug zu erhalten
- einen Wettbewerb für den lustigsten/schrulligsten Fehler pro Release und eine “Ruhmeshalle” einrichten
- ein “künstliches Fehler”-Szenario einrichten, bei dem ein Tester einen Typ eines bestehenden Problems erhält (z. B. eine SQL-Injection-Schwachstelle aufgrund einer nicht ordnungsgemäß validierten Eingabe), aber keinen Ort und keine Schritte zur Reproduktion erhält
Grundsätzlich finde ich diese Idee richtig gut. Die Gamification kann ein Teil der regelmäßigen Tests sein. Aber ob es sich positiv auf die Produktivität auswirkt, hängt weitgehend von der Art und Weise ab, wie ihr diese Idee umsetzt.
Es gibt auf jeden Fall positive Aspekte der Gamification, aber eben auch negative Punkte.
Ich möchte mich nur auf den Teil der Umsetzung konzentrieren. Denn wir müssen uns auch um die Schattenseiten der Gamification kümmern:
- Wettbewerb kann zu Ego-Konflikten zwischen Einzelnen führen, was für das Team kontraproduktiv ist.
- Um Anerkennung zu bekommen, könnten einige Teammitglieder in einen Wettlauf um die Meldung von Fehlern geraten, bei dem sie manchmal sogar Mist melden.
- Es kann vorkommen, dass Leute doppelte Fehler melden und sich dann wieder darüber streiten, wessen Fehler als doppelt markiert und geschlossen werden soll.
- Ein Teammitglied, das in den letzten ein oder zwei Sprints nicht ein einziges Mal anerkannt wurde, könnte demoralisiert werden. Wir müssen uns also auch darum kümmern.
Aber ich bin nicht nur dagegen, sondern auch dafür. Daher möchte ich den obigen Gedanken und Vorschlägen einige Punkte hinzufügen:
Meiner Meinung nach sollte die Absicht sein, so viele Menschen wie möglich anzuerkennen, weil es für alle motivierend sein wird.
- Zum Beispiel: Anerkennung für die Teammitglieder, die die Top-5-Fehler gemeldet haben (die am wichtigsten waren).
Ich schlage diese Art Auszeichnung vor, weil ich mit Leuten gearbeitet habe, die nicht sehr schnell sind. Sie brauchen ihre eigene Zeit, um eine Funktion zu testen, sind aber sehr gründlich. Daher sind die Fehler, die sie protokollieren, von großer Bedeutung für das Projekt. Diese Auszeichnung wird also solche Leute mit abdecken.
- Defect leakage: Eine weitere Auszeichnung für die Person oder das Team, das eine bestimmte Funktionalität getestet hat und bei der UAT keinen Fehler (oder 1 oder 2 Fehler mit niedriger Priorität) in dieser Funktionalität gemeldet hat.
- Review effectiveness award: Damit werden bessere Überprüfungen sichergestellt. Sie können dafür ein Ziel festlegen. Ich meine, wenn die Review-Effektivität größer als 30% ist (zum Beispiel), dann wird dieser Reviewer ausgezeichnet (wenn mehr als 30% der gesamten Fehler in einer Funktionalität während der Reviews gefunden wurden).
- No invalid defects: Dies wird die Qualität der gemeldeten Fehler verbessern. Wenn nach und nach alle Teammitglieder diese Auszeichnung erhalten und keine ungültigen Fehler melden, würde ich sie gerne an alle vergeben.
- Teamevents: Darüber hinaus kann es auch Teamevents geben. Ihr könnt auch einige Maßnahmen auf Teamebene festlegen. Wenn ein Team zum Beispiel eine Version abliefert, die bestimmte Qualitätsparameter einhält, gibt es eine Art Belohnung für das gesamte Team (wir haben Ziele für Qualitätsmatrizen wie Fehlerbeseitigungseffizienz, Fehlerdurchsickern und Überprüfungseffizienz). Dies ist wichtig, um den Teamgeist aufrechtzuerhalten. Andernfalls bin ich persönlich der Meinung, dass zu viele individuelle Belohnungen/Anerkennungen den Teamgeist beeinträchtigen können, sodass wir ein Gleichgewicht zwischen beidem wahren sollten.
Ich habe in der Vergangenheit ähnliche Gamification-Ideen ausprobiert, schon 2004 in einem Open-Beta Test bei Sacred. Hier sind einige Erfahrungen:
- Ein Teil des Teams (Betatester) war begeistert, ein anderer nicht – die Teammitglieder (in diesem Fall die Betatester), die nicht interessiert waren, zogen sich zurück und beteiligten sich nicht an dem unvermeidlichen Geplänkel unter den Enthusiasten: nicht gut für das Team und schon gar nicht für eine Open-Beta geeignet.
Enthusiasten erstellten mehr Tickets (Duplikate/Variationen, die eigentlich Erweiterungen früherer Tickets hätten sein sollen): Tester protokollieren möglicherweise mehrere Fehlervarianten
Die Enthusiasten wollten nicht mit anderen Teammitgliedern zusammenarbeiten bzw. ein Problem diskutieren, weil sie sich die Anerkennung für die Lösung erschleichen wollten. Ich kann mir vorstellen, dass dies beim Testen passiert: Tester werden Probleme nicht gemeinsam diskutieren und auf der Grundlage kollektiver Intelligenz zu einem Ergebnis kommen – sie werden einfach Fehler protokollieren.
Teammitglieder mit Spezialkenntnissen in bestimmten Bereichen bekamen früher Tickets zugewiesen, aber andere wollten sie für ihre Punkte behalten: Probleme wurden nicht effizient gelöst, was nicht gut für den Kunden ist.
Ein paar andere Gedanken:
- Tester, die an komplexerer Software arbeiten, erhalten mehr Punkte
- Tester werden mit Entwicklern von geringerer Qualität arbeiten wollen!
Es könnte mit Testern besser funktionieren, aber es wird unvermeidliche Veränderungen im Teamverhalten geben, die nicht immer positiv sein werden
Einige der Threads auf Workplace Exchange zum Thema Spiel(e)metriken:
https://workplace.stackexchange.com/questions/69894/how-to-handle-a-test-engineer-biased-to-one-of-our-team-member
https://workplace.stackexchange.com/questions/5940/how-to-measure-the-creative-workers-output-who-are-not-filling-in-the-timesheet
https://workplace.stackexchange.com/questions/87887/how-to-objectively-measure-colleague-cooperation (Erwähnungen: http://cuberules.com/2008/02/07/management-by-numbers-be-very-afraid/)
https://workplace.stackexchange.com/questions/22087/measure-competence-of-the-company-on-different-technology-areas
https://workplace.stackexchange.com/questions/48053/how-productivity-or-working-hours-are-measured-in-software-development-jobs
Neueste Kommentare