Il y a quelque temps maintenant, j’ai commencé à créer une application mobile permettant de faire du planning poker. L’idée de l’application est de démarrer une session de poker planning, chaque joueur vote sur son téléphone et à la fin du tour, le résultat est affiché pour tout le monde.

 

Le Poker Planning c’est quoi ?

Le poker planning, ou scrum poker, est issu de la méthodologie Scrum, c’est une façon ludique d’estimer l’effort de développement nécessaire pour chaque fonctionnalité présente dans le Backlog.

Cet exercice a plusieurs avantages :

  • Chacun vote dans son coin, ce qui permet d’éviter d’influencer les autres membres de l’équipe.
  • Les joueurs ayant voté aux extrêmes (note la plus élevée et la plus basse) doivent argumenter sur leur choix. Ainsi tout le monde participe.
  • La réunion de poker planning est un peu plus dynamique et ludique.

 

Pourquoi une application de Poker Planning ?

Premier avantage d’une application est de pouvoir dématérialiser le jeu, plus besoin du support cartonné !

Autre avantage, on peut aussi partager plus facilement une session de planning poker avec des gens à distance. Le télétravail devenant de plus en plus présent dans notre quotidien, nous utilisons donc des applications favorisant la communication.

Lorsque l’on vote à distance on vote sans utiliser des cartes. Ce qui peut influencer les autres. Une application planning poker pourrait régler ce problème de communication.

 

Comment créer notre application ?

Maintenant que l’on a l’idée, comment la réaliser ? Comment régler les problèmes de communication entre utilisateurs ? Bref, comment créer cette application ?

Pour la partie communication, il y a deux problématiques :

  • La première, il faut mettre en relation les joueurs.
  • La deuxième, il faut envoyer des notifications pour faire évoluer le jeu sur tous les téléphones en même temps.

Pour le développement de l’application cliente, j’ai fait le choix d’utiliser Xamarin Forms afin de pouvoir développer l’application sur plusieurs devices en même temps.

 

Communication : Mise en relation

Pour établir la communication entre tous les téléphones, il est nécessaire de créer une notion de canal, ou de room. C’est assez simple, chaque téléphone doit envoyer les informations de vote dans le même canal. Pour identifier le canal, il suffit de s’entendre sur un code identique entre tous les téléphones.

Pour générer ce code, il y a un premier téléphone qui créé le canal. Ce téléphone génère un Guid. Ce Guid permettra de créer un canal unique de discussion entre tous les smartphones. Pour le transmettre ce téléphone génère un QR-Code. Les autres téléphones doivent scanner ce QR-Code, ainsi ils récupèrent le Guid pour savoir sur quel canal écouter et transmettre.

Pour la génération et le scan j’utilise ZXing.Net cette librairie est disponible pour Xamarin Forms ZXing.Net Xamarin Forms

Il existe un contrôle Xamarin Forms qui permet de générer le QR-Code :

 

Communication : le transfert de données

Pour le transfert d’informations, nous avons besoin d’une communication réactive entre les téléphones. Très souvent, on consomme des API pour communiquer et afficher des informations.
Dans cette application, j’ai plusieurs scénarios de communications qui transmettent des données aux téléphones.

 

Exemple de scénario entre Aurélien, Thomas et Maxime

  • Aurélien crée un canal de communication en générant le QR-Code.
  • Thomas rejoint ce canal de communication en scannant ce QR-Code.
    • L’application de Thomas doit maintenant transmettre à Aurélien qu’il y un autre joueur.
    • L’application d’Aurélien répond à Thomas qu’il est déjà dans la partie.
  • Maxime rejoint ce canal de communication en scannant ce QR-Code.
    • L’application de Maxime doit maintenant transmettre à Aurélien et Thomas qu’il y a un autre joueur.
    • Les applications d’Aurélien et Thomas répondent à Maxime qu’ils sont déjà dans la partie.

Après cette communication tous les joueurs connaissent les autres joueurs présents dans la room.

Pour communiquer, j’ai développé une ASP.Net Web API en SignalR. L’avantage de SignalR c’est que l’on va s’inscrire sur un évènement. Cela utilise le protocole WebSocket pour la communication ce qui reste une communication en HTTP.

Il existe un paquet client .Net qui fonctionne avec Xamarin.SignalR Client

Une fois le package ajouté. Pour démarrer une communication il suffit de faire :

 

Ensuite pour démarrer l’écoute on fait :

 

Dans l’exemple on s’inscrit sur :

 

Lorsqu’il y a un nouveau joueur dans la partie, j’exécute une méthode pour mettre à jour la liste des participants.
Puis au lorsque l’on démarre une session, chaque joueur va appeler une méthode sur le serveur :

 

On appelle une méthode JoinGame avec le game code qui correspond au canal de communication envoyé par le scan du QR-Code. On ajoute des informations pour indiquer l’id et le nom du joueur.

Le serveur va alors exécuter la méthode :

 

Dans cette méthode, il y a deux étapes.

  • La première étape, c’est de rejoindre un groupe SignalR. Ce groupe est le game code. Cela va permettre à SignalR à chaque communication de renvoyer l’information dans le bon groupe.
  • La deuxième étape est d’envoyer la mise à jour d’un joueur à tous les membres de ce groupe sauf moi-même.

Ainsi, chaque joueur qui a rejoint le groupe récupèrera les informations de jeux. On pourra envoyer les votes, déclencher des nouvelles sessions, afficher les votes…

 

Intelligence de l’application

L’intelligence de l’application se fera sur chaque téléphone. Ainsi tous les téléphones récupéreront les nouveaux utilisateurs, les votes, … Chaque téléphone, en fonction des informations reçues, effectuera les calculs, l’affichage ou la navigation vers les écrans.

La classe GameService en singleton détient l’intelligence déduite des informations envoyées par chaque téléphone. Elle contient une liste des utilisateurs avec leurs scores et s’il a voté ou pas.

La Web API permet de mettre en relation les téléphones pour qu’il discute dans le même canal.

 

Next

L’application n’est pas terminée. La suite du backlog est :

  • Ajouter les projets Android, Mac, UWP avec l’usine de build associé.
  • Faire un visuel un peu sympa.

Dans les améliorations on pourrait lier l’application à un Azure DevOps. Cela permettrait de mettre à jour les points directement sur Azure DevOps.

 

Conclusion

Grâce à SignalR et Xamarin Forms, on peut avoir une application mobile réactive. Ce modèle réduit l’intelligence dans l’API.
Le code est disponible sur mon GitHub Planning Poker