Us personelles - dudleydehenau/ScapeGame GitHub Wiki

Résumé coaching 5.b

+ Chaque étudiant a bien décrit entièrement et soigneusement sa User story personnelle, comme attendu. 
+ Chaque étudiant indique ici quelle est sa US personnelle et indique le lien pour pouvoir accéder à sa description.

Pour rappel, les US individuelles, à valider avec un coach, sont :

  • spécifiques à votre projet (pas générique comme une page de login ou de changement de mot de passe par exemple)
  • "intéressantes", c'est-à-dire qui fait intervenir des compétences pertinentes, avec backend et frontend
  • pas trop courtes. (Même si en tant qu'US ce ne doit pas être trop gros.)
  • décrites et implémentées par un seul étudiant, pour permettre de valider ses compétences
  • relativement prioritaires, pour qu'elle soit réalisées tôt dans le projet
  • pour lesquelles l'analyse et le testing seront particulièrement soignés
  • pour lesquelles vous réaliserez une vidéo individuelle simple de présentation complète (max 10 min) (voir : https://github.com/dudleydehenau/ScapeGame/wiki/US-personelles-videos)

Pour rappel, une US analysée comporte :

  • un nom correct (Le titre est sous forme "en tant que …, je souhaite… afin de…")
  • un code unique, il faut pouvoir les TRIER PAR ORDRE DE PRIORITE toutes les US du projet, chacune avec un code ou numéro ou nom unique permettant d'ordonner.
  • la valeur pour le client
  • une description textuelle claire et complète, accompagnée de maquettes, définissant précisément la US, notamment son début et sa fin.
  • les US sont bien découpées. Une US devrait porter sur un (et un seul) ajout fonctionnel utile au client. Idéalement une US devrait pouvoir être implémentée en une journée.
  • la référence aux autres US liées, à faire avant ou après, est indiquée pour bien comprendre le contexte
  • les critères d'acceptation clairs et complets, sous forme de scénario (voire de checklist), permettant de définir précisément si une US est bien implémentée, complètement (attention aux cas d'erreurs également)

Fournir également (probablement dans le gestionnaire de tâches) avant d'implémenter :

  • une découpe en tâches techniques avec les infos nécessaires à l'implémentation, notamment les dépendances techniques de la US : prérequis, endpoints API, tables de la DB, librairies utilisées, ...
  • la complexité/durée estimée, pour aider à planifier le développement et pour comparer par la suite avec l'effort réellement apporté

1. Liste des US personnelles par étudiant avec les liens pour y accéder

Dudley De Henau

User Story : Jeu Prison

Description :

En temps qu'utilisateur, je souhaite jouer à un jeu en partant du hub et, lorsque je clique sur jouer, qu'il y ai un Escape Game qui se lance dans une page dédié.

Critères d'acceptation :

  1. Le jeu est accesible depuis le hub.
  2. Le jeu est compréhensible et jouable par n'importe qui.
  3. Le joueur doit avoir la possibilité de de terminer le jeu.

Dépendances :

  • Système d'autentification
  • Hub de la page d'accueil
  • Page dédié à la présentation du jeu

Tâches :

  1. Frontend :

    • Créer un composant dédié pour le jeu
    • Le composant doit chargé une page HTML stocker dans le site web
    • Le jeu doit être fonctionnel et finissable
    • Créer un jeu complet lançable dans la page web

  2. Tests :

    • Ecrire des tests qui vérifie que :
      • le chargement du jeu fonctionne correctement.
      • Que le composant RpgGame est bien créé.
      • Vérifie que le conteneur du joue fait bien appel à l'élément script du jeu RpgGame
      • Netoyer ensuite tout les changement qui ont servi à créer les tests.

Priorité :

Cette user story est relativement prioritaire étant donné que c'est la fonction principale du site. Cependant, il n'y a que pour le système de classement que celui-ci est indispensable. Ce n'est donc pas une priorité absolu.

User Story : Component ScoreTest

Description :

En tant qu'administrateur, je souhaite pouvoir accèder à un component qui me permet de tester le service Scores.service. Je dois pouvoir soumettre un score et récupérer le meilleur score d'un niveau.

Critères d'acceptation :

  1. Le component est accesible depuis un URL.
  2. Le component permet de choisir les valeurs qui seront envoyé.
  3. Le component affiche dans la page les résultats de la requêtes.

Dépendances :

  • Dépendance du Service Scores.
  • Dépendante de l'API
  • Dépendante de la base de données.

Tâches :

  1. Frontend :

    • Création d'un component.
    • Création d'un formulair simple permettant de choisir les valeurs à envoyé.
    • Création des méthodes pour pouvoir communiqué avec le serice.

  2. Tests :

    • Créer les test pour :
      • Tester la création du component ScoreTest
      • Tester la soumission du score et la récupération du meilleur score
      • Tester le gestion des erreurs lors de la soumission du score et de la récupération du score
      • Prédéfinir des valeur de tests pour la soumission de score

Priorité haute :

Cette User story est prioritaire car toute création de jeu nécessite la soumission d'un score. Il faut donc être prêt à tester le service pour, par après, pouvoir vérifier le bon fonctionnement de la soumission des scores par un jeu.

User Story : Service Scores

Description :

En tant que développeur, je souhaite pouvoir appeller un service qui envoie un score sur la base de donnée et qui vérifie que le score en question est bien un meilleur score et que si ce n'est pas le cas, que le score ne soit pas enregistré.

Critères d'acceptation:

  1. Le service permet de soumettre un score à la base de donnée et de récupérer un score stocker dans la base de donnée.
  2. Le service vérifie que le score soumit est bien inférieur à celui créer.
  3. Dans le cas où le score fourni est supérieur à celui stocké, le score ne doit pas être enregistré.
  4. Dans le cas où une erreur est généré, le service doit avoir une gestion des erreurs et renvoyé l'erreur en question.

Dépendance:

  • Api
  • Base de donnée

Tâches :

  1. Backend :

    • Création d'un service Scores
    • Création de méthode permettant de :
      • Récuper le meilleur score d'un utilisateur pour un niveau spécifique
      • Mettre à jour du meilleur score pour un utilisateur pour un niveau spécifique.
    • Dans le cas de la soumission du score, faire en sorte qu'elle ajoute un score uniquement si le nouveau score est meilleur que celui qui était déjà stocké en base de donnée.

  2. Tests :

    • Test de la création du service Scores.
    • Test si la soumission du score se fait bien dans le cas ou le score est inférieur (le meilleur score est celui le plus bas).
    • Vérification de la non-mise à jour du score si celui-ci est supérieur à celui socké en base de donnée.
    • Test de récupéartion du score.
    • Test de la gestion des erreur lors de la soumission et la récupération du score.

Priorité :

Cette User Story est importante car les jeux et le component testant le service ont besoin de ce service pour pouvoir ajouter un score dans la base de donnée.

User Story : API Scores

Description

En tant que développeur, je souhaite faire appel à l'API pour soumettre un scores à ma base de donnée afin d'enregistrer les scores des utilisateurs.

Critères d'acceptation :

  1. On doit pouvoir poster, récuperer et mettre à jour un score.
  2. Il doit vérifier si le score à mettre à jour est bien plus petit que celui déjà stocké (le meilleur score étant le plus petit)

Dépendances :

  • API

Tâches :

  1. Backend :
  • Configurer les routes APi pour :
    • Gérer les POST
    • Gérer les GET
    • Gérer les PUT
  • Correctement créer et configurer les fichiers :
    • modèles/socres.js
    • routes/scores.js
    • controllers/scores.js
  1. Tests :
  • Pour les tests, le component ScoresTests permet de tester le bon fonctionnement de notre API. Ainsi que l'auto génération de la documentation API Swagger qui vérifie chaque route. Il n'est donc pas nécessaire d'écrire de test manuellement.

Priorité :

Cette user story est de priorité importante étant donné que tous les jeux ayant besoin d'enregistrer un score dans la base de donnée vont avoir besoin de ces routes API.

Patrycja Drewnowska

User Story : Jeu Château

En tant qu’utilisateur je veux pouvoir avoir accès à un jeux afin de pouvoir y jouer

  • L'utilisateur doit pouvoir lancer le jeu
  • L'utilisateur doit pouvoir en cliquant sur les objets de l'image trouver des indices et progresser dans le jeux
  • L'utilisateur doit pouvoir finir le jeux
  • L'utilisateur doit pouvoir voir son score à la fin du jeux
  • L'utilisateur doit pouvoir voir un classement des scores de tous les joueurs qui ont joué à ce jeux

Description

Le jeux chateau est un niveau de jeux qui est disponible sur le site ScapeGame. Ce jeux consiste en une pièce d'un chateau et l'utilisateur doit interagir avec les objets qui s'y trouvent en cliquant dessus. L'utilisateur doit trouver et comprendres tous les indices pour trouver la solution pour finir le jeux.

A la fin du jeux, le score actuel de l'utilisateur s'affiche à l'écran. Le score correspond temps, en seconde, qu'a pris l'utiliateur pour finir le jeux. Sur cette même page où s'affiche le score de l'utilisateur, il y a le classement avec les scores de tous les joueurs qui on joué à ce niveau. Le classement va du meilleur au pire joueur. Dans le classement on retrouve également le meilleur score qu'a pu faire l'utilisateur actuel à ce jeu.

Delcorte Maxime

User Story : Commentaire

Description

je souhaite en tant que utilisateur de pouvoir rédiger un commentaire sur la page d'un jeu afin de partager mon avis avec la communauté

Critères d'acceptation :

  • il faut que le commentaire soit afficher correctement affiché sur la page après sa rédaction.
  • il faut pouvoir voir la date de création du commentaire
  • il faut que le commentaire écrit soit sur la page et uniquement sur la page ou il a été rédigé

Dépendances :

  • Login
  • Page dédié à la présentation du jeu
  • HTTP interceptor

Tâches :

  1. Frontend :

    • création d'un espace de création et d'affichage de commentaire pour chaque page de jeu
    • création de services pour contacter le backend ( fetchall, createComment)
    • création de modèle pour faciliter les services ( un commentaire => id , commentaireText, utilisateurId, page de jeu )

2.Backend :

- création de mes routes => commentaire/:levelId ,  commentaire/body{userId,levelId,commentaireText}
- création de modèle sql pour les commandes => récupérer et créer un commentaire dans la base de donnée
- création du middleware pour vérifier que la requête vient d'un utilisateur connecté

3.DB :

- création de la table commentaire

Priorité forte :

Cette fonctionnalité est très importante pour l'utilisateur puisque il pourra intéragir avec d'autres utilisateurs sur notre site web. Il pourra se faire un avis sur l'un des jeux grâces à l'expérience des autres utilisateurs.

User Story : Commentaire delete

Description

En tant que utilisateur, je souhaite pouvoir l'un de mes commentaires afin de pouvoir rectifier une erreur.

Critères d'acceptation :

  • il faut pouvoir supprimer un commentaire
  • une fois supprimer, le commentaire n'est plus visible sur la page
  • seul l'utilisateut peut supprimer son commentaire

Dépendances :

  • les services de la précédente US
  • la page de niveau
  • login
  • HTTP interceptor

Tâches :

  1. Frontend :

    • création d'un icone pour chaque commentaire affiché (seulement visible pour l'utilisateur) pour le delete
    • ajout de la fonction delete dans le service commentaire

