Post on 23-Jan-2018
Méthodes Agiles
SCRUM et eXtrem Programming (XP)
Youness BOUKOUCHI Enseignant-chercheur y.boukouchi@gmail.com
Ver
sio
n 1
.1 (
20
17
)
Introduction
Méthodologie agile
eXtreme Programming
SCRUM
Outils de l’agilité 2
Introduction aux méthodes agile
3
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
Str
até
giq
ue
Ta
cti
qu
e
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
Intro
du
ction
à l’agilité
4
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
Str
até
giq
ue
Ta
cti
qu
e
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
Intro
du
ction
à l’agilité Cycle de vie traditionnel
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
Str
até
giq
ue
Ta
cti
qu
e
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
Intro
du
ction
à l’agilité Cycle de vie traditionnel
6
Une réalité constatée…
Budget Dépassé
Planning non-respecté
Qualité insuffisante
Non conforme au Business
Intro
du
ction
à l’agilité
7
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
Str
até
giq
ue
Tacti
qu
e
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é
Intro
du
ction
à l’agilité
8
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 In
trod
uctio
n à l’agilité
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
Str
até
giq
ue
Tacti
qu
e
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
Expression des besoins
Conception
Développement
Tests, recette & debugage
Expression des besoins
Conception
Développement
Tests, recette & debugage
i1
i2
i3
in
Les solutions Agiles Les solutions classiques
Les équipes agiles font un peu de tout, tout le temps
Intro
du
ction
à l’agilité
Méthodologie agile
12
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éth
od
olo
gie Agile
13
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éth
od
olo
gie Agile
14
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éth
od
olo
gie Agile
Manifeste pour le développement Agile
15
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
étho
do
logie A
gile
16
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
étho
do
logie A
gile
17
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éth
od
olo
gie Agile
18
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éth
od
olo
gie Agile
19
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éth
od
olo
gie Agile
20
Agile regroupe plusieurs méthodologies : – Extreme Programming (XP)
– DSDM
– Crystal
– Scrum
– FDD
– …
les méthodes Agile M
étho
do
logie A
gile
21
Méthode eXtreme Programming
22
Méth
od
e eXtrem
e P
rogram
min
g • 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
Éléments fondamentaux d’XP
5 valeurs Communication
Simplicité
Feedback
Courage
Respect
Méth
od
e eXtrem
e Pro
gramm
ing
24
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éth
od
e eXtrem
e Pro
gramm
ing
25
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éth
od
e eXtrem
e Pro
gramm
ing
26
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éth
od
e eXtrem
e Pro
gramm
ing
27
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éth
od
e eXtrem
e Pro
gramm
ing
28
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éth
od
e eXtrem
e Pro
gramm
ing
29
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éth
od
e eXtrem
e Pro
gramm
ing
30
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éth
od
e eXtrem
e Pro
gramm
ing
31
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éth
od
e eXtrem
e Pro
gramm
ing
32
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éth
od
e eXtrem
e Pro
gramm
ing
33
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éth
od
e eXtrem
e Pro
gramm
ing
34
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éth
od
e eXtrem
e Pro
gramm
ing
35
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éth
od
e eXtrem
e Pro
gramm
ing
36
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éth
od
e eXtrem
e Pro
gramm
ing
37
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éth
od
e eXtrem
e Pro
gramm
ing
38
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éth
od
e eXtrem
e P
rogram
min
g
39
Méthode SCRUM
40
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éth
od
e SCR
UM
41
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éth
od
e SCR
UM
Méth
od
e SCR
UM
Les rôles
43
Le processus Scrum
1. Backlog produit (ou catalogue des besoins)
Besoins priorisés par le product owner
Besoins évalués par l’équipe
Méth
od
e SCR
UM
De 2 à 4 semaines
44
Le processus Scrum
2. Backlog de sprint
Extrait du backlog produit
Besoins éclatés en tâches
Méth
od
e SCR
UM
De 2 à 4 semaines
45
Le processus Scrum
3. Sprint
Développement des fonctionnalités du backlog de sprint
Aucune modification du backlog de sprint possible
Méth
od
e SCR
UM
De 2 à 4 semaines
46
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éth
od
e SCR
UM
De 2 à 4 semaines
47
Le processus Scrum
5. Incrément logiciel : livré au Product owner à la fin du
sprint.
Méth
od
e SCR
UM
De 2 à 4 semaines
48
Outils de l’agilité
49
Outils de l’agilité
• Le tableau des tâches (Le Sprint Board)
Ou
tils de l’agilité
50
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é O
utils d
e l’agilité
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é O
utils d
e l’agilité
Gestion d’une liste de tâche: AgileFant, IceScrum, etc.
Outils de l’agilité O
utils d
e l’agilité
53
Conclusions
54
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é…
Co
nclu
sion
s
Co
nclu
sion
s
56
Merci de votre attention
57