Les développements Agiles sont-ils plus rapides ?

Ce qui rassemble les différentes méthodes Agiles, dont la plus connue est SCRUM, c’est l’application d’un processus de développement itératif ; plutôt qu’une longue séquence entraînant un effet tunnel pour le client, les méthodes Agiles optent, schématiquement, pour une succession de petits cycles en V.

La rapidité des méthodes Agiles est une caractéristique souvent mise en avant par ses partisans. Pourtant, sur la base de la définition ci-dessus, rien ne permet de dire qu’elles offrent un résultat final plus rapidement qu’un cycle en V.

Alors, les méthodes Agiles sont-elles vraiment plus rapides ? Si oui, comment ?

Pour pouvoir répondre à la question, il faut définir où se situent les lignes d’arrivée et de départ :

• Pour la ligne de départ, disons que c’est le moment où le client est prêt à se lancer dans un projet.
• Pour la ligne d’arrivée, disons que c’est le moment où le client est satisfait du résultat qui lui est proposé, c’est à dire que l’application réalisée répond à l’ensemble de ses besoins réels.

Il est très complexe d’obtenir une application qui réponde parfaitement aux besoins réels :

• Le besoin réel est « dans la tête » du client ; ce besoin réel est rarement complètement mûr au niveau de la « ligne de départ »
• Pour que ce besoin réel soit réalisé par une équipe de développement, le client doit l’expliquer. Cela passe par une phase de spécification qui induit un décalage avec le besoin réel ; des éléments jugés évidents (à tort) ne sont pas expliqués / certains besoins sont oubliés, et des besoins superflus sont introduits
• Ensuite l’équipe de développement réalise une application, sur la base de sa compréhension des spécifications, ce qui crée un biais supplémentaire

Cette problématique de divergences multiples existe pour n’importe quelle méthode de réalisation et est souvent schématisée comme suit :

Le cycle en V part avec de nombreux handicaps pour faire converger rapidement besoins réels et réalisation :

• Les spécifications du besoin sont intégralement rédigées au démarrage du projet. Pendant cette phase, l’équipe de développement n’est pas encore mobilisée
• Celles-ci restent ensuite figées tout au long du projet, telle une Bible. Or, le besoin à l’instant t est rarement identique à l’instant t+1, surtout quand il s’écoule plusieurs mois de projet
• Un passage de relai est effectué (sans discussion possible) entre le client et les développeurs sur la base des spécifications

Tous ces handicaps mènent souvent à une situation où la réalisation de l’équipe ne correspond pas du tout aux attentes du client. Et malheureusement, cette situation n’est découverte qu’à la fin du projet, au moment de la recette fonctionnelle, après plusieurs semaines / mois d’effet tunnel pour le client.

A ce moment là, la « ligne d’arrivée » qui semblait se rapprocher est repoussée par un nombre important de demandes de correctifs issues de la Recette fonctionnelle.

C’est donc seulement à l’approche de la fin théorique du projet que le client peut enfin voir et s’exprimer sur l’application réalisée. Et dans la plupart des cas, l’absence de dialogue pendant le développement a provoqué une divergence marquée entre le besoin réel et la réalisation, ce qui oblige à prolonger le projet.

Méthode Agile : Course d’orientation en équipe / Chasse aux trésors

Les méthodes Agiles sont entièrement tournées vers l’atteinte rapide de la « ligne d’arrivée » en optant pour une démarche itérative et participative (le client et les développeurs forment une équipe).

Pour reprendre l’analogie de la course, un projet Agile ressemble à une course d’orientation par équipe (ou une chasse aux trésors) : le capitaine de l’équipe est le client ; son rôle est celui de « Product Owner » dans la méthode. C’est lui qui porte la vision de l’application développée ; il donne le Cap vers les différents points à atteindre lors de la course (qui sont autant de « lignes d’arrivées » intermédiaires). Les développeurs sont là pour proposer le meilleur chemin pour atteindre ces différents objectifs intermédiaires. Tout le monde échange et travaille en même temps, au quotidien. On n’assiste pas à une transmission de relai comme dans un cycle en V ; le client participe à la course du début à la fin.

