Méthodes Agiles

les fondamentaux
Méthode Agiles
 Agilité du SI

L’agilité du SI désigne la capacité de ce dernier à pouvoir s’adapter rapidement

aux changements (stratégiques, métiers, organisationnels…).
Elle se traduit par une approche de constitution du SI par assemblage de
composants modulaires faiblement couplés.

Cela évite ainsi les grands ensembles applicatifs couvrant des périmètres trop
larges et sources de rigidité. Cela permet également un meilleur alignement
fonctionnel /applicatif .

Ainsi une évolution fonctionnelle ne nécessite de modifier qu’un nombre restreint

de composants applicatifs.
 Cycle en V et ses limites

Démarche prédictive Cycle Séquentiel

 Activité de planification à l’échelle
du projet
 Activité d’estimation de l’ensemble
du projet
 Le projet est enfermé dans le
contrat rigide
 Traitement discontinu de chaque
fonctionnalité
 Coté client : effet tunnel
 Gestion des changements couteuse
 Production de valeur déportée à la fin
du projet
 Nécessité de documenter de façon
détaillée tous les éléments du projet
 Activité de formalisation et
d’exploitation des informations
 Eviter l’effet tunnel

Définition de l’effet tunnel :

«Lors du développement d'un logiciel, les futurs utilisateurs disent ce qu'ils
veulent, puis voient six mois ou un an plus tard le logiciel terminé. Entre ces deux
étapes, ils n'ont rien vu, ils n'ont été informés de rien, et bien évidemment, le
résultat est souvent très loin de leurs désirs ou de leurs besoins.»

En interne
Valider que les développements sont bien terminés et intégrés
Mesurer la qualité lors des recettes internes
S’assurer de la compétence des ressources
Communiquer auprès de la direction de projet et du management
Donner une vision globale du projet à l’équipe
Auprès du client
Le rassurer sur le bon déroulement des développements
Lui présenter l’application et éviter tous risques majeurs de rejet
Lui donner une mesure précise de l’avancement en % et en nombre de
fonctionnalités
Avoir son retour sur la qualité perçue
Transparence totale !
 L’alternative

«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»

Plusieurs méthodes
... de très nombreuses techniques
L’alternative
 L’alternative

Pourquoi utiliser Agile plutôt qu'une autre démarche ?

L'investissement est incrémental =>le risque est minimisé.
Le client contrôle le planning => le contrat / les investissements peuvent
s'arrêter à la fin de chaque sprint.
Le périmètre du travail est très précis => on rentre dans le détail au début de
chaque itération.
Le client peut changer d'avis => tous les changements sont incorporés (à taille
constante).
Le produit est construit ensemble, et ajusté au plus près en fonction de
véritables retours terrains.
Les gaspillages sont minimisés.
Transparence de l’avancement
 Les valeurs agile

Les 4 valeurs au cœur des projets Agiles

Les individus et les interactions plutôt que les processus et les outils

Un produit qui fonctionne plutôt qu’une documentation exhaustive

La collaboration avec le client plutôt que la contractualisation des relations

L’acceptation du changement plutôt que la conformité aux plans

 Les 12 principes généraux
1.«Notre première priorité est de satisfaire le client en livrant tôt et régulièrement
des logiciels utiles».

2.«Le changement est bienvenu, même tardivement dans le développement. Les

processus agiles exploitent le changement comme avantage compétitif pour le
client».

3.«Livrer fréquemment une application fonctionnelle, toutes les deux semaines à

deux mois, avec une tendance pour la période la plus courte».

4.«Les gens de l'art et les développeurs doivent collaborer quotidiennement au

projet».

5.«Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement

et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail».

6.«La méthode la plus efficace pour transmettre l'information est une

conversation en face à face».

7.«Un logiciel fonctionnel est la meilleure unité de mesure de la progression du

projet».
 Les 12 principes généraux
8.«Les processus agiles promeuvent un rythme de développement soutenable.
Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme
indéfiniment».

9.«Une attention continue à l'excellence technique et à la qualité de la conception

améliore l'agilité».

10.«La simplicité -l'art de maximiser la quantité de travail à ne pas faire -est

