Les méthodes agiles émergent pour surmonter les limitations des méthodes classiques, en favorisant l'adaptabilité et l'implication du client tout au long du processus de développement. Elles reposent sur un ensemble de valeurs et de principes qui promeuvent la collaboration, la simplicité et l'itération, permettant des ajustements en cours de projet. Différentes méthodologies agiles, telles que Scrum et Extreme Programming, mettent en œuvre ces principes pour optimiser la livraison de valeur et réduire les risques associés au développement logiciel.

1. LES MÉTHODES AGILES
1

2. ORIGINES
Ecueils des méthodes « classiques » prédictives
Dérapage cout/délai
Effet tunnel et difficulté implication client
Ecarts / besoin client

3. ORIGINES
Besoins mal compris
Manque de visibilité de la MOA sur les travaux et résultats
MOE : effet tunnel
Difficulté de communication
Rigidité : Changements mal vécus
de la MOA qui souhaite un résultat adapté au moment de sa
livraison
de la MOE qui souhaite respecter son contrat
Impossibilité de tout prévoir : certitude de l’incertitude
Adaptations difficiles : obligent à modifier les plans
Besoins
Boite noire
? Livraison

4. ORIGINES
En 2001, 17 développeurs ayant expérimentés des
développements légers s’accordent sur un socle
commun :
Manifeste Agile décrivant
4 valeurs
12 principes
Agile alliance pour la promotion de l’agilité et le soutien
aux équipes souhaitant les mettre en œuvre
Méthodes agiles = cadres de développement
s’inspirant des valeurs et principe du manifeste
agile

5. PRINCIPES GÉNÉRAUX
4 VALEURS
« 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 :
Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers. »
7
1. Les individus
2. Des logiciels opérationnels
3. La collaboration avec les
clients
4. L’adaptation au
changement
les processus et les outils
une documentation exhaustive
la négociation contractuelle
le suivi d’un plan
plus
que

6. PRINCIPES GÉNÉRAUX
4 VALEURS
Reformulées :
1. EQUIPE
 Idéalement colocalisée
 Communique au maximum et s’entend bien
 De niveau homogène
2. LOGICIEL
 Mieux vaut simple mais qui fonctionne plutôt que trop de fonctions
1. COLLABORATION
 Partenariat avec client plutôt que relation contractuelle client-fournisseur
 Client impliqué, au cœur de la méthode
2. ADAPTABILITE
 Accepter le changement,il y en aura forcément
 Refactoring permanent
 Réajustement à chaque livraison

7. PRINCIPES GÉNÉRAUX
12 PRINCIPES (RÉSUMÉS)

8. PRINCIPES GÉNÉRAUX
12 PRINCIPES
1. « Notre plus haute priorité est de satisfaire le client en livrant
ajoutée »
 Itération courte, avec validation par le clientet éventuelle repriorisation
2. « Accueillez positivement les changements de besoins,même tard
donner un avantage compétitif au client. »
3. « Livrez fréquemment un logiciel opérationnel avec des cycles de
courts. »
 Version intermédiaire visible et testable plus efficace que
4. Les utilisateurs ou leurs représentants et les
long du projet. »
 Collaboration avec des utilisateursimpliqués et disponibles

9. PRINCIPES GÉNÉRAUX
12 PRINCIPES
5. « Réalisez les projets avec des personnes motivées.
faites-leur confiance pour atteindre les objectifs fixés. »
 Clé du succès : l’équipe. L’organisation veille à lever les obstacles à
6. « La méthode la plus simple et la plus efficace pour transmettre de
le dialogue en face à face.»
 Favoriser l’échange oral par rapport aux seuls échanges écrits
7. « Un logiciel opérationnel est la principale mesure d’avancement.»
8. « Les processus Agiles encouragent un rythme de développement
utilisateurs devraient être capables de maintenir indéfiniment un
rythme constant. »

10. PRINCIPES GÉNÉRAUX
12 PRINCIPES
5. « Réalisez les projets avec des personnes motivées.
confiance pour atteindre les objectifs fixés. »
 Clé du succès :
fonctionnement
l’équipe. L’organisation veille à lever les obstacles à son bon
6. « La méthode la plus simple et la plus efficace pour transmettre de l’information
face.»
 Favoriser l’échange oral par rapport aux seuls échanges écrits
