1. Méthodes Agiles
SCRUM et eXtrem Programming (XP)
Youness BOUKOUCHI
Enseignant-chercheur
y.boukouchi@gmail.com
Version1.1(2017)

2. Introduction
Méthodologie agile
eXtreme Programming
SCRUM
Outils de l’agilité
2

3. Introduction aux méthodes agile
3

4. Cycle de vie traditionnel
Conception Réalisation Recette
Nouvelles
applications
Applications
améliorées
Applications
corrigées
Applications
retirées
Demandes de
Nouvelles applis
Demandes
D’amélioration
Problèmes
Défauts
StratégiqueTactique
Les utilisateurs sont sollicités
dans un délai court pour
valider l’intégralité du dossier
de conception
Il faut concevoir tout le
produit et répondre à toutes
les questions dès le début
Introductionàl’agilité
4

5. Conception Réalisation Recette Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes de
Nouvelles applis
Demandes
D’amélioration
Problèmes
Défauts
StratégiqueTactique
Les utilisateurs sont sollicités dans des
démonstrations trop longues leur montrant de
nombreuses fonctionnalités
Toutes les fonctionnalités sont intégralement
développées sans arbitrages sur le R.O.I.
Les travaux sont fortement parallélisés et sont
souvent bloqués par des questions fonctionnelles
Introductionàl’agilité
Cycle de vie traditionnel
5

6. Conception Réalisation Recette Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes de
Nouvelles applis
Demandes
D’amélioration
Problèmes
Défauts
StratégiqueTactique
Les utilisateurs sont fortement
sollicités sur une période très
courte
Certains points soulevés en
recette peuvent remettre en
cause profondément d’autres
fonctionnalités
Introductionàl’agilité
Cycle de vie traditionnel
6

7. Une réalité constatée…
Budget Dépassé
Planning non-respecté
Qualité insuffisante
Non conforme au Business
Introductionàl’agilité
7

8. Cycle de vie classique
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes de
Nouvelles applis
Demandes
D’amélioration
Problèmes
Défauts
StratégiqueTactique
Analyse
des Exigences
Système
Analyse
des Exigences
Conception
Générale
Conception
Détaillée
Code et tests
unitaires
Intégration et
tests d’intégration
Installation et
Déploiement
Exploitation et
Maintenace
• Pilotée par la documentation (la plus détaillée possible)
• Tâches enchaînées par des équipes cloisonnées
• Résistances aux évolutions des exigences
• Plus les modifications sont tardives = Plus le coût est élevé
Introductionàl’agilité
8

9. Les principaux inconvénients de la méthode classique sont :
 Il est très difficile de faire une conception exhaustive au démarrage du
projet.
 Les erreurs de conception ou de programmation ou variation du besoin
sont détectées au dernier moment ce qui aggrave leurs conséquences.
 Il n’est pas efficace de solliciter les utilisateurs de manière intense sur des
périodes courtes.
 L’application opérationnelle n’est disponible qu’à la fin du projet.
 Il est difficile de communiquer directement avec les utilisateurs
La méthode classique
Introductionàl’agilité

10. Cycle de vie Agile
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes de
Nouvelles applis
Demandes
D’amélioration
Problèmes
Défauts
StratégiqueTactique
Planifier, Faire, Vérifier, Adapter
Equipes Multi-compétentes qui intègrent le client, le développement, les tests et les
autres profils nécessaires
Livraison Incrémentale de fonctionnalités et d’une qualité de production à des
intervalles réguliers
Développements dirigés par les tests (TDD) pour mettre la qualité au premier rang
des préoccupations

11. Expression des besoins
Conception
Développement
Tests, recette & debugage
Expression des besoins
Conception
Développement
Tests, recette & debugage
i
1
i
2
i
3
i
n
Les solutions AgilesLes solutions classiques
Les équipes agiles font un peu de tout, tout le temps
Introductionàl’agilité

12. Méthodologie agile
12

