-

Pourquoi Scrum : comprendre l'intérêt de l'agile

Parlons d'abord de l'approche **agile** en général,

Parlons d'abord de l'approche agile en général,

En 2012, une étude a mis en évidence que les projets réalisés avec une méthode **agile** avaient un taux de réussite **4 fois supérieur** aux projets menés avec une méthodologie classique, en cycle en V ou waterfall (14% contre 42%)

En 2012, une étude a mis en évidence que les projets réalisés avec une méthode agile avaient un taux de réussite 4 fois supérieur aux projets menés avec une méthodologie classique, en cycle en V ou waterfall (14% contre 42%)

Le problème vient du fait que ces méthodes classiques **ne sont plus adaptées** au monde d'aujourd'hui, dans lequel **tout change de plus en plus vite**.

Le problème vient du fait que ces méthodes classiques ne sont plus adaptées au monde d'aujourd'hui, dans lequel tout change de plus en plus vite.

Dans les méthodes de gestion de projet classiques, les étapes sont **séquentielles**.

Dans les méthodes de gestion de projet classiques, les étapes sont séquentielles.

C'est-à-dire qu'on les applique **les unes après les autres**.

C'est-à-dire qu'on les applique les unes après les autres.

Chaque phase est dédiée à une **tâche spécifique**

Chaque phase est dédiée à une tâche spécifique

Et liée aux résultats de la **phase précédente**.

Et liée aux résultats de la phase précédente.

Il faut donc **compléter** entièrement une phase pour pouvoir **démarrer la suivante**...

Il faut donc compléter entièrement une phase pour pouvoir démarrer la suivante...

On clarifie d'abord les **besoins**.

On clarifie d'abord les besoins.

**PUIS**, on les formalise dans un document de **spécifications**

PUIS, on les formalise dans un document de spécifications

**PUIS**, on se lance dans le **développement** du produit

PUIS, on se lance dans le développement du produit

**PUIS**, on le **valide** en recette avec le client

PUIS, on le valide en recette avec le client

**PUIS**, on le monte en **production**

PUIS, on le monte en production

Ce modèle date des années 50 et n'est plus adapté au monde d'aujourd'hui avec son besoin de **flexibilité** et de **réactivité**.

Ce modèle date des années 50 et n'est plus adapté au monde d'aujourd'hui avec son besoin de flexibilité et de réactivité.

Cette approche est au contraire très **rigide**.

Cette approche est au contraire très rigide.

Des changements difficiles…

Il est très **difficile** d'y apporter des **changements**

Il est très difficile d'y apporter des changements

Les clients expriment leur besoin en **tout début de projet** et la **livraison** a lieu à la **toute** **fin**, des mois, parfois des années plus tard.

Les clients expriment leur besoin en tout début de projet et la livraison a lieu à la toute fin, des mois, parfois des années plus tard.

Si un **changement** significatif est demandé par le client en milieu de projet, tout le monde est en situation délicate, car il faut théoriquement **tout recommencer**: la phase d'analyse, le développement, les tests etc.

Si un changement significatif est demandé par le client en milieu de projet, tout le monde est en situation délicate, car il faut théoriquement tout recommencer: la phase d'analyse, le développement, les tests etc.

On se retrouve dans une situation qui n'est enviable pour personne,

On se retrouve dans une situation qui n'est enviable pour personne,

Le client se retrouve otage de ce qu'il a lui-même signé quelques mois plus tôt,

Le client se retrouve otage de ce qu'il a lui-même signé quelques mois plus tôt,

et si l'équipe ne sait pas s'**adapter** à ce changement et continue le projet, elle livrera au client, un produit dont **il n'a même plus besoin**.

et si l'équipe ne sait pas s'adapter à ce changement et continue le projet, elle livrera au client, un produit dont il n'a même plus besoin.

Tout le monde est **perdant** et c'est **frustrant** pour tout le monde.

Tout le monde est perdant et c'est frustrant pour tout le monde.

