Chapitre 3

Modèles de Cycle de vie

logiciel et méthodes de
développement

UP GL-BD
Objectifs du Chapitre 3
Partie 1
▪ Définir les étapes d’un cycle de vie logiciel.
▪ Expliquer différents modèles de cycles de vie
logiciel.
▪ Choisir le cycle de vie adapté pour un type de
projet donné.

GL & AGL 2
Partie 1 : Modèles de cycles de vie
I. Introduction
II. Définition du Cycle de vie logiciel
III. Modèles de cycle de vie logiciel :
✔Modèle de cycle de vie en cascade
✔Modèle de cycle de vie en V
✔Modèle de cycle de vie par prototypage
✔Modèle de cycle de vie incrémental
✔Modèle de cycle de vie en spirale

GL & AGL 3
 Introduction
Question : Que va-t-on faire pour construire un logiciel de qualité?
Réponse : Adopter des bonnes pratiques

Ateliers de
Processus de génie logiciel
développement

Cycle de vie
logiciel Méthodes de
Méthodologies de
développement
développement

Outils de
développement

GL & AGL 4
 Définition : Cycle de vie logiciel

Définition du cycle de vie

Ensemble d’étapes qui composent le processus de
développement et d’utilisation du logiciel

GL & AGL 5
 Modèle de Cycle de vie logiciel
Modèle de cycle de vie :
• Modélisation conventionnelle de la succession d’étapes
qui préside à la mise en œuvre d’un produit logiciel.
• Plusieurs modèles : en cascade, en V, en spirale, par
prototypage, incrémental, etc.

Les objectifs de ces modèles :

• Représenter le processus de développement de
manière graphique et physique.
• Donner une structure autour de laquelle les activités
d’assurance qualité peuvent être construites.
GL & AGL 6
 Définition d’un processus

❖ Un processus décrit 2 choses importantes:

▪ Les activités (étapes) (= quoi?)
▪ L’enchainement des activités (= quand?)

Qu’est-ce que le logiciel doit faire?

Comment s’assurer qu’il fait bien ce qu’il doit
faire? Le logiciel fait-il ce qu’il doit faire? r
s
Quoi? Comment s’assurer qu’on développe le bon
-
logiciel? A-t-on développé le bon logiciel?
Comment organiser et construire le logiciel pour qu’il fasse
ce qu’il doit faire? I
Comment s’assurer que le logiciel est organisé et construit
de manière à faire ce qu’il doit faire?
Le logiciel est-il organisé et construit de manière à faire ce
Comment? qu’il doit faire?
Comment traduit-on cette organisation en code
source? Le code source est-il bien écrit?

7
Modèles de cycles de vie

● Modèles classiques
▪ Modèles linéaires
▪ Modèle en cascade
▪ Modèle en V
▪ … etc
● Modèles itératifs et incrémentaux
▪ Modèle par prototypage
▪ Modèle de développement incrémental
▪ Modèle de développement en spirale
▪ … etc

8
 Modèle en cascade

❖ Présente le développement logiciel comme une suite de phases qui

s’enchaînent dans un déroulement linéaire.

Spécification
et analyse

V&V Conception
globale
V&V Conception
détaillée

V&V Codage

[Royce70] I Test
V&V

V&V Maintenance

GL & AGL 2017 - 2018 9

 Modèle en cascade

❖ Chaque étape doit être achevée avant que ne débute la

suivante.
❖ Chaque étape permet d’élaborer des produits
intermédiaires.
❖ Chaque fin d’étape est matérialisée par un événement, où s’exerce
une activité de contrôle (Vérification et Validation) afin d’éliminer
au plus tôt les anomalies des produits réalisés.
❖ Le passage à l’étape suivante est conditionné par le résultat de
contrôle (acceptation, rejet, ajournement)
❖ Les retours en arrière sur les étapes précédentes se limitent à un
retour sur l’étape immédiatement antérieure.
❖ Adapté aux projets dont les besoins sont clairs et stables dès le
début du projet.
 Modèle en cascade

• Avantages :
✔Simple à mettre en place.
✔Permet de garantir l'existence d'une documentation
bien structurée

