01/11/2020

Caractéristiques des méthodologies agiles

Agilité : réponse rapide et flexible aux changements
Plusieurs méthodologies existent, mais ont des
Méthodologies Agiles caractéristiques communes:
 Itérations à durée fixe
 Développement évolutif
 Raffinement progressif des besoins et de la conception
 Planification adaptative
 Livraisons incrémentales

89 90

Le manifeste agile Le manifeste agile ( les valeurs)

 La notion de méthode agile est née à travers un
manifeste signé en 2001 par 17 personnalités du
développement logiciel
 Ce manifeste prône quatre valeurs fondamentales
1 « Personnes et interactions plutôt que
processus et outils » :
dans l’optique agile, l’équipe est bien plus importante
que les moyens matériels ou les procédures. Il est
préférable d’avoir une équipe soudée et qui
communique, composée de développeurs moyens,
plutôt qu’une équipe composée d’individualistes, même
brillants. La communication est une notion
fondamentale.

91 92

1
 01/11/2020

Le manifeste agile ( les valeurs) Le manifeste agile ( les valeurs)

2 « Logiciel fonctionnel plutôt que
documentation complète » :
il est vital que l’application fonctionne. Le reste, et
notamment la documentation technique, est
secondaire, même si une documentation précise est
utile comme moyen de communication. La
documentation représente une charge de travail
importante et peut être néfaste si elle n’est pas à jour.
Il est préférable de commenter abondamment le code
lui-même, et surtout de transférer les compétences au
sein de l’équipe (on en revient à l’importance de la
communication).
93
3 « Collaboration avec le client plutôt que
négociation de contrat » :
le client doit être impliqué dans le développement. On
ne peut se contenter de négocier un contrat au début
du projet, puis de négliger les demandes du client. Le
client doit collaborer avec l’équipe et fournir un
feedback continu sur l’adaptation du logiciel à ses
attentes.
94

Le manifeste agile ( les valeurs) Les principes agiles

4 «Réagir au changement plutôt que suivre un
plan»:
la planification initiale et la structure du logiciel doivent
être flexibles afin de permettre l’évolution de la
demande du client tout au long du projet. Les
premières releases du logiciel vont souvent provoquer
des demandes d’évolution.
 Notre plus grande 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 les changements pour donner un avantage
compétitif pour le client

95 96

2
 01/11/2020

Les principes agiles Les principes agiles

 Livrez fréquemment un logiciel opérationnel avec des
cycles de quelques semaines à quelques mois et une
préférence pour les plus court
 Les utilisateurs ou leurs représentants et les développeurs
doivent travailler ensemble quotidiennement tout au long
du projet
 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

97 98

Les principes agiles Les principes agiles

 Un logiciel opérationnel est la principale mesure  Une attention continue à l’excellence technique et à
d’avancement une bonne conception renforce l’Agilité

 Les processus Agiles encouragent un rythme de  La simplicité - c’est à dire l’art de minimiser la
développement soutenable. Ensemble les quantité de travail inutile - est essentielle
commanditaires, les développeurs et les utilisateurs
devraient être capables de maintenir indéfiniment un
rythme constant

99 100

3
 01/11/2020

Les principes agiles Priorités du mouvement agile

 Les meilleures architectures, spécifications et  Communication et rétroaction
conceptions émergent d’équipes auto-organisées Dans l’équipe et avec le client
 Individus et équipe
Le développement est une activité humaine
 À intervalles réguliers, l’équipe réfléchit aux moyens Des développeurs heureux sont plus productifs
de devenir plus efficace, puis règle et modifie son  Simplicité
comportement en conséquence Processus et outils
 Processus empirique
Modifié dynamiquement en se basant sur des mesures
 État d’esprit
Le développement agile est plus qu’un processus

101 102

Les méthodes agiles en pratique Méthodologies agiles

