Scope Review

Comment bien aborder la scope review ?

  1. En amont de 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 spécifiques 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 début de projet tech.
  2. Pendant la scope review
    1. Posez des questions, laissez place à la discussion, soyez curieux.se.s !
  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 à tous les quiproquo 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.

Quelques quiproquo classiques

Voici quelques termes utilisés dans le cadre de projets tech qui peuvent avoir plusieurs significations. Nous vous invitons à être très vigilant.e.s lorsque vous les employez, et à accompagner ces termes d'une discussion/définition afin de s'assurer que tout le monde parle de la même chose.

"Maquettes" | S'agit-il d'une maquette fonctionnelle et cliquable ? D'un parcours utilisateur clair ? De simples croquis sans graphisme ? Sont-ils dans un format réutilisables ? Sur des feuilles de papier ?
▸ Pour aller plus loin :

"Base de données" | Sous quelle forme est cette "base de données" ? En informatique une "base de données" désigne quelque chose de bien précis : des tables de données - souvent implémentées en SQL pour les bases de données dîtes "ordonnées". Certain.e.s personnes peuvent utiliser le terme "base de données" pour d'autres choses, comme un tableau Excel, un csv ou des équivalents de ces choses-là, ce qui regroupe les "données" en soi.
▸ Pour aller plus loin :

"Back-office" | Le terme "back-office" désigne l'interface utilisée pour mettre à jour le contenu visible par les utilisateurs ("front-office"). Selon le type de back-office souhaité celui-ci peut prendre autant - voire plus - de temps de développement que le front office. Anticipez cette question en vous demandant qui va reprendre l'outil développé à la suite du projet Tech for Good Explorers. Cette personne a-t-elle besoin d'une interface "user-friendly" ? Il peut parfois être plus judicieux de revoir à la baisse le nombre de fonctionnalités du front-office pour développer un back-office que de laisser la structure bénéficiaire sans moyen pour mettre à jour l'outil développé.

"Utilisateurs" | Est-il nécessaire d'inclure une base d'utilisateurs à votre outil ? Y-a-t'il déjà une base d'utilisateurs qu'il faudra inclure au sein de la nouvelle solution ? Faut-il mettre en place des comptes d'utilisateurs ? Qui gérera la logique de création/modification/suppression des comptes ? Les utilisateurs ont-ils tous les mêmes droits d'administration ? Cela fait-il parti du périmètre du projet ? Autant de question qu'il faut se poser avant le début de la phase de prototypage.

"Documentation" | Reprendre le code de quelqu'un d'autre est complexe. Afin de faciliter la reprise du projet, il est nécessaire de commenter et documenter son code. Accordez-vous ensemble sur le type de documentation choisi en vous demandant si des pratiques existent déjà en interne et en identifiant la personne qui va reprendre le code une fois le projet terminé.
▸ Pour aller plus loin :

"Mise en production" | La mise en production - aussi appelée "déploiement", "mise en prod" ou "publication" - désigne le fait de rendre accessible le produit au public ciblé. Pour cela, la solution doit être hébergée sur un serveur. Accordez-vous sur qui met à disposition ce serveur et de qui se charge de la "mise en prod" (fait de mettre le code sur ce serveur dédié) : la structure bénéficiaire, les étudiant.e.s, l'école, le/la mentor ? Pour le cas particulier du développement mobile, on parle de "build" pour désigner le fait de créer un fichier partageable et directement lisible par un smartphone : une app. Cette "mise en prod" ou "build" fait-elle partie du travail des étudiant.e.s ? Si oui sont-ils/elles bien outillé.e.s pour le faire ? Si non la structure bénéficiaire sera-t-elle en mesure de l'effectuer par elle-même grâce à la documentation des étudiant.e.s ?