En terme de rapidité à atteindre la ligne d’arrivée, les avantages sont multiples :

• La phase de spécifications est bien plus courte que dans un cycle en V. Le client doit bien sûr spécifier un minimum son besoin, via la constitution d’un « Product Backlog», qui est une liste ordonnée par valeur Métier de l’ensemble des fonctionnalités attendues (appelées « Stories »), mais le démarrage du développement est quasi immédiat comparé au cycle en V (les détails fonctionnels sont fournis en cours de projet par le client).
• L’équipe (client et développeurs) réalise des itérations successives, appelées « Sprints ». A chaque Sprint son objectif, matérialisé par un « Backlog de Sprint » qui est la liste des Stories à réaliser lors du Sprint. Le résultat doit constituer une application présentable aux utilisateurs et potentiellement utilisable en Production. Cela empêche toute divergence entre le besoin réel et la réalisation.
• Chaque Sprint peut donc être vu comme un objectif intermédiaire (dont l’atteinte offre un résultat concret) de notre course d’orientation. En outre, chacun de ces objectifs intermédiaires peut se transformer en « ligne d’arrivée » définitive ! Lorsque le client est satisfait de ce qu’il a obtenu, il peut décider d’arrêter la course. Dès lors un projet qui était planifié sur 5 Sprints peut tout à fait se terminer au bout de 3 ou 4 si des besoins identifiés au départ s’avèrent finalement inutiles.

Arriver à un succès rapide est ce dont rêvent tous les managers et tous les clients. Mais lorsqu’un projet « cycle en V » échoue (les clients ne sont pas satisfaits, l’application n’est pas utilisable, etc.) après plusieurs mois de développement, nombreux sont ceux qui regrettent le gâchis de ces mois d’efforts…

Les méthodes Agiles permettent d’échouer rapidement (on parle du « Fail Fast »).

Dès le 1^er Sprint, si l’équipe se rend compte que les fonctionnalités qui ont le plus de valeur ne sont pas réalisables selon le souhait du client, le projet peut être arrêté (temporairement ou définitivement) alors que son équivalent en cycle en V se serait poursuivi plusieurs mois jusqu’à ce que le client voit enfin le résultat (qui ne lui convient pas)

Que ce soit dans la réussite ou dans l’échec, les méthodes Agiles sont donc bien plus rapides que le traditionnel cycle en V. Cette rapidité vient essentiellement d’un recentrage permanent entre la réalisation et le besoin réel ; recentrage rendu possible par des échanges quotidiens entre client et développeurs et une approche itérative du projet, facilitant les boucles de retours utilisateurs.

Bien sûr, il n’y a pas de miracle ; cette rapidité est obtenue au prix d’une organisation rigoureuse et d’une très forte disponibilité du client pendant le développement, qui sort de son rôle de spectateur (voire d’opposant quand on constate sur le terrain les relations MOA / MOE dans un cycle en V) pour endosser le brassard de capitaine d’équipe dans la méthode Agile.

La transition du cycle en V vers le développement Agile n’est donc pas triviale et nécessite une nouvelle organisation et un changement des habitudes aussi bien au niveau de la DSI que des Métiers.

Ces changements doivent avoir lieu en profondeur, avec un engagement fort du Management afin que l’Agilité soit réelle (et pas juste une application inefficace des principes Agiles). C’est un vrai projet de transformation, qui nécessite un accompagnement, des formations et l’adaptation des processus existants.

—-

Nicolas Montens

Nos autres articles sur les méthodes agiles

Méthodes Agiles – Qu’est ce qu’un PO Proxy ?

Méthodes Agiles – quelles leçons de leur utilisation ?