Epic Us Backlog

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

[La descriptions des différents types d'utilisateurs de l'application, par exemple : ]

• Administrateur : [Explication du métier]

• Client connecté : [Description des spécificités de cet utilisateur, de ses besoins spécifiques et de ses droits d'accès]

• Secrétaire: [Description des spécificités de cet utilisateur, de ses besoins spécifiques et de ses droits d'accès]

2. EPICs

Chaque étudiant décrit ici un EPIC, avec les maquettes associées, pour bien comprendre globalement l'application. La liste des fonctionnalités ("User Stories) des Epic est listée. (Le détail n'est pas obligatoire dans un premier temps.)

3. User Stories

Mettre ici le lien vers le logiciel que vous utiliser pour définir votre backlog, ou décrire directement les US ici i c'est votre choix. Au fur et à mesure de l'avancement di projet, vous complèterez les User Stories. Il est attendu un soin tout particulier pour la description des US personelles. Le nom de l'auteur de l'US est clairement indiqué dans le backlog.

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é