• Inconvénients :
✔Détection tardive des erreurs => Augmentation du coût
de la correction, etc.
✔N’est pas efficace pour les projets qui exigent la prise en
considération de risques.

GL & AGL 2017 - 2018 11

 Modèle en V

❖ Processus linéaire dérivé du modèle en cascade

❖ Les premières étapes du cycle doivent préparer les

dernières étapes, essentiellement les activités de
vérification et de validation.

❖ Le développement du logiciel et le développement des

tests sont directement corrélés.

⮚ Cette approche permet de vérifier la conformité à ce qui

devrait être fait et non ce qui a été fait.
 Modèle en V

Spécificatio Préparation des scénarios de test Tests de

n validation

Exigences

Conception Préparation des scénarios de test

Tests
Globale d’intégration

Composants
Préparation des scénarios de test
Conception Tests
détaillée unitaires

Les fonctions

Codage Exécution des tests

Développement et préparation
des scénarios de test
 Modèle en V

● Deux sortes de dépendances entre étapes :

▪ Traits continus : correspondent à l’enchaînement du modèle en
cascade, les étapes se déroulent séquentiellement en suivant le V
de gauche à droite
▪ Traits non continus : Une partie des résultats de l’étape de
départ est utilisée directement par l’étape d’arrivée.
▪ Par exemple : à l’issue de la conception globale, le protocole
d’intégration et les jeux de tests d’intégration doivent être
complètement décrits.

Flux Flux
descendants ascendants
 Modèle en V

Avantages
✔ Une meilleure spécification
▪ évite d’énoncer une propriété qu’il est impossible de vérifier objectivement une
fois le logiciel réalisé.
✔ Prévenir les erreurs
▪ l’obligation de concevoir les jeux de tests et leurs résultats oblige à une
réflexion et à des retours sur la description en cours.
✔ Une meilleure planification du projet:
▪ Les étapes de la branche droite du V peuvent être mieux préparés et planifiés.

Inconvénients
✔ Le client ne reçoit pas de résultats concrets pendant le développement d’un
logiciel
✔ Les validations intermédiaires n’empêchent pas la transmission des
insuffisances des étapes précédentes.
✔ Adapté aux problèmes sans zones d’ombre
▪ Idéal quand les besoins sont bien connus et quand l’analyse et la conception
sont claires et stables.
Modèles linéaires
Modèle en cascade

Analyse
Concepti
on
Codage
Test

Modèle en V

Analyse Test
Concepti
Test
on
Codage Test

Problème de l’effet tunnel où l’on ne voit tourner quelque chose qu’à la

fin Détection d’erreurs tardive

GL & AGL 2017 - 2018 16

 Cycles de vie itératifs

❖ Évaluation d’éléments concrets au cours du développement :

❖ Élimination d’effet tunnel
▪ basée sur l’évolution de prototypes exécutables, mesurables,

▪ diminution de l’importance des documents de spécification détaillée,

▪ livraisons intermédiaires: résultats concrets réguliers de l’équipe de développement,

▪ meilleures anticipation et prise en compte des problèmes,

▪ meilleure gestion de la prise en compte de modifications de spécification qui peuvent être

intégrées dans une itération future

▪ intégration progressive de composants.

 Cycles de vie itératifs

❖ En général, dans les cycles de développement itératifs,

chaque itération reproduit le cycle en cascade à une plus petite échelle.

❖ Ces processus sont basés sur l’ évolution de prototypes exécutables :

▪ L’utilisateur est placé devant des situations d’utilisation concrètes. Il est partenaire du projet.

▪ L’intégration est progressive et permet d’éviter l’effet « big bang » (découverte de nombreux bogues à
corriger et déploiement retardé) à l’approche de la date de livraison.

▪ Les progrès se mesurent par des programmes démontrables et non par des documents ou
estimations.

❖ Le découpage par incréments permet de réduire la complexité du système en la ventilant

dans les incréments.
 Modèle par prototypage

❖ Prototype = une version de tout ou d’une partie d’un logiciel, facile à

