Nouvelle organisation du projet

L’été est passé, et a vu plein de nouveautés pour Kalaxia ! Tout d’abord, de nombreuses mises à jour sont arrivées sur notre serveur de preprod, que vous pouvez découvrir via le portail ! Nous avons également mis à la disposition des développeurs participant à ce projet open-source un serveur de tests, qui leur permet de participer plus facilement ! Le portail quant à lui fait sa rentrée et adopte un nouveau design progressivement, tandis que l’équipe se décide à reprendre la communication en espérant voir de nouveaux joueurs rejoindre la communauté !

Mais le principal changement reste la nouvelle direction que nous avons pris dans la gestion du projet. Avant l’été déjà, pour parer au piétinement que l’on observait sur les différents sujets, la communauté a voté pour un système de prise de décision moins collégial. Désormais, nous avons réorganisé l’équipe en un noyau dur, qui adopte plus rigoureusement les principes de l’Agilité, en particulier les méthodes Scrum et Kanban.

Nous découpons désormais le projet en sprints, périodes de deux semaines durant lesquelles l’équipe s’engage sur la production d’User Stories (une User Story est une phrase permettant de donner plusieurs informations sur une fonctionnalité, par exemple “En tant que chef de faction, je veux déclarer la guerre, afin d’accroître mon territoire“). Nous priorisons également par la valeur, c’est à dire que nous estimons à quelle point une fonctionnalité sera importante pour nos utilisateurs finaux, nous estimons ensuite le temps de travail nécessaire pour accomplir ce travail, et nous commençons par produire les US à forte valeur et à faible complexité ! Cela permet de sortir plus rapidement une version MVP (Minimum Viable Product) !

Cette méthode porte déjà ses fruits ! On peut observer que la productivité a fortement augmenté depuis le milieu de l’été:

(ajout et suppression de code dans l’API, côté serveur)
(ajout et suppression de code client, côté navigateur)

Cependant, l’inconvénient de cette méthode a été le sentiment d’exclusion de la communauté de la conception du jeu, conception qui s’est voulue collégiale depuis le début du projet. C’est pourquoi nous avons convenu qu’un sprint se ferait en trois parties parallèles:

  • Les développeurs réalisent les User Stories sur lesquelles un engagement a été pris sur le sprint
  • Les designers font un Sprint Design, et préparent les maquettes et assets graphiques qui seront nécessaires au sprint suivant pour le développement
  • La communauté prépare les fonctionnalités au niveau Game Design, débat et construit les idées qui alimenteront le Sprint Design au sprint suivant.

Avec ce fonctionnement, nous pouvons établir que des fonctionnalités préparées par la communauté pourront être produites au bout d’un mois (deux semaines de Sprint Design et deux semaines de développement si embarqué dans les engagements). Cela établit un rythme fluide qui inclut tous les pans de la communauté.

Nous cherchons encore nos marques pour arriver à un rythme optimal qui convienne au maximum de personnes, le jeu ne peut qu’en bénéficier !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *