1

LES MÉTHODES AGILES

 Retour sur les méthodes de conception
2

 Rien
 Cascade

 Modèle en V

 Itératif (RUP)

 Agile
 Rien “code and fix”
3

 Bénéfices :
 Marche si vous travaillez seul
 Pas de surcoûts dus à la gestion de projet

 Inconvénients :
 Rapidement compliqué
 Pas de visibilité

 ...
 Cascade
4

Analyse des
besoins

Spécifications Utilisateurs
Conception
Architecturale

Conception
Retour détaillée

Codage

Intégration

Test
Installation
 Cascade
5

 Bénéfices :
 tâches établies au début du projet
 segmentation claire des responsabilités
 passation de tâches aisées

 Inconvénients :
 planification trop rigide alors que les tâches sont changeantes
 la responsabilité du succès du projet n’est pas partagée
 si une tâche n’est pas bien effectuée tout l’édifice est ébranlé
 trop de choses sont faites qui ne sont pas directement liées au
produit logiciel à construire
 Modèle en V
6

Analyse
Recette
des besoins

Tests
Spécifications de validation

Conception Tests
Architecturale d’intégration

Conception Tests
détaillée Unitaires

Codage
 Modèle en V
7

 Bénéfices :
 tâches clairement établies au début du projet
 responsabilisation via des retours en cas d’erreur

 Inconvénients :
 les tâches sont changeantes
 la responsabilité du succès du projet n’est pas partagée
 Méthodes agiles
8

 Trouver un compromis :
 le minimum de méthode permettant de
mener à bien les projets en restant agile
 capacité de réponse rapide et souple au
changement
 orientation vers le code plutôt que la
documentation
 Agile
9
 Historique
10

 Années 90
 réaction contre les grosses méthodes
 prise en compte de facteurs liés au développement logiciel
 Fin années 90: développement de méthodes
 d’abord des pratiques liées à des consultants, puis des livres
 XP, Scrum, FDD, Crystal…
 2001
 les principaux méthodologues s’accordent sur le « Agile
manifesto»
 Depuis
 projets Agile mixent des éléments des principales méthodes
 Principes des méthodes Agile
11

 Les principes communs

 Le Manifeste

 Agile et modélisation
 Principes communs aux méthodes agiles
12

 Méthodes adaptatives (vs. prédictives)

 itérations courtes
 lien fort avec le client
 fixer les délais et les coûts, mais pas la portée

 Insistance sur les hommes

 les programmeurs sont des spécialistes, et pas des unités
interchangeables
 attention à la communication humaine
 équipes auto-organisées

 Processus auto-adaptatif
 révision du processus à chaque itération
 Méthodes
13

 Simplicité
 Légèreté
 Orientées participants plutôt que plan
 Nombreuses :
 eXtreme Programming
 SCRUM
 ...

 Pas de définition unique mais un manifeste

 Le manifeste Agile
14

 Février 2001, rencontre et accord sur un manifeste

 Mise en place de la « Agile alliance »
 Objectif : promouvoir les principes et méthodes Agile
 http://www.agilealliance.com/

 Les signataires privilégient

 les individus et les interactions davantage que les processus et
les outils
 les logiciels fonctionnels davantage que l’exhaustivité et la
documentation
 la collaboration avec le client davantage que la négociation de
contrat
 la réponse au changement davantage que l’application d’un plan

 12 principes
 Manifeste Agile : principes
15

1) Prioriser la satisfaction du client

2) Accepter les changements
3) Livrer en permanence des versions opérationnelles de
l’application
4) Assurer le plus souvent possible une coopération entre
l’équipe du projet et les gens du métier
5) Construire les projets autour de personnes motivées
6) Favoriser le dialogue direct
 Manifeste Agile : principes
16

1) Mesurer l’avancement du projet en fonction de

