A propos

Introduction

Le projet du jeu Kalaxia a été créé par la communauté d’Asylamba, un autre jeu de stratégie spatiale.

Désireux de lancer une nouvelle aventure opensource, les membres ont lancé la conception d’un tout nouveau jeu, voulu innovant avec un gameplay riche.

Voici les grandes lignes du fonctionnement de la communauté Kalaxia

Prise de décision

La prise de décisions au sein de la communauté est collégiale. Chaque membre peut proposer une fonctionnalité, qui sera débattue puis votée par l’ensemble de la communauté.

Aucun membre, quel que soit son rôle dans la communauté, n’a une voix plus importante qu’un autre dans ce modèle de prise de décisions.

Le cycle de vie d’une fonctionnalité est le suivant: un membre souhaitant proposer une idée crée une carte dans le gestionnaire de projet.

Les autres membres, via le système de commentaires, vont pouvoir discuter l’idée proposée, débattre et proposer des adaptations.

L’auteur peut dès lors éditer sa proposition d’origine, et, lorsqu’il le souhaite, la soumettre au vote.

En cas d’approbation par la communauté, la carte devient “prête” et les développements peuvent être lancés.

En cas de rejet, la carte reste “à spécifier”, et l’auteur pourra apporter les évolutions nécessaires avant de tenter un nouveau vote !

Agilité

La philosophie Agile est au coeur de la vie de la communauté. Pour garantir un grand pouvoir d’adaptation, chaque fonctionnalité peut être sujette à des remaniements, des évolutions.

L’expérimentation ne doit pas être crainte, c’est ce qui permet de tester plusieurs possibilités avant d’arriver à une solution pérenne.

Nous fonctionnons par MVP (Minimum Viable Product). Ce concept consiste à développer en priorité le coeur des fonctionnalités, ce qui fait sa valeur, avant de passer à leurs finitions.

Le but de cette approche est de pouvoir garantir des livraisons régulières et ainsi conserver une dynamique forte au sein de la communauté, qui pourra donc faire des retours (feedbacks) sur les différents éléments livrés.

Ces retours sont le carburant d’un projet Agile, car ils permettent d’adapter le jeu jusqu’à obtenir un gameplay riche, adapté aux joueurs et solidement éprouvé !

Groupes de travail

Différents groupes de travail coexistent au sein de la communauté: les graphistes, les rédacteurs du Background/Lore du jeu, les développeurs…

Un coach est élu par son groupe pour coordonner les actions du groupe de travail.

Ce coach a un rôle de conseil qui consiste à faciliter les activités du groupe, pour en améliorer l’efficacité et fluidifier les échanges.

Régulièrement, un nouveau coach est élu à la place du précédent, ce afin de créer un cercle vertueux de responsabilisation et d’auto-gestion.

Il peut arriver dans un groupe que personne n’ait suffisament la maîtrise du domaine associé pour pouvoir remplacer le coach, auquel cas il conserve son rôle.

Le Coach de groupe:

  • aide les membres de son groupe à formaliser leurs idées
  • résume les idées de manière général
  • cherche le consensus pour son groupe
  • s’assure de la bonne ambiance de travail de son groupe
  • favorise les discussions, même les débats, mais modère les conflits!
  • s’adresse aux Modérateurs de la communauté s’il n’arrive pas à gérer un conflit

Attention, le coach ne doit pas pousser ses idées personnelles, mais favoriser l’émergence des idées des contributeurs de son groupe. Le Coach n’est pas un Manager, ni le chef de son groupe, c’est un facilitateur !

Le Product Owner:

Un Product Owner est présent dans la communauté, et a pour rôle de prioriser les différentes tâches et de valider que les travaux réalisés correspondent aux fonctionnalités votées par la communauté.Il mesure également l’impact des différentes fonctionnalités sur le gameplay et tient compte des retours (feedbacks) des utilisateurs pour pouvoir suggérer des adaptations.

 

Attributions

Illustration: par Pluralsight Creative attribution
& non-commercial