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 :
Que veut dire livrer une US ?
Aborder le découpage d'une application en tâches élémentaires.
Comprendre l'intérêt du découpage d'une application en tâches élémentaires.
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)
(15mn) Explications
sur l'activité, les objectifs
Présenter l'étude de cas.
Discuter le principe des user-stories.
Tous les ordinateurs sont “éteints”.
(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
(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.
(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 mn) Chaque PO enregistre (ou fait enregistré) sur sa fiche les prévisions des équipes.
(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.
(7 mn) Partages entre équipes
(20 mn) Débriefing
Qui passe le test donné au tableau par le professeur?
Jusqu'où êtes-vous allé ? Indiquez la position approximative de chaque équipe relativement
Visualiser au tableau, la différence entre les prévisions et la réalité des US prévues et traitées
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é ?
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 ?