Résumé coaching 2b

+ Les utilisateurs de l'application sont identifiés et présentés dans le Wiki dans le backlog, éventuellement en utilisant des personas. 
+ Les EPIC(regroupement logique de fonctionnalités) sont définies et décrites pour le projet, un EPIC par étudiant. 
+ Les User stories des EPIC sont listées (pas encore le détail). 
+ Les EPICS s'accompagnent de maquettes pour comprendre l'application visée.
+ Le groupe a défini où il rédigera son Backlog, soit la liste des user stories. Si c'est dans un outil en dehors du wiki, il donne le lien.

1. Liste des utilisateurs

• Administrateur : Gérant d'un bar ou employé d'un bar qui ont besoin de recevoir les alertes et de consulter les statistiques. Ils ont un accès complet.

• Client connecté : Les clients du bar qui ont besoin de pouvoir commander des shots et d'accéder aux mini-jeux. Ils ont un accès restreint.

2. EPICs

E01 : Commander des shots

Pouvoir commander des shots de la consultation du menu à la confirmation de la commande.

US :

• Voir le menu
• Remplir son panier
• Valider son panier
• Envoie du mail de confirmation de paiement
• File d'attente

E02 : Alertes

Recevoir des alertes directement sur le site web.

US :

• Alerte de prévention sur l'âge et l'abus d'alcool
• Alerte quand le niveau d'alcool est bas

E03 : Stats

Voir les statistiques liées à la vente de shot.

US :

• Voir les heures d'affluence
• Nombre de shot/commande

E04 : Mini-jeux

Mini-jeux en tout genre.

US :

• Identification des utilisateurs
• Leaderboard
• autres...

3. User Stories

Nos backlogs sont dans notre GitHub Project

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, 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 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 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é