13. Rappel sur les méthodes agiles
• Une méthode agile est une approche itérative et incrémentale, qui est
menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme
• Elle génère un produit de haute qualité tout en prenant en compte
l’évolution des besoins des clients
• Les Concepts de l’agilité sont formalisés en février 2001, aux États-Unis,
par le Manifeste Agile (http://agilemanifesto.org).
– dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes
respectives, dites méthodes agiles.
MéthodologieAgile
13

14. Manifeste pour le développement Agile
Nous découvrons comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :
1. Les individus et leurs interactions plus que les processus et les outils
2. Des logiciels opérationnels plus qu’une documentation exhaustive
3. La collaboration avec les clients plus que la négociation contractuelle
4. L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
MéthodologieAgile
14

15. 1 - Priorité aux personnes et aux interactions sur les procédures et les
outils (Individuals and interactions over processes and tools )
• La meilleure garantie de succès réside dans les personnes
• Les interactions, les initiatives et la communication interpersonnelles qui
feront le succès d’un projet.
2 - Priorité aux applications fonctionnelles sur une documentation
pléthorique (Working software over comprehensive documentation)
• la documentation est extrêmement consommateur de ressources.
• La documentations succincte (les grandes lignes) régulièrement tenue à jour
• Le meilleur transfert des connaissances s’effectue par la participation au
travail de l’équipe.
MéthodologieAgile
Manifeste pour le développement Agile
15

16. 3 - La collaboration avec les clients plus que la négociation contractuelle
(Customer collaboration over contract negotiation)
• Le succès d’un projet requiert un feedback régulier et fréquent de la part du
client.
• Un contrat qui spécifie les exigences, le planning et le coût d’un projet a priori
relève d’une vision utopique d’un projet informatique.
4 – L’adaptation au changement plus que le suivi d’un plan (Responding to
change over following a plan)
• La capacité à accepter le changement qui fait bien souvent la réussite ou l’échec
d’un projet.
• Lors de la planification, il est donc nécessaire de veiller à ce que le planning soit
flexible et adaptable aux changements qui peuvent intervenir dans le contexte,
les technologies et les spécifications.
Manifeste pour le développement Agile
MéthodologieAgile
16

17. L'équipe (« Personnes et interaction plutôt
que processus et outils »)
L'application (« Logiciel fonctionnel plutôt que
documentation complète »)
La collaboration (« Avec le client plutôt que
négociation de contrat »)
L'acceptation du changement (« Réagir au
changement plutôt que suivre un plan »)
Manifeste pour le développement Agile
MéthodologieAgile
17

18. Les 12 principes (manifeste agile)
Notre plus haute priorité est
de satisfaire le client en livrant
rapidement et régulièrement
des fonctionnalités à grande
valeur ajoutée.
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.
Livrez fréquemment un logiciel
opérationnel avec des cycles
de quelques semaines à
quelques mois et une
préférence pour les plus
courts.
Les utilisateurs ou leurs
représentants et les
développeurs doivent travailler
ensemble quotidiennement
tout au long du projet.
MéthodologieAgile
18

19. Les 12 principes (manifeste agile)
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.
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.
Un logiciel opérationnel est la
principale mesure d’avancement.
Les processus Agiles encouragent
un rythme de développement
soutenable. Ensemble, les
développeurs et les utilisateurs
devraient être capables de
maintenir indéfiniment un rythme
constant.
MéthodologieAgile
19

20. Les 12 principes (manifeste agile)
Une attention continue à
l'excellence technique et à
une bonne conception
renforce l’Agilité.
La simplicité – c’est-à-dire
l’art de minimiser la quantité
de travail inutile – est
essentielle.
Les meilleures
architectures, spécifications
et conceptions émergent
d'équipes auto-organisées.
À 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éthodologieAgile
20

21. Agile regroupe plusieurs méthodologies :
– Extreme Programming (XP)
– DSDM
– Crystal
– Scrum
– FDD
– …
les méthodes Agile
MéthodologieAgile
21

22. Méthode eXtreme Programming
22