essentielle».

11.«Les meilleures architectures, spécifications et conceptions sont issues

d'équipes qui s'auto-organisent».

12.«À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis
accorde et ajuste son comportement dans ce sens».
 Comparaison

Approche traditionnelle Approche Agile

Les processus sont définis : Processus Empiriques et boucle d’amélioration :

Sur la base de la chaine de production Réalisation d’un sous-ensemble du produit
Passage par toutes les étapes de la chaine Analyse du sous-ensemble réalisé
Ajustement

Les processus d’abord : Les hommes d’abord :

Une fois les processus définis, on cherche On monte une équipe pluridisciplinaire
les personnes pouvant les réaliser On partage la connaissance

Planning prédictif: Planning adaptatif:

Sur la base d’une liste d’exigences stable Mise à jour régulière du planning en fonction de
Succès mesuré sur la capacité à réaliser l’avancement des travaux
«comme prévu»

Communication à plusieurs niveaux : La communication est plus importante que la

L’avancement du projet est l’affaire des technologie:
chefs de projets Management visuel
Importance du feedback régulier
Méthodes Agiles
Vue d’ensemble
 LEAN

Le «Toyota Production System» remonte à la fin des années 1950. Quelques

principes de ce système sont:

Just-in-time : produire chaque élément à la bonne quantité et au bon moment

Zéro stock

Jidoka : non propagation d’un défaut dans la chaine de production

Kaizen : amélioration continue des processus

5S (ORDRE): la gestion de l’espace de travail

Kanban : l’utilisation de fiche cartonnée pour limiter la production et éviter ainsi la

production d’en-cours trop importants.

 LEAN en développement logiciel

Transposition des principes du lean thinking au monde du développement

logiciel
Eliminer les gâchis
fonctionnalités non nécessaires,
anomalies non détectées,
tests de non-régression manuels,
multiplication des intermédiaires et des échanges formels…
Réduire les attentes et les stocks
stocks d’exigences / spécifications en attente,
versions en attente de tests, recetteurs en attente de livraison…
Qualité intrinsèque
détection et élimination des défauts le plus tôt possible
Livrer rapidement
réduire ses délais de développement pour rapprocher le moment
d’une demande et le moment de sa livraison.
Respecter les personnes
identification des personnes qui apportent directement de la valeur
pour le client,
implication dans le processus d’amélioration
Eliminer les gâchis
 Les piliers du LEAN : Kaizen

Kainzen= amélioration continue

ShuHaRi= Le « Shu Ha Ri » est constitué de 3 étapes par lesquels

un novice doit passer pour acquérir une compétence ou maîtriser
une technique:
Shu : le disciple apprend les fondamentaux en suivant les règles
édictées par le maître
Ha : ayant maîtrisé les fondamentaux, le disciple applique les
règles en les questionnant, en comprenant leurs subtilités et en
cherchant les exceptions
Ri : le disciple ayant maîtrisé les règles, peut les transcender et les
adapter
 Principes du LEAN
Optimiser le système dans son ensemble=>Approche à long terme.
Travailler en mode flux
 Cycle court
 Livrer rapidement
 Visibilité régulière
Décider le plus tard possible: Reporter la décision "Last Responsible
Moment"
Maîtriser les standard
Management visuel simple
Technologie éprouvée
Responsabiliser l'équipe: Construire de la qualité intrinsèque
Résoudre les problèmes
Eliminer les gaspillages
 Notion de TIMEBOX

Allocation à la réalisation d'une activité donnée une durée fixe,

volontairement limitée de temps.

Un des principes de scrum est le fonctionnement en «time

boxing» ou «temps limité»
Pour tous les rituels du projet, une limite de temps est
suggérée:
La durée du sprint est fixe
Un sprint peut durer entre 2 et 4 semaines,
Une fois la durée du sprint choisie, l’équipe doit la respecter
sur tous les sprints
La réunion de planification dure une demi journée
La mêlée dure ¼ d’heure
La démo dure une demi journée
La rétrospective dure une demi journée
Notion de TIMEBOX
 Rôles & responsabilités

Un directeur de produit, (Product Owner)