mettre en œuvre et à modifier qui va permettre de vérifier rapidement
certaines fonctionnalités en sacrifiant la précision des autres. Il n’est pas
construit avec les mêmes contraintes de qualité que le logiciel final.
❖ Prototypage => étayé par la validation des besoins.
❖ Souvent utilisé pour la validation des spécifications MAIS
❖ Peut être aussi utilisé à différentes étapes du cycle de vie.
❖ Selon l’étape, les objectifs du prototype sont différents.
✔ Pour montrer la faisabilité
✔ Valider les interfaces utilisateurs
✔ etc.
 Modèle par prototypage

Analyse Analyse et sélection des État non

préliminaire nouvelles fonctions satisfaisant
des besoins
Construction
du prototype

Évaluation
expérimentation
État satisfaisant
Expression claire
des besoins réels

⮚ Initialement, les spécifications données par le client sont d’ordre général ;

⮚ Raffinement des spécifications, des fonctionnalités et des Spécification
⮚ performances par des prototypes successifs. définitives
⮚ Quand le client donne son accord, le développement suit souvent un cycle de
vie linéaire
 Modèle par prototypage

Avantages
❖ Pour le client: Une approche où domine l ’écoute total du client.
⮚ Le client reçoit des résultats tangibles rapidement ;
⮚ Le client peut exprimer ses besoins plus facilement;
⮚ Le client peut changer d’avis sans conséquences dramatiques.
❖ Pour l’ utilisateur:
⮚ Expérimentation rapide par les utilisateurs et feedback immédiat.
⮚ Former les utilisateurs avant la livraison du système final.
❖ Pour l’ équipe de développement:
⮚ Meilleure clarification des spécifications
⮚ Amélioration de la COMMUNICATION entre d’une part le client et
l’analyste, d’autre part l’analyste et le concepteur

Inconvénients
❖ Impatience du client qui croît avoir un logiciel final.
❖ Problème relatif à la gestion de projet ( planification, estimation des coûts, etc.)
 Modèle incrémentale

❖ A été proposé dans les années 80

❖ Incrément = version
Expression
des besoins
Spécification
fonctionnelle
Conception
Globale

Conception Conception
Incrément Incrément

Code Code

Test Test

Maintenance Maintenance
 Modèle incrémentale

❖ Propose un développement du logiciel par morceaux,

lesquels sont livrés successivement au client, en venant se
greffer à un noyau logiciel.
 Modèle incrémentale

❖ Un seul sous-ensemble des composants est développé à la fois

❖ Un logiciel noyau est tout d’abord développé puis,
❖ Des incréments sont successivement développés et intégrés
❖ Permet d’éviter de tout concevoir, de tout coder et de tout tester
❖ Les spécifications du logiciel sont figées et connues, l’étape de
conception globale est terminée.
❖ Certains modèles proposent de développer les différents
incréments en parallèle:
 Modèle incrémentale

Avantages
❖ Des livraisons et des mises en service possible après chaque
intégration d’ incrément ;
❖ Faire accepter progressivement un logiciel par les utilisateurs
❖ Intégration allégée: les intégrations et leurs tests sont progressifs ;
❖ Maintenance allégée ( par incrément)

Inconvénients
❖ un risque majeur de ce modèle est de voir remettre en cause le noyau ou les
incréments précédents ( définition globale des incréments et de leurs interactions
dès le début du projet).
❖ Complexité croissante de l ’ intégration de nouveaux incréments;
❖ Pour chaque version à développer après la 1 ère version livrée, il faut arbitrer
entre les demandes de correction et on et
❖ les nouvelles fonctionnalités à développer.
Modèle en spirale
 Modèle en spirale

❖ Il apporte une vue évolutive au modèle en cascade au travers d’une approche

❖ fondée sur l’analyse et la gestion des risques, puis la conception et la réalisation de prototypes
évolutifs en fonction de l’avancement du projet.

❖ Le développement présente quatre grandes phases qui se succèdent au fur et à mesure de la

construction de la spirale,

❖ Au dernier tour de la spirale, le produit est totalement défini, les risques résolus et le produit
développé.
Modèle en spirale

GL & AGL 2017 - 2018 28

 Modèle en spirale

