2022-2023
L’approche Agile
Chapitre 3 : Adopter l’approche
Agile dans gestion de projet
Appréhender la méthodologie Agile Scrum
Manipuler l’outil de gestion de projet Agile
(Scrum/Jira) I STA TI NGHI R
BOUTKHAMOUINE Brahim
2022-2023
INTRODUCTION
Dans certains projets (en particulier les projets informatiques), il n'est pas possible de
recueillir toutes les exigences dès le départ en raison de leur extrême incertitude. Par
conséquent, nous avons besoin d'une méthode de gestion de projet suffisamment flexible
pour gérer les nombreuses demandes de changement qui apparaissent au cours du projet et
pour maintenir la productivité de l'équipe de projet. Il existe un certain nombre de systèmes
conçus pour offrir ces deux propriétés. D’entre eux sont appelés cadres agiles. Scrum est une
méthode de gestion de projet du groupe Agile. C’est la plus connue et la plus largement
utilisée. Scrum repose sur un certain processus, qui sera expliqué dans la suite. Ce processus
Scrum ne sera pas efficace s'il n'est pas associé à certains rôles et artefacts, qui font l'objet de
la section "Événements Scrum" de ce cours.
Ce cours à pour objectif de faciliter la compréhension, l'adhésion et l'organisation
du modèle Scrum auprès de votre équipe agile. Vous apprendrez les caractéristiques du
modèle Scrum, et apprendre les clés pour organiser votre cadre de travail et mettre en
pratique le modèle Scrum. Grâce à ce modèle, vous développerez une approche pragmatique.
Vous serez ainsi en mesure de faire face aux changements imprévus dans la gestion de votre
projet.
MANIFESTE AGILE
En 2001, un groupe de développeurs de logiciels a publié un manifeste qui a été depuis lors
considéré comme le cœur de toutes les méthodes Agile. Scrum est une façon de réaliser ce manifeste.
Le manifeste Agile complet est le suivant :
NOUS DECOUVRONS DE MEILLEURES FAÇONS DE DEVELOPPER DES
LOGICIELS EN LE FAISANT ET EN AIDANT LES AUTRES A LE FAIRE.
GRACE A CE TRAVAIL, NOUS AVONS ACQUIS DE LA VALEUR :
INDIVIDUS ET INTERACTIONS PAR RAPPORT AUX PROCESSUS ET
OUTILS
UN LOGICIEL FONCTIONNEL PAR RAPPORT UNE
DOCUMENTATION COMPLETE
COLLABORATION AVEC LE CLIENT PAR RAPPORT LA NEGOCIATION DU
CONTRAT
REAGIR AU CHANGEMENT PAR RAPPORT SUIVI D’ UN PLAN
EN D'AUTRES TERMES, MEME SI LES ELEMENTS DE DROITE ONT DE LA VALEUR, CEUX
DE GAUCHE EN ONT DAVANTAGE.
Quand utiliser Scrum et quand utiliser les méthodes traditionnelles ?
Les deux approches ont leurs points forts, tout dépend donc du type de projet et de son
environnement. Cependant, les deux approches ont de nombreux points communs qui sont
souvent oubliés ; toutes deux prévoient une planification efficace suivie d'une exécution, d'un
suivi et d'un contrôle.
Quand utiliser Scrum Quand utiliser les méthodes traditionnelles
La portée n'est pas clairement définie La portée est clairement définie dès le
Le produit apparaîtra progressivement au départ ;
cours du projet Une description claire du produit est
disponible dès le départ ;
Des projets similaires ont été réalisés
auparavant.
Les exigences changent fréquemment Les exigences sont bien définies dès le
Le client en sait plus sur ce qu'il veut départ.
au fur et à mesure que le projet avance Peu de changements sont attendus au cours
du projet ;
Les produits ne sont pas censés changer
beaucoup.
Les activités ne peuvent pas être bien définies Les activités peuvent être bien définies à
au départ l'avance
L'estimation (planification) est difficile L'estimation est possible et fiable
Le processus est itératif (nombreux cycles) Le processus est à plus long terme
Chaque cycle dépend fortement des Le projet peut être divisé en plusieurs phases
précédents
précédents
Le succès se mesure principalement par la Le succès se mesure principalement par la
satisfaction des clients réalisation des objectifs du projet en termes
de délais, de coûts, de portée...
Les résultats incrémentaux ont une valeur et Les utilisateurs ne peuvent normalement pas
peuvent être utilisés par les utilisateurs commencer à utiliser les produits
jusqu'à ce que le projet soit terminé (par
exemple, un pont).
En résumé, il est préférable d'utiliser Scrum lorsqu'il y a beaucoup d'inconnues, lorsque les
projets sont plus complexes, qu'il est difficile de définir des exigences détaillées au départ et
donc de définir des estimations au début du projet.
Il est préférable d'utiliser les approches traditionnelles lorsqu'il y a peu d'inconnues, que le
projet est moins complexe, qu'il est facile de définir les exigences exactes dès le départ et donc
d'estimer et de planifier le projet dès le début.
Il faut également veiller à ne pas essayer d'appliquer Scrum si l'organisation n'y est pas prête,
par exemple s'ils n'ont pas été formés, si leur mode de fonctionnement actuel fait obstacle aux
rôles et responsabilités de Scrum et si les gens ne sont pas ouverts à l'apprentissage.
Voici quelques-uns des mythes populaires concernant Scrum, dont nous devons être conscients :
Mythes Réalité
Les développeurs sont libres de faire ce qu'ils Les développeurs travaillent dans un cadre
veulent. productif et prédéfini et le Scrum Master s'assure
qu'ils respectent Scrum.
Scrum se débarrasse de tout le travail administratif Il y a certaines étapes de planification impliquées
et permet à l'équipe de commencer à développer dans chaque projet Scrum et le développement ne
immédiatement peut ne peut commencer que lorsque le Sprint
Backlog a été défini.
Toutes les exigences (sous la forme de récits) L'équipe de développement peut commencer à
doivent être acceptées avant que l'équipe de travailler dès que les premières histoires ( Stories)
développement ne soit autorisée à commencer à du Backlog de produit sont en place.
travailler sur le produit.
Scrum est très facile à mettre en œuvre, même L'utilisation de Scrum est un changement
sans formation. important, facile de mettre en œuvre Scrum par
rapport à d'autresprojet, mais les gens doivent
toujours avoir une bonne compréhension de Scrum
pour pouvoir mener à bien leurs
projets.
Scrum est juste un ensemble de règles simples. Scrum est un ensemble de règles et un cadre de
travail, plus une culture et une éthique de travail
compatibles.
Le Scrum Master est comme un chef de projet. Il n'y a personne qui ressemble à un chef de projet
traditionnel de projet traditionnel dans un projet
Scrum. Le Scrum Master
s'assure que le cadre de Scrum est respecté.
Le Product Owner est le chef de projet Le Product Owner ne fait que créer et maintenir
le Backlog du produit, mais ne gère pas les activités
quotidiennes de l'équipe.
Le Product Owner est un représentant de la part Le Product Owner est l'une des personnes de la
du client l'organisation exécutante (l'organisation chargée de
responsable de la production du produit final du
projet ; un entrepreneur dans de nombreux cas), et
le point de contact avec le client.
CHRONOLOGIE DE SCRUM
Cette partie vous donnera une idée de base du fonctionnement d'un projet Scrum.
Ce qui se passe avant les Sprints :
1. L'énoncé de vision fournit une description concise des objectifs du projet, ce
qui l'équipe à se concentrer sur ce qui est important du point de vue de
l'organisation
2. La feuille de route du produit est un calendrier visuel initial des principa les
caractéristiques du produit à livrer et est normalement créée par le
propriétaire du produit (Product owner), un des rôles de Scrum qui sera
expliqué plus tard.
3. Recueillir les besoins des utilisateurs, et les transformer en fonctionnalités
livrables - on les appelle des histoires d’utilisateur (User stories). Les
histoires sont normalement écrites par le Product Owner et les exigences qui
composent ces histoires proviennent du client.
4. Toutes ces histoires d’utlisateur (User stories) constituent le Backlog de
produit. Dans Scrum, nous n'attendons pas que le Backlog de produit soit
préparé à 100% avec tous les détails pour commencer les Sprints. ; nous
commençons les Sprints dès que le Backlog de produit est suffisamme nt
mature pour le futur proche et continuer à mettre à jour le backlog tout au
long du projet.
Activités de sprint :
5. Les réunions de planification de sprint (Sprint Planning meetings) sont
organisées pour planifier ce qui sera mis en œuvre dans un sprint (une
période de temps fixe utilisée pour livrer des parties du produit final). Le
Product Owner donne la priorité à ces exigences et décide donc
indirectement du contenu du Sprint Backlog.
6. Ces histoires d’utilisateur (caractéristiques, fonctionnalités ou livrable s)
constituent le Sprint Backlog, Le Sprint Backlog est donc une liste de toutes
les histoires ( stories) qui seront développées au cours du prochain Sprint.
7. L'équipe décompose (développe) ces histoires en tâches.
8. L'équipe prend ensuite 2 à 4 semaines pour livrer un nombre convenu
d'histoires.
9. L'équipe tient une réunion quotidienne de Scrum de 15 minutes pour
collaborer entre eux.
10. A la fin du Sprint, l'équipe fait la démonstration des histoires (produits)
terminées au client lors d'une réunion de démonstration du sprint (aussi
appelée revue du sprint, en anglais : Sprint review meeting).
11. La dernière activité est la réunion de Sprint rétrospective, au cours de
laquelle l'équipe examine le sprint et cherche des moyens de l'amélio rer
(leçons apprises).
12. Le Scrum Master s'assure que le processus Scrum est entièrement suivi et
offre un encadrement à toutes les personnes impliquées.
LES ROLES DE SCRUM
Il y a trois rôles dans un projet Scrum ; pas moins, et pas plus. Nous ne sommes pas autorisés à
définir d'autres rôles, car cela nuit à l'unité de l'équipe, et ce n'est pas compatible avec la
philosophie de Scrum.
Une équipe Scrum se compose des trois rôles suivants :
Product Owner Scrum Master Equipe de développement
1 personne 1 personne 3 à 9 personnes
Orienté vers les affaires Coach et facilitateur Scrum Spécialiste
Le terme "équipe Scrum" désigne tous les membres de l'équipe de projet, c'est-à-dire toutes
les personnes internes au projet. Les membres de l'équipe Scrum n'ont généralement qu'un des
trois rôles standard de Scrum : Propriétaire du produit, Scrum Master, ou membre de l'équipe
de développement.
Il est possible pour une même personne d'être affectée à plus d'un rôle standard, mais ce n'est
pas recommandé.
L'équipe Scrum présente deux caractéristiques essentielles :
Auto-organisation : L'équipe Scrum gère ses propres efforts plutôt que d'être gérée ou dirigée
par d'autres. Dans les méthodes traditionnelles, les efforts de gestion sont séparés et centralisés
; un sous-ensemble de l'équipe de projet est responsable de la gestion du projet et d'autres ne
sont responsables que des activités spécialisées. Cependant, les efforts de gestion et les activités
spécialisées ne sont pas séparées dans Scrum.
Transversale (Cross-functional) : L'équipe Scrum dispose de toute l'expertise et de toutes les
compétences nécessaires pour accomplir le travail sans l'aide de personnes extérieures à
l'équipe.
Ces deux caractéristiques sont conçues pour optimiser la flexibilité, la créativité et la
productivité ,nécessaires à l'environnement Agile Scrum.
Rôle 1 : Product Owner
Il n’a pas besoin d'avoir une connaissance du domaine d'application du
projet ; ils se concentrent sur l'aspect commercial. Dans les projets de
développement de logiciels, par exemple, le Product Owner n'a pas
besoin d'être lui-même un développeur. Il a t juste besoin d'en savoir un
peu sur le développement, mais beaucoup sur l'activité de
développement.
Le Product Owner est responsable du Product Backlog. Le Backlog de
produit est une liste hiérarchisée d'éléments (appelés "stories" ou "user
stories") que le client attend du projet ; Il s'agit du principal outil de
planification de Scrum. Il est également de la responsabilité du Product
Owner de s'assurer que chaque élément (user story) est facile à
comprendre pour l'équipe Scrum et les autres parties prenantes.
Le Product owner doit communiquer efficacement avec le client (le
facteur de succès inévitable dans chaque méthode de gestion de projet) et
utiliser les informations pour tenir à jour le Backlog de produit ave c tous
les changements. Ils mesurent également la performance du projet,
prévoir la date d'achèvement, et rendre ces informations transparentes
pour toutes les parties prenantes.
Un Product Owner peut déléguer certaines de ses responsabilités (comme la
préparation de la liste des d'éléments pour le Backlog de produit) à l'équipe de
développement, mais il en reste le responsable.
Rôle 2 : Scrum Master
Le Scrum Masters sont celui qui comprend parfaitement Scrum,
et qui aide l'équipe Scrum en les encadrant et en veillant à ce que
tous les processus de Scrum soient correctement mis en œuvre. Le
Scrum Master est un poste de gestion, qui gère le processus
Scrum, plutôt que l'équipe Scrum.
En plus de s'assurer que l'équipe de développement comprend et
utilise correctement Scrum, le Scrum Master s'efforce également
d'éliminer les obstacles auxquels se heurte l'équipe de
développement, facilite ses événements, et les forme ou les
entraîne.
Les responsabilités des Scrum Masters ne se limitent pas à
l'équipe Scrum. Ils doivent également aider les personnes
extérieures à l'équipe de Scrum à comprendre les interactions
appropriées avec l'équipe de Scrum afin de maximiser la valeur
créée par l'équipe de Scrum.. En général, le Scrum Master
dirige l'organisation dans ses efforts pour adopter Scrum.
Il est possible pour une même personne d'être à la fois Scrum Master et membre de
l'équipe de développement, bien que cela ne soit pas recommandé. Être Scrum Master
d'un projet peut ne pas occuper 100% du temps d'une personne ; dans ce cas, la
meilleure solution est d'assigner cette même personne comme Scrum Master dans plus
d'un projet, plutôt que de la faire membre de l'équipe de développement.
Rôle 3 : L'équipe de développement
Les membres de l'équipe de développement sont des experts du domaine
d'application qui sont responsables de livrer les éléments du backlog et de gérer
leurs propres efforts.
Ils doivent être transversaux, c'est-à-dire qu'ils doivent être capables d'assurer la
création de A à Z de chaque élément du Product Backlog. Ils doivent être auto-
organisés, trouver leur propre voie au lieu de recevoir des ordres. Ils doivent
être alignés sur l'objectif du projet au lieu de travailler aveuglément. Une tâche
peut être assignée à un seul membre tout au long du sprint, mais l'ensemble de
l'équipe de développement sera responsable de cette tâche ; aucun individu n'est
propriétaire d'une tâche.
L'équipe de développement livre le produit final du projet par incréments
successifs, tels que définis dans le Backlog de produit.
Il est fortement recommandé aux membres de l'équipe de développement de
travailler à temps plein sur un seul projet afin de rester concentré et agile. La
composition de l'équipe de développement ne doit pas changer si souvent. S'il
est nécessaire de changer les membres de l'équipe, ce changement ne doit pas
avoir lieu pendant un sprint, et il y aura une diminution à court terme de la
productivité lorsque la composition de l'équipe change.
Scrum est efficace lorsque l'équipe de développement compte de 3 à 9
membres. Pour les grands projets, nous pouvons utiliser un modèle à échelle
réduite avec plusieurs équipes Scrum.
Maintenant que nous avons parlé de tous les rôles de Scrum, vous pouvez vous demande r
qui est le chef de projet ?
La réponse est simple : ce rôle n'existe pas dans Scrum, et aucun des 3 rôles de Scrum n'agit
comme un chef de projet traditionnel. Certaines personnes considèrent que les Scrum Masters
sont l'équivalent des chefs de projet traditionnels ; mais ce n'est pas vrai, car les responsabilités
du Scrum Master sont très différentes que celles d'un chef de projet traditionnel.
LES EVENEMENTS SCRUM
Il y a seulement cinq événements dans un projet Scrum :
1. Sprint : Chaque projet Scrum est un ensemble de sprints. Le Sprint
est un conteneur pour les quatre autres événements (tels que
représentés dans le diagramme ci-dessus),
2. Planification du sprint ( Sprint Planing) : La planification du sprint
est le premier événement d'un sprint. L'équipe Scrum planifie les
éléments qu'elle va livrer dans le sprint et la façon dont elle va les
livrer.
3. Mêlée quotidienne (Daily Scrum) : L'équipe de développement
commence à travailler sur les objectifs du sprint dès que la
planification du sprint est terminée. Pendant ce temps, elle tient une
réunion quotidienne (normalement de 15 minutes) afin de
coordonner le travail des 24 heures à venir.
4. Revue du sprint ( Sprint review) : Avant la fin du Sprint, l'équipe
de développement présente (démontre) le résultat du Sprint au client
et reçoit un feedback. Cette réunion est appelée Revue du Sprint
(également appelée Démo du Sprint).
5. Rétrospective du sprint : Après la revue de sprint et juste avant la
fin du sprint, l'équipe de développement tient une réunion interne
pour examiner le Sprint et l'utiliser pour améliorer le processus
(leçons apprises) lors du prochain Sprint. Cette réunion est appelée
rétrospective du sprint.
Evénement 1 : Sprint
Chaque projet Scrum livre le produit final après un certain nombre de cycles, appelés
Sprints. Un incrément est développé dans chaque Sprint. Un incrément est une partie
potentiellement libérable du produit final ; c'est la somme de tous les éléments du Backlog de
produit réalisés dans un sprint et ses sprints précédents. Un incrément peut être considéré
comme une révision mineure du produit avec de nouvelles caractéristiques et fonctionnalités.
Un incrément peut ou non être publié à la fin du sprint, mais il doit être potentielle me nt
publiable.
Les clients demandent généralement des changements lorsqu'ils voient l'incrément (revue
du sprint), et nous appliquons les changements dans le backlog de produit.
Le sprint est un événement limité dans le temps, ce qui signifie que nous devons fixer
sa durée au début du projet et ne pas la modifier fréquemment ou occasionnellement.
Les sprints sont généralement fixés pour 2 à 4 semaines .
Le point important est que nous ne modifions pas les éléments du Sprint Backlog
après le début du Sprint et l'établissement des plans. L'objectif du sprint ne doit pas
non plus changer. Le Product Owner et l'équipe de développement peuvent essayer de
clarifier et de renégocier la portée du projet. et renégocier le champ d'application au
fur et à mesure qu'ils en apprennent davantage, mais ils ne modifieront pas le Sprint
Backlog. Même la composition de l'équipe de développement ne doit pas changer au
cours d'un sprint. Ces contraintes sont conçues pour permettre de se concentrer et de
faire avancer les choses.
Chaque élément (story) du Backlog de produit doit normalement être développé
(terminé) en un seul Sprint. un seul Sprint, car cela est beaucoup plus facile à gérer. Le
Product Owner et l'équipe de développement sélectionnent un certain nombre
d'éléments en haut du Backlog de produit (qui a déjà été classé par ordre de priorité
par le Product Owner et s'efforcent de les terminer à 100%). Nous voulons qu'ils
soient vraiment "terminés" à la fin du sprint, et créer un incrément. Un incrément est
la somme de tous les éléments terminés pendant un Sprint et tous les Sprints
précédents.
Il est important de se mettre d'accord sur une définition de "Fait" (Done) dès le début
du projet. Nous ne dirons pas que quelque chose est "terminé", à moins qu'il ne
corresponde à la définition. Un élément terminé à 99,999% n'est pas n'est pas
considéré comme "terminé", il ne fera pas partie de l'incrément et ne sera pas
démontré au client lors de la revue du sprint.
Une Sprint peut-elle être annulée ?
Même si chaque Sprint est gelé et ne change pas, le Product Owner a le pouvoir d'annuler
un Sprint. Cela peut se produire lorsque l'objectif du sprint devient obsolète, en raison de
changements dans le Backlog de produit, les stratégies, l'approche, etc.
Événement 2 : Planification du sprint ( Sprint Planning)
L'équipe de développement n'attend pas que le produit Backlog soit planifié à 100 %
(toutes les exigences sont recueillies et approuvées) pour commencer à développer le
projet. Dès que le Product Backlog est suffisamment mature pour nous guider dans un
futur proche, le propriétaire du produit et l'équipe de développement peuvent
commencer le premier Sprint.
La première chose à faire dans chaque Sprint est la planification du Sprint. La
planification du sprint est une réunion limitée dans le temps généralement fixée à 8
heures pour un Sprint d'un mois, ou plus courte pour les Sprints de moins d'un mois.
Les trois rôles doivent assister à cette réunion.
L'équipe de développement doit estimer la capacité de travail qu'elle peut fournir en
un seul Sprint. Le Product Owner a déjà classé et ordonné le Backlog de produit en
fonction de la valeur des éléments. Le Product Owner s'assure également que les
éléments (stories) sont faciles à comprendre. L'équipe de développement sélectionne
ensuite un nombre approprié d'éléments dans le haut du Product Backlog, et les place
dans le Sprint Backlog, pour les livrer dans le Sprint en cours.
Ceci est un exemple de L’objectif de Sprint :
Nous allons activer toutes les parties essentielles de la boutique en ligne pour mettre
en place un processus d'achat complet. Cela rendra les autres fonctionnalités du site
Web plus significatives pour le client et les éventuelles demandes de changement
seront soulevées plus tôt.
Événement 3 : Mêlée quotidienne
Le Scrum quotidien est normalement une réunion de 15 minutes pour l'équipe de
développement afin d'inspecter le travail effectué depuis la dernière réunion, de
synchroniser le travail et de planifier les prochaines 24 heures. Elle doit avoir lieu tous
les jours.
Pendant la mêlée quotidienne, chaque membre de l'équipe de développement doit
répondre à ces trois questions :
1. Qu'est-ce qui a été accompli depuis la dernière réunion ?
2. Qu'est-ce qui sera fait avant la prochaine réunion ?
3. Quels sont les obstacles qui se dressent sur le chemin ?
La réunion quotidienne de Scrum doit se tenir à la même heure et au même endroit
tout au long du Sprint, afin de minimiser la complexité. Elle n'est destinée qu'à
l'équipe de développement ; ce n'est pas une réunion pour toutes les parties
prenantes.
Événement 4 : Revue du sprint (Sprint Review)
La durée de cette réunion est normalement de quatre heures pour un Sprint d'un mois. Si les
sprints sont plus courts, cette réunion sera proportionnellement plus courte.
À la fin du sprint, l'équipe de Scrum et les autres parties prenantes se réunissent et
tiennent une réunion de quatre heures pour présenter et inspecter les éléments "
terminés " (l'incrément) du sprint actuel et adapter le Backlog de produit en marquant
les éléments "terminés" comme complets et ajouter de nouveaux éléments ou modifier
les éléments existants si nécessaire. La présentation de l'incrément lors de cette
réunion est destinée à recueillir des feedbacks et à soulever des demandes de
changement au plus tôt possible.
Nous accueillons favorablement les changements dans Scrum et encourageons leur
demande, car cela augmente la satisfaction du client et permettra de créer un produit
final qui correspond mieux aux besoins du client.
Événement 5 : Rétrospective du sprint
Cette réunion dure normalement trois heures pour un Sprint d'un mois. Si le Sprint est plus
court qu'un mois, cette réunion sera proportionnellement plus courte.
Il existe une règle : nous devons toujours chercher à nous améliorer. Cette réunion est une
opportunité formelle pour d'amélioration, même si nous ne limitons pas notre amélioration
aux résultats de cette réunion. Nous allons examiner (inspecter) le Sprint, en ce qui concerne
les personnes, les relations, les processus et les outils, et identifier les moyens de les améliorer
pour le prochain Sprint.
LES ARTEFACTS SCRUM
Les artefacts Scrum - résultats/produits de nos activités de gestion - sont conçus pour
augmenter transparence des informations relatives à la réalisation du projet, et offrent des
opportunités d'inspection et d'adaptation.
Il y a trois artefacts dans Scrum :
Backlog de produit : Une liste ordonnée de tout ce (appeleés stories) qui pourrait être
nécessaire dans le Le produit final.
Backlog de sprint : Éléments sélectionnés (stories) du Backlog de produit à livrer au cours
d'un sprint. dans le cadre d'un sprint, ainsi que l'objectif du sprint et les plans pour livrer les
éléments et réaliser l'objectif du sprint.
Incrément de produit : L'ensemble de tous les éléments du Backlog de produit terminés
jusqu'à la fin d'un certain Sprint
Axe 2 : Manipuler l’outil de gestion de projet Agile
(Scrum/Jira) (Travaux Pratiques)
