TD2 : Savoir décomposer un problème

SMARTIE Party !

Nous adaptons ici l'exerce de Alistair Cockburn1) à notre contexte d'enseignement. L'implication de tous et en particulier des étudiants est indispensable pour que cette séance soit constructive et amusante!

Description en français de l'exercice vu par Frank Taillandier.

Nos objectifs sont :

  1. Que veut dire livrer une US ?
  2. Aborder le découpage d'une application en tâches élémentaires.
  3. Comprendre l'intérêt du découpage d'une application en tâches élémentaires.
  4. Auto-Evaluer vos capacités de production.

Ce que nous allons faire

Construire une application simple en 40 minutes de développement, divisées en 5 itérations de 8 minutes. Beaucoup développeraient cette application en découpant en 2-3 tranches, nous la découperons en 15-20 tranches. Elephant Carpaccio = tranches très fines, chacune a quand même la forme de l’éléphant, ensemble elles constituent l’éléphant entier.

Déroulement (Voir recommandation pour le professeur ici)

  1. (15mn) Explications
    • sur l'activité, les objectifs
    • Présenter l'étude de cas.
    • Discuter le principe des user-stories.
    • Tous les ordinateurs sont “éteints”.
  2. (5mn) Choisir 4 étudiants (PO) qui auront la charge de valider les US
    • leur distribuer les fiches de suivi
    • les verres à mettre devant les équipes
    • les smarties à distribuer
  3. (5mn) Former des équipes de 2 à 3 étudiants ⇒ ~8 groupes ⇒ 2 groupes par étudiant PO
    • Dans chaque équipe un seul ordinateur.
    • Environnement et langage de développement libre.
    • Entre les 2 équipes d'un PO, et encore moins entre les groupes, il ne doit pas y avoir d'échanges.
  4. (20 mn)
    • Les équipes découpent l'étude en “user stories” écrites sur Papier.
      • Il faut au moins 10 US.
      • Elles sont estimées programmables dans un temps de 2 à 6 minutes chacune,
      • Chacune est potentiellement “démontrable” et surtout estimable.
      • Une US n’est valide que si elle comprend UI, entrée sortie et est visuellement distincte d'une autre US. Une UI peut être une simple console.
      • Aucune US n’est composée que d’une maquette ou d’une interface, d’un jeu de données ou d’un test.
      • On n'attend pas de bases de donnée, d'IHM, …
    • Les PO vérifient qu'ils comprennent bien les US, qu'ils sauront les estimer, etc.
    • Les équipes décident des US qu'elles sont capables de délivrer dans les 5 Sprints de 7 mn qui suivent. Elles pourront créer de nouvelles US en cours de cycle mais attention de bien les valider avec le PO.
  5. (5 mn) Chaque PO enregistre (ou fait enregistré) sur sa fiche les prévisions des équipes.
  6. (40 mn) Exécutez 5 sprints de programmation de 7 min.
    • Pendant le Sprint de programmation, dès qu'une US est prête à être livrée,
      • Crier “Livraison” mais pas trop fort quand même 2)
      • Vous la présentez au PO.
      • Il peut la rejeter si elle ne correspond pas à ce qui a été défini avec lui.
      • S'il l'accepte, l'équipe reçoit dans le verre placée devant-elle 3 smarties.
      • Le PO note la US livrée et le temps par exemple 3eme minute du Sprint.
      • Evidemment vous avez compris qu'une livraison “coûte du temps de programmation”, donc il vaut mieux tester vos US avant de les livrer.
      • En mémorisant les tests, vous vous assurez de ne rien casser!
    • À la fin de chaque sprint, le chrono retentit pour signaler que l'on passe au Sprint suivant. Le Chrono ne s'arrête pas et repart aussitôt.
      • Une US livrée correspond à 3 smarties, mais que si le PO décide qu'elle correspond bien à ce qui était annoncé.
  7. (7 mn) Partages entre équipes
    • Chaque équipe d'un PO fait une démonstration à une équipe d'un autre PO et inversement.
    • Pendant ce temps les PO et le professeur font le point pour préparer l'étape suivante.
  8. (20 mn) Débriefing
    • Qui passe le test donné au tableau par le professeur?
      • Pour tous ceux qui passent le test, écrire le résultat au tableau….
      • Tout le monde trouve pareil?
    • Jusqu'où êtes-vous allé ? Indiquez la position approximative de chaque équipe relativement
      • au nombre de US réalisées puis
      • relativement à la valeur, en particulier
        • qui a géré au moins un état?
        • qui a géré tous les états état?
        • qui a géré les remises?
    • Visualiser au tableau, la différence entre les prévisions et la réalité des US prévues et traitées
      • Savez-vous mieux vous estimer ?
    • Constatez-vous une évolution du nombre de US traitées au fil du temps ?
    • Les PO comment avez-vous vécu la séance?
    • Pour les développeurs : comment ça a été ?
      • Quelle est la qualité de votre code ? êtes vous fier de de votre code ? (chaque développeur lève entre 1 et 5 doigts)
    • Tour de salle : Qu’avez-vous appris ? Qu’allez-vous faire ? Nommez une idée avec laquelle vous repartez aujourd’hui, et une chose que vous ferez différemment à l’avenir.
    • D’autres questions ou réflexions ?
2)
juste pour mettre la pression sur les autres équipes ;-)