La recherche montre que les projets ayant le plus de succès
possèdent certaines caractéristiques favorisées par les  Extreme Programming (XP)
méthodes agiles :
 Scrum
 Cycle de vie itératif
 Intégration quotidienne  Crystal clear
 Beaucoup de rétroaction et de participation des  Test Driven Development
utilisateurs/clients
 Et bien d’autres.
 Courte durée / taille du projet
 Livraisons incrémentales

103 104

4
 01/11/2020

La programmation extrême
La programmation extrême (Extreme Programming,
XP) est une méthodologie agile très répandue
Extreme Programming
 Idée principale : pousser à l’extrême les bonnes
pratiques et valeurs de développement
 Par exemple: les tests sont utiles donc
 Les tests seront effectués chaque jour
 Les tests seront développés avant de coder
XP utilise un modèle de développement itératif avec
itérations très courtes (1-3 semaines)

105 106

Pratiques Client membre de l’équipe

 Le client est considéré comme un membre de
 Client membre de l’équipe l’équipe à part entière
 Jeu de la planification / histoires d’utilisateurs Le client est ultimement la personne qui devra
 Programmation en paires
utiliser le système
Un représentant du client devrait être disponible
 Développement piloté par les tests en tout temps pour répondre aux questions
 Réusinage fréquent  Rôles du client
 Propriété collective du code Écrire les histoires d’utilisateurs
 Intégration continue Écrire les tests d’acceptation
 Et quelques autres pratiques Choisir les histoires lors du jeu de la planification

107 108

5
 01/11/2020

Pratiques Histoires d’utilisateurs

 XP exprime les besoins sous forme d’histoires
 Client membre de l’équipe d’utilisateurs
 Jeu de la planification / histoires Les histoires ne contiennent que suffisamment
d’utilisateurs d’information pour pouvoir estimer l’effort requis
 Programmation en paires pour développer une fonctionnalité
 Développement piloté par les tests L’estimé est produit rapidement pour permettre à
 Réusinage fréquent l’équipe de prendre des décisions
 Propriété collective du code  Les histoires sont généralement inscrites sur des
 Intégration continue cartes qui peuvent être manipulées et placées sur un
 Et quelques autres pratiques mur ou un tableau

109 110

Exemple – Carte d’histoire utilisateur Exemple – Disposition des cartes

Enr egist r ement ! avec! comp r ession 8 ! hr s

P r ésent ement ,! les! op t ions! de! comp r essions

se! t r ouvent ! dans! une! boî t e! de! dialogue!
subséquent e! à! celle! de! la! sauvegar de.! Il! f aut ! les!
dép lacer ! ver s! le! dialogue! d'enr egist r ement ! lui-
même.