7. « Un logiciel opérationnel estla principale mesure d’avancement.»
8. « Les processus Agiles encouragent un rythme de développement
devraient être capables de maintenir indéfiniment un rythme constant. »
 Rythme déterminé par l’équipe et le client

11. PRINCIPES GÉNÉRAUX
12 PRINCIPES
9. « Une attention continue à l'excellence technique
 Code propre et évolutif, pas de jetable
10. «La simplicité c’est-à-dire l’art de minimiser la
11. «Les meilleures architectures, viennent d’équipe auto organisé
 L’équipe se partage elle-même les tâches
volontariat
sur la base du
12. «À intervalles réguliers, l'équipe réfléchit aux moyens
comportement en conséquence. »

12. PRINCIPES GÉNÉRAUX
« TRADITIONNELLE » VS AGILE
On définit au début le plan
(ressources nécessaires,
planning et donc délais) pour
réaliser le périmètre visé
on définit au début les ressources
alloués et le délai visé
… et on adapte régulièrement en
cours de projet le périmètre
Méthode « traditionnelle » =
prédictive
Méthode agile = adaptative

13. PRINCIPES GÉNÉRAUX
DÉVELOPPEMENT
Une succession de cycles complet :
Préparation
Conception
Réalisation
qualification
+ retour d’expérience pour amélioration
Développement
Incrémental
Itératif
Adaptatif

14. PRINCIPES GÉNÉRAUX
DÉVELOPPEMENT
Incrémental : Construire partie par partie
Itératif: réaliser et valider de manière de plus en plus précise,
pour passer d’une idée vague à une réalisation aboutie
Adaptatif : le besoin peut évoluer en cours de projet

15. PRINCIPES GÉNÉRAUX
DÉVELOPPEMENT
Incrémental+Itératif + adaptatif =
Chaque cycle
ajoute des fonctions (incrémental)
Raffine des fonctions du cycle précédent (itératif)
Prend en compte de nouveaux besoins (adaptatif)
Source :Jeff Patton

16. PRINCIPES GÉNÉRAUX
DÉVELOPPEMENT
Itératif+incrémental : choix pour l’équipe et le client de
pouvoir arrêter
Très tôt si on s’aperçoit que ce n’était pas une bonne idée
Coût limité à la préparation des cycles réalisés << cout total du
projet
En cours de route si le résultat est jugé déjà satisfaisant
Et que les autres fonctions ont un retour sur investissement
désormais évalué faible
Ou que les autres fonctions ne sont plus jugées si nécessaires
… facilité par
des résultats visibles régulièrement permettant au client de
juger du niveau atteint
des retours d’expérience et replanifications régulières

17. PRINCIPES GÉNÉRAUX
GAINS RECHERCHÉS
Le développement
itératif favorise
l’adaptation au
changement, intégré à
chaque itération
Livraison fréquente
Contenu de chaque
livraison hiérarchisé en
fonction de la valeur
pour le client

18. PRINCIPES GÉNÉRAUX
GAINS RECHERCHÉS
Les itérations
maintiennent l’équipe
constamment
mobilisées
L’enjeu est réparti sur
les itérations
Client au maximum au
contact de l’équipe tout
au long du projet
Implication incité par
Le pilotage des choix de
chaque itération
les démonstrations à
chaque itération

19. PRINCIPES GÉNÉRAUX
« TRADITIONNELLE » VS AGILE : SYNTHÈSE
« Traditionnelle » Agile
Cycle Séquentiel, en cascade ou V, sans
rétroaction
Itératif et incrémental
Documentation Importante car centrale dans
l’échange avec le client
Réduite car le retour du client est
obtenu en lui démontrant
régulièrement un incrément
Planification Prédictive, plan défini au début du
projet à partir du périmètre
Adaptative, périmètre ajusté au
fur et à mesure, précision juste à
Equipe Equipe hiérarchisée et spécialisée Equipe autoresponsable et
autoorganisée, privilégiant
Qualification À la fin du projet Le plus régulièrement possible

