05/01/2024

MÉTHODOLOGIES AGILES Pr. A. DARGHAM

 05/01/2024

HISTORIQUE
Au milieu des années 90, un groupe d’expert en cycles de vie de
logiciels voulaient proposer de nouveaux modèles.
Les nouveaux modèles proposés sont plus « légers »  moins de
documentation et moins de contrôle sur le procédé.
Ils s’adressent à des projets de petite ou moyenne taille avec une
équipe réduite.
Ils permettent de s’ajuster rapidement aux changements des
spécifications tout en garantissant des livraisons fréquentes.
Ces modèles ont été qualifiés de « méthodes agiles ».

MÉTHODES AGILES
Les méthodes agiles sont plus pragmatiques et plus souples que
les méthodes traditionnelles (qui sont très strictes et très lourdes) :
« Quelles activités pouvons nous abandonner tout en produisant des
logiciels de bonne qualité ? »
Les méthodes agiles permettent une grande réactivité aux
demandes utilisateurs :
« Comment mieux travailler avec le client pour nous focaliser sur ses
besoins les plus prioritaires et être aussi réactifs que possible ? »
 05/01/2024

MÉTHODES AGILES
Appliquent des processus itératifs, incrémentales et adaptatives.
Orientées satisfaction des besoins client (et non contrat).
Officialisées en 2001 par le Manifeste Agile.
Reconnaissent leur parenté directe avec les Méthodologies RAD
(Rapid Application Development) de James Martin (1991).

MÉTHODES AGILES
La difficulté est répartie sur plusieurs parties grâce à la
décomposition du projet.
Livraisons fréquentes et validation continue.
Gère mieux les demandes de changements en cours en acceptant
d’introduire des changements plutôt que de suivre strictement un
plan rigide.
Orientées interactions plus que processus et outils.
 05/01/2024

EXEMPLES DE MÉTHODES AGILES

Scrum (1996).
XP : eXtreme Programming (1999).
DSDM : Dynamic Software Development Method (1994).
ASD : Adaptative Software Development (1990).
CCM : Crystal Clear Methodologies (2004).
FDD : Feature Driven Development (1997).
RAD : Rapid Application Development (1991).
AUP : Agile Unified Process (2001).

MANIFESTE AGILE
Le terme « agile » fut apparu dans le domaine du logiciel avec le
« Manifeste agile » (Agile Manifesto).
Publié en Février 2001 et inchangé depuis, ce manifeste définit une
attitude de réaction par rapport à des processus lourds et
bureaucratiques, en vogue à l’époque (et parfois encore
aujourd’hui).
Signé par 17 personnalités, dont les créateurs de Crystal, Scrum,
Adaptive Software Development, etc.
 05/01/2024

MANIFESTE AGILE
Le Manifeste agile définit des valeurs et des principes qui sont
universels, mais la façon de les mettre en œuvre sur des projets
varie.
Cette application se fait par l’intermédiaire de ce qu’on appelle les
pratiques.
Une pratique est une approche concrète et éprouvée qui permet de
résoudre un ou plusieurs problèmes courants ou d’améliorer la façon
de travailler lors d’un développement.

VALEURS AGILES
Le Manifeste agile inclut quatre valeurs :
Les personnes et leurs interactions sont plus importants que les
processus et les outils.
Un logiciel qui fonctionne bien prime sur de la documentation
exhaustive.
La collaboration avec les clients est préférable à la négociation
contractuelle.
La réponse au changement passe avant le suivi d’un plan.
 05/01/2024

VALEURS AGILES

Individus et Logiciel fonctionnelle

interaction au lieu au lieu de
de processus et documentation
outils massive

Collaboration client Réagir au

au lieu de changement au lieu
négociation du de suivre un plan
contrat

INDIVIDUS & INTERACTIONS

Les collaborateurs sont la clé du succès.
Les seniors échoueront s’ils ne collaborent pas en tant qu’équipe.
Un bon collaborateur n’est pas forcément un bon programmeur,
mais c’est quelqu’un qui travaille bien en équipe.
Une surabondance d’outils est aussi mauvaise que le manque
d’outils.
Démarrer petit et investir peu au démarrage.
Construire l’équipe est plus important que construire
l’environnement.
 05/01/2024

LOGICIELS FONCTIONNELS
Un code sans documentation est un désastre, mais trop de
documents est pire que pas de documents.
Difficulté à produire et à synchroniser avec le code.
Souvent les documents sont des "mensonges" formels, par contre le
code ne ment jamais sur lui-même.
Produire toujours des documents aussi courts que possible.

COLLABORATION DU CLIENT
Très difficile de décrire la totalité du logiciel depuis le début.
Les projets réussis impliquent les clients d’une manière fréquente et
régulière.
Le client doit avoir un contact direct avec l’équipe de
développement.
 05/01/2024

RÉACTION AUX CHANGEMENTS

Un logiciel ne peut pas être planifié très loin dans le futur.
Tout change : technologie, environnement et surtout les besoins.
Les chefs de projets classiques fonctionnent sur la base de GANTT,
PERT  les diagrammes se dégradent (des tâches s’ajoutent et
d’autres deviennent non nécessaires).
Une meilleure stratégie est de planifier très court (2 semaines à 1
mois).
Plannings détaillés pour la semaine à venir, rigoureux pour les trois
mois et très vagues au-delà.

LES 12 PRINCIPES AGILES