R+) (<1F&Ñ1*3&' 1<ÖJ&iOL3(1; 1&M(+>(7; ; /*>&OL=87/*15F&O; K(7<1&P] 7*>1j J&W55/2+*"{ 1281I &$##X:&

111 112

6
 01/11/2020

Jeu de la planification Jeu de la planification

Pour la livraison d’une version du logiciel
Pour une itération
 But : choisir les histoires à implémenter,
planifier et allouer les tâches à effectuer
 Le client choisit les cartes pour la prochaine
itération, les développeurs créent les tâches
 Une tâche qui est estimée à durée > 2 jours est
divisée à nouveau
 But : définir la portée de la prochaine version
opérationnelle
 Typiquement, le client écrit les histoires et les
développeurs en font l’estimation au cours d’un
atelier d’une demi-journée
 Les cartes peuvent être choisie en fonction d’une
date fixe, ou la date peut être déterminée en
fonction des cartes sélectionnées

113 114

Pratiques Programmation en paires

Tout le code est écrit par une paire de programmeurs
 Client membre de l’équipe travaillant ensemble sur une même machine
 Jeu de la planification / histoires d’utilisateurs  Un programmeur écrit le code et les tests pendant que
l’autre observe dans le but d’identifier les erreurs et les
 Programmation en paires améliorations potentielles
 Développement piloté par les tests  Les rôles sont inversés fréquemment
 Réusinage fréquent Les paires sont redistribuées fréquemment(ex. une fois
 Propriété collective du code par jour)
 Intégration continue  Cette pratique permet de distribuer les connaissances du
code rapidement à travers l’équipe
 Et quelques autres pratiques
 En pratique le code produit contient moins d’erreur sans
affecter la productivité de façon mesurable
115 116

7
 01/11/2020

Pratiques Développement piloté par les tests

Le code de production est écrit de façon à faire réussir
 Client membre de l’équipe des tests unitaires
Avant d’implémenter une fonctionnalité, un test est
 Jeu de la planification / histoires d’utilisateurs
ajouté.
 Programmation en paires Le code qui fait réussir le test est écrit
 Développement piloté par les tests Le code est développé en itérations successives d’écriture
 Réusinage fréquent de tests et de code
L’utilisation d’outils de test automatisés est essentielle à la
 Propriété collective du code
réussite de cette approche
 Intégration continue Résultat
 Et quelques autres pratiques Un jeu de test unitaires très complet est développé pour le
système entier
Très peu de code inutile est développé
117 118

Pratiques Réusinage fréquent

But : améliorer le code sans changer sa fonctionnalité
 Client membre de l’équipe Idéalement effectué à l’aide d’outils automatisés
 Jeu de la planification / histoires d’utilisateurs Les tests existants permettent de vérifier que le
 Programmation en paires
comportement observable demeure inchangé
Exemple de réusinage : restructurer la hiérarchie des
 Développement piloté par les tests
classes, éliminer la duplication
 Réusinage fréquent Motivation : la conception est plus efficace lorsque
 Propriété collective du code effectuée près de son utilisation
 Intégration continue Résultat : le système demeure plus simple et plus
 Et quelques autres pratiques facile à développer pour une longue période

119 120

8
 01/11/2020

Pratiques Propriété collective du code

 Une paire de programmeur peut travailler sur n’importe
 Client membre de l’équipe quelle partie du code et l’améliorer
 Jeu de la planification / histoires d’utilisateurs Les développeurs ne sont pas responsables d’un ou de
 Programmation en paires plusieurs modules en particulier
Motivation : si une partie du code est défectueuse, elle
 Développement piloté par les tests
devrait être corrigée le plus tôt possible
 Réusinage fréquent
 Attention aux risques !
 Propriété collective du code
Cette pratique est à éviter si l’équipe n’a pas encore
 Intégration continue développé une responsabilité collective
 Et quelques autres pratiques Un membre de l’équipe ne doit pas modifier du code sans
se soucier de celui qui aura à le modifier et le maintenir

121 122

Pratiques Intégration continue

 Client membre de l’équipe
 Jeu de la planification / histoires d’utilisateurs
 Programmation en paires
 Développement piloté par les tests
 Réusinage fréquent
 Propriété collective du code
 Intégration continue
 Et quelques autres pratiques
 Diviser, régner et intégrer : tous les changements doivent être
testés et intégrés fréquemment
 Fréquemment = plusieurs fois par jour
 Peut nécessiter la résolution de conflits si plusieurs programmeurs
ont modifié le même code
 Deux stratégies
Intégration asynchrone : les tests sont exécutés après un
changement ou à intervalles réguliers , les programmeurs sont
avisés si leurs changements causent des régressions
Intégration synchrone : les programmeurs exécutent eux mêmes
les tests et attendent les résultats avant de passer à la prochaine
étape (permet de conserver le contexte, favoriser la
communication)

123 124

9

XP – Phases de développement
1. Exploration
 But : produire suffisamment de cartes d’histoires pour une
première version, déterminer si le projet est réalisable
 Activités : prototypes, programmation exploratoire (preuve de
technologie), écriture de cartes et estimation
2. Planification
 But : déterminer la date et les cartes de la première livraison
 Activités : jeu de planification (version), écriture de cartes et
estimation
3. Itérations et premières livraisons
 But : implémenter un système complet prêt à être livré
 Activités : programmation, tests, jeu de planification (itérations),
élaboration des tâches et estimation
125 126
XP - Valeurs
 Communication
 Des problèmes de communication sont à la base de la majorité des
difficultés de projet
 XP fait la promotion de la communication :
 Entre programmeurs : programmation en paire, réunion
quotidienne, jeu de la planification
 Avec le client : tests d’acceptation, jeu de la planification
 Simplicité
 Faire la chose la plus simple qui puisse fonctionner
 S’applique aux besoins, à la conception, etc.
127 128
01/11/2020
XP – Phases de développement
4 Mise en production
 But : déploiement
 Activités : documentation, formation, commercialisation, etc.
5 Maintenance
 But : corrections, améliorations, nouvelles versions
 Activités : répétition des phases précédentes
XP - Valeurs
 Rétroaction
 Court terme : développement piloté par les tests unitaires,
intégration continue, cartes d’histoires
 Long terme : tests d’acceptation, itérations courtes (permettant au
client de clarifier les besoins)
 Courage
 Le courage de développer rapidement et d’effectuer des
changements rapides découle des autres valeurs et pratiques de la
programmation extrême et des outils modernes
 Par exemple, effectuer des changements architecturaux sans un
ensemble de tests et outils automatisés est difficile et risqué
10
 01/11/2020

Introduction
Scrum est une méthodologie agile axée sur la gestion de
projet
Scrum  Complémetaire à d’autres pratiques agiles
 L’origine du nom est un terme du Rugby : mêlée
 Analogie : les membres de l’équipe doivent atteindre l’objectif en
équipe, comme les joueurs qui se passent le ballon

129 130

Présentation de Scrum Présentation de Scrum

24
heures
Définition des fonctionnalités. PREPARATION Réunion de Réunion
Ajout de fonctionnalités en cours du projet. planification quotidienne
o Analyse de rentabilité
Mise à
et de financement. Processus
jour du
du Sprint
Incrément RELEASE
Iterative o Accord contractuel. Backlog du de produit Version finalisée
produit 2–4
oConstituer l’équipe.
semaines
Client Rétrospective
Backlog Backlog du Sprint Revue du Team
du produit du Sprint Sprint Product
Members
Scrum Owner

LES LES LES

Réalisation d’un ensemble de ARTEFAC User TIMEBOXES RÔLES
fonctionnalités par itération d’une Méthode agile de gestion de TS Stories
durée (de 2 à 4 semaines) : Sprint. projets utilisée pour organiser Burndown
les équipes et améliorer la chart
131 productivité . 132 Story
Point

11
 01/11/2020

Cycle de développement
Caractéristiques
Dévelo
pper
 Processus itératif
PREPARATION
Adapter
SPRIN
TS
Packager  Itérations plus longues que d’autres méthodologies (30 jours)
FINALISATION
 Equipe auto-gérée
Revoir

 Pas de processus rigide

 Le développement est adapté empiriquement
PHASE DU PHASE
DU JEU
PHASE DU
POST-JEU
 Réunion debout quotidienne
PRE-JEU
Déroulement des
 Packaging global de
 Démonstrations du système après chaque itération
 Définition du Backlog, Sprints.
la version.
de l'équipe. Développement
 Jeux de tests.
 Planification impliquant le client après chaque
Identification des facteurs (analyse, conception,
de risques. codage), ainsi que la
Documentation & itération
Choix des outils & manuels utilisateur.
révision et
infrastructure. l’adaptation.
133  Architecture générale. 134

Phases Phases
1. Planification
3. Développement
 Établir la vision du projet, les attentes et assurer le
 Implémentation d’un système par une série d’itérations de 30
financement jours (sprints)
 Activités : définition du carnet de produit, estimés,  Activités : planification de sprint, définition du carnet de
conception exploratoire, prototypes sprint, mêlée quotidienne, revue de sprint
2. Mise en scène 4. Livraison d’une version du système
 Identification de plus de besoins, priorisation (release)
suffisante pour une première itération  Déploiement
 Activités : planification, conception exploratoire,  Activités : formation, documentation, commercialisation, etc.
prototypes
135 136

12
 01/11/2020

Rôles Rôles
« Scrum Master » Équipe
 Élimine les obstacles  Scrum recommande que les équipes soient limitées à 7-10 personnes
 Prend les décision lorsque nécessaire  Les grands projets contiennent plusieurs équipes
 Agit comme pare-feu (firewall) pour s’assurer que Propriétaire du produit (Product Owner)
l’équipe n’est pas interrompue par des requêtes venant  Un représentant du client
de l’extérieur  Assigne les priorités dans le carnet du produit
 Renforce la vision du projet  Choisit les besoins à inclure dans une itération

 Un Scrum Master inefficace doit être remplacé « stakeholders »

 Personnes qui ne participent pas directement au projet mais dont les
intérêts doivent être pris en compte
 Ex : utilisateurs, clients, gestionnaires, etc.

137 138

Carnets (Backlogs) Scrum

Carnet de produit
 Appartient au propriétaire du produit Tableau de tâches
Graphique
 Contient les besoins de haut niveau, leur priorité, leur valeur À faire En cours Terminées
d’avancement
Mêlée
d’affaire et un estimé de l’effort requis quotidienne
 Durant la planification, toutes les parties prenantes Carnet de
Revue
(stakeholders) peuvent ajouter des fonctionnalités, des cas produit
et
d’utilisation, des améliorations et des défauts au carnet de Planif. rétro.
produit de Carnet Sprint de
sprint de sprint sprint
Carnet de sprint
 Appartient à l’équipe Logiciel
fonctionnel
 Contient des tâches et un estimé de l’effort requis / restant

139 140 Propriétaire de Scrum Membre de

produit Master l’équipe

13
 01/11/2020

Sprints Mêlée quotidienne (scrum)

Deux réunions sont tenues avant le début d’une itération
(sprint)
 1ère réunion : les intervenants priorisent le carnet de
produit, habituellement en fonction de la valeur d’affaires
et des risques
 2ème réunion : le propriétaire du produit et l’équipe
déterminent comment atteindre les objectifs demandés, et
produisent le carnet de sprint
 Le carnet de sprint est mis à jour à mesure que l’itération
progresse
Tenue à chaque jour, à la même heure et au même endroit
 Doit débuter à l’heure, il est fréquent d’imposer des amendes aux
retardataires qui sont ensuite utilisées par exemple pour financer la
pause café!
Doit répondre à 5 questions :
 Qu’avez-vous fait depuis le scrum précédant?
 Qu’allez-vous faire d’ici le scrum suivant?
 Qu’est ce qui entrave l’atteinte des buts de l’itération en cours?
 Y a t’il des tâches à ajouter au backlog?
 Avez-vous appris ou décidé quelque chose de nouveau qui serait utile
aux autres membres de l’équipe?

141 142

Mêlée quotidienne (scrum)

 Idéalement tenue debout en cercle pour encourager la
brièveté Unified Process (UP)
 Doit se tenir près d’un tableau où les tâches sont
inscrites
 Dure en moyenne 15-20 minutes pour une équipe de
7-10 personnes
 Les membres qui sont absents doivent participer à
distance

143 144

14

Unified Process (UP)
 "Le Processus Unifié (UP) est un processus de
développement logiciel" itératif et incrémental, centré
sur l’architecture, conduit par les cas d’utilisation et
piloté par les risques :
 Itératif et incrémental : le projet est découpé en
itérations de courte durée (environ 1 mois) qui
permettent de mieux suivre l’avancement global. A
la fin de chaque itération, une partie exécutable du
système final est produite, de façon incrémentale.
145
Unified Process (UP)
 Conduit par les cas d’utilisation : le projet est mené en
tenant compte des besoins et des exigences des utilisateurs.
Les cas d’utilisation du futur système sont identifiés, décrits
avec précision et priorisés.
147
01/11/2020
Unified Process (UP)
 Centré sur l’architecture : tout système complexe
doit être décomposé en parties modulaires afin de
garantir une maintenance et une évolution facilitées.
Cette architecture (fonctionnelle, logique, matérielle,
etc.) doit être modélisée en UML et pas seulement
documentée en texte.
 Piloté par les risques : les risques majeurs du projet
doivent être identifiés au plus tôt mais surtout levés le
plus rapidement possible. Les mesures à prendre dans ce
cadre déterminent l’ordre des itérations.
146
Phases
La gestion d’un tel processus est organisée en 4 phases
 La phase d’initialisation conduit à définir la " vision " du
projet, sa portée, sa faisabilité, son " business case ", afin de
pouvoir décider au mieux de sa poursuite ou de son arrêt.
 La phase d’élaboration poursuit trois objectifs principaux en
parallèle :
 Identifier et décrire la majeure partie des besoins utilisateurs,
 Construire (et pas seulement décrire dans un document !)
l’architecture de base du système,
 Lever les risques majeurs du projet.
148
15
 01/11/2020

Phases
 La phase de construction consiste surtout à concevoir
et implémenter l’ensemble des éléments opérationnels
(autres que ceux de l’architecture de base). C’est la phase
la plus consommatrice en ressources et en effort.
 Enfin, la phase de transition permet de faire passer
l’application des développeurs aux utilisateurs finaux. Les
mots-clés sont : conversion des données, formation
utilisateurs, déploiement, béta-tests.
Phases
 Chaque phase est elle-même décomposée séquentiellement
en itérations limitées (2 à 4 semaines). Le résultat de
chacune d’elles est un système testé, intégré et exécutable.
 L’approche itérative est fondée sur la croissance et
l'affinement successifs d’un système par le biais d’itérations
multiples. Le système croît avec le temps de façon
incrémentale, itération par itération, et c’est pourquoi cette
méthode porte également le nom de développement itératif
et incrémental.
=> le principe le plus important du Processus Unifié.

149 150

Phases Phases
Les activités de développement sont définies par cinq  Contrairement au processus en cascade (souvent appelé cycle en
disciplines fondamentales : V), le PU ne considère pas que les disciplines sont purement
 la capture des exigences, séquentielles.
 l’analyse et la conception,  En fait, une itération comporte une certaine quantité de travail
 l’implémentation, dans la plupart des disciplines. Mais la répartition de l’effort
relatif entre celles-ci change avec le temps.
 le test et
 PU doit donc être compris comme une trame commune des
 le déploiement.
meilleures pratiques de développement, et non comme l’ultime
tentative d’élaborer un processus universel."

151 152

16
 01/11/2020

Phases Méthodologies dérivées

 Catalysis : méthode de modélisation de l'architecture basée sur
UML, orientée composants www.catalysis.org
 Extreme System Analysis : méthodologie qui se place entre le
dépouillement d'un petit Extreme Programming et la rigidité d'un
gros RUP
 RUP = Rational Unified Process. Le RUP, processus de
développement "clé en main", proposé par Rational Software, est
lui aussi modélisé (documenté) avec UML. Il offre un cadre
méthodologique générique qui repose sur UML et la suite d'outils
Rational.

153 154

Méthodologies dérivées
 EUP = Enterprise Unified Process, extension du RUP : ajoute deux
phases : Production et Retirement.
 2TUP = 2 Tracks Unified Process. Plus récemment, VALtech propose
le 2TUP, un processus unifié (c’est-à-dire construit sur UML, itératif,
centré sur l’architecture et conduit par les cas d’utilisation), qui
apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d’informations des entreprises.

155

17