Chapitre 3: Les

principes de
méthodes agiles
(Scrum)
S2/ 2023
Projet féderé
Nessrine Abbassi

1
 Introduction générale
• Le secteur informatique a connu une évolution
générale, dans les vingt dernières années.
 Cette évolution se trouve à l’origine de la
rapidité et de la complexité des projets
informatiques : instabilité des demandes, fortes
exigences des clients, accélération du marché
technologique, diversification des offres, etc.

2
Les méthodes Agiles sont : des pratiques qui s'appliquent aux projets de
développement logiciel (Projets informatiques).
Elles permettent une grande réactivité aux demandes des utilisateurs.

Ce sont des structures: cycliques, itératives, incrémentales et adaptatives.

Ces méthodes sont plus pragmatiques que les méthodes

traditionnelles.

3
 Rappel : Les faiblesses de modèles
classiques
Peu
d’adaptation
aux
changements
des clients

4
 • Elles reconnaissent leur parenté
directe avec les Méthodologies
RAD (Développement rapide
d'applications) de James Martin
Le parenté de (1991)
la • Les RAD les plus connues sont :
méthodologie • Scrum(1996)
• XP (eXtreme Programming,
Agile 1999)

5
 Plusieurs réponses sont
possibles pour être agile.

Responsabilité de la
C’est garantie du bien-être de
travail.
quoi être
Satisfaction des clients et
agile ? présentation des bons
produits

Productivité et
organisation efficace du
travail
6
 Définition de
l’agilité
• Appliquée au monde des
logiciels, la notion d’agilité
renvoie à la capacité
d’adaptation des sociétés
informatiques aux demandes
évolutives des clients, arrivant
le plus souvent en cours de
projet à une meilleure maîtrise
du triptyque
« coût/qualité/périmètre fonctionnel ».

7
 Les moyens
(Comment?)
• Utiliser une approche
collaborative, Itérative et
incrémentale
• Découper le besoin des clients et
prioriser
• Découper la réalisation
• Livrer fréquemment des
incréments de produit
• Accepter les changements
• Contrôler régulièrement
l’avancement avec les parties
prenantes

8
 Les objectifs de
méthodes Agiles
(Pourquoi?)
• Trouver un compromis entre le
minimum de méthode
permettant de mener à bien les
projets, tout en restant
adaptable et créatif
• Accepter le changement des
besoins et être capable d’y
Répondre de façon rapide et
souple
• Privilégier le code plutôt que
la documentation

9
 I- Le Manifeste
Agile
• Le Manifeste Agile est un
texte rédigé en 2001 par
17 experts du
développement
d'applications
informatiques.

• Il détermine 4 valeurs et
12 principes pour définir
les méthodes qui peuvent
garantir de l’agilité.

10
A- Valeurs de méthodes Agiles
1- Les individus 3- La
et leurs 2- Un logiciel collaboration 4- L’adaptation
interactions qui fonctionne avec les clients au
plus que les plus qu’une plus que la changement
processus et documentation négociation plus que le
les outils. exhaustive. contractuelle. suivi d’un plan.

11
 B- Les principes
des méthodes
agiles (1-6)
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
elles 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.

12
 Les 12 principes (7-12)
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. À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

13
• L'essentiel à retenir

14
• Il ne s’agit pas de penser un
dispositif idéal (qui n’existe
pas)
• Mais un dispositif intelligent,
souple, vertueux, et évolutif,
qui évoluera de lui même vers
ses objectifs économiques et
écologiques.
-> L’agilité permet de tester et
mettre en œuvre très rapidement
des choses simples

15
 C-Les Pratiques
des Méthodologies Agiles

Excellents pour les développement de logiciels

Un cadre de travail, un Framework plus qu’une

méthodologie pour les projets « non
prédictibles » et complexes

SCRUM (Mêlée, Rugby)

XP (eXtreme Programming)

AUP (Agile Unified Process)

Crystal

FDD (Feature Driven Development)

16
Carine Khalil. Les méthodes "agiles" de
management de projets informatiques
: une analyse "par la pratique".
Gestion et management. Télécom
ParisTech, 2011. Français. (Khalil,
2011)

17
 II- SCRUM
Définition: Scrum est une méthode agile dédiée à la
gestion de projets informatiques
Objectif: Son objectif est d'améliorer la productivité des
équipes
Origine: Le mot « Scrum » vient du mot « mêlée » du
rugby, (le
concept a été initié par Takeuchi et Nonaka, 1986)
 La méthode n'est pas une technique de
programmation, il faut lui associer une méthode de
développement comme: XP (eXtreme Programming)
ou la « Construction structurée » de la méthode RAD.

18
 SCRUM: Le processus s'articule autour d'une équipe
soudée, qui cherche à atteindre un but, comme en
rugby pour avancer avec le ballon pendant une mêlée.

19
Le modèle
empirique

20
• 1- Le modèle empirique du Scrum

21
• 2- Le modèle empirique du Scrum

22
Le jargon de Scrum

23
24
Sprint: Est une itération

Backlog: Est une liste de tâches ouvertes

Product Backlog: Est une liste d’items ouverts pour livrer le produit

Sprint Backlog: Est une liste de tâches ouvertes attribuées au Sprint

L’EQUIPE ou la Development TEAM: C’est l’équipe de développement

La Scrum Team: C’est l’ EQUIPE + le ScrumMaster + le Product

Définitions
Owner Estimation Meeting : C’est la réunion d’estimation Sprint

Planning Meeting C’est la réunion de planification de Sprint

Daily Scrum ou Stand-up Meeting C’est la réunion journalière de 15’ où

l’EQUIPE inspecte et adapte, coordonne son effort.

Sprint Review ou Revue de Sprint C’est la réunion de fin de Sprint où tous les
acteurs de projet se retrouvent pour inspecter les délivrables du Sprint.

Rétrospective C’est la réunion d’inspection et d’adaptation de la Scrum Team

25
 Scrum Team

La Development Team

Le ScrumMaster

Le Product Owner

Rôles Rôles organisationnels

Le Management

Le Client

Les Utilisateurs

26
 • Sa fonction:
• Elle délivre le produit et elle est responsable de sa qualité
• Elle travaille avec les utilisateurs-finaux, le client, le Product
Owner pour comprendre les exigences.
• Elle s’engage volontairement
• Elle travaille continuellement avec le Product Owner pour
définir la direction stratégique du Produit.

La •
•
•
Sa mission:
Garantir la Qualité
Livrer • Livrer • Livrer
Development •
•
Estimer • Estimer • Estimer
S’engager
•
Team •
S’autogérer
S’organiser .... Elle-même

27
 • Sa fonction:
• Protège l’équipe des turbulences
• Il n’est pas un membre de l’Équipe
• Il optimise la productivité de l’Équipe
• Il contrôle l’”Inspect-&-Adapt” de l’Équipe
• Il assure que les idéaux “agiles” soient bien compris et
respectés par tous les participants au projet.
Le •
•
Il n’est pas responsable des déliverables.
Sa mission :
ScrumMaster •
•
Protéger l’Équipe Scrum
Lever les obstacles
• Exécuter le process
• Travailler avec le Product Owner
• Changer l’Organisation
28
 Le Product
Owner
• Sa fonction:
• Il pilote le projet d’un point de vue métier
• Il communique une vision claire du produit et
défini ses caractéristiques
• Il accepte ou rejette le produit à la fin de chaque
Sprint
• Il s’assure que l’Équipe se concentre sur les items
du Backlog de plus forte valeur ajoutée
• Il a le même objectif que l’Équipe
• Il est responsable du Retour sur Investissement et
des livraisons.
• Sa mission:
• Se concentre sur le retour sur investissement
• Construit et communique la vision
• Entretien le Product Backlog
• Rend compte de l’acceptance des délivrables
• Établi et maintien le Plan de Livraison

29
 Le Client
• Sa fonction:
• Il demande le produit
• Il contracte l’organisation pour le
développement de son produit
• Typiquement, il s’agit d’un responsable qui
achète un développement de produit par
un sous-traitant.
• Dans les projets internes, il s’agit
principalement du sponsor au projet, c’est à
dire la personne validant le projet et le
budget.
• Sa mission:
• Il commande le produit
• Il paye le développement du produit
• Il donne des feed-back et des révisions

30
 Le Manager
• Sa fonction:
• Le management, la gestion, est
primordial dans tout projet Scrum. Il
permet à l’Équipe de constituer un
environnement optimal pour le
déroulement du projet Scrum.
• Le manager donne de la structure et
de la stabilité.
• Il travaille de concert avec le
ScrumMaster pour réorganiser
l’organigramme de la structure et
donner de la guidance si nécessaire.
• Sa mission:
• Il s’assure que l’organisation puisse
survivre en cas de défaillance.
• Il crée des règles et des lignes
directrices.

31
 L’Utilisateur Final

• Sa fonction
• Ce rôle peut être joué par un grand nombre de personnes.
• L'Utilisateur final est celui qui connaît les besoins et avec cette
connaissance, il définit le produit en disant à l'équipe ce dont il a besoin
comme fonctionnalités.
• Sa mission
• Il connaît ses besoins et ses exigences
• Il donne son feed-back lors des revues
• Il participe au Sprint Planning 1

32
User Story Card

33
Les bonnes Stories

34
XP: modèle Agile

35
• Exemples
des projets
d’innovation

36
37
38