2.Backend :

- création de la route delete => commentaire/:id
- création de modèle sql pour les commandes => supprimer le commentaire dans la base de donnée

Priorité moyenne :

Cette us n'est pas la plus importante dans le cadre de ce projet pour l'utilisateur. Il y a mieux à faire avant cela mais cela était selon moi un bon ajout pour mon US principal

Florian Scalais

User story : Jeu chambre

Description :

En tant qu'utilisateur, je souhaite accéder à la page de jeu et jouer au jeu "Chambre" lorsque je clique sur le bouton jouer.

Critères d'acceptation :

  1. Le jeu est accessible depuis le hub.
  2. Le jeu est fonctionnel et bien expliqué.
  3. Le joueur voit son score lorsqu'il a fini le niveau.

Dépendances :

  • Système d'authentification

Tâches :

  1. Frontend :
    * Créer la page de jeu.
    * Le jeu est fonctionnel et complet.
    * Le jeu doit être visuellement agréable.

  2. Backend :

    • Route pour la page de jeu.
    • Service, modèle et controllers pour le score.
    • Route pour le score.

  3. Tests :

    • Test qui vérifie que le timer du jeu se lance en même temps que le component.
    • Test qui vérifie que le formulaire commentaire.
    • Test qui vérifie la soumission correcte/incorrecte du code de fin de partie.
    • Test qui vérifie l'inspection des éléments.
    • Test d'intégration qui appelle la méthode addScore du service ScoreService.