20. PRINCIPES GÉNÉRAUX
« TRADITIONNELLE » VS AGILE : SYNTHÈSE
« Traditionnelle » Agile
Changement résistance au changement,
accepté après un processus de
Intégré et accepté, voire apprécié,
car inéluctable
Avancement Mesuré par rapport au plan
initiaux (doc livrées etc…)
Mesuré par les fonctionnalités
réalisées et le reste à faire
Gestion des
risques
Processus distinct et codifié Intégré dans le processus, chacun
est responsable des les identifier
Objectifs Respect de l’engagement
qualité/coût/délai
Satisfaction client par livraison de
valeur ajoutée

21. MÉTHODES AGILES
REMARQUES
Contrairement aux idées reçues l’Agile n’est pas
moins rigoureux
Définition préalable des notions de Prêt et Réalisé
Suivi aux quotidiens (du consommé, des risques …)
Ajustement à chaque sprint des méthodes d’estimation des
tâches et de la « vélocité » de l’équipe
plus « léger »
Nécessite beaucoup de réunions (quotidienne, début/fin
sprint, préparation sprint, optimisation backlog…)
CR de toutes les réunions

22. PRINCIPALES MÉTHODES AGILES
A
A
A
A
A
A
A
A
A : Agiles

23. PRINCIPALES MÉTHODES AGILES
PHILOSOPHIE VS METHODOLOGIES
Bien discerner les approches et philosophie des
méthodologies qui s’en inspirent

24. PRINCIPALES MÉTHODES AGILES
RAD
Rapid Application Development (1991)
Mère des méthodes agiles
Introduit un nouveau cycle itératif/incrémental/adaptatif

25. PRINCIPALES MÉTHODES AGILES
ASD
Adaptative Software Development (1997)
Initialisation puis série de cycles comportant
(re)-planification en itérations de 4 à 8 semaines
Collaboration : réalisation des composants
Apprentissage : contrôle qualité et suivi de l’avancement
Caractéristiques
S’appuyer sur des composants
Découper le temps en se fixant des échéances (timeboxed)
Accepter le changement
Apprentissage
Collaboration
Spéculation
Planification
Initialisation
Planification
Planification
Planification
Planification
Dev.
composants
Planification
Planification
Contrôle
qualité
Contrôle
final et
livraison
Boucle d’apprentissage

26. PRINCIPALES MÉTHODES AGILES
CRYSTAL (1995)
Famille de méthodologie
Sélection de la méthode en fonctions de la taille et de la criticité
Rôles, livrables et cycle plus ou moins complexe selon la taille
Contrôle plus ou moins lourd selon la criticité
Caractéristiques
Livraison fréquentes
Adaptations permanentes
Communication permanente avec les utilisateurs
Pas de leader mais un coordinateur

27. PRINCIPALES MÉTHODES AGILES
DSDM
Dynamic Systems Development Method (1994)
9 principes
Implication active des utilisateurs
Autonomie et pouvoir de décision des équipes
Livraisons fréquentes
Adéquation aux besoins des clients comme seul critère d’acceptation du produit
Développement itératif et incrémental
Modifications réversibles
Définition macroscopique des besoins
Intégration des tests dans tout le cycle de vie
Collaboration et coopération entre toutes les parties prenantes
« Features » priorisés via Moscow(cf cours priorisation)
30

28. PRINCIPALES MÉTHODES AGILES
LEAN
Issu du système de production de Toyota dans les
années 50
Approche (et non méthode) visant à optimiser le
système de production
Quelques principes :
Flux tendu : passage fluide et rapide des pièces (ou
informations) entre acteurs, limiter stock
Management visuel
Qualité intégrée au processus de fabrication : défaut détecté
et traité à chaque étape
Remise en question permanente
Production
juste à temps pour satisfaire la demande
de la bonne quantité

29. PRINCIPALES MÉTHODES AGILES
LEAN
Eviter
gaspillages
Surproduction
Attente
Transports
Stocks inutile
Tâches inutiles
Mouvement inutile
défauts
Surcharge, excès
Moyens surdimensionnés par rapport à l’objectif
Variabilité
De quantité, de qualité …

30. PRINCIPALES MÉTHODES AGILES
LEAN VS AGILE
Le LEAN (également appelé LEAN manufacturing) a
inspiré le monde du développement logiciel
Lean Software Development en 2003 (notion de Lean IT)
basé sur 7 principes
Eliminer les gaspillages : retirer tout ce qui n’apporte pas de
valeur au client
Intégrer la qualité
Reporter la décision : prendre la décision le plus tard possible
pour avoir les meilleures informations…et prendre la meilleure
Créer de la connaissance : cycle court pour avoir un feedback
fréquent
Livraison rapide
Respecter les personnels
Optimisation globale : équipes multi compétences
Beaucoup de points communs avec la philosophie agile