1. Toujours satisfaire le client à travers des livraisons rapides et
continues.
2. Bien accueillir tous les changements même les tardifs.
3. Livrer fréquemment un système fonctionnel.
4. Les clients et les développeurs doivent collaborer.
5. Conduire le projet autour d’équipes motivées.
6. La meilleure méthode de faire circuler l’information c’est le
contact direct entre collaborateurs.
 05/01/2024

LES 12 PRINCIPES AGILES

7. La première mesure d’avancement c’est un logiciel fonctionnel.
8. Le développement doit être durable et à un rythme constant.
9. La bonne conception et l’excellence technique augmentent
l’agilité.
10. Simplifier au maximum.
11. Les meilleurs architectures, besoins et conceptions proviennent
d’équipes qui s’organisent d’elles-mêmes.
12. L’équipe s’améliore d’une manière autonome et régulière.
 05/01/2024

XP : EXTREME PROGRAMMING
Créée par Kent Beck en 1995, XP a été l’une des premières
méthodologies agiles.
Destinée à des équipes de moyenne taille avec des spécifications
incomplets et/ou vagues.
XP met l’accent sur le codage.
La philosophie de XP se résume dans la citation suivante dû à son
créateur : « L’une des hypothèses universelles du génie logiciel est
que le coût de la modification d’un programme augmente de façon
exponentielle avec le temps ».

XP : EXTREME PROGRAMMING
La force de XP réside dans sa simplicité et le fait qu’on va
droit à l’essentiel, selon un rythme qui doit rester constant.
XP est fondé sur les 4 piliers suivants :
Les valeurs.
Les pratiques.
Les activités.
Les rôles.
 05/01/2024

VALEURS D’XP
Communication :
XP met l’accent sur la communication verbale, plutôt que le
cloisonnement des activités et les échanges de documents formels.
Les développeurs travaillent directement avec la maîtrise
d’ouvrage.
Feedback :
Les pratiques XP sont conçues pour donner un maximum de
feedback sur le déroulement du projet afin de corriger la trajectoire
au plus tôt  un peu de feedback peut remplacer beaucoup de
travail analytique.

VALEURS D’XP
Simplicité :
Du processus.
Du code.
Courage :
D’honorer les autres valeurs.
De maintenir une communication franche et ouverte.
D’accepter et de traiter de front les mauvaises nouvelles.
 05/01/2024

PRATIQUES D’XP
XP est fondé sur des valeurs, mais surtout sur 13 pratiques
réparties en 3 catégories :
Gestion de projets.
Programmation.
Collaboration.

PRATIQUES DE GESTION DE PROJETS

Livraisons fréquentes :
L’équipe vise la mise en production rapide d’une version minimale
du logiciel, puis elle fournit ensuite régulièrement de nouvelles
livraisons en tenant compte des retours du client.
Planification itérative :
Un plan de développement est préparé au début du projet, puis il
est revu et remanié tout au long du développement pour tenir
compte de l’expérience acquise par le client et l’équipe de
développement.
 05/01/2024

PRATIQUES DE GESTION DE PROJETS

Client sur site :
Le client est intégré à l’équipe de développement pour répondre
aux questions des développeurs et définir les tests fonctionnels.
Rythme durable :
L’équipe adopte un rythme de travail qui lui permet de fournir un
travail de qualité tout au long du projet.
Jamais plus de 40h de travail par semaine (un développeur fatigué
développe mal).

PRATIQUES DE PROGRAMMATION
Conception simple :
Jamais développer quelque chose qui soit inutile tout de suite.
Remaniement :
Le code est en permanence réorganisé pour rester aussi clair et
simple que possible.
Tests unitaires :
Les développeurs mettent en place une batterie de tests de
non-régression qui leur permettent de faire des modifications
sans crainte.
 05/01/2024

PRATIQUES DE PROGRAMMATION
Tests de recette :
Les testeurs mettent en place des tests automatiques qui
vérifient que le logiciel répond aux exigences du client.
Ces tests permettent des recettes automatiques du logiciel.

PRATIQUES DE COLLABORATION
Responsabilité collective du code :
Chaque développeur est susceptible de travailler sur n’importe
quelle partie de l’application.
Programmation en binômes :
Les développeurs travaillent toujours en binômes, ces binômes
étant renouvelés fréquemment.
Règles de codage :
Les développeurs se plient à des règles de codage strictes
dénies par l’équipe elle-même.
 05/01/2024

PRATIQUES DE COLLABORATION
Métaphore :
Les développeurs s’appuient sur une description commune du
design.
Intégration continue :
L’intégration des nouveaux développements est faite chaque
jour.

ACTIVITÉS D’XP
Codage :
Représente à peu près l’ensemble du projet (noyau de XP).
Test :
Accorder une grande importance aux tests pendant le codage.
Écoute :
Mettre de côté leurs idées préconçues et écouter ce que les
clients disent réellement.
Conception :
Réfléchir comment simplifier cela.
 05/01/2024

RÔLES XP
Pour un travail en équipe, on distingue 6 rôles principaux au sein
d’une équipe XP :
Développeur.
Client.
Testeur.
Tracker.
Manager.
Coach.

RÔLES XP : DÉVELOPPEUR
Conception et programmation, même combat !
Participation aux séances de planification & évaluation des tâches et
de leurs difficultés.
Définition des tests unitaires.
Implémentation des fonctionnalités et des tests unitaires.
 05/01/2024