23. MéthodeeXtremeProgramming
• C’est une méthode plus récente basée sur le
rassemblement de bonnes pratiques déjà connues et
utilisées
• C’est une méthodologie de développement basée sur les
valeurs, les principes et les pratiques de l’agilité
– Petites livraisons : entre 1 et 2 mois
– Itérations : entre 2 à 3 semaines
23

24. Éléments fondamentaux d’XP
5 valeurs
 Communication
 Simplicité
 Feedback
 Courage
 Respect
MéthodeeXtremeProgramming
24

25. Les 5 valeurs d'XP
Communication
• la communication entre tous les intervenants :
– entre développeurs (programmation en binôme), entre développeurs et managers (tests,
estimations), entre développeurs et clients (tests, spécifications).
• La communication permettre à chacun de se poser les bonnes questions
et de partager l'information.
Simplicité
• XP encourage l'orientation vers la solution la plus simple qui puisse
satisfaire les besoins du client.
Feedback
• un feedback permet de repérer et de corriger les erreurs plus facilement et
d’accueillir les changements.
– Des tests unitaires, fonctionnels
– Du client: Revue avec le client toutes les deux à trois semaines
– De l’équipe: Grace à la communication continuelle
MéthodeeXtremeProgramming
25

26. Les 5 valeurs d'XP
Courage
• Le courage permet de sortir d'une situation inadaptée.
• Certains changements demandent beaucoup de courage:
– changer l'architecture d'un projet,
– jeter du code pour en produire un meilleur
– essayer une nouvelle technique.
Respect
• le respect pour les autres, ainsi que le respect de soi.
• Les membres respectent leur propre travail en cherchant toujours la
qualité et la meilleure conception pour la solution.
– ne jamais valider les modifications qui cassent la compilation,
– Ne jamais échouer les tests unitaires existants
– Ne jamais retarder le travail de pairs.
MéthodeeXtremeProgramming
26

27. Les 12 pratiques XP
1 - Planning game
• Exprimer les besoins de client sous forme de "user stories"
• Attribuer à chaque user story un nombre de points (Temps, priorité, effort)
• Planifier les releases avec la participation des développeurs et le client.
2 - Petites releases
• Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus
souvent possible.
3 - Utilisation de métaphores
• Utiliser des métaphores pour décrire l'architecture du système.
• Avoir une vision globale du système(comprendre ses éléments ainsi que leurs
interactions).
MéthodeeXtremeProgramming
27

28. Les 12 pratiques XP
4 - Conception simple
•Développer la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. C’est
pas d’utiliser le moins possible de classes et de méthodes.
•Produire la documentation seulement demandée par le client.
5 - Tests (unitaires et fonctionnels)
•Les tests unitaires sont écrits et effectués pour vérifier le bon fonctionnement des méthodes ou des
constructeurs.
•Il est recommandé d'écrire les tests avant le code de l'application.
•Les tests fonctionnels sont conçus par le client pour vérifier le fonctionnement global du système, de
contrôler l'évolution du projet, et d' d'affiner l'expression de ses besoins.
6 - Refactoring du code
•Simplifier, structurer le code, tout en faisant en sorte que tous les tests soient satisfaits.
•le refactoring du code assure l’évolution et la maintenance de système.
MéthodeeXtremeProgramming
28

29. Les 12 pratiques XP
7 - Programmation en binôme
•Toute l'écriture du code se fait à deux personnes sur une même machine,
•On distingue deux rôles : le pilote("driver") programme et le "partner" observe et suggère des solutions
•Les binômes ne doivent pas être statiques : chacun change de partenaire relativement pour un meilleur
partage des connaissances
8 - Appropriation collective du code
•Toute l'équipe est sensée connaître la totalité du code (plus ou moins dans le détail selon les parties).
•Tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code.
9 - Intégration continue
•le code nouvellement écrit doit être intégré à l'existant de manière à avoir à tout moment un existant
fonctionnel qui passe avec succès tous les tests.
MéthodeeXtremeProgramming
29