Principe
La première spire résulte de la spécification du logiciel, les tâches à réaliser
pour cette spécification :

✔ Communiquer avec le client pour obtenir les spécifications

✔ Planifier le projet et les étapes de l’ analyse des spécifications
✔ Évaluer les risques technologiques des techniques d’ analyse
✔ Décider sur les techniques à utiliser pour l’ analyse des spécifications
✔ Réalisation proprement dite de l’ analyse des spécifications
✔ Présenter les résultats au client

On réalisera les autres tours du modèle de la même façon

On profitera de la région «planification » pour réajuster le plan du projet
 Modèle en spirale

Avantages
✔ Modèle réaliste et naturel
✔ Conserve le caractère « étapiste » du modèle en cascade mais l’ intègre
dans une approche itérative
✔ Le risque est un facteur qui est tenu en compte explicitement dans ce modèle.

Inconvénients
✔ Il est difficile de faire comprendre au client le mode d’opération de ce modèle
✔ L’ évaluation des risques exige une expertise spécifique
Objectifs Partie 2 :
Méthodes de développement
• Distinguer entre une méthodologie lourde et une
méthodologie agile.

• Illustrer les principales caractéristiques d’une

méthodologie de développement – lourde ou agile.

• Explorer les instances du processus unifié 2TUP et RUP.

• Organiser et planifier un projet informatique

conformément à une méthode de développement
donnée.
GL & AGL 31
 Plan
I. Méthodologies lourdes
✔Le processus Unifié.
✔RUP (Rational Unified Process)
✔2TUP (Two Track Unified Process)
II. Méthodologies agiles
✔Scrum
✔ Lean
✔ Kanban
✔ Scrumban
✔Extreme programming (XP)
✔Safe
✔ Less

GL & AGL 32
 Unified Process : UP
L'objectif d'un processus unifié est de maîtriser la complexité des
projets informatiques en diminuant les risques

QUI ?
participe au projet

QUOI ? COMMENT ?
Le produit livré Processu
s Unifié doit-il être réalisé

QUAND ?
est réalisé
chaque livrable 33
Unified Process : UP

Une méthode générique de développement de logiciels

Les cas
Architecture Les risques
d’utilisation
piloté par centré sur guidé par

Language Pocessu Itératif et

UML basé sur s Unifié incrémental
se déroule

RUP 2TUP

34
Unified Process : UP
UP est itératif et incrémental
Le processus itératif permet de :

⮚Capitaliser à chaque cycle les enseignements du cycle précédent

⮚Découvrir les erreurs et les incompréhensions plus tôt

⮚Avoir une vision plus objective de l'avancement du projet

35
 Unified Process : UP

UP est centré sur l'architecture

Vue
Vue logique implémentation
Vue cas
d’utilisation
Vue composants Vue déploiement

⮚ L'architecture du système est décrite à l'aide de différentes vues

⮚ Définir une architecture simplifiée qui répond aux besoins classés comme
prioritaires

⮚Définit à partir de l’architecture simplifiée les sous-systèmes de manière

beaucoup plus précise
36
Unified Process : UP
UP est piloté par les cas d'utilisation d’UML

⮚Système analysé, conçu et développé pour des utilisateurs

⮚Tout doit donc être fait en adoptant le point de vue utilisateur

37
Unified Process : UP
UP est orienté risques

⮚Identifier les risques

⮚Maintenir une liste de risques tout au long du projet

⮚UP contribue à la diminution des risques au fur et à

mesure du déroulement des itérations successives
 Unified Process : UP
Les 4 phases
Etude d’opportunité
▪ Etudier la faisabilité du projet, les
frontières du système et les risques
▪ Fournir une vision globale des
exigences, fonctionnalités clés et
contraintes
▪ Établir une estimation initiale des
risques, un "Project Plan", un
"Business Model"
Transition
▪ Test et correction des
anomalies.
▪ Préparer la version finale
du produit.
▪ Déploiement du produit.
Elaboration
▪ Reprise des résultats de
la phase d’incubation.
▪ Spécification détaillée
des cas d’utilisation.
▪ Détermination de
l’architecture de référence
Construction
▪ Construction d’une première
version du produit (version bêta
ainsi qu’une version du manuel
utilisateur).
▪ Construction de tous les cas
d’utilisation.
39
Unified Process : UP
Les activités
Expression des besoins
▪ Identification des besoins fonctionnels et non fonctionnels
Analyse
▪ Formalisation du système à partir des besoins.
▪ Modélisations de diagrammes statiques et dynamiques.
▪ Vue logique du système.
Conception
▪ Définition de l’architecture du système.
▪ Étendre les diagrammes d’analyse.
▪ Prise en compte des contraintes de l’architecture technique.

