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
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