RÔLES XP : CLIENT
Rédaction, explication et maîtrise les scénarios.
Spécification des tests fonctionnels de recette.
Définition des priorités.

RÔLES XP : TESTEUR
Aide du client à élaborer des jeux de test.
Écriture des tests de recette automatiques pour valider les scénarios
clients.
Intervention dans les choix de conception pour éviter des options qui
augmentent les difficultés de test, donc les risques de non détection
d’erreur.
Ce rôle délicat nécessite une bonne connaissance du métier et des
compétences en développement. Il s’appuie le plus souvent sur des
outils automatisés.
 05/01/2024

RÔLES XP : TRACKER
Le tracker est le gestionnaire du temps au sein de l’équipe.
Il intervient notamment en début de chaque itération lors de
l’estimation, et ensuite il contrôle la progression par des échanges
avec les développeurs.
Cette tâche correspond à un pilotage opérationnel et quotidien.
Le tracker n’a pas d’autorité hiérarchique.
Son rôle est de maintenir le souci du respect des engagements par
son activité quotidienne, mais aussi de détecter d’éventuels
problèmes suffisamment tôt pour alerter le coach ou le manager.

RÔLES XP : TRACKER
Chaque matin, il anime une brève réunion, appelée standup
meeting car l’on reste debout, au cours de laquelle chaque
développeur annonce ce qu’il va faire durant la journée et
d’éventuelles difficultés auxquelles il se heurte.
 05/01/2024

RÔLES XP : TRACKER
Suivi du planning pour chaque itération.
Compréhension des estimations produites par les développeurs
concernant leur charges.
Interaction avec les développeurs pour le respect du planning de
l'itération courante.
Détection des éventuels retards et rectifications si besoin.

RÔLES XP : MANAGER
Supérieur hiérarchique des développeurs  responsable du projet.
Vérification de la satisfaction du client.
Contrôle du planning.
Gestion des ressources.
 05/01/2024

RÔLES XP : COACH
Garant du processus XP.
Organisation et animation des séances de planification.
Favorisation de la créativité du groupe (n’impose pas ses solutions
techniques).
Résolution des problèmes entre les membres de l’équipe.

CYCLE DE VIE XP
 05/01/2024

CYCLE DE VIE XP : EXPLORATION

Les développeurs se penchent sur les questions techniques :
Explorer les différentes possibilités d’architecture pour le système.
Etudier par exemple les limites au niveau des performances
présentées par chacune des solutions possibles.
Le client s’habitue à exprimer ses besoins sous forme de US (user
strories) qui sont proches de diagrammes de cas d’utilisation
illustrés par des diagrammes de séquences.
Les développeurs estiment le temps de développement.

CYCLE DE VIE XP : PLANNING

Planning de la première release :
Uniquement les fonctionnalités essentielles.
Première release à enrichir par la suite.
Durée du planning : 1 ou 2 jours.
Première version (release) au bout de 2 à 6 mois.
 05/01/2024

CYCLE DE VIE XP : ITÉRATIONS

Développement de la première version de l’application.
Itérations de une à quatre semaines :
Chaque itération produit un sous ensemble des fonctionnalités
principales.
Le produit de chaque itération subit des tests fonctionnels.
Itérations courtes pour identifier très tôt des déviations par rapport
au planning.
Brèves réunions quotidiennes réunissant toute l’équipe, pour mettre
chacun au courant de l’avancement du projet.

CYCLE DE VIE XP : MISE EN PRODUCTION

La mise en production produit un logiciel :
Offrant toutes les fonctionnalités indispensables.
Parfaitement fonctionnel.
Mis à disposition des utilisateurs.
Itérations très courtes.
Tests constants en parallèle du développement.
Les développeurs procèdent à des réglages affinés pour améliorer
les performances du logiciel.
 05/01/2024

CYCLE DE VIE XP : MAINTENANCE

Continuer à faire fonctionner le système.
Adjonction de nouvelles fonctionnalités secondaires :
Pour les fonctionnalités secondaires, on recommence par une
rapide exploration.
L’ajout de fonctionnalités secondaires donne lieu à de nouvelles
releases.

CYCLE DE VIE XP : MORT

Quand le client ne parvient plus à spécifier de nouveaux besoins, le
projet est dit mort :
Soit que tous les besoins possibles sont remplis.
Soit que le système ne supporte plus de nouvelles modifications en
restant rentable.
 05/01/2024

AVANTAGES DE XP
Implication forte et active du client.
Forte réactivité des développeurs.
Responsabilisation et solidarité de l’équipe.
Appel aux meilleurs pratiques de développement.
Souplesse extrême.
Efficacité pour les petits et moyens projets effectués par des équipes
réduites.

INCONVÉNIENTS DE XP
Demande une certaine maturité des développeurs.
La programmation par paires n’est toujours pas applicable.
Difficulté de planifier et de budgétiser un projet.
Stress dû aux devoir de l’intégration continue et des livraisons
fréquentes.
La faible documentation peut nuire en cas de départ des
développeurs.
 05/01/2024

INTRODUCTION
Scrum n’est pas un processus complet, et encore moins une
méthodologie, c’est un cadre de processus.
Scrum signifie mêlée en rugby.
Scrum utilise les valeurs et l’esprit du rugby et les adapte aux
projets de développement.
L’objectif principal de Scrum est d’aider les gens à améliorer leur
façon de travailler.
Il s’applique en particulier au développement de produits, de
services, d’applications ou de systèmes.
 05/01/2024