Implémentation
▪ Production du logiciel : Composants, Bibliothèques, Fichiers, etc.
Test
▪ Vérifier l’implémentation de tous les besoins (fonctionnels et non
fonctionnels).
▪ Vérifier l’interaction entre les objets.
▪ Vérifier l’intégration de tous les composants.
▪ Différents niveaux de tests (unitaires, d’intégration, de performance, 40
etc.).
 UP-Implémentation

UP a plusieurs implémentations et / ou variations :

✔RUP : Rational Unifed Process

✔2TUP : 2 Tracks Unifed Process

✔AUP : Agile Unifed Process

✔BUP : Basic Unifed Process

✔EUP : Entreprise Unifed Process, une extension de RUP

✔OUM : Oracle Unfied Method

✔ ….
41
 Rational Unified Process : RUP

• RUP est une instance / implémentation de UP.

• RUP est une démarche de développement qui est souvent utilisé
conjointement au langage UML.
• RUP implémente les caractéristiques de UP.
Phases

Activités

Itérations
(temps)
42
 Rational Unified Process : RUP

Les principaux éléments

▪ Comportement et responsabilités d’un ensemble de personnes

Rôles ▪ Décrit le Qui

▪ Opération exécutée au sein d’un état

Activités ▪ Une activité peut être interrompue
▪ Décrit le Comment
▪ Élément d’information, produit ou utilisé lors d’une activité de
Artefacts développement logiciel (modèle, source …)
▪ Décrit le Comment
▪ Décrire les enchaînements d’activités
Disciplines ▪ Décrit le Quand

GL & AGL 2017 - 2018 43

 Rational Unified Process : RUP

Les principaux éléments

44
Rational Unified Process : RUP

Chaque individu est

associé à un ou
plusieurs rôles.

45
 Rational Unified Process : RUP

Exemple illustratif des activités Analyse et Conception

46
 Rational Unified Process : RUP

Avantages
✔ Traçabilité à partir des Uses Cases jusqu’au déploiement grâce à
l’utilisation de l’UML,
✔ Approche basée sur l’architecture
✔ Les risques sont atténués dès le début du projet
✔ Planification est complète et détaillée
✔ Cadre propice à la réutilisation
✔ Possibilité de recadrer le projet après une itération
✔ Vérification constante de la qualité

Inconvénients
✔ Coût de personnalisation souvent élevé
✔ Vision non évidente ni immédiate
✔ Management lourd à mettre en place
✔ Ne convient à un projet de petite envergure.
47
 2 Track Unified Process : 2TUP

2 Track Unified Process : signifie littéralement que le processus suit deux

chemins. Il s’agit des «chemins fonctionnels » et « d’architecture technique », qui
correspondent aux deux axes de changement imposés au système d’information.

⮚C’est un processus qui répond aux caractéristiques du Processus Unifié.

⮚Apporte une réponse aux contraintes de changement continuel imposées aux

systèmes d’information de l’entreprise.

⮚Renforce le contrôle sur les capacités d’évolution et de correction de tels

systèmes.
La réalisation du
Axe système
Axe consiste à
fonctionne
technique fusionner les
l
résultats des
deux branches
48
2 Track Unified Process : 2TUP
 2 Track Unified Process : 2TUP

• Le développement d’un système peut se décomposer

suivant :
• Une branche fonctionnelle :
• Capitalise la connaissance du métier de l’entreprise.
• Capture les besoins fonctionnels.
• Une branche technique :
• Capitalise un savoir-faire technique et/ou des contraintes techniques.
• Les techniques développées pour le système sont indépendantes des
fonctions à réaliser.
• La phase de réalisation :
• Réunir les deux branches, permettant de mener une conception applicative
• Livrer une solution adaptée aux besoins.

