Skip to content

Epic Us Backlog

lvdEphec edited this page Feb 7, 2024 · 13 revisions

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 définira son Backlog, soit la liste des user stories. Si c'est en dehors du wiki, il met un 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. Epic

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, sans le détail 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 US analysée comporte :

  • un nom correct,
  • un code unique, avec la possibilité d'ordonner toutes les US depuis le début du projet
  • la valeur pour le client
  • une description textuelle claire et complète, accompagnée de maquettes, définissant précisément la US
  • la référence aux autres US liées à faire avant ou après, pour bien comprendre le contexte
  • les critères d'acceptation clairs et complets, sous forme de scénario (voire de checklist) ainsi qu'avant d'implémenter :
  • une découpe en tâches technique avec les infos nécessaires à l'implémentation
  • la complexité/durée estimée

Plus de précisions :

  • Il faut pouvoir les TRIER PAR ORDRE DE PRIORITE, chacune avec un code, numéro ou nom unique permettant d'ordonner._

  • Le titre est sous forme "en tant que …, je souhaite… afin de…"

  • L'apparence de l'interface utilisateur de la US est précisée, avec un lien si la maquette se trouve ailleurs : emplacement/navigation, layout, maquettes, …

  • 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.

  • Les dépendances techniques de la US sont précisées : prérequis, endpoints API, tables de la DB, librairies utilisées, …

  • Les US sont estimées en terme de durée et complexité, pour comparer par la suite avec l'effort réellement apporté

Clone this wiki locally