Pourquoi cette séance maintenant?

• Selon le plan de cours, les semaines 5 à 7 sont dédiées au Sprint 2 (MVP).
• En semaine 7, vous remettez le dossier de présentation du MVP avec une démonstration fonctionnelle (20%).
• Le but n'est pas d'ajouter beaucoup de fonctionnalités.
• Le but est de livrer une première version fiable du noyau scientifique.

Sortie attendue en 30 minutes

À la fin de la séance, votre equipe doit avoir :

• une vertical slice MVP claire (entrée -> traitement -> sortie);
• trois tickets critiques priorisés pour la semaine en cours;
• une définition de terminée partagee;
• un scénario de démo fonctionnelle pour la semaine 7.

MVP utile vs MVP trop ambitieux

Choisissez ce qui maximise ces 4 critères :

• valeur immédiate pour l'utilisateur cible;
• faisabilité en 3 semaines;
• réduction d'un risque scientifique majeur;
• capacité a etre démontre en direct.

Évitez :

• les écrans cosmétiques sans logique de calcul;
• les options avancées qui bloquent le flux principal;
• la perfection technique avant la preuve de valeur.

Vertical slice : le minimum qui compte

Votre tranche MVP doit couvrir :

• Entrée : paramètres scientifiques minimaux valides.
• Traitement : calcul/simulation centrale qui tourne.
• Sortie : résultat interpretable (valeur, courbe, tableau).
• Validation : un test de plausibilité ou comparaison simple.

Si un élément manque, ce n'est pas encore un MVP démonstrable.

Definition de terminée (DoD) - Sprint 2

Un ticket est "terminé" seulement si :

• les critères d'acceptation sont vérifiés;
• la MR est revue par un pair;
• le comportement est démonstrable localement;
• la limite connue est documentee (si presente);
• le ticket est relié au jalon Sprint 2 - MVP.

Plan 3 semaines (S5-S7)

• Semaine 5 : premier flux complet de bout en bout.
• Semaine 6 : stabiliser, traiter les cas d'erreur, réduire la dette.
• Semaine 7 : figer v0.1.0, preparer la démo et le dossier MVP.

Règle d'exécution :

• garder peu de tickets "En cours";
• finir petit et integrer souvent;
• privilégier une tranche verticale complete.

Qualité scientifique minimale en Sprint 2

Pour chaque fonctionnalité MVP, rendre explicite :

• l'hypothèse scientifique utilisée;
• les variables/unités attendues;
• une vérification de résultats (ordre de grandeur, cas test, comparaison);
• les limites connues du modele.

Sans validation minimale, la démo perd de la crédibilité.

IAg : autorisée, mais responsabilité complete

Rappel du plan de cours :

• declarez les usages de l'IAg (outil + type d'aide + sections concernées);
• vous restez responsables du code soumis;
• vous devez pouvoir expliquer et modifier tout le code en démonstration.

Si vous ne pouvez pas justifier une portion de code, elle peut etre pénalisée.

Micro-atelier (8 minutes)

1. 3 min : choisissez une seule vertical slice pour v0.1.0.
2. 3 min : rédigez 3 tickets critiques avec critères d'acceptation.
3. 2 min : écrivez le scénario de démo (données d'entree, action, résultat attendu).

Sortie attendue : un mini-plan MVP executable des aujourd'hui.

Checklist de sortie de seance

• [ ] Vertical slice MVP nommée et comprise par toute l'equipe
• [ ] 3 tickets Sprint 2 priorisés et assignés
• [ ] DoD commune validée par l'equipe
• [ ] Scenario de démo fonctionnelle écrit
• [ ] 1 risque technique et 1 risque scientifique identifiés
• [ ] Prochain point de contrôle fixe (date + responsable)

À retenir

• En Sprint 2, la largeur du produit compte moins que sa démonstrabilite.
• Une version v0.1.0 simple, fiable et explicable vaut plus qu'un produit incomplet.
• Votre progression sera jugée sur ce qui est livrable, testable et défendable.

Prochaine étape : executer le plan MVP dès cette semaine.