30. Les 12 pratiques XP
10 - Pas de surcharge de travail
• une équipe ne doit jamais être surchargée de travail plus de deux semaines consécutives.
• Respecter la vélocité de l’équipe
11 - Client sur site
• la présence sur site d'une personne minimum à temps plein pendant toute la durée du
projet.
• Cette personne doit avoir une vision plus globale du contexte pour pouvoir préciser les
besoins, l’ordre de priorité de user stories, établir les tests fonctionnels, etc.
12 - Standards de code
• Disposer de normes de nommage et de programmation (les bonnes pratiques).
MéthodeeXtremeProgramming
30

31. Cycle de vie d’un projet XP
Exploration
• Au cours de cette phase, les développeurs se penchent sur des questions d'ordre technique
destinées à explorer les différentes possibilités d'architecture pour le système.
• Le client s'habitue à exprimer ses besoins sous forme de user stories que les développeurs
devront estimer en terme de temps de développement.
MéthodeeXtremeProgramming
31

32. Cycle de vie d’un projet XP
Planning
• Le planning de la première release (uniquement des fonctionnalités essentielles), à enrichir par
la suite.
• Le planning game dure un ou deux jours et la première release est en général programmée
pour deux à six mois plus tard.
MéthodeeXtremeProgramming
32

33. Cycle de vie d’un projet XP
Itérations jusqu'à la première release
• C'est la phase de développement sous forme d'itérations de une à quatre semaines.
• Chaque itération produit un ensemble de fonctionnalités passant avec succès les tests
fonctionnels associés.
• La première itération est dédiée à la mise en place de l'architecture du système.
• des brèves réunions réunissent toute l'équipe quotidiennement pour mettre chacun au courant
de l'avancement du projet.
MéthodeeXtremeProgramming
33

34. Cycle de vie d’un projet XP
Mise en production
• Des itérations plus courtes pour renforcer le feedback.
• Au cours de cette phase, les développeurs procèdent à des réglages affinés pour améliorer
les performances.
• A la fin de cette phase, un produit réalisé avec toutes les fonctionnalités indispensables et
parfaitement fonctionnelles.
MéthodeeXtremeProgramming
34

35. Cycle de vie d’un projet XP
Maintenance
• continuer à faire fonctionner le système
• adjoindre des fonctionnalités secondaires.
• L'ajout de fonctionnalités secondaires donne lieu à des nouvelles releases, une nouvelle
phase d'exploration rapide doit avoir lieu.
MéthodeeXtremeProgramming
35

36. Cycle de vie d’un projet XP
Mort
• La fin d'un projet intervient quand le client n'arrive plus à écrire de user stories
supplémentaires.
MéthodeeXtremeProgramming
36

37. Rôles
Développeur
– Conception et programmation
– Participe aux séances de planification, évalue les tâches et leur difficulté
– Définition des test unitaires
– Implémentation des fonctionnalités et des tests unitaire
Client
– Écrit, explique et maîtrise les scénarios
– Spécifie les tests fonctionnels de recette
– Définit les priorités
Testeur
– Écriture des tests de recette automatiques pour valider les scénarios clients
– Peut influer sur les choix du clients en fonction de la testabilité des scénarios
MéthodeeXtremeProgramming
37

38. Rôles
Tracker
– Suivre le planning pour chaque itération.
– Interagir avec les développeurs pour le respect du planning de l'itération courante
– Détection des éventuels retards et rectifications si besoin
Manager
– Responsable du projet
– Apporte à l'équipe le courage et la confiance
– Vérification de la satisfaction du client
– Contrôle le planning
Coach
– Organise et anime les séances de planifications
– Favorise la créativité du groupe, n'impose pas ses solutions technique
– Au fur et à mesure de la maturation de l'équipe, sont rôle diminue et l'équipe devient
plus autonome.
MéthodeeXtremeProgramming
38

39. Utiliser XP quand…
 Besoins flous
 Périmètre mal défini
 Petite équipe – 12 personnes