PRINCIPES DE SCRUM
Approche empirique :
Dans les domaines complexes, il n’est pas possible de prévoir à
l’avance ce qui sera réellement obtenu à la fin : les spécifications
détaillées, les plans détaillés faits à l’avance sont donc inadaptés.
L’approche empirique s’appuie sur des cycles courts avec des
rétroactions fréquentes pour avancer vers une solution inconnue au
départ.
Scrum applique une approche empirique.
L’empirisme dans Scrum est appelé « inspection & adaptation ».

PRINCIPES DE SCRUM
Rythme :
Scrum utilise des blocs de temps fixes pour créer de la
régularité.
Le cœur du rythme de Scrum est le sprint.
La nouveauté est que la fin du sprint n’est pas décidée quand
un travail est achevé, mais fixée à l’avance et jamais
repoussée.
 05/01/2024

PRINCIPES DE SCRUM
Priorité :
Pendant un sprint, le travail de l’équipe porte sur les choses
qui apportent le plus de valeur.
On évite de perdre du temps sur des choses sans valeur
immédiate.
On évite de commencer plein de travaux en même temps.

PRINCIPES DE SCRUM
Autogestion :
L’équipe a le pouvoir et l’autorité pour organiser son travail en
fonction de l’objectif.
Cela donne plus de responsabilité aux personnes impliquées et
leur permet de mieux s’épanouir dans le travail.
Centré utilisateur :
Les besoins client sont capturés en tant que « user stories ».
 05/01/2024

PRINCIPES DE SCRUM
Transparence :
Le suivi est fait par l’équipe elle-même.
Il est visible et reste simple afin qu’il soit facilement
compréhensible par tout le monde.
Un bon moyen pour y parvenir est de pratiquer
systématiquement le management visuel.
Feedback continu :
Le client fait partie de l’équipe et évalue de façon continue le
système pendant toues ses phases de développement.

PRINCIPES DE SCRUM
Émergence :
On laisse du temps à l’équipe pour favoriser l’émergence de
nouvelles idées pour le produit, pour la conception et aussi
pour améliorer la façon de travailler ensemble.
Itératif :
Le projet est découpé en plusieurs boîtes de temps (2 à 4
semaines).
 05/01/2024

PRINCIPES DE SCRUM
Incrémental :
Les livraisons sont fréquentes.
Les « users stories » qui marquent la fin d’un sprint doivent
donner lieu à des tâches opérationnelles et à des
fonctionnalités directement utilisables.
Agile :
Durant tout le projet, le client et l’utilisateur final sont intégrés
dans l’équipe.

MÉCANIQUE DE SCRUM
Scrum sert à développer des produits, généralement en
quelques mois.
Les fonctionnalités souhaitées sont collectées dans le backlog
de produit et classées par priorité.
C’est le Product Owner qui est responsable de la gestion de ce
backlog.
 05/01/2024

MÉCANIQUE DE SCRUM
Une version (release) est produite par une série d’itérations
d’un mois appelées des sprints.
Le contenu d’un sprint est défini par l’équipe, avec le Product
Owner, en tenant compte des priorités et de la capacité de
l’équipe.
À partir de ce contenu, l’équipe identifie les tâches nécessaires
et s’engage pour réaliser les fonctionnalités sélectionnées pour
le sprint.

MÉCANIQUE DE SCRUM
Pendant un sprint, des points de contrôle sur le déroulement
des tâches sont effectués lors des mêlées quotidiennes
(scrums).
Cela permet au Scrum Master, l’animateur chargé de faire
appliquer Scrum, de déterminer l’avancement par rapport aux
engagements et d’appliquer, avec l’équipe, des ajustements
pour assurer le succès du sprint.
 05/01/2024

MÉCANIQUE DE SCRUM
À la fin de chaque sprint, l’équipe obtient un produit partiel
(un incrément) qui fonctionne.
Cet incrément du produit est potentiellement livrable et son
évaluation permet d’ajuster le backlog pour le sprint suivant.

CYCLE DE VIE SCRUM

 05/01/2024

RÔLES DE SCRUM
Dans Scrum, on distingue généralement trois rôles :
Le product Owner.
Le Scrum Master.
L’équipe Scrum.

PRODUCT OWNER
Personne physique de l’équipe (la seule) qui soit responsable
du produit auprès des parties prenantes  le product owner est
le responsable du résultat final.
Sa présence dans l’équipe est indispensable, car il est souvent
amené à prendre des décisions stratégiques et techniques.
Le Product Owner ne décide pas tout seul; beaucoup de
travaux qu’il mène se font en équipe et ses décisions sont
prises, chaque fois que c’est important, en accord avec elle.
 05/01/2024

RESPONSABILITÉS DU PRODUCT OWNER

Partager la vision du produit :
La raison pour laquelle on crée le produit.
L’objectif de la prochaine release.
Les impacts attendus sur les acteurs.
La liste des fonctionnalités essentielles qui y contribuent.
Tous les membres de l’équipe et toutes les parties prenantes du
projet devraient partager la même vision, et c’est au Product
Owner de s’en assurer.

RESPONSABILITÉS DU PRODUCT OWNER

