Simulic
Français

Sprint agile de développement – planifier, développer, tester, livrer

InformatiqueMétiers de l'informatique17–18 ans

Chargement…

Partager Signaler un problème

Une petite équipe logicielle mène un sprint agile pour créer une appli de clubs scolaires : choisissez dans le backlog les user stories qui tiennent dans la capacité de l'équipe, puis simulez le sprint jour après jour. Les cartes passent par les colonnes À faire, En cours, Test et Terminé, un graphique burndown suit les points restants, et les bugs créés en codant sont repérés par les tests ou arrivent chez les utilisateurs. Le sprint se termine par une revue qui note la satisfaction du client.

Leçon : Métiers du développement logiciel : la démarche agile et les rôles de l'équipe

Ce qu’elle montre

Cette simulation montre comment une vraie équipe logicielle travaille pendant un sprint agile. Le product owner a classé par valeur les user stories d'une appli de clubs scolaires ; l'équipe s'engage sur celles qui tiennent dans sa capacité, estimée à développeurs × jours × 0,8 point. Chaque jour, des stories sont développées, des bugs apparaissent dans le nouveau code, et les tests ou la revue de code en attrapent une partie. Sauter les tests accélère le développement, mais davantage de bugs atteignent les utilisateurs. Un burndown suit l'avancement et la revue de sprint note la satisfaction du client. Les coefficients sont des hypothèses illustratives.

Mode d’emploi

Choisissez une option de Planification ou cochez vous-même les stories, réglez Développeurs, Testeurs, Jours et Temps de test, puis activez ou non la revue de code. Appuyez sur Avancer d'1 jour pour parcourir le sprint ou sur Lancer le sprint pour l'animer, et observez le tableau, la courbe burndown et le compteur de bugs. Comparez la revue de sprint après avoir changé un réglage et utilisez Autre scénario pour voir la variation aléatoire.

Paramètres modifiables

  • Planification du sprint Adapté à la capacité, Tout le backlog, Choix manuel
  • Nombre de développeurs 2–6 personnes
  • Nombre de testeurs 0–2 personnes
  • Durée du sprint 5–15 jours
  • Temps des développeurs consacré aux tests 0–40 %
  • Revue de code entre pairs

Questions à explorer

  1. De combien l'équipe va-t-elle plus vite sans temps de test, et combien de bugs de plus atteignent les utilisateurs ?
  2. Pourquoi prendre tout le backlog fait-il souvent baisser la satisfaction du client ?
  3. Qu'apporte chaque rôle (product owner, développeur, testeur) à la réussite d'un sprint ?

Simulations associées