---
# System prepended metadata

title: Vision déroulement d'un épic

---

# Vision déroulement d'un épic

Le but de ce document est d'avoir une idée claire des responsabilité attendu de chacun durant les différentes phases d'un épic.
Notes: Être reponsable ne veut pas forcément dire que c'est à lui de faire le travail. Il peut déléguer certaines tâches, mais il a la responsablitlé de s'assurer que les tâches sont complétées :slightly_smiling_face: 

## Création de l'épic
Le PO responsable s'occupe de créé l'épic et documente le pitch de l'épisode. Le plus détails qu'il peut fournir sur les éléments suivant, le meilleur

* OKR (Objectives and Key Results) / KPI (key performance indicator) à atteindre
* Flows à supporter
* Cas limites
* Risques accociés au projet
* Phases de developpenent (dans le cas d'une télésérie)
* Inclusions/exclusions
* Budget (soit en USP et/ou semnaine) alloué à l'épsiode
Inclure toutes les informations pertinentes retenu de slack, productboard, figma est un +.


## Rencontre kickoff
Le PO planifie une rencontre avec l'équipe de développement assigné à l'épic ainsi que les stratèges clés (designer UI/UX, Reponsable produit, Architecte en charge d'approbation d'épisode de l'équipe, Responsable de communications...).

Le but de la rencontre est d'informer tout ce monde des grandes lignes de l'épisode et d'effectuer un brainstom sur les points soulever plus haut et d'aligner la suite de l'analyse.
* Retravailler sur les maquettes
* Documenter des scénarios d'utilisations
* Créer des tickets d'explorations techniques à réaliser
* Uniformiser certains comportements à travers l'application
* Savoir ce qui est réutilisable dans nos micro-services, composante frontend...
* Découper le projet en phases s'il est trop gros et réfléchir l'implémentation en considérant où est-ce qu'on veut s'en aller
* ...

## Analyse fonctionnelle
Le PO et les designers collabore pour faire avancer/approuver l'analyse fonctionnelle
À la fin de l'analyse fonctionnelle, je m'attend à ce que
* Épics est à jour les points mentionnés lors de la création de l'épic
* Les maquettes finales soient approuvées
* La révision des textes soit effectuée
* Le QA ait pris connsaissance de l'effort à mettre au niveau des tests automatisés à réaliser
* Documentations des métriques à collecter durant la phase pilotes et OnAir pour s'assurer qu'on atteint nos OKR/KPI


## Analyse technique
L'architecte peut de façon indépendante coordonner les explorations de différents aspects dans l'analyse technique, soit des nouvelles technos à explorer et/ou éliminer les risques/cas limites pour s'assurer que le développement de l'épic se passse sans grande surprise.
Ce n'est pas nécessairement lui qui doit effectuer seul l'analyse. L'équipe peut contribuer à celle-ci, mais l'architecte devrait encadrer de façon claire qu'elles sont les finalités à atteindre pour chaque morceaux d'analyse et de timeboxer ceux ci afin de ne pas trop diverger.


À la fin de l'analyse technique, je m'attend à ce que
* Les schémas finaux (C4, séquences, classes...) soient documentés dans l'épic 
* Preuves de concept et/ou toutes documentations pertinentes sur les différetentes analyses techniques effectué
* Documentation sur le monitoring à mettre en place pour s'assurer du bon fonctionnement de la fonctionnalité (Le gardien applicatif participe fortement à mettre le bon monitoring en plance)
* Création d'un backlog pour l'épisode
* Identifier ce qui pourrait être de la RSDE potentiel dans l'épic

## Approbation d'épisodes
PO et Architecte sont responsable de préparer Les approbations de l'analyse fonctionnelle et techniques respectivement. Ceux-ci peuvent se faire de façon indépendante (fonctionnelle viens souvent avant par contre).

Une fois les analyses complétés, il est important de rediscuter du budget nécessaire pour compléter l'épisode. L'estimation initiale peut être erroné selon les analyses et il est nécessaire de revoir le buget dans cette situation à savoir si on alloue plus de temps que prévue initialement pour compléter l'épisode et/ou s'il faut exclure certain morceaux pour respecter le temps alloué.


## Grooming 
L'architecte prépare une rencontre d'équipe pour groomer le backlog.
Le but de la rencontre est qu'on présente à l'équipe les différents tickets à implémenter et priorisé le backlog selons la priortié des tickets et les interdépendances entre ceux-ci.

## Implémentation de l'épisode
Le PO, Scrum Master s'assure du bon déroulement de l'épsiode implémenté par l'équipe

### Sprint
Le scrum master s'occupe du day to day, que l'équipe travaille sur les objectifs de sprint et fait l'intermédiaire entre PO et l'équipe (s'il y a des enjeux fonctionnelles sont à réviser durant la phase d'implémentation() ou avec l'architecte (s'il s'agit plus d'enjeux techniques).

### Sprint review
Animé par le scrum master, l'équipe est responsable de présenter les avancements des dernières semaines. Ces un bon moment pour discuter si l'épic avance à la vitesse prévue et/ou des ralentissement imprévue impact les dates de livraisons estimés.

Le PO et autres parties prenantes sont présent lors des sprints reviews. Ils peuvent durant cette rencontre apporter des ajustements au scope de l'épisode (Ajouter/retirer des features et revoir les délais).

## Pilotes et OnAir
Le PO est responsable de récolter les commentaires des utilisateurs durant la phases pilotes. Il peut discuter par la suite avec l'équipe et autres parties prenantes les changements à effecter et/ou de documenter des demandes d'amélioration sur ce qui serait à implementer dans une phase ultérieure
Le PO est également responsable de récolter les métriques d'utilisations et des atteintes des OKR/KPI

Le gardien applicatif monitor s'il n'y a pas d'erreur avec l'activation de la fonctionnalité et que ça n'a pas eu d'impact négatifs dans le reste de l'applicaiton non plus.
Si des bugs sont détecté (soit par notre propre monitoring et/ou par les clients), il est responsables de documenter des tickets et priorisés ceux-ci.

## Definition of Done
S'il y a eu des modificaitons en cours d'implémentation d'épsiode, Le PO et architecte sont responsables de remettre la documentation à jours dans l'épic.

### RSDE
L'architecte (et/ou responsable RSDE) de l'équipe à la redevabilité qu'un document RSDE soit rédigé pour l'épic. Toute l'équipe est responsable toutefois d'identifier/documenter dans leur ticket s'il y a de la RSDE potentiel observé durant l'analyse, l'implémentation et/ou en support niveau 3. 
