-
Notifications
You must be signed in to change notification settings - Fork 22
Organisation projet
L'organisation au sein du projet s'appuie sur la méthodologie agile Scrum. Un sprint a une durée de deux semaines.
L'organisation s'appuie sur 3 cérémonies :
- Péridoicité ? Journalière
- Horaire ? 9h30
- Durée ? 30 min
- Qui ? PO + Devs
Le PO commence :)
- Questions sur des éléments de la veille
- Point sur des sujets importants de la journée
Puis vient au tour des devs :
2 min par personnes, pas d'interruption à part du PO (on essaie de garder nos questions pour la fin 🙂 ).
- Qu’ai-je fait hier ?
- Que vais-je faire aujourd’hui ?
- Quels sont les points de blocage existants qui m’empêchent d’avancer ?
- Péridoicité ? Toutes les 2 semaines
- Horaire ? Jeudi à 14h
- Durée ? 1 à 2 heures
- Qui ? PO + Devs
En amont :
- Création de la liste des tâches par Romain. Les tâches sont ordonnées de la plus importante à la moins importante.
- Chacun fait une passe sur les tickets permettant de remonter en amont les interrogations sur le sujet.
Le jour J, sprint planning sous forme de poker planning. Le poker planning s’effectue sous la forme de point de complexité sur chaque tâche.
On va utiliser la suite de Fibonacci, voici un exemple d’étalonnage:
- 1 : Mettre à jour un wording sur un simulateur
- 2 : Ajouter un modèle de document
- 3 : Mettre à jour le nom d’une CC
- 5 : Mettre en place le questionnaire sur le parcours / Ajouter une CC classique
- 8 : Ajouter une CC complexe aux simulateur d’indemnité
- 13 : Implémenter les conventions collectives sur l’indemnité de licenciement
- 21 : Revoir l’export de la BDD hasura dans ES
A partir de 13, la tâche doit être revue pour être découpée en plus petites tâches.
Ceci est un exemple, les points de complexité vont se mettre en place au fil du temps. ils vont évoluer car on sera de plus en plus à l’aise sur certains points et cela fera baisser la complexité de certains sujets.
Note :
Il faut faire attention à ne pas confondre complexité et durée. La frontière est fine mais il ne faut pas se dire : Combien de temps cela va me prendre ? Mais Comment vais-je mettre cela en place ?
Exceptions:
- Les bugs ne sont pas estimés car impossible à estimer. Cependant, on peut time boxer pour éviter de passer trop de temps sur le bug si pas jugé critique.
- Les tâches de type R&D (analyse/POC) ne sont pas estimées. On peut également time boxer pour se donner un ordre d’idée du temps que l’on souhaite y consacrer. Celui ci peut être revu, par exemple, dans le cas où l’on est rapidement bloqué ou l’on trouve des choses intéressantes à approfondir.
- Péridoicité ? Toutes les semaines
- Horaire ? Lundi à 14h
- Durée ? 1 heure
- Qui ? Toute l'équipe CDTN
- Présentation de l'avancement des devs + les devs finalisés à la fin d'un sprint
- Discussion avec l'équipe métier des sujets en cours et à venir
- Discussion avec l'équipe chargé du déploiement sur l'avancement des sujets