A la responsabilité de la définition des exigences
est propriétaire du backlog de produit : contenu et priorités
Disponible durant le sprint, et en particulier

lors de la réunion de planification de sprint

lors de la revue de sprint (démo)
L’équipe (Team)
Elle porte les engagements
Elle est constituée des personnes nécessaires pour produire le livrable

concepteur Développeur, expert technique, testeur ..

support ponctuel : ergonome, architecte
Le maitre de la mêlée (ScrumMaster)
Veille à une bonne interaction entre l’équipe et le directeur de produit (pour
maximiser le ROI et atteindre leurs objectifs)
Facilite la réalisation du projet (résolution des problèmes, interface ..)

Support à l’équipe pour améliorer sa productivité (pratique d’ingénierie, outils..)

Facilite la montée en puissance de l’équipe : compétence et autonomie
Met à jour l’information d’avancement et la rend visible à tous
Informe le management de l’avancement du projet, alerte
 LES TIMEBOXES DANS SCRUM

Sprint ou itération
Habituellement entre 2 et 4 semaines.

Sprint Planning Meeting

Pour 2 à 3 semaines de sprint : généralement 1 journée,
dont la moitié pour définir le contenu du sprint,
et l'autre moitié pour définir comment les fonctionnalités
sélectionnées vont être développées.

Sprint review
Généralement 4h< (la moitié de la durée du Sprint Planning Meeting). Plutôt
1 à 2h.

Sprint retrospective
Généralement 4h< (la moitié de la durée du Sprint Planning Meeting). Plutôt
1 à 2h.

Daily Scrum
15Mn
Mise en œuvre
Mise en œuvre
Mise en œuvre
 Récapitulatif des étapes

Itération 0

Itération 1 –n
Planification de sprint
Déroulement du sprint
Réunion quotidienne
Mise en visibilité des infos projet
Courbe du reste à faire
Démo
Rétrospective

Tout au long des sprints

Courbe d’avancement

(Itération finale)
Equipe agile
 Constitution de l’équipe
Taille de l’équipe : 7 +/-2 membres

Sélection des membres de l’équipe

pas de profil type ni de critère d’aptitude
les antécédents individuels ne sont pas toujours représentatifs
Motivation
… un minimum de goût pour le travail d’équipe
… une complémentarité minimale : compétence technique et processus

Qui décide de la composition de l’équipe ?

Probablement pas le Scrummaster ou le Product owner
Le management
Les membres du projet
Option mixte

La stabilité de l’équipe est nécessaire:

à la synergie
à une efficacité plus importante de l’équipe.
 Constitution de l’équipe

Les étapes de développement d’une équipe :

Forming
Les membres de l’équipe souhaitent se faire accepter les uns des autres
Ils s’observent, font connaissance, évitent les conflits
Storming
Les caractères s’affirment et les individus confrontent leurs idées et leurs
perspectives sur les problèmes à résoudre
Norming
L’équipe avance dans le même sens.
Performing
Quelques équipes seulement parviennent à atteindre ce niveau de
performance élevée.
Ces équipes fonctionnent comme une unité et parviennent à réaliser les
travaux sans obstacles particuliers.
Adjourning and transforming
Lorsque le projet se termine, l’équipe peut être dissoute ou
Si le projet continue, l’équipe se transforme pour pouvoir atteindre de
nouveaux paliers d’amélioration
 Le product owner

Quel est son rôle ?

Le directeur de produit est le représentant des clients et utilisateurs.
Il prends les décisions importantes sur l’orientation du projet mais n’a pas de rôle hiérarchique sur l’équipe au sens
traditionnel.
Ses droits:
Il a un pouvoir de décision opérationnel sur le projet et le produit
Il décide de ce qui est fait ou non dans une release du produit.
Ses devoirs:
Etre au contact régulier des utilisateurs
Se synchroniser avec les utilisateurs en temps et en heure ,les "fédérer" autour d'une vision du produit
Etre leur représentant
Coordonner les recettes avec les utilisateurs métiers et produire les scénarios d'acceptation
Faciliter la conduite du changement

Participer aux rituels projets :

