User Tools
2013_2014:lp:idse:gl:gestiondeprojets:expose
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
2013_2014:lp:idse:gl:gestiondeprojets:expose [2014/02/20 18:27] blay |
2013_2014:lp:idse:gl:gestiondeprojets:expose [2014/03/11 11:06] (current) blay [Exposé de mi-parcours] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Exposé de mi-parcours ====== | ====== Exposé de mi-parcours ====== | ||
| - | <note warning>DRAFT!!!!</note> | ||
| - | EN premier, un par projet : | + | <note><del>7 mars 2014</del> 14 mars, présentation par groupe, séparément, avec des coachs par projet. </note> |
| - | Pour cela vous préparerez au moins un « elevator pitch » ( argumentaire condensé dans lequel vous présentez votre projet de 30 secondes à 2 minutes maximum, en moins de 120 mots) | + | |
| + | <note warning>Les temps et l'organisation sont donnés à titre indicatif. Tous les éléments demandés doivent cependant être présents dans votre exposé.</note> | ||
| + | ===== 1- elevator pitch ===== | ||
| + | EN premier, un par projet : | ||
| + | Pour cela vous préparerez au moins un « » ( argumentaire condensé dans lequel vous présentez votre projet de 30 secondes à 2 minutes maximum) | ||
| + | Vous devez en 2mn nous faire "acheter" votre projet : pertinence, conduite de projet, etc. | ||
| - | - Description du Projet | + | Cette étape sera suivie de questions. |
| - | [Public:Non-‐Spécialiste.Longueur: Entre 1 et 2 pages] | + | |
| - | [Cette | + | |
| - | section | + | |
| - | doit | + | |
| - | donner | + | |
| - | un | + | |
| - | aperçu | + | |
| - | à | + | |
| - | très | + | |
| - | gros | + | |
| - | grain | + | |
| - | de | + | |
| - | votre | + | |
| - | projet, | + | |
| - | pour | + | |
| - | permettre | + | |
| - | à | + | |
| - | un | + | |
| - | non-‐spécialiste | + | |
| - | de | + | |
| - | comprendre | + | |
| - | son | + | |
| - | contexte] | + | |
| + | ===== 2- Description du projet ==== | ||
| + | 3 mn maximum pour mettre en relief les principaux cas d'utilisation de votre projet, la qualité, voir l'originalité de votre proposition et son **adéquation aux utilisateurs**. | ||
| - | 2. Synthèse des résultats obtenus | + | ===== 3- Objectifs, planning et Rôles ==== |
| - | Objectif #1 | + | 10mn maximum |
| - | [Pour | + | |
| - | chaque | + | |
| - | objectif | + | |
| - | décrit | + | |
| - | dans | + | |
| - | votre | + | |
| - | DoW, | + | |
| - | donnez | + | |
| - | une | + | |
| - | description | + | |
| - | des | + | |
| - | résultats | + | |
| - | obtenus | + | |
| - | dans | + | |
| - | le | + | |
| - | cadre | + | |
| - | du | + | |
| - | projet, | + | |
| - | en | + | |
| - | utilisant | + | |
| - | les | + | |
| - | critères | + | |
| - | de | + | |
| - | succès. | + | |
| - | En | + | |
| - | cas | + | |
| - | d’échec, | + | |
| - | donnez | + | |
| - | un | + | |
| - | paragraphe | + | |
| - | de | + | |
| - | synthèse | + | |
| - | en | + | |
| - | expliquant | + | |
| - | les | + | |
| - | raisons.] | + | |
| + | - Objectifs : vous établissez clairement les objectifs que vous vous êtes fixés dans le projet et vos critères de succès par objectifs | ||
| - | 3. Implication des ressources | + | - Planning : tâches, affectation, dates, relations entre les tâche |
| - | [Public : Non-Spécialiste. Longueur : Entre 1 et 2 pages] | + | - n'oublier pas que la préparation d'une démonstration est une tâche |
| + | - les jalons (livrables) ont leur place dans le planning | ||
| + | - la date à prendre pour le retro-planning est le **23 mai** | ||
| - | Ressource #1 | + | - Rôles & Responsabilités |
| + | - par exemple : chef de projet, développeur, intégrateur, testeurs, risque manager | ||
| + | - évidemment les tâches doivent correspondre dans le planning | ||
| + | - un même membre combine plusieurs rôles | ||
| + | - un membre doit être actif tout au long du projet (vous ne pouvez pas avoir un membre qui ferait seulement la démo finale ou le cahier des charges par exemple). | ||
| + | - les rôles peuvent être momentanés, vous pouvez prévoir d'échanger les rôles, mais cela doit être "officiel" | ||
| + | - Liste des livrables (au moins les descriptions et les dates) | ||
| + | - Un livrable c'est : une description, les critères prévisionnels d'acceptation, la date de livraison | ||
| + | - Un livrable peut être intermédiaire, il sert à vérifier avec le client que l'on est bien d'accord | ||
| + | - trop de livrables, vous ne produisez plus, pas assez vous déviez | ||
| + | - les critères d'acception des livrables sont très importants : il s'agit d'un engagement de votre part. Sur la démonstration terminale, ils rejoignent les critères d'acceptation du projet globalement. | ||
| + | |||
| - | [Pour chaque ressource décrivez de manière synthétique son implication réelle dans le projet, ainsi que la différence entre ce que vous aviez planifié et ce qui a réellement été fait. Rappel : les encadrants font parti des ressources du projet.] | + | - Critères d'acception |
| + | global au projet | ||
| + | pour chaque livrable | ||
| - | Ressource … | + | ===== 3- Synthèse des résultats déjà obtenus ==== |
| + | 3mn maximum | ||
| + | - vous décrivez ce que vous avez déjà fait | ||
| - | 4. Synthèse des livraisons | + | - Vous analysez les points positifs et négatifs de votre travail, le déroulement de votre projet. Identifiez ce qui s’est bien passé, ce qui s’est mal passé, et ce qui aurait pu mieux se passer. Pour chaque point faible identifié, donnez des pistes pour pallier le problème dans la suite. |
| - | [Public : Non-Spécialiste. Longueur : 1 page] | + | |
| - | Tableau 2 – Synthèse des livraisons | + | - Vous mettez l'accent sur les actions à venir à court terme : <personne> <verbe> |
| - | Livrable Nom du livrable Prévu Livré | + | |
| - | 1 Nom de l’objectif Sx Sy | + | |
| - | … … | + | |
| - | … … | + | |
| + | |||
| - | 5. Suivi budgétaire | + | Pour les plus avancés cette partie peut inclure la présentation de l'architecture logicielle, l'organisation des codes, etc... un peu plus de temps sera alors prévu. |
| - | [Public : Non-Spécialiste. Longueur : 1 page] | + | |
| - | Consommation du budget | + | |
| - | [Sur la base des feuilles de temps, donnez un graphe cumulé de votre budget (temps) prévisionnel, ainsi que de votre consommation réelle. Chaque colonne représente le nombre d’heure depuis le début du projet.] | + | |
| - | |||
| - | |||
| - | Synthèse | ||
| - | |||
| - | [Donnez un paragraphe expliquant de manière synthétique les déviations entre votre budget prévisionnel et votre consommation réelle.] | ||
| + | <html> | ||
| + | <!-- - WBS | ||
| + | http://fr.wikipedia.org/wiki/Work_Breakdown_Structure | ||
| - | 6. Suivi des lots | + | - Liste des risques, % de "chance" et mitigation |
| - | [Public : Spécialiste. Longueur : 1-2 pages par lot] | + | - Les risques que vous percevez déjà et pour certains si vous les avez vos plans B |
| - | Lot #1 : | ||
| + | - trop de livrables, vous ne produisez plus, pas assez vous risquez de vous prendre un train ;-) | ||
| + | - | ||
| + | --!> | ||
| + | </html> | ||
| - | [Pour chaque lot, reprenez du DoW les objectifs associés. Pour chaque tâche, rappelez de manière synthétique sa description, et expliquez clairement la différence prévu/consommé. Vous pouvez expliquer dans les termes des spécialistes de votre domaine. Identifiez clairement les liens entre objectifs du lot, résultats obtenus, en fonction de vos critères de succès.] | + | |
| - | [Pour chaque livrable, donnez une description synthétique de son contenu, sa date planifiée et sa date de livraison réelle. Expliquez les déviations de livraison du point de vue client.] | ||
| + | ===== 4- Mise en exergue des prochaines étapes ==== | ||
| - | 7. Synthèse & Retour d’expérience | + | - Quand voulez-vous nous revoir? Pour quoi faire? |
| - | [Public : Non-Spécialiste. Longueur : 2 pages max.] | + | Quid de la gestion des besoins du client? quels éléments pour la conduite de projet? Pour des livraisons? Revues de codes? démo? |
| - | [Décrivez de votre point de vue le déroulement de votre projet. Identifiez ce qui s’est bien passé, ce qui s’est mal passé, et ce qui aurait pu mieux se passer. Pour chaque point faible identifié, donnez des pistes pour pallier le problème dans un futur projet.] | ||
| - | |||
| - | ===================== | + | ====== Exposés du 14 mars ====== |
| - | demo | + | |
| + | <note>Les étudiants passent par sous-groupes. | ||
| + | L'ordre ci-après est donné à titre indicatif. | ||
| + | Chaque groupe a au maximum 20mn pour présenter son travail. </note> | ||
| + | - **Groupe 1 -- 08:00 ** | ||
| + | * Alexandre LALAAS | ||
| + | * Axel TOCCI | ||
| + | * Georges RAMBELOSON | ||
| + | * Kevin GOYONS | ||
| + | - **Groupe 2 -- 08:30:00** | ||
| + | * Amir BEN DAOUD | ||
| + | * Hajar elouahabi | ||
| + | * Robin BARALE | ||
| + | -**Groupe 3 -- 09:00:00** | ||
| + | * Axel DARDENNE | ||
| + | * Cem ARIGSOY | ||
| + | * Guillaume DALICHAMP | ||
| + | * Sylvain FERNANDES | ||
| + | -**Groupe 4 -- 09:30:00** | ||
| + | - * Axel FAGOAGA | ||
| + | * Benjamin DETTORI-CAMPUS | ||
| + | * Julien SCAJOLA | ||
| + | * Sébastien GREGOIRE | ||
| + | -**Groupe 5 -- 10:00:00** | ||
| + | * Mathieu BROCHET | ||
| + | * Maxime RODIER | ||
| + | * Steeven CROIZER | ||
| - | exposé | + | <html> |
| - | GL | + | <!-- |
| + | De plus nous vous encourageons à prévoir "seuls" des réunions (scrum of scrums) pour assurer au moins un bon positionnement des projets relativement les uns des autres et si possible des intégrations entre groupes, voire même l'intégration globale... Ces réunions sont selon le besoin, soit le fait des chefs de projets, soit celui des intégrateurs. | ||
| + | Cette communication cross-projet est essentielle à la réussite globale. | ||
| + | Ecouter le picth du groupe voisin permet d'y voir plus clair | ||
| + | Mutualiser les études, les outils et les bonnes pratiques est une excellente idée | ||
| - | Gestion de projet | + | Enfin nous vous rappelons que chaque jour, |
| + | - une réunion (mélée, scrum meeting) doit vous permettre de faire le point | ||
| + | - que celle-ci fait toujours l'objet d'un compte-rendu écrit même bref qui doit nous être adressé, avec pour sujet :meeting : Nom du projet si vous en avez un ou nom des étudiants | ||
| + | - Dans le compte-rendu précisez qui était présent. | ||
| + | - dans le compte-rendu mettez : | ||
| + | points abordés | ||
| + | actions prévues | ||
| + | actions terminées | ||
| + | (Une action doit s'exprimer par un verbe, et etre assignée à une personne) | ||
| + | |||
| + | Travaillez-bien et amusez vous, bon courage !!! | ||
| + | --!> | ||
| + | </html> | ||
| - | Codes | ||
| - | qualité IHMs scenario fonctionnalités correspondance avec les specs qualité des slides contenu gestion de version Tests gestion des defects Autres (fwk?,..) organisation; planning itérativité proactivité. COMMUNICATION avec le client partage des tâches Architecture BD FORMAT Codes organisation | ||
| Line 160: | Line 155: | ||
| - | 1 2 1 1 1 1 1 2 1 1 1 1 1 1 1 1 1 1 | ||
| + | <html> | ||
| + | <!-- | ||
| + | --!> | ||
| + | </html> | ||
| - | ================== | + | <html> |
| - | + | <!-- | |
| - | ARchitecture? | + | ====== RAPPORT pour le XX ====== |
| - | ===================== | + | |
| Votre rapport ne devra pas excéder le nombre de pages indiqué ci-après de manière détaillée : | Votre rapport ne devra pas excéder le nombre de pages indiqué ci-après de manière détaillée : | ||
| Les points suivants doivent apparaitre clairement dans le rapport final en faisant l'objet d'une section particulière. | Les points suivants doivent apparaitre clairement dans le rapport final en faisant l'objet d'une section particulière. | ||
| Line 191: | Line 187: | ||
| - | ================== | + | --!> |
| - | + | </html> | |
| - | - CR post Mortem (CR == Compte Rendu) | + | |
| - | points positifs | + | |
| - | points negatifs | + | |
| - | actions: <personne> <verbe> | + | |
| - | - WBS | + | |
| - | http://fr.wikipedia.org/wiki/Work_Breakdown_Structure | + | |
| - | + | ||
| - | - Planning (version 1.0) : tâches, affectation, dates, relations entre les tâches | + | |
| - | - n'oublier pas que la préparation d'une démonstration est une tâche | + | |
| - | - les jalons (livrables) ont leur place dans le planning | + | |
| - | - la date à prendre pour le retro-planning est le 21 mai après vérification dans votre planning | + | |
| - | + | ||
| - | - Rôles & Responsabilités | + | |
| - | - par exemple : chef de projet, développeur, intégrateur, testeurs, risque manager | + | |
| - | - évidemment les tâches doivent correspondre dans le planning | + | |
| - | - un même membre combine plusieurs rôles | + | |
| - | - un membre doit être actif tout au long du projet (vous ne pouvez pas avoir un membre qui ferait seulement la démo finale ou le cahier des charges par exemple). | + | |
| - | - les rôles peuvent être momentanés, vous pouvez prévoir d'échanger les rôles, mais cela doit être "officiel" | + | |
| - | + | ||
| - | - Liste des risques, % de "chance" et mitigation | + | |
| - | - Les risques que vous percevez déjà et pour certains si vous les avez vos plans B | + | |
| - | + | ||
| - | + | ||
| - | - Liste des livrables (au moins les descriptions et les dates) | + | |
| - | - Un livrable c'est : une description, les critères prévisionnels d'acceptation, la date de livraison | + | |
| - | - Un livrable peut être intermédiaire, il sert à vérifier avec le client que l'on est bien d'accord | + | |
| - | - trop de livrables, vous ne produisez plus, pas assez vous risquez de vous prendre un train ;-) | + | |
| - | - les critères d'acception des livrables sont très importants : il s'agit d'un engagement de votre part. Sur la démonstration terminale, ils rejoignent les critères d'acceptation du projet globalement. | + | |
| - | + | ||
| - | + | ||
| - | - Critères d'acception | + | |
| - | global au projet | + | |
| - | pour chaque livrable | + | |
| - | + | ||
| - | - De quoi voulez-vous causer mardi 15 ? | + | |
| - | organisation | + | |
| - | technique | + | |
| - | revue de documents | + | |
| - | revue de designs | + | |
| - | ... | + | |
| - | précisez la nature du elevator pitch que vous pensez faire si vous en avez envie. | + | |
| - | + | ||
| - | + | ||
| - | De plus nous vous encourageons à prévoir "seuls" des réunions (scrum of scrums) pour assurer au moins un bon positionnement des projets relativement les uns des autres et si possible des intégrations entre groupes, voire même l'intégration globale... Ces réunions sont selon le besoin, soit le fait des chefs de projets, soit celui des intégrateurs. | + | |
| - | + | ||
| - | Cette communication cross-projet est essentielle à la réussite globale. | + | |
| - | Ecouter le picth du groupe voisin permet d'y voir plus clair | + | |
| - | Mutualiser les études, les outils et les bonnes pratiques est une excellente idée | + | |
| - | + | ||
| - | Enfin nous vous rappelons que chaque jour, | + | |
| - | - une réunion (mélée, scrum meeting) doit vous permettre de faire le point | + | |
| - | - que celle-ci fait toujours l'objet d'un compte-rendu écrit même bref qui doit nous être adressé, avec pour sujet :meeting : Nom du projet si vous en avez un ou nom des étudiants | + | |
| - | - Dans le compte-rendu précisez qui était présent. | + | |
| - | - dans le compte-rendu mettez : | + | |
| - | points abordés | + | |
| - | actions prévues | + | |
| - | actions terminées | + | |
| - | (Une action doit s'exprimer par un verbe, et etre assignée à une personne) | + | |
| - | + | ||
| - | Travaillez-bien et amusez vous, bon courage !!! | + | |
| - | + | ||
| - | + | ||
| - | ========================== | + | |
2013_2014/lp/idse/gl/gestiondeprojets/expose.1392917248.txt.gz · Last modified: 2014/02/20 18:27 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