maximum
 Site unique
 Pas de sous-traitance
Ne pas utiliser XP si…
 Besoins changeront peu
 Périmètre bien défini
 Équipe de plus de 12 personnes
 Développement multi-sites
 Développement offshore
 Projets critiques
MéthodeeXtremeProgramming
39

40. Méthode SCRUM
40

41. Principes clés
• Scrum est une méthode agile qui permet de produire la plus grande valeur
métier dans la durée la plus courte.
• Méthode itérative et incrémentale:
– Réalisation d’un ensemble de fonctionnalités par itération
– Itération d’une durée fixe (de 2 à 4 semaines) => Sprint
– Livraison d’un produit partiel fonctionnel par itération
• Participation du client
– Définition des fonctionnalités prioritaires
– Ajout de fonctionnalités en cours de projet (pas pendant un sprint)
MéthodeSCRUM
41

42. Les rôles
 Le Product Owner : Il représente les
utilisateurs, définit et priorise les demandes
produit. Il est intégré à l’équipe et doit savoir
être disponible.
 Le Scrum Master : Ce n’est pas le chef de
projet. Il a un rôle de facilitateur. Sa mission
est de tout mettre en œuvre pour que l'équipe
travaille dans de bonnes conditions et se
concentre sur l'objectif du projet.
 L’équipe SCRUM : Une équipe regroupant tous
les rôles traditionnels : architecte,
développeur, testeur, administrateur, etc. Cette
équipe développe le produit et se gère en
toute autonomie.
 Coach agile : Il intervient de manière
ponctuelle pour aider à mettre en place les
outils Agile dans un domaine méthodologique
MéthodeSCRUM

43. MéthodeSCRUM
Les rôles
43

44. Le processus Scrum
1. Backlog produit (ou catalogue des besoins)
 Besoins priorisés par le product owner
 Besoins évalués par l’équipe
MéthodeSCRUM
De 2 à 4 semaines
44

45. Le processus Scrum
2. Backlog de sprint
 Extrait du backlog produit
 Besoins éclatés en tâches
MéthodeSCRUM
De 2 à 4 semaines
45

46. Le processus Scrum
3. Sprint
 Développement des fonctionnalités du backlog de sprint
 Aucune modification du backlog de sprint possible
MéthodeSCRUM
De 2 à 4 semaines
46

47. Le processus Scrum
4. Mêlée quotidienne
 Point de contrôle quotidien de l’équipe
 Interventions régulées – 2 min. par personne
MéthodeSCRUM
De 2 à 4 semaines
47

48. Le processus Scrum
5. Incrément logiciel : livré au Product owner à la fin du
sprint.
MéthodeSCRUM
De 2 à 4 semaines
48

49. Outils de l’agilité
49

50. Outils de l’agilité
• Le tableau des tâches (Le Sprint Board)
Outilsdel’agilité
50

51. Le Burndown Chart
Le Burndown chart permet de matérialiser l’avancement global du projet.
Les courbes représentent la taille total du backlog ainsi que le nombre d’user
stories restant à réaliser (en points de complexité).
Outils de l’agilité
Outilsdel’agilité

52. La vélocité
La vélocité est le nombre de points recettes pour chaque itération.
Cet indicateur permet d’avoir une bonne vision de la productivité globale
de l’équipe projet.
Outils de l’agilité
Outilsdel’agilité

53.  Gestion d’une liste de tâche: AgileFant, IceScrum, etc.
Outils de l’agilité
Outilsdel’agilité
53

54. Conclusions
54

55. SCRUM : Gestion de projet : définition de rôles, itérations courtes de durées
fixes, participation active du client, collaboration, communication, feedback,
flexibilité aux changements, amélioration continue …
XP (eXtreme Programming) : Gestion du développement logiciel : forte
réactivité, travail d’équipe, qualité du code , développement dirigé par les tests
(TDD), intégration continue, simplicité…
Conclusions

56. Conclusions
56

57. Merci de votre attention
57