Résumé de cours Gestion de Projet TI (partie 2) - Séance 4 à 7
3 vues 0 fois vendu
Cours
Gestion de Projet TI (PROJ20730)
Établissement
HEC Montréal (
)
Partie 2 du résumé de corus de gestion de projets TI, couvrant les séances 4 à 7 (quiz 2 + Intra et final). Faits à partir des notes de cours, il couvre toute la matière et peut être utilisé facilement pour trouver l'information
Séance 4 - L’approche Agile en gestion de
projet
Approche Agile : se concentre sur ce qui compte vraiment
Méthodologie Scrum
Méthodologie XP, Lean etc...
Agile Manifesto (2001) :
→ Accorde de l'importance à :
Individus et interactions plutôt que processus et outils
Logiciel fonctionnel plutôt qu'une documentation exhaustive → performance de
l'équipe > documentation
Collaboration avec les clients plutôt plutôt qu'une négociation contractuelle → mettre
entre les mains du client pour avoir un feedback en cours de chemin : transparence
pour baisser le risque
Adaptation au changement plutôt que l'exécution d'un plan
→ 12 Principes du manifeste agile :
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et
régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le projet. Les
processus Agiles exploitent le changement pour donner un avantage compétitif au
client.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à
quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble
quotidiennement tout au long du projet.
5. Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le
soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l'information à
l'équipe de développement et à l'intérieur de celle-ci est le dialogue en face à face.
7. Un logiciel opérationnel est la principale mesure d'avancement.
8. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble,
les commanditaires, les développeurs et les utilisateurs devraient être capables de
maintenir indéfiniment un rythme constant.
9. Une attention continue à l'excellence technique et à une bonne conception renforce
l'Agilité.
10. La simplicité - c'est-à-dire l'art de minimiser la quantité de travail inutile - est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-
organisées.
12. A intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle
et modifie son comportement en conséquence.
,Méthodologies de développement Agile :
1. Méthodologie SCRUM
2. Extreme Programming (XP)
3. Lean Development
4. Kanban
5. Autres (Crystal Family, DSDM, FDD)
Méthodologie SCRUM
Product Owner : représente le client → définit les caractéristiques du produit, les
priorités de ce qu'il faut développer, les deadlines et jalons
→ valide les fonctionnalités/résultats
→ est responsable du retour sur investissement
SCRUM Master : garant du processus SCRUM, porteur des valeurs SCRUM → s'assure
de la productivité, gère les rôles et fonctions de l'organisation, protège l'équipe contre
les interférences extérieures
L'Équipe : 3 à 9 membres → inclus toutes les divisions, ne changent pas pendant un
SCRUM
→ auto-organisation du travail
Product Backlog : feuille de route du projet, hiérarchiser les exigences/besoins → liste
incrémentale, change au fur et à mesure, évolue selon les exigences
1. User Story : décrire l'expérience de l'utilisateur selon l'utilisation de l'utilisateur
(raconter l'histoire en mettant comme personnage principal l'utilisateur, racontée au
''Je'' par lui-même)
→ Il faut la raconter du point de vue de TOUS les utilisateurs (utilisateur externe,
gestionnaire...)
2. Les Epic : fonctionnalités qui composent le produit
→ des items sont ajoutés au Product Backlog, retirables en tout temps selon les priorités
3. Évaluer la durée des items dans le Product Backlog : 3 méthodes :
Timeboxing : fixer une durée maximale pour faire la tâche (réunion SCRUM) → se
concentrer sur les objectifs court terme et la tâche à accomplir
Poker Planning : chaque membre estime le temps que prendra une tâche → les
estimations les plus extrêmes sont débattues, et on refait jusqu'à obtenir un
consensus
T-Shirt Sizing : la même que le Poker Planning mais avec des tailles (XS, S, M, L, XL
etc...) → estimation plus approximative et non détaillée
Affiner le Product Backlog : Rencontres récurrentes qui permettent au PO et à l’équipe
de :
Conserver une vision à long terme;
Estimer les nouveaux items;
Regrouper les items de moins grande valeur
Découper les items de plus grande valeur
Partager sur les risques techniques et autres informations utiles
, 1. Planifier le Sprint Backlog :
→ réunion de 8 heures max
→ arbitrée par le SCRUM Master
→ dirigée par le Product Owner
→ Objectifs : prochain sprint :
qu'est-ce qu'on livre ? (pourquoi ? qu'est-ce qu'on met dedans ?)
comment le livrer ? (contraintes)
→ Faire le suivi avec un tableau KANBAN (voir ci-dessous)
2. Suivre le projet par le « Daily SCRUM » : réunion quotidienne de 15 minutes max,
debout, à une heure fixe
→ arbitrée par le SCRUM Master
→ dirigée par le Product Owner
→ Objectif : répondre à ces questions :
Mon avancement hier ?
Ma contribution aujourd'hui pour atteindre le but du sprint ?
Obstacles qui pourraient m'empêcher ou empêcher l'équipe d'atteindre le but du
sprint ?
→ Faire le suivi avec un tableau KANBAN (voir ci-dessous)
3. Sprint Review : à la fin du sprint → présenter la solution au client par une
démonstration et avoir son retour (max 4 heures, approche informelle)
→ arbitrée par le SCRUM Master
→ dirigée par l'équipe de développement et les parties prenantes
→ les améliorations suggérées et problèmes rencontrés ajoutés dans le Product Backlog
→ concentré sur le produit
→ Objectifs :
inspecter l'incrément à la fin du Sprint
adapter le Produc Backlog
déterminer comment créer de la valeur au prochain sprint
rechercher la rétroaction du Product Owner et SCRUM Master
4. Sprint Retrospective : max 3 heures, souvent immédiatement après le sprint review
→ arbitré par le scrum master
→ dirigé par les membres de l'équipe de développement
→ Objectifs :
évaluer le dernier sprint (gens, relations, processus...)
identifier/classer les principaux items qui ont été réussis et les améliorations
possibles
créer un plan pour implémenter les améliorations → efficacité de l'équipe SCRUM
au prochain sprint
→ Et on recommence...
Tableau Kanban: permet de suivre et limiter les travaux en cours → flux de travail et de
valeur (lien avec Projet Phoenix dans l'usine)
Exemple d'Outil : Trello
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur youssefchemli. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour 7,17 €. Vous n'êtes lié à rien après votre achat.