Or, avec l'**évolution** de plus en plus **rapide** du marché, ces **changements** en cours de route sont de plus en plus **fréquents**.

Or, avec l'évolution de plus en plus rapide du marché, ces changements en cours de route sont de plus en plus fréquents.

Les entreprises ont besoin de pouvoir **rectifier le tir** en cours de route s'ils s'aperçoivent que la manière dont ils ont exprimé leur besoin **n'est plus adaptée à leur situation**.

Les entreprises ont besoin de pouvoir rectifier le tir en cours de route s'ils s'aperçoivent que la manière dont ils ont exprimé leur besoin n'est plus adaptée à leur situation.

Et si l'équipe décide de prendre en charge le changement dans le cadre d'une méthodologie classique, l'**impact** sur les **coûts** et les **délais** peuvent être **énormes**.

Et si l'équipe décide de prendre en charge le changement dans le cadre d'une méthodologie classique, l'impact sur les coûts et les délais peuvent être énormes.

Des retards trop fréquents

De même, les phases étant fortement **dépendantes** les unes des autres, dans l'éventualité où l'une d'entre elles est en retard, c'est l'effet **boule de neige**.

De même, les phases étant fortement dépendantes les unes des autres, dans l'éventualité où l'une d'entre elles est en retard, c'est l'effet boule de neige.

Ce sont toutes les phases suivantes qui seront retard, et par conséquent, le **projet** **entier** !

Ce sont toutes les phases suivantes qui seront retard, et par conséquent, le projet entier !

Pas de retours utilisateurs

Dans les méthodes classiques, le client exprime ses **besoins** au **début** du projet uniquement.

Dans les méthodes classiques, le client exprime ses besoins au début du projet uniquement.

Puis pour lui, le reste du projet reste un long **tunnel** sans visibilité, il n'a pas la possibilité de donner des **retours**, des **feedbacks** sur ce qui est en train d'être réalisé.

Puis pour lui, le reste du projet reste un long tunnel sans visibilité, il n'a pas la possibilité de donner des retours, des feedbacks sur ce qui est en train d'être réalisé.

Il doit donc **attendre** la livraison finale pour voir si ce qui lui est livré **correspond bien à ses besoins**.

Il doit donc attendre la livraison finale pour voir si ce qui lui est livré correspond bien à ses besoins.

#### Ce qu'apporte l'agilité

Ce qu'apporte l'agilité

Les méthodologies **agiles** changent ce paradigme, car le **client** est **impliqué** pendant **toutes les phases** du projet.

Les méthodologies agiles changent ce paradigme, car le client est impliqué pendant toutes les phases du projet.

On peut même le considérer comme un **membre** à part entière de l'équipe.

On peut même le considérer comme un membre à part entière de l'équipe.

La méthode agile est une méthode **itérative** et **incrémentale**.

La méthode agile est une méthode itérative et incrémentale.

Itérative et incrémentale ?

Au lieu de développer le produit de A à Z, on va le **découper** en morceaux.

Au lieu de développer le produit de A à Z, on va le découper en morceaux.

Ces morceaux sont des sous-projets, les fameuses "**itérations**", qu'on livrera à chaque fois au client.

Ces morceaux sont des sous-projets, les fameuses "itérations", qu'on livrera à chaque fois au client.

Ainsi, le client peut **tester** le produit **régulièrement** et donner son **avis** sur ce qui est livré.

Ainsi, le client peut tester le produit régulièrement et donner son avis sur ce qui est livré.

La **relation** avec le client est ainsi **plus forte** et on répond beaucoup mieux à ses **besoins**.

La relation avec le client est ainsi plus forte et on répond beaucoup mieux à ses besoins.

Le produit va ainsi se construire **itération après itération** sous les yeux du client.

Le produit va ainsi se construire itération après itération sous les yeux du client.

Le client a alors son **mot à dire** sur ce qui est fait pour lui et pourra même **intervenir** sur la **priorisation** des fonctionnalités.

Le client a alors son mot à dire sur ce qui est fait pour lui et pourra même intervenir sur la priorisation des fonctionnalités.