Agilité

Notre vision agile est amenée à changer avec l’expérience et l’apprentissage, cette page l'est donc aussi ! Elle représente notre approche actuelle mais peut très bien être totalement différente par la suite


Scrum depuis les douves


Bien qu'encore jeune, le projet aspire à gagner en maturité et en ambition. Notre nouvelle organisation nous permet de continuellement redéfinir à la hausse nos objectifs tout en gardant un taux de livraison élevé.

La méthode scrum overclockée à l’extrême programming est vraiment adaptée pour un serveur de jeu ! nous n'allons pas voir ici ce qu'est scrum ni l'agilité ni l’extrême programming (vous avez votre ami google pour cela) mais plutôt comment nous l'appliquons et pourquoi.


Ce qu'il faut retenir :

L'aproche agile découle de 4 mindset fondamentaux qu'il faut respecter dans tout les cas !

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Qu'est ce que ça nous apporte ? :

  • Des mises à jour constantes basées sur le feedback des joueurs.
  • Une productivité démultipliée
  • Une optimisation complète du travail grâce à notre intégration continue.
  • La possibilité d'agrandir les équipe sans avoir de problèmes de répartition du travail.
  • Les équipes sont auto-gérées il n'y à plus de hiérarchie pour imposer des taches.
  • Le cadre de travail est agréable, plus de stress ni d'isolement (dev binôme, daily scrum, etc..).
  • L'entraide et la transparence sont mise en avant.
  • Le fait d'avoir un produit terminé toutes les deux semaine est motivant.

Séparer les tâches et se concentrer sur une release améliore grandement la productivité


Comment l'utilisons nous ?

Nous utilisons la méthode scrum qui consiste à fonctionner selon des itérations (il existe beaucoup d'articles sur le sujet si vous voulez en savoir plus)

Chez AresRPG il y a 3 pôles :

  • les développeurs
  • les builders
  • les graphistes

Il est primordial que chaque scrum-team comporte du développement, du buid, et du graphisme. Séparer les teams par "type" serait une erreur monumentale

Un Scrum-Master qui gère les réunions et veille à ce que les teams suivent le principe agile défini en les épaulant, en répondant aux questions et traitant les possibles problèmes dans le but d'une amélioration etc..!

Un Product-Owner qui ordonnance le backlog général en se basant sur les retours de la communauté (c'est un porte parole qui traduit les idées de la communauté en tache traitable par l'équipe de développement.)

Idéalement il faudrait un scrum master par team et un Product owner global

Chaque team possède des sprint différents mais les départ des trains de releases sont les mêmes ce qui implique que les sprints aient les même dâtes


Nos sprints ont une durée de 2 semaines. Ce qui veut dire que toutes les 2 à 3 semaines (car les sprints ne s’enchaînent pas forcément) une mise à jour est prête et qu'elle sera poussée en production si elle passe les tests d'acceptations (ces tests sont effectués par les Testeurs, ils sont différents des tests unitaires, des security gates etc, qui font partis de la checklist de mise en prod et effectués pendant le sprint)

No Comments

Back to top