l’opérationnalité du produit
2) Adopter un rythme constant et soutenable par tous les
intervenants du projet
3) Contrôler continuellement l’excellence de la conception
et la bonne qualité technique
4) Privilégier la simplicité en évitant le travail inutile
5) Auto-organiser et responsabiliser les équipes
6) Améliorer régulièrement l’efficacité de l’équipe en
ajustant son comportement
 Processus agile et modélisation
17

 Utilisation d’UML
 La modélisation vise avant tout à comprendre et à
communiquer
 Modéliser pour les parties inhabituelles, difficiles ou
délicates de la conception.
 Rester à un niveau de modélisation minimalement
suffisant
 Modélisation en groupe

 Outils simples et adaptés aux groupes

Les développeurs créent les modèles de conception

qu’ils développeront
 Cycle de développement SCRUM
18
 Rôles et responsabilités
19

 Le Product Owner (PO)

 Définit les exigences,
 Les priorise

 Scrum Master : garant de l'application du processus,

Scrum en l'occurrence.
 Equipe de développement
 Activités de développement
20

 Cycle Scrum
 Spécification fonctionnelle
 Architecture

 Codage (et test unitaire)

 Test (test d’intégration).
 le backlog du produit
21

 Vision :
 Le but ou l’objectif principal
 Les besoins des utilisateurs et des parties prenantes
 Une présentation de la solution qui répond à ces
besoins
 Les contraintes importantes imposées au
développement.
 le backlog du produit
22

 Rôles :
 Qui fournira, supprimera, utilisera les informations de
l’application?
 Qui utilisera le logiciel?
 Qui est intéressé par une fonction ou un service proposé?
 Qui assurera le support et la maintenance du système?
 Avec quels autres systèmes doit interagir le logiciel à développer
?
 le backlog du produit
23

 Les features :
Une feature est un service fourni par le système,
observable de l’extérieur qui répond à un besoin et
dont la description se situe à un niveau tel que toutes
les parties prenantes comprennent facilement ce dont il
s’agit.
 le backlog du produit
24

 Prioriser les stories :

 La méthode MoSCoW.
 M pour Must Have : DOIT être fait. L’exigence est essentielle. Si elle n’est pas
faîte le projet échoue. On peut dire également priorité haute.
 S pour Should Have : Il s’agit d’une exigence essentielle, qu’il faut faire dans
la mesure du possible (DEVRAIT). Mais si elle n’est pas faîte, on peut la
contourner et la livrer plus tard.
 C pour Could Have: Il s’agit d’une exigence souhaitable. Elle POURRAIT être
faîte dans la mesure où elle n’a pas d’impact sur les autres tâches
 W pour Won’t Have Il s’agit d’une exigence «Luxe». NE SERA PAS faîte cette
fois mais plus tard, mais intéressante et à garder pour la prochaine version
 le backlog du produit
25

 Prioriser les stories :

 La méthode priority Poker (pour les feature)
 Chaque participant reçoit un lot de neuf cartes numérotées de 1 à 9
 Chaque feature est étudié successivement.
 Le premier vote porte sur l’intérêt d’avoir le feature.
 Le deuxième vote, porte sur la pénalité de ne pas avoir le feature
dans le produit.
 On définit l’importance des deux votes.
 En faisant la somme des deux votes pondérés on obtient l’utilité de
l’élément. Les features les plus utiles sont les plus prioritaires.
 Exemple de backlog de produit
26
 Planning Poker
27
 Planning Poker : estimer l’effort
28

 Chaque participant reçoit un jeu de cartes.

 Sur chaque carte, il y a une valeur positive pour estimer la
story 1.
1) Le PO présente la story.
2) Les membre de l’équipe posent des questions pour clarifier
la story.
3) Tous les participants présentent en même temps la carte
choisie pour l’estimation
4) L’équipe discute des différences éventuelles entre les
estimations.
5) On recommence jusqu’à une convergence des estimations.
6) On passe à la prochaine story
 Exemple de backlog detaillé
29