Priorité :

La priorité est plutôt secondaire étant donné qu'il faut un site fonctionnel avant tout mais cela reste un site d'escape game donc je mettrais une priorité de 7/10.

Tran Thi Tony

User Story : Barre de recherche

Description

je souhaite en tant que utilisateur de rechercher un jeu sans devoir chercher partout sur la page home via une barre de recherche

Critères d'acceptation :

  • Il faut que, lorsqu'on effectue une recherche, cela nous emmène sur la page du jeu recherché.
  • il faut que ce soit une recherche dynamique en fonction des jeux présent dans la base de données
  • il faut que la liste de suggestion soit cohérente avec les caractères inscrite dans la barre de recherche

Dépendances :

  • La page home
  • La base de données
  • L'API
  • login

Tâches :

  1. Frontend :

    • création d'une barre de recherche avec un bouton avec une loupe à côté
    • création de services pour contacter le backend ( fetchAll, searchByName)
    • création de modèle pour faciliter les services ( un level => id , name, difficulty, theme, like, publication_date, views )

2.Backend :

- création de mes routes => level/data (pour les données des jeux), level/search
- création de modèle sql pour les commandes => récupérer le nom d'un jeu dans la base de données

3.DB :

- Utilisation de la table level

Priorité moyenne :

Cette fonctionnalité n'est pas très importante pour l'utilisateur puisqu'il ne lui est pas nécessaire de devoir avoir une barre de recherche c'est un confort et surtout un gros plus mais il peut quand même accéder au jeux sans cela.

User Story : Tri & filtre

Description

En tant que utilisateur, je souhaite pouvoir filtrer et trier les jeux affichés dans la page home pour une meilleur lisibilité de ce que je souhaite

Critères d'acceptation :

  • il faut trier ou filtrer les jeux selon différents critères
  • il faut pouvoir afficher les jeux trier ou filtrer après chaque action effectué
  • il faut que cela soit dynamique avec les données dont dispose la base de données

Dépendances :

  • La page home
  • La base de données
  • L'API

Tâches :

  1. Frontend :

    • création d'un bouton contenant les autres boutons de trie
    • création d'un menu déroulant (sidenav) pour le système de filtrage
    • utilisation des mêmes services que la barre de recherche pour récupérer les données dynamiquement

2.Backend :

- création de mes routes => level/data (pour les données des jeux), level/search
- création de modèle sql pour les commandes => récupérer toutes les données des jeux dans la base de données

3.DB :

- Utilisation de la table level

Priorité moyenne :

Priorité moyenne. Bien que ce soit un grand plus d'avoir ces fonctionnalités, elles ne sont pas nécessaires pour accéder aux fonctionnalités principales du site.