Scope Review : Différence entre versions

(Une checklist de choses à ne pas oublier)
(Une checklist de choses à ne pas oublier)
Ligne 32 : Ligne 32 :
 
<br>🗹 Ce livrable est découpé en différentes fonctionnalités que nous pourrons prioriser à nouveau si nécessaire.
 
<br>🗹 Ce livrable est découpé en différentes fonctionnalités que nous pourrons prioriser à nouveau si nécessaire.
  
🗹 Nous avons fait attention aux [[Glossaire de termes techniques|quiproquo classiques]] qui peuvent nous concerner.
+
🗹 Nous avons fait attention aux [[Glossaire de termes techniques|quiproquos classiques]] qui peuvent nous concerner.
  
 
==Quelques conseils spécifiques==
 
==Quelques conseils spécifiques==

Version du 30 octobre 2018 à 20:53

Une scope review réussie en 3 étapes :

  1. Avant la scope review
    1. Latitudes vous propose une trame de scope review qui aborde les points qui nous semblent importants à ce stade du projet. Inspirez vous-en pour structurer votre réunion.
    2. Soyez sûr.e.s d'aborder les points présents dans cette page avec une checklist de choses à ne pas oublier, et quelques conseils spécifiques sur la position à adopter selon votre rôle au sein du projet.
    3. Pour aller plus loin vous pouvez allez voir notre glossaire de termes techniques afin de vérifier que vous ne tombez pas dans les quiproquos classiques de projet tech.
  2. Pendant la scope review
    1. Posez des questions, laissez place à la discussion et aux échanges, soyez curieux.se.s !
    2. Ne partez pas de la réunion avant d'avoir coché toutes les cases de la checklist de choses à ne pas oublier, levez toute ambigüité possible au plus vite !
  3. Après la scope review
    1. Pensez bien à remplir la section "phase d'exploration" de votre page projet. On vous remercie par avance pour votre contribution à ce beau wiki ! 😊

Une checklist de choses à ne pas oublier

Ne sortez pas de la scope review sans avoir coché toutes ces cases !

🗹 Les étudiant.e.s ont accès à tous les documents existants (code, maquette…) ou bien savent comment y avoir accès.

Nous avons produit une roadmap qui prend en compte :
🗹 la phase de montée en compétences des étudiant.e.s.
🗹 les besoins de ressources (données, templates, accès…).
🗹 les séances de travail, vacances, indisponibilités de chacun.e (étudiant.e.s, porteur.se de projet, mentor, autres parties prenantes intervenants dans la mise en œuvre du projet.

🗹 Nous nous sommes accordé.e.s sur le livrable final de manière précise.
🗹 Ce livrable est découpé en différentes fonctionnalités que nous pourrons prioriser à nouveau si nécessaire.

🗹 Nous avons fait attention aux quiproquos classiques qui peuvent nous concerner.

Quelques conseils spécifiques

Je suis étudiant.e

Mon équipe est responsable du bon déroulé de cette scope review.

  • Je suis proactif.ve et rigoureux.se dans la préparation de cette réunion.
  • Je n'hésite pas à contacter mon/ma mentor en amont de la réunion pour lui demander des conseils.
  • Je communique les détails pratiques pour la scope review (date, lieu, matériel nécessaire si documents à projeter, etc).

Je suis mentor

J'accompagne les étudiant.e.s et les aide à avoir une démarche professionnelle dans la conduite de cette scope review.

  • J'évoque la question au sein de l'un de nos stand-up meeting pour m'assurer que cela est sur de bons rails.
  • Je les invite à prioriser les fonctionnalités qu'ils/elles souhaitent implémenter.
  • Je les aide à prendre du recul sur leurs estimations et les conseille sur la mise en place d'outils de suivi pour la suite (Trello ou équivalent).

Je suis porteur.se de projet

Je m'assure que les étudiant.e.s ont une vision claire des enjeux du projets et des étapes à venir.

  • Je les accompagne dans la définition du périmètre du projet - en étant conscient.e des besoins de ma structure et du temps dont l'équipe dispose.
  • Je transmets les besoins de ma structures pour aider l'équipe à prioriser les fonctionnalités à implémenter.
  • Je complète ce que les étudiant.e.s me présentent lorsque cela me semble nécessaire.