31. PRINCIPALES MÉTHODES AGILES
FDD
Feature Driven Development (1997)
Commence par le développement d’un modèle global gros
« grain »
Puis décomposition en fonctionnalités (définies sous la forme
<action> causant <résultat> sur <objet>)
Développement progressif d’ensemble de fonctionnalités
Chaque ensemble développé en 2 semaines max
Potentiellement plusieurs équipes en parallèle
Structure fortement l’organisation du développement : 9 rôles
définis
Conçu aussi pour les projets de grande taille

32. PRINCIPALES MÉTHODES AGILES
XP
eXtreme Programming (1999)
Objectifs :
remettre le développeur au centre de la création de logiciel
Réduire les couts du changement
Conçu en poussant à l’extrême les bonnes pratiques du
développement.
les revues de code sont une bonne pratique  revues de code
permanentes  »pair programming », cad deux développeurs derrière
une seule machine
Conception importante  la faire tout au long du projet (refactoring)
Tests utiles  les préparer avant le développement (cf TDD)
Intégration nécessaire  la faire en continue, plusieurs fois par jour

33. PRINCIPALES MÉTHODES AGILES
XP
Communication
Intense
Clients/développeurs/testeurs
et décideurs
Simplicité
Le plus simple est le mieux
Ne pas chercher à anticiper les
évolutions !
+simple = + évolutif
YAGNI (you ain't gonna need it) :
ne développer que l’indispensable
Retour (feedback)
Indispensable pour
développeur et client
Via test unitaire, tests
fonctionnels et livraison
fréquente
Courage
Accepter de se tromper, de
jeter, de refaire, de changer
l’architecture
Dire ses difficultés
4 valeurs :

34. PRINCIPALES MÉTHODES AGILES
XP
Pratiques
Planning game
 Planifier de manière incrémentale
Small release
 Livrer aussi souvent que possible pour être
Metaphor
 Utiliser des images pour représenter des
Simple design
 Faire le plus simple possible
Testing
 Tout tester, en automatisant au maximum
Refactoring
 Faire évoluer la conception au fur et à mesure
Pair programming
 Programmer en binôme pour émulation et
Collective code ownership
 Tout les membres de l’équipe peuvent changer
Continuous integration
 Compilation et test automatique régulier
Sustainable pace
 Eviter heures supplémentaires…
Whole team
 Membre plutôt généraliste que spécialiste, tout
Coding standard
 Règles communes définies par l’équipe
On site custormer
 Accès fréquent au client si besoin
 Représentantutilisateur idéalement sur site

35. PRINCIPALES MÉTHODES AGILES
XP
Zoom sur des pratiques :
Test Driven Development
Ecrire les tests avant de développer la
fonction
Intégration continue
Compilation, test unitaires, analyse du
code etc… lancés régulièrement et
sur une variété
d’environnements
Pair programming
Une machine pour deux développeurs
Émulation et contrôle permanent = meilleures
idées et moins de bugs

36. PRINCIPALES MÉTHODES AGILES
XP
Les pratiques se soutiennent et renforcent les unes
les autres

37. PRINCIPALES MÉTHODES AGILES
XP
Processus et cycles de développement
*
*

38. PRINCIPALES MÉTHODES AGILES
SCRUM

39. PRINCIPALES MÉTHODES AGILES
SCRUM : BACKLOG
Liste des fonctions ordonnées
par priorité
par le client (product owner)
Fonction détaillée en tâche uniquement au
moment de l’intégration au sprintà venir
Définie sous forme de « User Story »
En tant que <utilisateur, administrateur…> je
veux pouvoir <trier les instances par …> afin de
<…>
Incluant dès le début les critères d’acceptation

40. PRINCIPALES MÉTHODES AGILES
SCRUM : ITERATION
De durée fixe
Début d’itération
Choix des stories à implémenter
Décomposition en tâches et estimation
Itération :
Développement, documentation, qualification
Préparation itération n+1
Fin d’itération
Démonstration du logiciel
Feedback
Pas de réorientation en cours d’itération

41. PRINCIPALES MÉTHODES AGILES
SCRUM : RÔLES
Scrum Master
Coordinateur et membre de l’équipe
Eventuellement tournant après quelques itérations
Gère et lève les obstacles
Product Owner
Propriétaire du backlog
Priorise les élements du backlog
A la connaissance métier (en tant qu’utilisateur)
Doit être disponible
Equipes
Auto responsable, auto organisée, porteuse de l’engagement/ product
owner
~5 à 9 personnes
Développeurs (au moins) dédié à un seul projet
S’appuie sur autres acteurs (équipe étendue) : admin, …

42. PRINCIPALES MÉTHODES AGILES
SCRUM : PRATIQUES DE COMMUNICATION
Travail en équipe intégrée (le plus possible) colocalisée
Réunion quotidienne (ex Scrum:
15 minutes, debout
Chacun dit
Ce qu’il a fait
Ce qu’il reste
Les obstacles
Equipe (+ product owner si dispo)
Management visuel :Tableaux, post it… présentant
au quotidien
avancement, équipe, risques, obstacles…
Estimation par planning poker

43. PRINCIPALES MÉTHODES AGILES
SCRUM : PRATIQUES DE COMMUNICATION
49

44. PRINCIPALES MÉTHODES AGILES
RAISONS D’ADOPTION ET RÉSULTATS

45. PRINCIPALES MÉTHODES AGILES
ADOPTION ET RÉPARTITION

46. ADOPTER UNE APPROCHE AGILE
HYBRIDE
Des approches hybrides traditionnelles/agiles sont aussi
possibles, en transition ou non
Ex : waterscrumfall ou vrum

47. EVOLUTIONS
DEVOPS
DEVOPS(2009) = intégrer DEVeloppement et OPerationS
Initié notamment par Netflix
Dépasser la séparation entre
équipes en charge du développement ayant pour objectif de produire le
plus au plus vite … parfois au détriment de la qualité
équipe en charge du déploiement/maintenance/ exploitation, responsable
de la stabilité … parfois au détriment de l’adaptabilité et de la réactivité
Adopte la philosophie et les principes de l’Agile
Déploiement régulier pour accroitre le feedback
Décaler « vers la gauche » les tests
Tester dans un environnement similaire à la production
Intégrer et tester en continu
Notion de continuous delivery

48. EVOLUTIONS
KANBAN
Méthode d’amélioration de processus appliquant les principes
du LEAN
Appliquée depuis 1950 (Toyota)
…et plus récemment déclinée au logiciel
Permet d’améliorer
l’agilité pour répondre à la demande
la prédictibilité du processus
Principes
Matérialisation par un tableau ou les colonnes
et
Vision globale sur toute la chaine pour optimiser globalement
plutôt que localement
Eviter les stocks
Minimiser le temps de traversée du système

49. EVOLUTIONS
KANBAN
Notion fondamentale : système tiré
Traditionnellement un analyste fournit les spécifications à
implémenter au développeur, qui les stocke le temps de les
réaliser  flux poussé
En flux tiré, le développeur demande les spécifications
quand il va manquer de travail, et l’analyste ne les réalise
qu’à la demande
60
Analyste Développeur
Produit toutes
Système poussé
Analyste Développeur
Système tiré
J’ai besoin
d’une
spécification

50. EVOLUTIONS
KANBAN
Autrement dit
On ne développe de fonctionnalités dont personne n’a besoin
On n’écrit pas plus de spécification que l’on ne peut en coder
On n’écrit pas plus de code que l’on ne peut en tester
On ne teste pas plus de code que l’on peut en déployer
On ne déploie pas plus que l’on peut utiliser
Souvent utilisé conjointement au Scrum auquel il ajoute
des pratiques
Définir un nombre limite d’éléments dans chaque colonne
Définition des règles d’entrée/sortie dans chaque du tableau
Suppression des stories trop anciennes du backlog
…
Mais va beaucoup plus loin, notamment en permettant
différentes durée de cycles

51. CONCLUSIONS
Les méthodes Agiles renverse la logique des méthodes
en faisant du périmètre la variable
d’ajustement
Elle s’appuie sur
un développement itératif et incrémental
une implication importante du client/utilisateur
de (petites) équipes communiquant le plus possible
des tests et des démonstrations ou livraisons à chaque
itération pour avoir le maximum de retour