Affiner le produit :
Le Product Owner définit le contenu du produit.
Pour cela, il identifie les fonctionnalités requises, collectées
auprès des parties prenantes et mises dans une liste, appelée
« backlog du produit ».
Concrètement, le Product Owner s’occupe du backlog et
passe une bonne partie de son temps à l’affiner, en anticipation
sur les sprints suivants.
 05/01/2024

RESPONSABILITÉS DU PRODUCT OWNER

Planifier le cycle de vie :
Le Product Owner définit l’ordre dans lequel les parties du
produit seront développées.
Il alimente l’équipe avec les fonctionnalités à développer, en
s’efforçant de maximiser la valeur.
C’est aussi lui qui définit les jalons du cycle de vie du produit.
Il donne l’objectif d’une release et prend les décisions sur son
contenu et sa date de mise à disposition auprès des utilisateurs.

COMPÉTENCES SOUHAITÉES DU PO
Bonne connaissance du métier.
Maîtrise des techniques de définition du produit.
Autorité pour prendre des décisions rapidement.
Capacité à détailler au bon moment.
Esprit ouvert au changement.
Aptitude à la négociation.
 05/01/2024

SCRUM MASTER
Le Scrum Master est une personne dans l’équipe Scrum qui se
met à son service, pour faciliter la réalisation des travaux
demandés par le Product Owner, en appliquant Scrum au
mieux, compte tenu du contexte de l’organisation.
Le scrum master est un capitaine d’équipe et non pas un chef
du projet.

RESPONSABILITÉS DU SCRUM MASTER

Servir l’équipe :
Motiver l’équipe pour qu’elle s’auto-organise.
Pousser l’équipe à devenir pluridisciplinaire, en renforçant ses
capacités en ingénierie, pour ne plus dépendre d’experts
extérieurs (devenir autonome).
S’il réussit, l’équipe aura moins besoin de lui  c’est le
paradoxe du Scrum Master.
 05/01/2024

RESPONSABILITÉS DU SCRUM MASTER

Éliminer les obstacles :
Un obstacle est un fait concret touchant une ou plusieurs personnes
et qui empêche l’équipe d’avancer à son rythme : un développeur
s’est cassé le bras au ski, le serveur Git est tombé en panne, le
composant attendu pour le paiement en ligne n’est pas prêt, etc.
C’est au SM de pousser l’équipe à mettre en évidence les obstacles,
et c’est aussi à lui de s’assurer de leur élimination.
Il fait en sorte d’éviter qu’ils ralentissent durablement l’équipe.

RESPONSABILITÉS DU SCRUM MASTER

Appliquer Scrum :
Aider à progresser avec Scrum et à l’appliquer, dans le respect des
valeurs d’équipe.
Enseigne les pratiques jusqu'à ce que l’équipe les mette en œuvre.
L’originalité de Scrum vient du fait que les responsabilités sont
partagées : le PO prévoit et anticipe, tandis que le SM accompagne
l’équipe qui réalise ce que demande le PO.
La réussite de Scrum repose sur la tension de la demande entre le
PO et l’équipe, tension contrôlée de façon positive par le SM.
 05/01/2024

RESPONSABILITÉS DU SCRUM MASTER

Pratiquer l’art du possible :
Le SM a pour mission de faire appliquer Scrum, mais une posture
trop radicale face au management peut conduire au rejet de Scrum.
Il doit tenir compte du contexte de l’organisation.
En particulier, le SM protège l’équipe des perturbations, mais il doit
savoir jusqu’où il est possible d’aller, face à une organisation qui
n’arrive pas à changer ses habitudes rapidement.

COMPÉTENCES SOUHAITÉES DU SM
Bonne connaissance de Scrum.
Aptitude à comprendre le fonctionnel et la technique.
Facilité à communiquer.
Capacité à guider.
Talent de médiateur.
Ténacité.
Inclination à la transparence.
Goût à être au service de l'équipe.
 05/01/2024

L’ÉQUIPE SCRUM
« Les gens et leurs interactions sont plus importants que les
processus et les outils »
L’équipe a un rôle capital dans Scrum :
Elle est constituée avec le but d’optimiser la flexibilité et la
productivité.
Elle s’organise elle-même et doit avoir toutes les compétences
nécessaires au développement du produit.
Elle est investie avec le pouvoir et l’autorité pour faire ce
qu’elle à faire.
 05/01/2024

IMPORTANCE DES GENS DANS SCRUM

Dans les équipes Scrum, les gens ne sont pas considérés
comme des ressources mais comme des créateurs de valeur.
Scrum est associé à cinq valeurs : focus, ouverture, respect,
courage et engagement (d’autres ajoutent la visibilité et
l’humour).
L'équipe Scrum est composée des personnes qui contribuent à
produire un résultat à chaque sprint.

CARACTÉRISTIQUES D’UNE ÉQUIPE SCRUM

Taille :
Pour que le cadre Scrum reste efficace, le nombre de personnes
dans une équipe doit rester limité.
Une seule personne, cela ne constitue pas une équipe.
De 2 à 4, cela représente une petite équipe Scrum.
Entre 5 et 9, on a la taille idéale.
À partir de 10, l’équipe est trop grande pour bien faire du
Scrum.
 05/01/2024

CARACTÉRISTIQUES D’UNE ÉQUIPE SCRUM

