Méthodes Agiles

Jihen Malek
(jihenmalek.isamm@gmail.com)

1
 Apparition
Au milieu des années 90, un groupe d’expert en Cycles de
vie de logiciels voulaient proposer de nouveaux modèles
Les nouveaux modèles sont plus « légers » : moins de
documentation et moins de contrôle sur le procédé
Ces modèles s’adresse à des projets de petite ou moyenne
taille avec une équipe réduite
Ces modèles permettent de s’ajuster rapidement aux
changements des spécifications tout en garantissant des
livraisons fréquentes
Ces modèles sont qualifiés de « modèles agiles »

2
 Principes agiles

Personnes et Plutôt que Processus et outils

interactions

Documentation
Un produit opérationnel Plutôt que
exhaustive

Collaboration Plutôt que

Négociation d'un
avec le client contrat

Adaptation au
Plutôt que Suivi d'un plan
changement

3
 Principes agiles
INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET
OUTILS
Les collaborateurs sont la clé du succès
Les « seniors ǽ échoueront s’ils ne collaborent pas en tant
qu’équipe
Un bon collaborateur n’est pas un forcément un bon
programmeur. C’est quelqu’un qui travaille bien en équipe
Une surabondance d’outils est aussi mauvaise que le manque
d’outils
Démarrer petit et investir peu au démarrage
Construire l’équipe c’est plus important que construire
l’environnement

4
 Principes agiles
LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION
MASSIVE
Un code sans documentation est un désastre
Trop de documents est pire que pas de documents
Difficulté à produire et à synchroniser avec le code
Souvent les documents sont des « mensonges » formels
Le code ne ment jamais sur lui-même
Produire toujours des documents aussi courts que possible

5
 Principes agiles
COLLABORATION DU CLIENT AU LIEU DE LA
NÉGOCIATION DE CONTRATS

Très difficile de décrire la totalité du logiciel depuis le début

Les projets réussis impliquent les clients d’une manière

fréquente et régulière
Le client doit avoir un contact direct avec l’équipe de développement

6
 Principes agiles

RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN

Un logiciel ne peut pas être planifié très loin dans le futur
Tout change : technologie, environnement et surtout les
besoins
Les chefs de projets classiques fonctionnent sur la base de
GANTT, PERT et le système de tâches
Avec le temps, les diagrammes se dégradent car des tâches
s’ajoutent et d’autres deviennent non nécessaires
Une meilleure stratégie est de planifier très court (02
semaines à 01 mois)
Plannings détaillés pour la semaine à venir, rigoureux pour les
trois mois et très vagues au-delà

7
Méthodologie Scrum
 Méthodologie Scrum
Inspiré par une approche développée en 1986 par H. Takeuchii
et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked
Problems, Rightteous Solutions » par DeGrace et Stahl en 1991
Utilisé comme méthodologie dans le livre : « Agile Software
Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en 2001

9
Méthodologie Scrum- Principes

10
11
 Scrum : Les Acteurs

Scrum Master Equipe

Product Owner

Clients , parties
prenantes et
utilisateurs
 Scrum : Les Acteurs
• Product Owner
– Porteur de la vision globale du produit
– Gère le Backlog du Produit
– Défini des priorités
– Accepte ou Rejette les livrables

• Scrum Master
– Veille au bon fonctionnement de l’équipe
– Enlève les obstacles
– Gardien des pratiques de Scrum
– Serviteur de l’équipe - Facilitateur
– N’est pas un chef de projet !
13
 Scrum : Les Acteurs
• Scrum Master
– Veille au bon fonctionnement de l’équipe
• Enlève les obstacles
– Gardien des pratiques de Scrum
– Serviteur de l’équipe - Facilitateur
– N’est pas un chef de projet !

14
 Scrum : Les Acteurs
• L’équipe
– 5 à 9 personnes
– Autogérée ; les décisions sont prises collectivement
– Contient toutes les compétences nécessaires pour
terminer le sprint
– Ne change pas pendant un Sprint

15
 Les réunions Scrum