Préparation des itérations (contenu, scénarios de tests)
Lancement de l’itération (priorisation, valeur métier des exigences)
Bilan de l’itération
Faire partie de l’équipe

Rester proche physiquement de l'équipe

Etre réactif pour répondre aux questions de l'équipe et pour donner l’avis sur des aspects logiciel (écrans, ergonomie,
cinématique).
Assumer son rôle de décideur opérationnel

Prendre les décisions métier, mais pas les décisions techniques (équipe)
Fixer les priorités métier (Capacité et pouvoir de prioriser, de repousser, d'ajouter, ...)
Faire vivre le product backlog(liste des user stories)
Trancher sur les points de litige concernant le produit
Pouvoir changer d'avis d'un sprint à l'autre (en acceptant le surcoût)
Valider les éléments qui lui sont présentés.
 Le scrumMaster

Le ScrumMaster joue un rôle capital: protecteur et facilitateur, mais ce

n’est pas un chef de projet ni un intermédiaire avec le client.
Ses droits:
Parler à la hiérarchie des interférences empêchant l’équipe d’avancer
sereinement
Ses devoirs:
Protéger l’équipe des éléments perturbateurs (autres projets,
intervenants externes), aide l’équipe à résoudre les problèmes non
techniques.
Etre garant des valeurs et pratiques Scrum, se charge de faire
respecter les règles que l’équipe s’est fixée.
Veiller à la santé de l’équipe
S’assurer qu’une démarche d’amélioration continue est suivie

Aussi appelé le chien de berger (SheepDog)

 Le product Baklog

Product Backlog : Liste des fonctionnalités à réaliser

Expression globale des besoins => premier backlog produit
La vision du projet doit être partagée en début de projet
Recueil du besoin des utilisateurs
A chaque «item» du Backlog sont associés deux attributs :
Un ordre de réalisation (toujours unique, ce n’est pas une priorité)
Une estimation de durée en points
Pour préparer un projet Agile :
le backlog est constitué et priorisé
… donc les stories les plus importantes pour le Product Owner sont identifiées
les stories du backlog sont estimées

ainsi le Backlog de Produit permet d’extraire le Backlog de

Sprint
 Le product Baklog

Le directeur de produit fixe les fonctionnalités à développer, leur priorité

par rapport à leur importance métier
L’équipe estime de façon macro, la durée de chaque item (en points)
 Le product Baklog

Le Backlog de Produit est un document vivant

les stories planifiées pour les sprints suivants peuvent évoluer à la fin du sprint
de nouvelles stories peuvent émerger

les stories réalisées dans les sprints précédents restent visibles

Le directeur du produit:
Peut changer l’ordre des items
Peut modifier le contenu du Backlog de produit en cours de projet tant que ces
changements n’affectent pas les éléments du sprint en cours !

L’équipe :
Peut ajuster les durées en cours de projet selon l’expérience acquise

La somme des durées du backlog de produit donne le

«reste à faire» théorique du projet
 A éviter

 Ne pas avoir de backlog de produit

 Avoir plusieurs backlogs pour un seul produit (ou d'autres sources
parasites, comme un bugtracker)
 Ne pas partager le backlog avec toute l'équipe
 Ne pas actualiser le backlog pendant le projet
 Confondre avec le backlog de sprint en y mettant des tâches
 Ne pas prioriser les éléments ou donner des priorités égales
 Expression de besoin

Fonctionnel => User Story

Technique => Tech Story
architecture
exploitation
automatisation des test
…
Une User story est une exigence du système à développer,
formulée en une ou deux phrases dans le langage de l'utilisateur.
En tant que <type d’utilisateur>,
j’ai besoin de <fonctionnalité>
afin de <obtenir un résultat ayant une valeur business>
+ critère du test d’acceptation
Les User Stories émergent au cours d'ateliers de travail menés avec le
Métier, le Client ou les Utilisateurs
 User Stories

USER STORIES
Les histoires utilisateurs (user story) ne sont pas des cas
d'utilisations (use case)
« Une user story (histoire utilisateur) est une exigence logicielle
formulée en une ou
plusieurs phrases dans le langage de tous les jours ou celui lié
au métier de l’utilisateur.
Les user stories sont utilisées dans le développement logiciel dit
Agile comme
spécifications (en même temps que les tests d’acceptance). Le
formalisme est limité à un
carte de type postit.
»
Les User Story encouragent à ne pas entrer dans le détail tant
que cela n'est pas
nécessaire.
 Conseil pour formaliser le
besoin
Elles doivent répondre aux critères suivants (INVEST) :
I –Independent
Indépendante pour faciliter son traitement.
N –Negotiable
Elle est négociée, discutée dès les réunions d’estimation et de planification du
Sprint mais aussi tout au long de ce dernier.
V –Valuable
Elle est source de valeur pour le Client final ou l’utilisateur.
E –Estimable
Elle est estimée par les équipes de développement; une estimation relative c’est à
dire les unes par rapport aux autres, en story points.
S -SizedAppropriatelyou Small
Le plus souvent petite car susceptible d’être traitée (livrée et testée) par l’équipe sur
une seule itération de 2 à 3 semaines.
T –Testable
Une User Story “de qualité” est avant tout testable, déjà dans sa forme et surtout
dans le sens où les critères d’acceptation sont envisagés d’entrée.
Daily Scrum
Radiateur d’information
 Vélocité

La vélocité est une mesure typique des méthodes agiles

C’est le nombre de points traités en une itération. Elle traduit la
capacité de l’équipe :
En nombre de points par sprint
Permet de fixer un périmètre réaliste au sprint
Repère quantitatif
Comment on la calcule :
Moyenne des itérations
Si c’est un premier sprint …
40 % seront consommés pour rendre l’équipe opérationnelle
2 à 3 itérations permettent de dégager une tendance

Points de vigilance :
La vélocité n’est pas un outil de management pour optimiser la capacité de l’équipe
pression et rôle du Scrum Master
L’augmentation de la vélocité n’est pas toujours une bonne nouvelle…
C’est un outil de planification pour le reste du projet
 Vélocité

Calcul prévisionnel de la capacité par sprint

Exemple :
6 personnes (équipe de développement)
Itération de 2 semaines
Estimations :

Un point d’histoire = 1,5 jour/homme idéal

Facteur de disponibilité effective (Focus factor) = 75%
Calcul :

Nombre de jours calendaires : 10 jours

Nombre de jours-homme : 60 jours
Nombre de jours-homme effectifs : 60 jours x 75 % = 45 jours
Vélocité : 45 jours / 1,5 = 30 points par itérations
 Capitalisation

Objectif : Analyser le déroulement du sprint afin d’en tirer des

enseignements pour la suite du projet
Démarche d’amélioration continue au niveau de l’équipe

Déroulement :
1.Analyser le plan d’actions précédent
Demander à chaque personne de noter :
2.
1.Ce qui a bien fonctionné
2.Ce qui n’a pas bien fonctionné
3.Suggestions d’amélioration
Regrouper les informations en élimant les doublons et les afficher
3.
4.Prioriser ensemble chaque point
Déterminer ensemble un plan d’actions «réaliste» pour le prochain Sprint
5.

Plan d’action: pas plus de 3 actions à mener dans le prochain sprint

 Capitalisation

A noter:
Le directeur de produit n’est pas convié, seuls l’équipe et le
ScrumMaster participent à cette réunion qui appartient à l’équipe.
Seule l’équipe décide des aménagements à apporter par la suite, le
ScrumMaster veillera à ce que ces derniers soient respectés.
Avantages
Faire des bilans sans attendre la fin du projet
Evaluer la motivation de l’équipe et renforcer l’esprit d’équipe
Des discussions sur l’efficacité des tests, l’intervention des experts, la
vélocité peuvent s’avérer très constructif pour les itérations suivantes.
Temps alloué:
Environ 1h par nombre de semaines dans l’itération
1 à 2 h par personne par itération au minimum
 Facteurs de succès

Dynamique d’équipe
La force d’une équipe qui s'engage sur des objectifs …
Quelques pratiques favorisent cette dynamique ..
le partage actif et passif de l’information projet
la création d’un esprit d’équipe
l’implication des membres pour contribuer à la réussite du projet
la diffusion des savoirs et le développement des compétences
Le ScrumMaster veille à :
impulser un rythme
rappeler le cadre méthodologique
conserver des modes de communication simples
donner la visibilité sur l’avancement du sprint et de l’itération
gérer les difficultés identifiées

…. pour construire et entretenir l'esprit d'équipe

 Facteurs de succès
Faciliter l’agilité de l‘équipe
Proximité physique et instantanéité de la communication:
l'équipe projet partage un même espace de travail

si répartition sur différents bureaux, possibilité de se réunir facilement

ex : même bâtiment,
salles de réunion ou de travail facilement accessibles

Avantages :
Communication facilitée et plus efficace
Permet la communication passive
Renforce la cohésion

c’est une condition nécessaire à la mise en place d’autres pratiques …

 Facteurs de succès

WarRoom :
toutes les informations importantes sont visibles
forme visuelle et «simplifiante»
toutes les informations affichées sont utiles
pertinentes
à jour

unicité de lieu : l’espace de travail est l’espace de réunion

avantages :
Communication facilitée et plus efficace
Met en visibilité les éléments clés du projet
Entretient la transparence
Facilite l’intégration des nouveaux, la présentation du projet
 Architecture agile

Origine de l’architecture agile

Les meilleures décisions techniques sont prises par l’équipe, et non par un
panel d’architectes autonomes déconnectés des enjeux du projet
Un rôle spécifique
Un architecte agile travaille réellement au sein de l’équipe
Il est impliqué durant la totalité du projet
Il n’effectue pas seul les choix techniques et de conception: Ces décisions doivent être prises de
manière collégiale par l’équipe.
Il partage son expérience et donne les grandes directions sur les différents choix d’architecture
tout au long du projet.
Il utilise au mieux les capacités de l’équipe en la guidant sur les nouvelles technologies, les
frameworkstechniques, et si besoin comble le déficit technique de l’équipe pour lui permettre de
décider en connaissance de cause.
Un architecte agile écrit les tests systèmes qui permettent de tester les
performances de l’architecture
L’architecture n’est pas figée durant les premières itérations, et continue
d’évoluer lors de chaque itération=> contrairement aux architectes «
traditionnels », il ne quitte pas le projet après la phase de mise en place de
l’architecture.
d’après http://www.agilejournal.com/articles/articles/the-shiny-new-agile-architect.html
 Architecture agile

Un architecte agile cherche à faire du refactoring à grande échelle

Il démarre par la solution la plus simple possible et refactore ensuite en
permanence la solution afin de garder le niveau de qualité requis tout en
implémentant les nouvelles fonctionnalités.
Il rend le système modulaire avec au démarrage du projet le système le plus simple
possible.
Il implémente de façon modulaire les composants communs, masque derrière des
interfaces ceux qui sont susceptibles de changer le plus souvent afin de minimiser
les impacts lorsqu’ils évoluent.
Veille pour détecter des risques. Au fur et à mesure que le système s’étend, il
s’assure que l’architecture suit. Il évalue les impacts des changements et apporte
des optimisations système
Un architecte agile embrasse le changement
à la fois pour l’architecture et pour son propre rôle
la vraie architecture agile vise à supporter le changement rapidement et facilement
sans la dégrader, et avec le minimum d’impact sur les systèmes externes.
 Facteurs de succès

Facteurs humains
Compréhension de la démarche Agile
Motivation des équipes

Engagement managérial
Respect de la démarche agile
Eligibilité des projets
Objectifs clairs et négociés
Mise à disposition des ressources nécessaires
Organisation
Disponibilité des acteurs de l’Agilité : ScrumMaster mais surtout Product Owner
=>Accompagnement de la démarche

Investir sur les hommes : formation, participation, communication

Un vrai support projet opérationnel et méthodologique …
 Facteurs d’échec

Product Owner défaillant

Résistance au changement

Sous-évaluer les résistances au changement

Peur de la transparence

Culture peu favorable à l’apprentissage collectif

Etre pressé

Manquer de rigueur

Management trop directif