Cours au département INFO - IUT - UNS

User Tools

Site Tools

Trace: • td

Sidebar

S3 : Méthodologie de la production d'applications

2017_2018:s3:methodo:td:start

Planification

I - Phase d'élicitation (Sprint 0)

L'organisation proposée est là pour vous aider à atteindre votre objectif. Des groupes de TD peuvent la faire varier, mais l'objectif doit être atteint dans les temps, c'est à dire à la fin des 4 semaines, tous les livrables sont terminés et complets. A priori le chef de projet devrait prendre un peu d'avance au début pour mieux diriger ses camarades.
  • semaine 1 A. Découverte du sujet (Analyse)
    1. [✓ portmann, 2017-10-18] Chacun étudie le sujet, cherche des informations, évalue ses capacités pour faire des propositions la semaine suivante, construit les bases du jeu.
  • semaine 2 B. Choix technologiques et organisation (De l'analyse à la conception)
    1. [✓ portmann, 2017-09-20] Les étudiants s'inscrivent sur SLACK qui va nous service de canal de discussion partagé.
    2. Le groupe choisit (si c'est déjà fait, tant mieux)
      1. [✓ portmann, 2017-09-20] les technologies utilisées (il faut penser à l'intégration);
      2. [✓ portmann, 2017-09-20] son chef de projet et les autres postes si besoin;
      3. [✓ portmann, 2017-09-20] les thèmes des différentes pièces et la répartition en sous-équipes.
      4. [✓ portmann, 2017-09-26] les propriétés qu'il est important de traiter telles que : sécurité, persistance, robustesse.
    3. Le chef de projet saisit dans la forge
      1. [✓ portmann, 2017-09-20] au choix sous-projet par sous-projet ou globalement, ses camarades (sous configuration/Membres) en tant que développeurs. Ils peuvent à présent se connecter au projet et commencer à travailler dans le sous-groupe choisi.
      2. [✓ portmann, 2017-10-04] Dans chacun des sous-projet, il précise au niveau du wiki, ou demande à ses camarades de préciser le thème du sous-groupe par exemple : //Groupe4A, la salle à manger//.
    4. Le chef de projet saisit dans le wiki du projet (global au groupe)
      1. [✓ portmann, 2017-10-04] le "pitch" global du projet
      2. [✓ portmann, 2017-10-18] l'organisation du groupe et la structure du projet . Cette partie doit permettre à chaque sous-équipe de préciser le contenu de sa pièce et les références. Le chef de projet n'est pas responsable des descriptions données par les sous-équipes, par contre tout le groupe est responsable de ce qu'il diffuse.
      3. [✓ portmann, 2017-10-18] le glossaire des mots utilisés par tout le groupe. Cette partie est importante, elle fixe le vocabulaire et doit faciliter l'intégration. Il convient que tous les membres du groupe s'accordent sur le vocabulaire et utilisent uniquement ces termes. Ils peuvent aider le chef de projet dans cette tâche.
      4. [✓ portmann, 2017-10-18] les choix technologiques du groupe s'il y en a et sinon explicite l'architecture envisagée
      5. les propriétés qu'il vous semble essentiel de traiter telles que : sécurité, persistance, robustesse, en expliquant pourquoi. Vous pouvez vous appuyer sur le classement FURPS, nous reviendrons dans le cours plus tard sur ce point.
      6. [✓ portmann, 2017-10-18] les grands cas d'utilisation i.e. pas le détail des jeux mais les grands principes
    5. Chaque sous-équipe saisit dans le wiki de son propre sous-projet (Le chef de projet devra y faire référence dans le wiki principal)
      1. [✓ portmann, 2017-10-04] le thème et les scénarios généraux de la pièce qu'il va construire .
      2. la complexité de la pièce .
      3. [✓ portmann, 2017-10-18] le vocabulaire utilisé ne doit pas être ambigüe, il faut si nécessaire soit ajouter les mots dans le glossaire global, soit un glossaire propre à la sous-équipe mais attention les redéfinitions de termes du glossaire global sont interdites.
      4. les technologies qu'elle va utiliser : si toutes les sous-équipes du groupe font référence aux mêmes technologies, dans cette partie, chaque équipe doit expliquer comment elle va les utiliser dans sa pièce précisément. Cette partie pourra être complétées plus tard par exemple, lors de premiers POC (Proof Of Concept).
    6. Chaque sous-équipe saisit dans dans le kanban du sous-projet, les histoires (elles sont dans la colonne nouveau au début).
      1. le contenu de chaque histoire est cohérent et son objectif est atteignable en 1 semaine . Une semaine c'est très court, mais nous n'avons pas le choix et cela doit vous permettre de ne pas vous retrouver avec tout à faire au dernier moment. Plusieurs histoires peuvent être regroupées en EPIC (pas plus de 1/4 d'EPIC), mais pour chaque histoire vous avez de la valeur pour votre “joueur”.
      2. Chaque histoire a une valeur métier, c'est à dire une valeur pour le joueur. Vous choisissez l'échelle à votre convenance : Très important, 5, ... . Certaines histoires peuvent avoir une plus faible valeur “métier”, dans le cas où vous auriez à faire des choix, vous commenceriez par éliminer ces histoires probablement.
      3. Les critères d'acceptation et les tests sont cohérents, "complets" et atteignables.
      4. Il ne s'agit pas de définir beaucoup d'histoires mais des histoires réalisables dans le temps qui vous est donné; Il faut par pièce avoir au moins 3 énigmes, une par individus au minimum; Les énigmes doivent permettre de trouver des indices; ces indices doivent vous permettre de résoudre d'autres énigmes.
  • semaine 3 C. Organisations et mise au point des histoires (Conception)
    1. Le chef de projet, dans la forge
      1. saisit les différents livrables attendus avec leur date de début et de fin;
      2. prépare les tâches liées à l'intégration
    2. Chaque sous-équipe, dans la forge
      1. saisit les tâches pour la phase de développement : une tâche ne dure pas plus d'une semaine. Exemples de tâches : lire un fichier d'indice, Afficher la pièce, réaliser un POC, .. Vous prenez en compte la suite du planning qui vous est donné et a été saisie par le chef de projet. Vous prévoyez les semaines où vous réaliserez ces tâches. Votre objectif va être de vérifier l'adéquation entre vos prévisions et la réalité : êtes-vous plus rapides ou moins rapides que vous le pensez?
      2. Des POCs peuvent être réalisés pour vous aider à mieux planifier, par exemple, ajouter une tâche "Developper un PC" consistant à afficher une énigme, saisir la réponse, mémoriser l'indice s'il est gagné. Vous pourrez mettre à jour vos prévisions après la réalisation de ce POC.
  • semaine 4 D. Construction d'un schéma global d'intégration et des tâches afférentes (Conception)
    1. Le chef de projet, dans le wiki
      1. Mise au point d'un scénario général (Diagramme de séquence en conception) de l'entrée dans une pièce jusqu'à la sortie de la pièce
      2. Mise au point d'un scénario global de l'entrée dans le jeu jusqu'à la sortie du jeu
      3. Diagramme des classes communes partagées par l'ensemble du groupe. (Evidemment ce point est réalisé avec l'ensemble du groupe).
    2. Chaque sous-équipe, dans le wiki
      1. Mise au point d'un scénario correspondant à la résolution d'une énigme
      2. Diagramme des classes de la sous-équipe, il doit être cohérent par rapport au diagramme de classes propre à l'ensemble du groupe. Il présente essentiellement les classes métier de l'application. Il peut faire référence (i.e. faire apparaitre des classes du diagramme global).
      3. Si vous avez le temps, Mise au point d'un autre scénario de résolution d'une autre énigme.

Tous les points précédents sont des éléments des 2 éléments du livrables : un wiki et le kanban.

Attention à cette étape, tous les wiki sont "public" pour permettre les évaluations croisées. Vous serez évalué à partir des formulaires ci-après. Vous avez donc toutes les informations pour faire au mieux.

Formulaire d'évaluation

Formulaire d'évaluation des chefs de projet

Répartition des rendus à évaluer par étudiants

Quelques erreurs relevées dans les rendus de l'an dernier

  • La première page du document doit “évidemment” (lire wiki du groupe, cette année)
    • préciser votre formation
  • Ne racontez pas votre vie ou celle de vos acteurs (par exemple, il choisit les “gros mots” en parlant avec ces collègues… bah… vous êtes sûrs?… Ca apporte quelle information intéressante?)
  • “Nous essayerons de respecter les dates de livraison prévues. ” NON NON … Même pas la peine de le dire, vous les respecterez c'est tout!
  • La valeur métier d'une US ne s'estime pas en heure ! C'est une valeur relative qui exprime “la valeur que lui accorde le métier” une tâche très rapide à réaliser peut avoir une très forte valeur métier, et inversement… Ces valeurs sont à apprécier avec votre enseignant .. mais étant donnée le cas d'étude cette année, c'est quand même très facile!
  • Une tâche “développement” n'est pas vraiment informative… On s'attendait davantage à des tâches plus précises liées aux US, par exemple, construction des composants graphiques, intégration de la lecture de fichiers, etc.

II - Phase de développement en sous-équipes

Comme pour la phase précédente, l'organisation proposée est là pour vous aider à atteindre votre objectif mais, sauf pour l'évaluation, vous pouvez vous organisez comme bon vous semble. En particulier, vous pouvez faire des tests utilisateurs régulièrement. Mais l'objectif doit être atteint dans les temps, d'autant que la phase suivante est l'intégration et que seuls les pièces répondant aux exigences seront intégrées.
  • semaine 5 A. Evaluation et développement
    1. Analyse du rendu d'une sous-équipe ou d'un autre chef de projet par étudiant (une évaluation par étudiant). Pour vos évaluations voir plus haut dans "livrable" les formulaires d'évaluation.
    2. Prenez le temps dans l'équipe de faire le point sur ce que cette évaluation vous a apportée.
    3. Développement mais attention, celui-ci doit se faire tout en respectant les tâches que vous avez définies ou que vous définissez en fonction de vos besoins. </todo>
  • semaine 6 - 7 B. Développement et Suivi des tâches
    1. Développements et gestion des tâches
  • semaine 8 C. Tests utilisateurs Puisqu'il s'agit de jeux, il est important que vous ayez le retour d'utilisateurs potentiels. Il convient donc de les faire tester. Pour cela vous prévoyez des scénarios de tests. Puis vous notez la manière dont votre utilisateur se comporte. En fonction des retours vous ajoutez des tâches pour corriger les bugs rencontrés, les améliorations à faire etc. Certaines pourront ne pas être faîtes mais vous les mémorisez comme des perspectives.

Il faut éliminer les pièces non testées ou non à la hauteur. Ces groupes continuent seuls mais ne seront notés que que sur 15 (c'est à dire qu'en supposant qu'il fasse un excellent travail, ils ne pourront pas avoir plus de 15 au livrable 3.2 et ils ne seront pas évalués sur la démo. Dans le meilleur des cas, ils auront la même note que leur camarade.

III - Phase d'intégration et Livraison

  • semaine 9 A. Evaluation, Choix des pièces à intégrer, construction d'un scénario global
    1. Tous les étudiants : Démonstration
    2. Tous les étudiants : Evaluation des démos par les étudiants
      1. formulaire
    3. Tous les étudiants : Choix des pièces gardées
    4. Chef de projet : Déclaration officielle des pièces gardées. Attention, si une pièce gardée n'est pas intégrée, c'est l'ensemble du groupe qui est sanctionné.
    5. Tous les étudiants : Détermination des tâches à faire, assignation aux étudiants et ordonnancement :
      1. Pour intégrer
      2. Pour améliorer les pièces
  • semaine 10-13 Intégration et Suivi des tâches
  • semaine 14 Finalisation des jeux au sein d'un groupe
  • semaine 15 Exposé
Livrables du Sprint III
2017_2018/s3/methodo/td/start.txt · Last modified: 2017/12/02 18:23 by blay

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Run on Debian Driven by DokuWiki