Pourquoi Agile pour votre projet intégrateur?

• Projet scientifique = incertitude élevée au départ
• Risque : construire longtemps et découvrir trop tard que ça ne marche pas
• Agile = boucles courtes : livrer tôt, valider, ajuster

Agile (en 1 phrase)

Un mode de travail itératif : on livre souvent, on apprend, on ajuste.

Les 4 valeurs (version terrain)

• Valeur du produit > paperasse
• Collaboration > travil en silos
• Ajustement > plan figé
• Qualité continue > "on fixera à la fin"

Ce qu'Agile n'est pas

• "Pas de plan"
• "On improvise"
• "On code sans doc"
• "On fait juste des standups (réunions)"

Votre cadence (plan de cours)

• S3-S4 : Sprint 1 - conception prototype (wireframes, cadrage)
• S5-S7 : Sprint 2 - MVP (noyau scientifique)
• S8-S10 : Sprint 3 - itération V2 (validation)
• S11-S14 : Sprint 4 - stabilisation + livraison

La boucle courte (ce qu'on veut faire)

1. Définir une hypothèse testable
2. Livrer un petit incrément
3. Mesurer / valider
4. Ajuster la prochaine itération

Scrum léger : 3 artefacts minimum

• Backlog produit : tout ce qu'on veut faire (priorisé)
• Sprint backlog : ce qu'on fait maintenant
• Incrément : un morceau utilisable (même petit)

Tranche verticale (important)

Préférez une tranche "de bout en bout" plutôt que :

• 10 écrans sans logique
• un modèle parfait sans interface

Rôles dans l'équipe

• Product Owner (PO) : priorité, valeur, décisions produit
• Scrum Master (SM) : facilite, enlève obstacles, protège le focus
• Responsable scientifique (RS) : hypothèse, validation, rigueur et interprétation
• Dev/Build : conçoit + code + teste + doc (tout le monde)

Rôle : Product Owner (PO)

• Porte la vision du produit (pour ce cours : valeur + contraintes d'évaluation)
• Priorise le backlog et tranche quand il faut choisir
• Clarifie les récits utilisateurs et leurs critères d'acceptation
• Synchronise avec le prof (et l'expert midi-sciences)

Rôle : Scrum Master (SM)

• Fait respecter la cadence (standups, planning, review, rétro)
• Rend le travail visible (tableau, blocages, décisions)
• Protège le focus et aide à débloquer l'équipe
• Favorise une collaboration saine (conflits, communication)

Rôle : Responsable scientifique (RS)

• Écrit/clarifie l'hypothèse et les hypothèses secondaires
• Définit la méthode de validation (données, métriques, comparaisons)
• Vérifie unités, ordre de grandeur, plausibilité et limites du modèle
• S'assure que les résultats sont interprétables et bien communiqués

Rôle : Équipe Dev/Build

• Transforme le backlog en incréments utilisables
• Conçoit l'architecture minimale (simple, testable)
• Implémente, teste/valide, documente, intègre souvent
• Maintient la Définition de terminé (qualité continue)

Choisir vos rôles

Critère simple :

• PO : tranche et clarifie
• SM : cadence et collaboration
• RS : rigueur scientifique et validation
• Tous : qualité + livraison

Récit utilisateur (format simple)

En tant que [type d'utilisateur]
Je veux [objectif]
Afin de [valeur]

Exemple :
"En tant qu'étudiant, je veux visualiser l'évolution de X afin de comprendre l'impact de Y."

Critères d'acceptation

Format "Étant donné / Quand / Alors" (3-5 max)

Exemple :

• Étant donné un dataset valide
• Quand je lance la simulation
• Alors je vois une courbe avec unités + un résultat reproductible

Prioriser (simple)

• Impact (valeur / apprentissage / évaluation) vs Effort (temps / complexité)
• Règle : commencer par l'item qui réduit le plus le risque

Estimer (sans se perdre)

T-shirt sizes :

• S = 1-3h
• M = 0.5-1 jour
• L = 2-3 jours
• XL = trop gros -> découper

Définition de terminé

Un item est "terminé" si :

• fonctionne sur les différents ordinateurs de l'équipe
• est intégré à la branche principale (main)
• a une validation (test, comparaison, exemple reproductible)
• a une mini doc (README / note de décision / comment reproduire)

Le principe clé

"Terminé" > "Presque fini"

Un item n'existe pas tant qu'il n'est pas : intégré, testé/validé, démontrable.

Collaboration (règles simples)

• Rendre le travail visible (backlog à jour)
• Préférer petites MR/PR et intégration fréquente
• Se parler tôt quand ça bloque (pas le lendemain)
• Noter les décisions (même 3 lignes)

Atelier - Backlog initial

Pour votre idée :

1. Écrire 5-10 récits utilisateurs
2. Ajouter 2-3 critères d'acceptation par récit
3. Estimer en S/M/L
4. Prioriser les 5 premières

À faire (avant la prochaine séance)

• Créer votre projet GitLab (1 dépôt par équipe)
• Ajouter un README.md initial :Réutilisez les informations de la fiche projet présentée aux midi-sciences.
• Ajouter un BACKLOG.md : 5-10 items priorisés (récits utilisateurs + critères d'acceptation)
• Faire un premier commit (et pousser sur GitLab)