50
2 Track Unified Process : 2TUP

51
2 Track Unified Process : 2TUP

⮚ S’intéresser au métier de
l’utilisateur.

⮚Etudier précisément la spécification

fonctionnelle de manière à obtenir
une idée de ce que réalise le système
sans se soucier des technologies à
utiliser.

52
2 Track Unified Process : 2TUP

53
2 Track Unified Process : 2TUP

⮚ Voit toutes les contraintes et les

choix dimensionnant la conception
du système
(outils+matériel+contrainte
d’intégration).
⮚ Capture des besoins techniques avec
l’existant.

⮚Définit les composants nécessaires à la

construction de l’architecture technique.

54
2 Track Unified Process : 2TUP

55
2 Track Unified Process : 2TUP

⮚ Intégration des 2 branches.

⮚ Étude de la réalisation de chaque

composant.

⮚Codage des composants + test.

⮚ Validation et vente du produit.

56
 Méthodologies lourdes vs Agiles

Lourdes

Agiles

57
 Méthodologie lourde ou Agile

• Inconvénients du PU :
• Fait tout, mais lourd.
• Parfois difficile à mettre en œuvre de façon spécifique.
• UP pour les gros projets qui génèrent beaucoup de documentation.
• Quelles activités pouvons-nous abandonner tout en produisant des logiciels
de qualité?
• Comment mieux travailler avec le client pour nous focaliser sur ses besoins les
plus prioritaires et être aussi réactifs que possible ?
Processus unifié vs SCRUM
• RUP 4 fois plus lent que Scrum : jusqu’à 27 rôles !
beaucoup plus de réunions
beaucoup plus de reportings
beaucoup plus d’efforts de communication
58
 Pourquoi Agile ?

C'est quoi l'agilité en entreprise ?

Une entreprise agile n'est pas figée dans ses processus. Elle est capable de
s'adapter rapidement aux changements imprévus (de façon réactive) et aux
nouvelles tendances (de façon proactive) qui se dessinent dans son secteur tout
en conservant une continuité stratégique et humaine.

C'est quoi l'agilité pour le développement des projets informatique?

L’agilité est une manière de réduire le cycle de développement des projets

informatiques, de répondre plus rapidement aux évolutions des demandes de
l’utilisateur final, les projets informatiques agiles sont gérés de manière adaptative,
incrémentale et itérative.

GL & AGL 2017 - 2018 59

 Méthodologie Agile :
Introduction
Métriques Classique Agile
(Waterfall)

Objectif Fixe Variable (flexible) /Fixe

Processus linéaire Cyclique

Implication du client Après le développement Au cours du

de projet (implicatio développement de projet
faible) (implication contenu)

Détection des erreur Tardive précoce

Niveau de risque Elevé Réduit

Tests Tardive fréquente

Livraison (délais) Lente Rapide

Changement Résistance au changement changeable

Qualité Contrôle qualité à la fin Contrôle qualité précoce et

permanant

Coût du projet élevé Réduit

 Méthodologie Agile

• Les méthodes agiles caractérisent un mode de gestion des

