Évaluation du cours

La grille d'évaluation du cours Méthodologie de projet, fondée sur l'état final du repo de l'équipe côté gestion de projet.

Documentation réalisée à 80% 80
Créée par :  Adrien Bracq

Ce qui est évalué

Le cours évalue la gestion de votre projet, pas sa technique : la qualité de la machine, du code ou des pièces est évaluée dans le cadre du projet lui-même.

L’évaluation porte sur l’état de votre repo à la fin du cours, à une date communiquée en séance (avec quelques jours de marge après la dernière séance). Tout ce qui est dans le repo à cette date compte, y compris l’historique : les dates des commits montrent si le travail a été fait régulièrement ou la veille.

Part Poids Ce qu’on regarde
Individuelle 60 % Votre journal de bord et vos contributions au repo
Groupe 40 % Le cadrage, l’organisation et la lisibilité de la documentation de l’équipe
  Pourquoi autant d'individuel ?

Le journal de bord est la trace la plus directe de ce que vous avez fait, compris et décidé. Il se construit séance après séance : c’est ce qui rend la documentation au fil de l’eau payante.

Part individuelle (60 %)

Élément Ce qui doit apparaître
Journal : régularité Une entrée datée par séance, projet et méthodologie, dans votre dossier docs/journal/
Journal : contenu Chaque entrée dit ce qui a été fait, pourquoi (décisions, problèmes rencontrés) et ce qui reste à faire. Une personne extérieure la comprend sans explication
Contributions au repo Des commits faits depuis votre compte GitHub, réguliers, avec des messages qui disent ce qui change
Participation à la gestion Issues créées, assignées et fermées ; relectures faites pour les autres

Voir Tenir un journal de bord et Git, GitHub Desktop et VSCode.

Part groupe (40 %)

Élément Ce qui doit apparaître
Cadrage objectifs.md : contexte, problème et public cible, cahier des charges avec des critères mesurables
Organisation equipe.md : un responsable et un backup par rôle. Issues et jalons utilisés et tenus à jour
Traçabilité des choix Les choix importants sont écrits avec les alternatives envisagées et la raison de la décision
Lisibilité et transmissibilité README à jour, plus aucun marqueur a_modifier / a_supprimer, pages structurées (titres, figures légendées, sources)

Voir Définir son besoin et son cahier des charges, Constituer et organiser son équipe, Gérer son projet avec GitHub et Tracer ses choix techniques.

Avant la date de rendu

Parcourez la checklist de clôture de projet avec votre équipe : elle reprend ces critères point par point.