• A minima un niveau de 6 points métiers est attendu pour les US, donc tout est étudiant sera noté a priori sur 60 pour les US
• A minima 3 points métiers pour les IHMs : donc tout est étudiant est noté a priori sur 30 pour les IHMs
• A minima un niveau de 8 points métiers pour les intégrations est attendu par l'équipe, donc 80 points pour l'intégration

Chaque étudiant obtient une note individuelle basée sur :

• la note obtenue par l'équipe au premier rendu sur la planification
• la note obtenue par chacune des US auxquelles il a participé, pondérée par la valeur métier de la US; exemple : Note à la US 5/10, valeur métier 2 ⇒ 10 points
• la note obtenue par l'équipe dans l'intégration des US au sein de l'équipe et éventuellement avec d'autres équipes :
  • l'intégration de 2 US correspond à une note pondérée par la valeur métier qui est de 2 : elle est évaluée sur la pertinence de l'intégration, objets partagés, interfaces, …
  • l'intégration de 2 US issues de groupes différents suit les mêmes principes que précédemment, mais elle sera ajustée par un coefficient de complexité de 1,5 en fonction de la pertinence de l'intégration et du découpage : exemple : Note à l'intégration entre deux groupes 6/10, valeur métier 2 ⇒ 12 points, découpage justifié entre les deux équipes, pertinence de l'assemblage coefficient s'applique : 18 points
  • Chaque IHM, autre que textuelle, fournie avec une US est évaluée sur la base d'un point métier. Si une IHM, non textuelle, couvre plusieurs US elle est évaluée sur la base d'un point par US exemple : Note à l'IHM 7/10, elle couvre 3 US ⇒ 21 points
  • Chaque étudiant doit avoir participer pour au moins 6 points de US et/ou d'IHM

Dans le cas contraire, un malus s'appliquera en plus.

Une première étude de l'appel d'offre nous a conduit à dégager les “user story”(US) suivantes avec leur poids.

A chaque US doit correspondre :

• sa description
• ses critères d'acceptation
• son évaluation par l'équipe

Une livraison par US

• la US (elle a dû être complétée)
• les développeurs
• Evaluation de la présentation par le groupe
• un ou des Diagrammes de séquence en conception au minimum,
• un diagramme de classes¹⁾ comprenant multiplicité, navigation, …;
• des codes avec leurs tests : la qualité des codes sera considérée;
• Evidemment une US est livrée que lorsqu'elle répond à tous les critères.

Nous considérons alors la US comme “done”. Nous ne la considérons comme “validée” que lorsque le “client” l'a validée.

• Le “product owner” est joué par votre encadreur de TP.
• Chaque équipe peut s'attribuer un “scrum master”²⁾.
• Il n'est pas possible de mélanger les membres des différentes équipes. Il est par contre possible, voir encouragé, d'intégrer les travaux de plusieurs équipes.
• Certaines US sont trop grosses et peuvent faire l'objet d'un redécoupage. Ce redécoupage est discuté avec le “product owner” qui attribue les points métiers aux US.
• Certaines US sont incomplètes. Avec le “product owner” vous devez les compléter. Sans son accord, vous ne pouvez pas ajouter de nouvelles fonctionnalités. La valeur métier d'une US ainsi redéfinie peut être modifiée par le “product owner”.

• Evaluation des US: pour qu'une US passe en “livraison”, elle doit faire l'objet d'une “évaluation” par l'équipe complète qui valide le rendu.
• Intégration des différentes US fait l'objet de discussions au sein de l'équipe.

Première séance, tout ce qui suit doit être rendu :

• Chaque équipe décrit l'ensemble des use cases sans les décrire sous la forme de flots d'événements
  • Objectifs : visualiser l'ensemble des UC répondant à l'appel d'offre (limitez-vous à ceux déduits à partir des histoires utilisateurs).
• Chaque équipe planifie les US qu'elles va prendre en compte,
  • Qui fait quoi? Pas plus de deux personnes par US, les paires doivent changer;
  • les dates de rendus des US prévus,
  • Cette planification est faite dans la forge
• Chaque équipe planifie les IHMs évoluées qu'elle va rendre ou non
• Une équipe peut décider de l'intégration avec les travaux d'une autre équipe.

Dans Les séances suivantes vous travaillerez US par US, en respectant les règles suivantes:

1. Toujours prendre le temps avant de commencer à travailler seul ou en paire sur une US, d'en discuter avec l'équipe (au moins pour validation)
2. Prévoir les tests de validation
3. Une US est livrée que lorsque elle est complète au sens défini dans la partie XXX

Chaque séance pourra faire l'objet d'une livraison.

De quoi s'agit-il?

La matrice Given-When-Then est un format recommandé pour le test fonctionnel d'une User Story: (Given) (Etant donné) un contexte, (When) (Lorsque) l'utilisateur effectue certaines actions, (Then) (Alors) on doit pouvoir constater telles conséquences Par exemple: Etant donné un solde positif de mon compte, et aucun retrait cette semaine, Lorsque je retire un montant inférieur à la limite de retrait, Alors mon retrait doit se dérouler sans erreur ou avertissement Des outils tels que JBehave, RSpec ou Cucumber encour