projets privilégiant
➢ le dialogue (daily meet) entre toutes les parties prenantes,
clients, utilisateurs, développeurs et autres professionnels
du projet,
➢ la souplesse en cours de réalisation,
➢ la capacité à modifier les plans et la rapidité de livraison.
[https://www.piloter.org/projet/methode/methode-agile.htm]
Exemples de méthodes agiles
• Scrum
• Lean
• Kanban
• Scrumban
• Extreme Programming (XP)
• Safe
• Less

62
 Méthode Scrum
• Elle vise à satisfaire au mieux les besoins du client tout en
maximisant les probabilités de réussite du projet.
• Un projet utilisant Scrum est composé d'une suite d'itérations
courtes de l'ordre de 2 à 4 semaines appelées sprints.
• A la fin d'un sprint, l'équipe livre au client un incrément de
logiciel fini potentiellement livrable.
• Le projet peut être réorienté par le client à la fin de chaque
sprint.

63
Méthode Scrum

64
Méthode Scrum

65
 Artefacts Scrum
• Product Backlog : liste ordonnancée des exigences fonctionnelles et
non fonctionnelles du projet. Le travail à faire durant un sprint est
listé dans le backlog du sprint.

• Mêlée quotidienne (daily scrum): se fait afin faire le point sur la

progression journalière du sprint.

• Revue de sprint (Sprint Review): bilan du sprint réalisé. L'équipe

de développement présente les livrables et les nouvelles
fonctionnalités terminées au cours du sprint.

• Rétrospective du sprint: Après la revue du sprint, cette réunion est

l'occasion de déterminer ce qui peut être amélioré suite au sprint
écoulé (productivité, qualité, efficacité, cadre de travail, etc.).

66
 Outils Scrum
• Les outils dédiés au management de projets agiles
exemple IceScrum, Xplanner, Trello, Jira, etc.

67
 Méthode Kanban
• Terme japonais signifie
« carte », « étiquette » ou
encore« panneau d’affichage ».
• inspiré de lean et basé sur la
demande plutôt que sur l’offre.
• Elle se fait en flux tendu, et
implique l’implémentation
quasiment en temps réel
des feedbacks clients.
• Suivre clairement et
visuellement le projet grâce à
un système de tableau et de
post-it constitué d’étiquettes
(ou kanbans).

68
 Méthode Scrumban
• Tous les avantages de Scrum + Kanban.
• Elle conserve l’approche de Scrum tout en permettant
de mener des projets en flux continu.
• adaptée à des projets mixtes et peut s’appliquer sur
plusieurs équipes différentes.
• Possède une méthode de travail proche de celle de
Kanban.
• Les itérations sont limitées, tout comme les tâches à
effectuer, afin de permettre aux équipes de s’adapter et
modifier un plan d’actions si nécessaire.
• S’appuie sur une planification basée sur la demande, les
équipes ne prévoient plus des tâches pour un sprint
complet mais doivent désormais les prioriser au fur et à
mesure de l’avancement du projet.

69
 Méthode Extreme Programming
• Pousser les valeurs de l’agile à l’extrême (itérations de
développement très courtes), ce qui permet une grande
flexibilité.

• À mi-chemin entre Scrum et Kanban: elle repose, comme

Scrum, sur le développement itératif. Mais là où XP se
rapproche de Kanban, c’est que ces itérations sont à très
court terme (une semaine maximum), pour pouvoir réagir
plus rapidement aux demandes du client.

70
Safe
⮚Le Framework SAFe (Scaled Agile Framework): permet
l'implémentation de la méthode agile à l'échelle de
l'organisation.
⮚La méthode se base sur des principes et connaissances pour
favoriser l'alignement, la collaboration et la livraison au sein
d'un grand nombre d'équipes agiles.
⮚l'approche la plus largement utilisée pour la l'agilité à l'échelle
(37%), suivie de Scrum (9%).

Less
⮚Large-Scale Scrum
⮚ est un framework de développement de produit qui vient étendre
la mise en place du Scrum sur plusieurs équipes.
⮚Autres méthodologies scrum large scale: Nexus, spotify…

GL & AGL 2017 - 2018 71

GL & AGL 2017 - 2018 72
 Quelle méthode choisir ?
• La méthode agile que vous choisirez doit répondre aux
besoins de l’équipe en charge de développement du
projet. Différents facteurs peuvent aider à faire son
choix :
⮚La disponibilité du client ou de l’utilisateur
⮚Les caractéristiques du produit que vous développez
⮚Le besoin du client et la visibilité du développement du
produit
⮚La rapidité avec laquelle le produit doit être mis à disposition
⮚Les membres de votre équipe, leur expérience face aux
méthodes agiles et son mode de fonctionnement
⮚Dans tous les cas, aucune méthode n’est par nature meilleure
qu’une autre. Les valeurs et les principes énoncés dans le
manifeste agile sont bien plus essentiels que l’application
plus ou moins stricte de telle ou telle méthodologie.

73