User Tools

Site Tools


2014_2015:s3:concprogobjet:td:td2

This is an old revision of the document!


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 sur sa fiche ou au tableau
  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, elle est présentée 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”.
    • À 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. (10 mn) Partages entre équipes
    • Chaque équipe d'un PO fait une démonstration à une équipe d'un autre PO et inversement.
      • Aviez-vous les mêmes US?
      • Avez-vous développer les mêmes US?
  8. (10 mn) Débriefing
    • Visualiser la différence entre les prévisions et la réalité
    • Constatez vous une évolution du nombre de US traitées?
2014_2015/s3/concprogobjet/td/td2.1409238421.txt.gz · Last modified: 2014/08/28 17:07 by blay