Développement en Sprint 1

1. 7mn en temps chronométré par équipe pour faire le point sur les avancés réalisées et la répartition du travail sur la séance à venir. L'enseignant n'intervient pas, si ce n'est pour rappeler la fin du temps. les équipes s'auto-organisent.
2. Chaque étudiant ou par paire si nous n'avons pas assez de machine, travaille sur sa partie de projet le reste de la séance modulo les interactions ci-après.

• Dans le temps de développement, le chef de projet a la responsabilité de s'assurer que les développements convergent.

Attention la répartition du temps dans les séances qui suivent est une suggestion. Si vous avez un autre point de vue sur l'organisation au sein du groupe, tentez-le mais, les points suivants sont non négociables :

• Les dates de livraison sont non négociables. Si vous ne livrez pas pendant la séance où vous êtes prévus, vous avez un 0. Il vaut donc mieux ne rendre qu'une partie des US que RIEN.
• Tous les étudiants travaillent et chacun produit individuellement au cours de la séance : VOUS AVEZ TOUS les connaissances pour faire avancer votre projet !
• Gardez l'oeil sur les livrables!
• Attention la non-concordance entre les US et les livrables est synonyme d'erreur et donc de points négatifs.
• Cette étude doit vous conduire à affiner les US, surtout capitalisez bien tout changement dans leur description, critères ou autres dans le kanban.
• Si la répartition change ou si de nouvelles tâches apparaissent enregistrez les bien!
• Les commits sont utilisés pour évaluer qui fait quoi.
• La plagia est sanctionnée par un 0 sans discussion sur toutes les livraisons sans distinction.
• Utilisez un chronomètre pour vous aider à organiser votre temps au sein du groupe.

Quelques conseils :

• Soyez bien à l'aise avec vos classes métier, et partagez les.
  • Séparer la logique applicative de la persistance ou des interfaces graphiques pour vous concentrer au début sur le coeur des US, mais soyez bien sûr que vos US travaillent bien sur un même modèle de classes.
  • Vous pouvez utiliser les diagrammes de séquence pour vérifier la cohérence des modèles.
  • Penser à générer les codes une fois que vous êtes confiant dans vos modèles.
  • Dans vos codes n'oubliez pas les principes de “responsabilité unique”, …