Auto-organisation :
C’est l’équipe qui réalise le produit, en développant un nouvel
incrément à chaque sprint.
Elle est investie du pouvoir et de l’autorité pour le faire de la
façon qu’elle estimera la plus efficace : elle définit
l’organisation des travaux.
Chaque membre de l’équipe apporte son expertise, la synergie
améliorant l’efficacité globale.

CARACTÉRISTIQUES D’UNE ÉQUIPE SCRUM

Pluridisciplinarité :
Idéalement, une équipe Scrum possède en son sein toutes les
compétences nécessaires pour finir le travail dans un sprint.
Une équipe est pluridisciplinaire quand elle couvre,
collectivement, toutes les disciplines requises pour développer
le produit.
 05/01/2024

CARACTÉRISTIQUES D’UNE ÉQUIPE SCRUM

Stabilité :
Une équipe Scrum doit être stable sur une longue durée.
Rester avec la même équipe permet d’apprendre à mieux travailler
ensemble.
Le modèle de Tuckman présente les étapes de constitution d’une
équipe : création et structuration, confrontations et tensions,
régulation et normalisation, synergie et performance, dissolution et
séparation.
La stabilité permet de laisser du temps aux équipes pour tendre vers
l’harmonisation et la performance.

CARACTÉRISTIQUES D’UNE ÉQUIPE SCRUM

Identité :
Une bonne équipe Scrum possède une forte identité.
L’adhésion à des valeurs communes y contribue.
Vivre dans le même espace physique est aussi important pour
augmenter l’identité de l’équipe.
 05/01/2024

ÉLÉMENTS DU CADRE SCRUM

Dans Scrum, on distingue les éléments (artefacts)
fondamentaux suivants :
Le product backlog.
Le sprint backlog.
L’incrément.

LE PRODUCT BACKLOG
Après avoir décidé de lancer le développement d’un logiciel, il est
temps de transformer la vision de départ en quelque chose
d’exploitable par l’équipe de développement.
Avec Scrum, les spécifications émergent progressivement par une
collaboration continue entre les membres de l’équipe et le PO, et
grâce aux feedbacks réguliers donnés par les parties prenantes.
L’outil de collecte et de partage s’appelle le product backlog (ou
tout simplement le backlog) : en première approche, le backlog est
simplement une liste ordonnée des choses à réaliser par l’équipe.
 05/01/2024

CARACTÉRISTIQUES DU BACKLOG
Unicité :
Un seul backlog par produit.
Être publique :
Le backlog est élaboré et maintenu par le PO, mais c’est l’outil de
toute l’équipe.
Il également visible des parties prenantes : clients, utilisateurs,
managers, …
Tout ce monde y a accès, ce qui favorise la transparence et facilite le
feedback, qui se concrétise par l’ajout de nouvelles idées.

CARACTÉRISTIQUES DU BACKLOG
Être ordonné :
Les éléments du backlog sont ordonnés par valeur décroissante.
Le PO peut utiliser diverses techniques agile pour ordonner le
backlog (voir ci-dessous).
Vivacité :
Le backlog suit la vie du produit qu’il décrit et évolue avec lui  il
peut donc durer très longtemps et être utilisé sur plusieurs releases
successives.
 05/01/2024

CARACTÉRISTIQUES DU BACKLOG
Émergence :
Le backlog n’est pas figé.
Il n’est jamais complet ou fini tant que vit le produit.
Il est élaboré dans une forme initiale pendant le sprint zéro, puis il
évolue constamment  des éléments sont ajoutés, d’autres sont
supprimés, certains sont décomposés et l’ordre ajusté.
Être réduit :
Le backlog doit être assez court  entre 40 et 60 éléments en
général.

ÉLÉMENTS DU PRODUCT BACKLOG

La story :
Une user story (US) est un petit morceau de fonctionnalité visible
d’un utilisateur et qui peut être développé en un sprint.
Exemple :
Comme un utilisateur enregistré  Who
Je dois avoir la possibilité de modifier le mot de passe  What
Afin de garder mon compte sécurisé  Why
Cependant, dans un backlog, toutes les histoires (stories) ne sont
pas relatives à des utilisateurs (user).
 05/01/2024

ÉLÉMENTS DU PRODUCT BACKLOG

L’epic :
L’epic (ou story épique) est une story dont l’équipe considère
qu’elle ne peut pas entrer dans un sprint en l’état (ne peut pas passer
au statut « prête »).
C’est une story trop grosse ou mal connue, car on ne sait pas encore
ce qu’elle cache.
Une story épique doit donc être décomposée ou étudiée  elle a
besoin d’affinage.
Exemple : comme professeur enregistré dans la plateforme e-
learning, je dois gérer mes cours afin qu’ils soient toujours à jour.

ÉLÉMENTS DU PRODUCT BACKLOG

Le feature :
Une feature est un service ou une fonction d’un logiciel dont
l’énoncé est clair pour les parties prenantes.
Elle contribue à un impact et se décompose en stories.
Exemple : gestion des notes étudiants.
Elle sera réalisée par plusieurs stories.
Elle n’est pas rythmée par le sprint comme la story.
Elle peut être non finie à la fin d’un sprint, mais elle doit être finie à
la fin de la release, au plus tard.
 05/01/2024

CYCLE DE VIE D’UNE STORY : 5C