Scrum donne un cadre au déroulement d'une
itération (un sprint) avec les 4 réunions de base :
• La réunion de planification de sprint (Le but de
la réunion est de planifier le sprint qui commence, après
avoir fixé son périmètre).
• La mêlée quotidienne.
• La revue de sprint ( Le but de la revue est de
montrer ce qui a été réalisé pendant le sprint afin d'en
tirer les conséquences pour la suite du projet).
• et la rétrospective (Le but de la réunion est
d'améliorer le processus pour le prochain sprint).

16
 La mêlée quotidienne
L'objectif de la mêlée quotidienne ou Scrum quotidienne est
de :
• Evaluer l'avancement du travail
• Identifier les obstacles nuisant à la progression
• Garder l'équipe concentrée sur l'objectif du sprint
• Améliorer l'esprit d'équipe
• Permettre une communication objective sur l'avancement

D'un autre côté Scrum donne un cadre pour l'organisation de

ces réunions :
• durée limitée à 15 minutes
• tout le monde debout
• 3 questions posées à chaque membre de l'équipe :
• Qu’as-tu fait depuis la dernière fois?
• Que prévois-tu de faire jusqu'à la prochaine réunion ?
• Qu'est-ce qui pourrait empêcher d'y arriver ?
17
 Tableau des tâches- Scrum
Un tableau de tâches sert à montrer l'avancement
des travaux pendant le sprint, c'est une
représentation physique du backlog de sprint. Il est
élaboré lors de la réunion de planification du
sprint. Pour chaque story sélectionnée, l'équipe
identifie les tâches correspondantes. Sur le
tableau, les stories et les tâches sont placées avec
des notes collantes. L'état des tâches est reconnu
selon la place de la tâche dans des zones
représentant chaque état : à faire, en cours et
finie.

18
Tableau des tâches- Scrum

19
Tableau des tâches 2 niveaux

20
Les artefacts de la méthodologie SCRUM

• Plan des releases

• Backlog de Produit
• Backlog de Sprint
• Burndown Charts

21
 Backlog de Produit
• Le backlog du produit est la liste des fonctionnalités
attendues d’un produit. C'est en quelque sorte une
« liste priorisée de besoins et d’exigences, d'histoires
(user stories), ou autre ». Le backlog produit est
maintenu par le product owner.
• Chaque élément doit apporter de la valeur aux
utilisateurs ou clients du produit
• Les éléments du backlog sont appelées
de histoires (user stories). Une histoire doit avoir un but
métier, son ajout au backlog doit généralement justifier
une valeur ajoutée. On n'y met pas de tâches
techniques

22
 Backlog de Produit
Dans ce cadre, le Product Owner doit :
- être le représentant du client ou des utilisateurs.
- récolter les attentes, besoins, exigences du client
ou des utilisateurs et les priorités associées.
- formaliser le backlog de produit avec le niveau de
précision adapté à la priorité
- être en mesure de les expliquer au Scrum Master
et à l’équipe de développement ou d’inviter le
client et/ou un utilisateur pour le faire.
- définir le planning des releases dans lesquels les
Sprints s’inscriront
23
 Backlog de Produit
Qu’est ce qu’une User Story ?
• Une User Story est une exigence du système à développer,
formulée en une ou deux phrases dans le langage de l’utilisateur.
• Les User Stories émergent au cours d’ateliers de travail menés avec
le Métier, le Client ou les utilisateurs.
• Dans Scrum cela s’appelle un Item
• Modèle de structure d’une User Story
- En tant que <rôle, persona, user type>
- Je veux <fonctionnalité, tâche, action>
- Afin de <valeur ajoutée, résultat>
Exemples
– En tant qu’acheteur en ligne, je veux pouvoir ajouter des items à
mon panier afin d’enregistrer mes achats que je ne souhaite pas
acheter dans l’immédiat
– En tant que recruteur, je veux déposer des offres d’emplois afin
de … 24
 Une bonne User Story doit contenir…
• Des critères & des tests d’acceptance
• Pourquoi faire des tests d’acceptation ?
- Savoir quand s’arrêter de développer
- Outil de collaboration pour une compréhension globale et partagée
- Donnée réelle pour mesurer l’avancement du développement
Exemple
• En tant que client, je veux connaître la liste des factures par
date.
• Test d’acceptation : afficher la liste des factures
ordonnées par la date de facturation

25
 Backlog de Produit
Comment écrire une user story ?
• Au sein du backlog, chaque user story constitue un item, une ligne : le
backlog produit se présente comme un tableau ordonné par priorité. Pour
chaque histoire, on décrit généralement dans le backlog :
• Un identifiant unique, que l'on incrémente à chaque nouvelle histoire,
• Un nom de quelques mots décrivant l'histoire. Généralement, pour rendre
ce nom explicite, une bonne façon de procéder est d'utiliser le template
suivant : « En tant que X, je veux Y, afin de Z ». Exemple : « En tant que
responsable commercial, je veux mettre en place un outil d'upload massif
des prix, afin d'optimiser les temps de modification des prix dans mon
équipe ». « En tant que client, je peux connaître le montant total des
factures impayées ».
• Une description de la story.
• L'importance de la story. C'est un nombre qu'attribue le product owner à
l'histoire : plus l'importance est grande, plus l'histoire devra être traitée en
priorité.
• Estimation (temps de réalisation estimé)
• Critère(s) d’acceptation 26
• Demandeur du User story
Ex Backlog de Produit

27
 Backlog de Produit
Priorité MOSCOW (L'importance de la story)
• MoSoCoW est un outil de priorisation simple et efficace
• Must : identifie ce qui est indispensable pour que
l’application soit opérationnelle, indépendamment de tout
confort.
• Should : identifie ce qu’il faudrait vraiment avoir pour
que l’application soit utilisable dans de bonnes
conditions
• Could : Introduit un confort d’utilisation pour faciliter
l’expérience des utilisateurs finaux
• Won’t : identifie des options qui seraient sympathiques,
mais que, lucidement, on n’aura pas le temps/budget de
réaliser !
28
 Plan des releases
Product Backlog
3

Sprint 1 3

2
Release 1
3

Sprint 2 1

Sprint 3 2

3
Release 2
Sprint 4
5

Sprint 5 8

29
 Backlog de Sprint
• Il s’agit d’un sous-ensemble des User Stories du backlog
du produit sur lesquelles l’équipe de développement
s’est engagée pour le sprint courant. Ces User Stories
sont alors découpées en tâches réalisables sur un temps
raisonnable pour voir l’évolution du travail.
• Est un engagement. Chaque développeur s'engage sur
un temps de travail pour chaque tâche établie. Suite à
cela on évalue quotidiennement grâce aux SCRUM
quotidiennes les différences de prévision. Voici les
principales caractérisitques du Baclog de produit :
• L'estimation du reste à faire est ajustée tous les jours
• Le backlog est adaptable

30
Backlog de Sprint

31
 Le Brundown Chart
• Un burndown chart (graphique d'avancement)
est une représentation graphique de l'évolution
de quantité de travail restante par rapport au
temps sur une période de temps donnée. Le
travail restant se situe en général sur l'axe
vertical, alors que le temps est sur l'axe
horizontal. Une interprétation simple (régression
linéaire) permet d'avoir une prévision de l'état
d'avancement à la fin de la période d'activité.
• Le Brundown Chart est un indicateur temporel
de l'évolution des tâches en cours dans le
Sprint.
32
Le Brundown Chart

33
Le Brundown Chart

34
Le Brundown Chart d’un sprint

35
 Planning Poker
Présentation
• Le planning poker est une façon ludique de produire des
estimations sur la complexité des fonctionnalités
à développer. Cette pratique est surtout utilisée en
informatique, en Scrum et dans les méthodes agiles en
général pour évaluer les scénarios utilisateurs (user stories)
du backlog du produit.
• L'avantage principal du planning poker est de permettre à
tous de s'exprimer librement. L'estimation serait meilleure
parce que plusieurs personnes l'auront validée : des
participants avec des niveaux d'expérience et d'expertise
différents. De plus, cette technique favorise les échanges
entre le product owner et l'équipe de développement.
36
 Planning Poker ( déroulement)
• Les participants s'installent autour d'une table, placés de façon à ce que
tout le monde puisse se voir.
• Le product owner explique à l'équipe un scénario utilisateur (User story).
• Les participants posent des questions au product owner, discutent du
périmètre du scénario, évoquent les conditions de satisfaction qui
permettront de le considérer comme "terminé".
• Chacun des participants évalue la complexité de ce scénario, choisit la
carte qui correspond à son estimation et la dépose, face vers le bas, sur la
table devant lui.
• Au signal du facilitateur, les cartes sont retournées en même temps. S'il n'y
a pas unanimité, la discussion reprend.
• On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.

Une procédure optimisée consiste, après la première "donne", de demander

aux deux acteurs ayant produit les évaluations extrêmes d'expliquer leurs
points de vue respectifs. Ces explications achevées et comprises de tous,
une nouvelle estimation est produite et c'est alors la moyenne arithmétique de
ces estimations qui est prise en compte. 37
 Planning Poker
Story Points

1 2 3 5 8

13 20 40 100 ?

38
Planning Poker

39
Planning Poker

40
Planning Poker

3 5

? 13

41
Planning Poker

42
Planning Poker

3 5

5 5
5

43
 Timebox
Boite de temps (Timebox)
Période d’une durée fixe et ne pouvant être étendue, durant
laquelle se déroule un événement ou une réunion. Par exemple,
une réunion Daily Scrum est limitée à quinze minutes et se
termine à la fin des quinze minutes, quoiqu’il arrive. Certaines
réunions peuvent être plus courtes. Pour les Sprints, cela dure
exactement ce temps.
Durée de la réunion de planification de sprint: chaque partie
est limitée à une heure par semaine de Sprint.
Durée de la mêlée quotidienne: 15 minutes maximum
Durée de la revue de sprint: timebox d’une heure par semaine
de Sprint.
Durée de la rétrospective: timebox de 45 minutes par semaine
de Sprint.
44
Méthodologie XP
 Extreme programming (XP)
eXtreme Programming
Créée en 1995 Kent Beck and Ward Cunningham
XP est un moyen léger, efficace, à bas risques, flexible, scientifique et
amusant de développer des logiciels
Destinée à des équipes de moyenne taille avec des spécifications
incomplets et / ou vagues
Le codage est le noyau de XP

Implication Test unitaire

massive du client continu (TDD)

Itérations
Programmation courtes et
par paires livraisons
fréquentes 46
 Méthodologie
Cours 2 - Cycle de vie deXP - Les 12 pratiques
SECTION 4 -
logiciels MÉTHODES AGILES

1- LE JEU DE PLANNING :
Le client et les développeurs décident quoi mettre dans la prochaine livraison
en triant les spécifications par priorité
L’estimation est la responsabilité du développeur, pas du chef de projet ni du
client SECTION 4 -
logiciels
2 - DE PETITES ET FRÉQUENTES LIVRAISONS :
D’abord livrer un système minimaliste puis le faire évoluer à travers des
versions à des délais très courts
3- LES MÉTAPHORES
Exprimer de manière naturelle et très simples des fonctions du système
Le client et les développeurs doivent s’accorder sur les métaphores
4 - CONCEPTION SIMPLE
Le système doit être Méthodologie
conçu de la manière
XP - Lesla12
plus simple possible
pratiques
5 - TESTS
Les développeurs rédigent les tests unitaires d’une manière continue,
Le client rédige les tests d’acceptation des fonctionnalités 47
 Méthodologie XP - Les 12 pratiques
6 - REFACTORING
Les développeurs améliorent continuellement le code tout en
veillant à le garder fonctionnel
7 - PROGRAMMATION PAR PAIRES
La totalité du code est écrite par deux programmeurs sur une
seule machine. L’un est appelé conducteur (driver) et l’autre
navigateur. Les rôles s’inversent régulièrement.
8 - PROPRIÉTÉ COLLECTIVE
N’importe qui peut changer le code n’importe où dans le
système à n’importe quel moment
9 - 40 HEURES LA SEMAINE
Le travail ne doit pas dépasser 40 heures par semaine

48
Méthodologie XP - Les 12 pratiques

10 - intégration continue
Construire le système à chaque fois qu’une tâche est terminée.
11 - Le client est sur site
Le client est tout le temps présent avec l’équipe pour participer
et répondre aux questions
12 - Les standards de codage
À cause de la propriété collective, des standards (une charte decodage) doivent
être établis et adhérés par l’équipe de développement

49