Un jour, quelqu’un a une idée de story et la note sur une Carte.
Le PO et l’équipe affinent cette story, afin qu’elle puisse être réalisée
en un sprint, au cours d’une Conversation.
L’équipe apporte sa Confirmation qu’elle est prête.
L’équipe réalise la story pendant un sprint, en tenant une nouvelle
Conversation avec le PO, sur son acceptation.
Le PO apporte sa Confirmation qu’elle est finie.

CYCLE DE VIE D’UNE STORY

 05/01/2024

LE SPRINT BACKLOG
Les sprints sont un élément de base du cadre Scrum et font
référence à une courte période de temps (généralement 1 à 2
semaines, mais peut parfois aller jusqu’à 1 mois) au cours de laquelle
l’ensemble du calendrier d’un projet est découpé.
Un sprint est une capsule temporelle autonome qui se répète
cycliquement jusqu’à ce que le projet soit terminé.
À la fin de chaque sprint, il y a un livrable du produit qui est
essentiellement sous forme d’un incrément.

LE SPRINT BACKLOG
Ceci est important, car non seulement le produit est conçu de manière
successive et itérative, mais à la fin de chaque sprint ou itération, le
produit doit être en état de fonctionnement, même s’il est limité en
fonctionnalités.
 05/01/2024

LE SPRINT BACKLOG

LE SPRINT BACKLOG
Planification :
Cette première activité consiste pour l’équipe à sélectionner les
principaux éléments du product backlog (user stories) qui doivent
être développés dans le sprint en cours.
Ces éléments constituent désormais le sprint backlog.
Ils sont ensuite subdivisées en tâches.
On s’assure alors que les tâches engagées pour le sprint sont claires,
et qu’elles sont réalisables compte tenu de la durée.
L’effort de chaque tâche est également estimé par l’équipe.
 05/01/2024

LE SPRINT BACKLOG

LE SPRINT BACKLOG
Développement :
Pendant cette période, chaque membre de l’équipe récupère des
tâches spécifiques du sprint backlog et les fait passer au statut « en
cours » ou « travail en cours ».
Cela peut être fait sur un tableau qui affiche l’état de chaque tâche
(appelé tableau Scrum).
Le développement peut être subdivisé en des activités typiques :
conception, programmation, test et déploiement.
Le développeur déplacerait alors la tâche vers « terminé » une fois
que tout le cycle de développement de la tâche serait terminé.
 05/01/2024

LE SPRINT BACKLOG
Mêlé quotidien :
En début de journée et chaque jour, une session Scrum quotidienne
a lieu au cours de laquelle chaque membre de l’équipe rapporte aux
autres membres de l’équipe ce qu’elle a fait la veille en termes de
travail et ce qu’elle fera aujourd’hui.
Il s’agit d’une réunion courte (environ 15 min), généralement
debout, qui a pour but d’informer chacun sur l’avancée des tâches.

LE SPRINT BACKLOG
Réunion de bilan :
Il s’agit d’une réunion au cours de laquelle l’équipe présente au PO
et à toute autre partie prenante (PP) intéressée par le produit,
généralement vers la fin du sprint, le produit potentiellement
livrable.
Le PO discute des éléments qui ont été réalisés et de ceux qui n’ont
pas satisfait aux critères d’acceptation.
C’est également l’occasion pour les PP de donner leur avis à
l’équipe sur les fonctionnalités ou les changements qu’elles
souhaiteraient réellement dans le produit.
 05/01/2024

LE SPRINT BACKLOG
Réunion rétrospective :
Elle a lieu à la fin du sprint. Il s’agit d’une réunion entre les membres
de l’équipe pour discuter de ce qui s’est bien passé avec leur processus
actuel et également de ce qui peut être amélioré.
Il s’agit d’une session qui vise à affiner et à améliorer davantage
l’ensemble du processus Agile-Scrum, afin de le rendre plus efficace
lors des prochaines courses de sprint et c’est une session où les
membres se donnent mutuellement leurs commentaires.
En règle générale, à mesure que l’équipe progresse, elle développe
plus de cohésion et tend à s’améliorer à chaque cycle de sprint
suivant.

LE SPRINT BACKLOG
Réunion de planification des versions :
Au cours de cette réunion (en fin du sprint), le product backlog est
revisité et les prochaines user stories examinées en préparation du
prochain sprint. L’équipe pourra alors :
Analyser le product backlog pour voir comment il s’intègre dans les
prochains sprints à venir et analyser les dépendances.
Diviser certaines des user stories les plus importantes en histoires plus
petites et plus faciles à gérer.
Vérifier la priorisation pour voir si elle est toujours adéquate et la mettre
à jour.
 05/01/2024

L’INCRÉMENT
Un sprint est une itération qui produit un nouvel incrément et peut
aussi enrichir l’incrément obtenu dans un sprint précédent.
L’équipe ne s’engage jamais sur un incrément, mais plutôt sur
la "definition of done".
On considère ainsi la "definition of done" comme l’engagement de
l’incrément.

CARACTÉRISTIQUES DES INCRÉMENTS

Un incrément est une première étape concrète vers l’objectif de
produit.
Chaque incrément s’ajoute à tous les incréments précédents.
Chaque incrément fait l’objet d’une vérification approfondie, ce qui
garantit que tous les incréments fonctionnent ensemble.
Afin de fournir de la valeur, l’incrément doit être utilisable.
Plusieurs incréments peuvent être créés durant un sprint.
La somme des incréments est présentée lors de la sprint review.
 05/01/2024

CARACTÉRISTIQUES DES INCRÉMENTS

Un incrément peut être livré aux parties prenantes avant la fin du
sprint.
Un travail qui ne remplirait pas les conditions de la "definition of
done" ne peut pas être considéré comme un incrément.

OUTILS SCRUM
Jira.
Azure DevOps Project Mangement.
GoodDay.
Trello.
ClickUp.
Zoho Sprints.
 05/01/2024

AVANTAGES DE SCRUM
Flexibilité & Adaptabilité :
Une approche Scrum est la mieux adaptée à un environnement
relativement incertain où il est très difficile, voire impossible, de
définir avec précision les exigences et la conception détaillée de la
solution avant le début du projet.
Dans ce type d’environnement, la flexibilité et l’adaptabilité sont
essentielles pour définir et élaborer davantage les exigences et la
conception de la solution au fur et à mesure de l’avancement du
projet.

AVANTAGES DE SCRUM
Créativité & Innovation :
Dans l’environnement hautement compétitif dans lequel nous vivons
aujourd’hui, personne ne veut acheter des produits moyens et banals.
Les gens attendent un niveau d’excellence plus élevé, ce qui
nécessite de la créativité et de l’innovation.
Une approche Scrum met l’accent sur la créativité et l’innovation
pour maximiser la valeur commerciale de la solution plutôt que sur
la planification et le contrôle qui ont tendance à étouffer la créativité
et l’innovation.
 05/01/2024

AVANTAGES DE SCRUM
Délai de mise sur le marché :
Une approche Scrum se traduit généralement par un délai de mise
sur le marché plus rapide en raison de temps de démarrage plus
courts et d’un effort de développement incrémentiel qui permettra
une livraison rapide d’au moins une partie de la solution sans
attendre que la solution entière soit terminée à 100%.

AVANTAGES DE SCRUM
Coûts réduits :
Une approche Scrum peut réduire les coûts d’un projet de plusieurs
manières :
Réduction significative des frais généraux résultant de la réduction des
exigences inutiles en matière de documentation et de contrôle.
Productivité plus élevée de l’équipe de projet.
Réduction du « gonflement des fonctionnalités » dû à l’utilisation d’un
effort de développement progressif et à la priorisation des exigences,
cela deviendra évident lorsque le projet commencera à atteindre un point
de rendement décroissant où la valeur des fonctionnalités ne dépasse
plus le coût de développement.
 05/01/2024

AVANTAGES DE SCRUM
Qualité améliorée :
Dans un projet Scrum, la qualité fait partie intégrante du processus
de développement plutôt qu’une activité séquentielle. Les
développeurs savent que la qualité n’est pas « la responsabilité de
quelqu’un d’autre ».
Satisfaction du client :
Une approche Scrum devrait entraîner une plus grande satisfaction
du client et des solutions plus efficaces, car le client est fortement
impliqué dans la fourniture de commentaires et de contributions tout
au long du processus de développement.

AVANTAGES DE SCRUM
Satisfaction des employés :
Une approche Scrum devrait également entraîner une plus grande
satisfaction des employés de la part de tous les employés engagés
dans l’effort, car ils sont beaucoup plus engagés à assumer la
responsabilité de leur propre travail au sein d’une équipe
responsabilisée.
 05/01/2024

AVANTAGES DE SCRUM
Autres avantages de Scrum :
Cadre de processus très simple et très efficace.
Adoptée par les géants du marche : Microsoft, Google, Nokia, …
Orientée projet, contrairement a XP qui est orientée développement.
Peut inclure d’autres activités venant d’autres méthodologies
(surtout XP).

INCONVÉNIENTS DE SCRUM
N’est pas 100 % spécifique au génie logiciel.
Difficulté de budgétiser un projet Scrum.
Formation et compétences requises :
Une approche Scrum nécessite une quantité considérable de
formation et de compétences pour être mise en œuvre avec succès.
De nombreuses équipes de projet ne comprennent pas pleinement le
besoin de formation et de compétences et tentent de faire Scrum de
manière mécanique sans en comprendre pleinement les principes, ce
qui n’est généralement pas très efficace.
 05/01/2024

INCONVÉNIENTS DE SCRUM
Transformation organisationnelle :
Une approche Scrum peut également nécessiter un certain niveau de
transformation organisationnelle pour réussir.
Cela nécessite que les utilisateurs métier travaillent en collaboration
avec l’équipe de développement dans un esprit de confiance et de
partenariat.
Cela peut nécessiter de supprimer certaines barrières
organisationnelles qui rendent cela difficile, voire impossible, à
réaliser.

INCONVÉNIENTS DE SCRUM
Évolutivité :
Il est difficile d’adapter une approche Scrum à des projets de grande
envergure et complexes.
Il existe quelques modèles pour ce faire (Scrum-of-Scrums, LeSS
et SAFe en sont des exemples), mais aucun d’entre eux n’est une
solution de livre de recettes facile à mettre en œuvre.
 05/01/2024

INCONVÉNIENTS DE SCRUM
Intégration avec la gestion de projet/programme :
Une approche Scrum peut ne pas être totalement appropriée pour
les projets qui nécessitent une approche davantage axée sur un plan.
Cependant, il existe de nombreuses façons de créer une approche
hybride qui mélange une approche traditionnelle basée sur un plan et
une approche Scrum dans les bonnes proportions pour s’adapter à la
situation.