Mort au cycle en V, mais surtout mort à Scrum

Pour lire d’autres articles sur le développement, cliquez ici.

Depuis plus de 20 ans, Agile est le paradigme le plus utilisé dans le développement logiciel.

Plus spécifiquement, c’est Scrum qui est aujourd’hui appliqué dans la plupart des projets faisant appel aux méthodes agile.

Avant les années 2000, c’était le cycle en V qui était utilisé dans la vaste majorité des cas.

Nous allons voir par quoi ces 2 méthodes ont été influencées, en quoi elles consistent, et pourquoi elles sont en réalité toutes les deux terriblement inefficaces.

Le développement en tant que chaîne de production

Le parti-pris du cycle en V et de Scrum est d’envisager le développement logiciel comme une chaîne de production.

C’est-à-dire que ces méthodes partent du principe qu’il faut pouvoir l’organiser avec des processus très spécifiques au sein d’un cadre strict dans le but d’améliorer l’efficacité des équipes en charge.

Pour comprendre comment on en est arrivé là avec les méthodologies de développement logiciel, il faut comprendre de quoi elles s’inspirent.

Le taylorisme

Représentation visuelle du Taylorisme.
C'est une pyramide représentant les 3 niveaux hiérarchiques de l'organisation Tayloriste du travail.
La base représente l'exécution, menée par les ouvriers.
L'étage intermédiaire représente la vérification, assurée par les contremaîtres.
Le sommet représente la conception, assurée par les ingénieurs.
La dimension horizontale consiste en la répartition des tâches entre personnes d'un même étage.
La dimension verticale consiste en la répartition des types de tâches en fonction de l'étage de la pyramide.

Le taylorisme est une des méthodes d’organisation du travail les plus connues.

Inventée par Frederick Winslow Taylor à la fin du XIXe siècle, elle préconise d’organiser le travail sur 2 dimensions :

La dimension verticale : on sépare les phases de conception, de vérification, et d’exécution. Les ingénieurs pensent le produit, les ouvriers le fabriquent, et les contremaîtres supervisent le travail des ouvriers.
La dimension horizontale : on découpe l’exécution en tâches simples confiées aux ouvriers.

Lean

Inspiré de la gestion du système de production de Toyota, le Lean est une méthode de gestion de la production visant à éliminer le gaspillage des ressources, l’irrégularité, et la surcharge de travail.

De manière plus résumée, Lean cherche à améliorer la valeur pour le client en améliorant les performances de production.

Pour comprendre Lean, il faut connaître les 2 modes de pilotage d’une chaîne de production :

Le flux poussé : on produit pour stocker (on s’apprête à vendre)
Le flux tiré : on produit pour livrer (on a déjà vendu)

Lean applique une gestion dite de « juste à temps » (JIT), en flux tiré, afin de toujours produire exactement ce qui est demandé par le client de manière instantanée.

De plus, en faisant en sorte de détecter les défauts dans la chaîne de production au plus tôt, Lean permet de réduire des coûts de non-qualité qui seraient détectés plus tard.

Lean se base également sur le principe de l’amélioration continue, consistant à résoudre les problèmes directement sur le terrain avec les acteurs concernés.

Cycle de Shewhart : Plan-Do-Check-Act

Représentation visuelle du cycle de Shewhart.
C'est un cercle vertueux consistant en 4 étapes : la planification, la réalisation, la vérification, et l'ajustement.

Le cycle de Shewhart est une méthode de gestion de la qualité utilisée par Lean, prenant la forme d’un cercle vertueux et permettant d’améliorer la qualité d’un produit de manière continue.

Il se déroule en 4 étapes :
1) Planifier ce que l’on veut réaliser en identifiant un problème et les solutions possibles à sa cause racine
2) Réalisation
3) Contrôler l’efficacité et la qualité de la solution mise en place
4) Ajuster et déployer

Le modèle en cascade

Représentation visuelle du modèle en cascade.
On y retrouve 6 étapes successives : exigences, analyse, conception, mise en œuvre, validation, et mise en service.

Le modèle en cascade n’est pas inspiré du Taylorisme de manière officielle, mais il serait difficile de ne pas y voir une certaine forme de mimétisme.

Il s’agit d’une des organisations de projet les plus utilisées en développement logiciel.

Ici, on s’intéresse au projet dans sa globalité en séparant le développement en 6 phases successives :

Exigences, l’expression d’un besoin
Analyse, l’étude du besoin exprimé
Conception, préparation à la mise en oeuvre
Mise en œuvre, la réalisation du produit
Validation, vérification de la conformité du produit aux exigences
Mise en service

L’avantage du modèle en cascade est qu’il permet de tenir une documentation conséquente constituée des livrables créés lors de chaque phase.

Dans le cadre d’un projet de développement logiciel, on se retrouverait avec les livrables suivants :

Exigences : Expression de besoins
Analyse : Cahier des charges
Conception : Architecture et modèles
Mise en œuvre : Produit
Validation : Tests

Cycle en V

Le cycle en V est une spécification du modèle en cascade pour les projets d’ingénierie et de développement logiciel.

Il reprend le fonctionnement en phases successives du modèle en cascade, en ajoutant 4 étapes supplémentaires et étant plus spécifique sur les tâches à accomplir.

Pour cela, il regroupe les phases de la gestion du projet en 4 niveaux, avec pour chaque catégorie une phase de conception et une phase de vérification, lui donnant ainsi une forme de V lorsqu’il est schématisé :

Métier
Fonctions du produit
Système et architecture
Composants du système

On retrouve donc les étapes suivantes :

Exigences : expression d’un besoin
Analyse : création d’un cahier des charges à partir des exigences
Conception générale : conception du système et de son architecture
Conception détaillée : conception de chaque composant du système
Mise en œuvre : développement des composants
Tests unitaires : vérification de la conformité de chaque composant
Tests d’intégration : vérification des interactions entre les composants conformément aux exigences de la conception générale
Tests systèmes : vérification de la conformité du système aux exigences
Validation : tests d’acceptation
Recette : le client valide le produit avant sa mise en service

Les entités du cycle en V

La maîtrise d’ouvrage (MOA) : l’organisme décideur pour qui le projet est réalisé
La maîtrise d’œuvre (MOE) : l’organisme réalisant le projet
- L’équipe architecturale : équipe en charge du système et de l’architecture
- L’équipe de développement : équipe en charge des composants
Le comité de pilotage : assure le suivi du projet et sert d’intermédiaire entre la MOA et la MOE

Le problème du cycle en V

Le cycle en V possède un énorme défaut.

C’est d’ailleurs ce défaut qui lui a été fatal quand la méthode Agile est arrivée.

Ce défaut, c’est l’effet tunnel.

« Un jour, j’irai vivre en Théorie, car en Théorie tout se passe bien.«
Pierre Desproges

L’effet tunnel, c’est un manque de visibilité sur l’avancement du projet.

En se faisant succéder une phase de conception, une phase de réalisation, et une phase de validation, le cycle en V semble partir du principe que l’on n’aura jamais besoin de retoucher aux exigences ou de repartir en arrière.

Pourtant, ce n’est pas rare que les spécifications d’un projet évoluent dans le temps, car elles étaient incomplètes ou parce que l’objectif a changé.

« Vous ne pouvez pas demander aux clients ce qu’ils veulent et ensuite essayer de le leur donner. Au moment où vous l’aurez construit, ils voudront autre chose. »
Steve Jobs

De plus, que se passe-t-il si l’on s’aperçoit qu’une partie de la conception est finalement impossible à réaliser ?

On revient en arrière ? Sous quelles conditions ? Les responsables de la phase en question sont-ils encore disponibles ?

Une méthode qui ne prend pas en compte ce genre d’imprévus n’a pas beaucoup d’utilité.

Vous pouvez bien nommer autant de responsables, et produire autant de livrables que vous voulez, si le train déraille au moindre caillou sur la voie, vous aurez peu de chance d’arriver à destination.

Les critiques du modèle en cascade

Comme vu précédemment pour le cycle en V, le principe des phases successives est une énorme source de problèmes.

Mener toute une gestion de projet sur la base d’exigences susceptibles d’évoluer rend presque obligatoire le fait d’effectuer des retours en arrière intempestifs entre les différentes phases.

Le but du jeu est de descendre la cascade, alors pourquoi passerait-on notre temps à la remonter ?

Quel peut bien être l’intérêt de tout planifier si ça ne sert à rien ?

Agile

Aux antipodes du modèle en cascade et de sa rigidité, les méthodes agiles proposent de s’appuyer sur des équipes pluridisciplinaires auto-organisées au sein d’un cadre favorisant l’amélioration continue.

Agile s’inspire du Lean pour apporter les principes de flux tiré, d’amélioration continue, et de planification adaptative au domaine du développement logiciel.

Agile est apparu de manière officielle lorsque 17 développeurs ont publié le Manifeste pour le développement agile de logiciels en 2001.

En 4 valeurs, Agile se place en opposition complète au modèle en cascade et son cycle en V :

Les individus sont plus importants que les processus et les outils.
Un logiciel opérationnel est plus important qu’une documentation exhaustive.
Collaborer avec les clients est plus important que la négociation contractuelle.
L’adaptation au changement est plus importante que l’exécution d’un plan.

Ce que ces valeurs signifient, c’est que la plus haute priorité est de satisfaire le client avec la livraison rapide d’un produit qui correspond à ses attentes.

Ce faisant, il ne sert à rien d’appliquer strictement des méthodes si elles nuisent à l’avancée du projet, et il faut pouvoir accueillir positivement le changement tout au long du développement.

Le Manifeste Agile nous apporte également un principe important : le principal témoin d’avancement d’un projet de développement est un logiciel opérationnel.

Développement itératif et incrémental

Complètement opposé au modèle en cascade et à sa philosophie de planification excessive, Agile se base sur le principe du développement itératif et incrémental.

Itératif : le développement est approché de manière cyclique
Incrémental : chaque cycle apporte un nouvel incrément du produit

Le développement itératif et incrémental puise son inspiration directement dans le cycle de Shewhart.

Scrum

Le petit problème avec Agile, c’est que c’est en fin de compte une philosophie à adopter, et non une véritable méthode.

Le manifeste nous indique 4 valeurs à respecter et 12 principes à suivre, mais ne nous dit à aucun moment comment faire.

C’est là qu’entrent en scène 2 méthodes censées appliquer les principes agiles : Scrum et exTreme Programming (XP).

Si les méthodes agiles sont inspirées par la philosophie Lean, Scrum est carrément un moyen de transformer un projet logiciel en chaîne d’assemblage de Toyota.

Scrum est considéré comme un framework, c’est-à-dire un cadre de travail, et non une méthode de gestion de projet en tant que telle.

D’ailleurs, Scrum en tant que tel n’est pas spécifiquement conçu pour le développement informatique.

Plus exactement, ici on va parler du syncrétisme de Scrum et d’eXtreme programming, qui est généralement ce que l’on nomme Scrum au sein des entreprises.

Scrum se base sur 3 piliers :

Transparence : tous les membres de l’équipe Scrum sont tenus au courant des actualités
Inspection : le travail est vérifié au fur et à mesure
Adaptation : l’équipe Scrum s’adapte à l’évolution du contexte du projet

Le développement est divisé en sprints, des blocs de temps plus ou moins longs (d’une semaine à un mois, très généralement 2 semaines).

Lesdits sprints commencent tous par une réunion de planification de sprint, et se finissent par une rétrospective.

La planification de sprint vise à prioriser les tâches du product backlog, qui liste toutes les fonctionnalités et les corrections à implémenter et qui se remplit et se vide au fur et à mesure du projet.

Entre les deux, le développement suit son cours en fonction de ce qui a été défini lors de la planification.

Les entités de Scrum

Les parties prenantes : l’ensemble des individus et organisations extérieurs à l’équipe, mais concernés par le projet. (ex : client, utilisateurs, partenaires)
Le product owner : le représentant de l’utilisateur final au sein de l’équipe de développement, ou l’utilisateur final lui-même. Il a la charge de prioriser les tâches du backlog pour servir les nouvelles exigences.
Le scrum master : le membre de l’équipe de développement chargé de faire appliquer les principes du Scrum. Ce n’est pas un chef de projet, mais un facilitateur.
L’équipe scrum : l’équipe pluridisciplinaire chargée de concevoir et de réaliser le produit.

Les « cérémonies » Scrum

Daily scrum : réunion quotidienne rapide (max. 15 minutes) au cours de laquelle les membres de l’équipe font le point sur ce qui est en cours et a été fait.
Planification de sprint : réunion d’ouverture d’un sprint au cours de laquelle l’équipe définie avec le product owner l’objectif du sprint et les tâches du backlog à y inclure.
Revue de sprint : réunion précédent la rétrospective au cours de laquelle l’équipe Scrum présente les ajouts du dernier sprint aux parties prenantes du projet.
Rétrospective de sprint : réunion de clôture d’un sprint au cours de laquelle l’équipe fait le bilan sur l’avancement des tâches prévues et cherche des axes d’amélioration.

Le problème avec Scrum

« Maintenant, Agile signifie appliquer la moitié des principes de Scrum et utiliser Jira. »
Andy Hunt

Scrum n’est pas agile.

Il va à l’encontre de la première valeur d’Agile : « Les individus sont plus importants que les processus et les outils ».

Scrum est rempli de processus qui servent à se donner l’illusion d’une planification, mais qui apportent finalement très peu de valeur, voire ralentissent les choses.

On aura beau mettre un joli enrobage autour en remplaçant le terme « réunions » par « cérémonies », le résultat est le même.

Pendant que l’on passe 5 heures par semaine* à discuter du backlog et des tickets, on ne conçoit pas et on ne développe pas.

*il s’agit réellement du temps occupé par toutes les cérémonies quand on suit les recommandations officielles.

Scrum est un moulin à bullshit.

À quoi cela sert-il d’estimer le temps et la difficulté des tâches ?

La prise de décision devrait être simple : si la tâche semble trop lourde ou difficile, il faut la diviser en sous-tâches ou l’abandonner.

Pourquoi donc essayer de quantifier ces paramètres à coups de poker planning ?

La réponse : pour pouvoir faire des sprints de 2 semaines.

Nouvelle question : pourquoi organiser le développement en sprints en premier lieu ?

Bien sûr, il s’agit de pouvoir livrer un incrément du produit régulièrement, mais « régulièrement » ne veut pas dire « absolument toutes les 2 semaines »

L’utilisateur final s’en fiche que son logiciel se mette à jour toutes les 2 semaines, il veut un logiciel qui marche.

Ça n’a pas de sens, au lieu d’axer le développement autour de quelque chose qui a énormément de valeur (un logiciel opérationnel), Scrum l’axe autour de quelque chose qui en a beaucoup moins (des mises à jour régulières)

Les délais ou la qualité

Qu’obtient-on lorsque l’on essaie de diviser un développement en blocs de temps fixe ?

Un produit mal conçu et à moitié opérationnel (personne ne veut ça)
Des tickets qui sont retardés d’un sprint à un autre (donc aucun intérêt à faire des sprints)

Cela revient à essayer de rentrer un éléphant dans un frigo. Ça ne passera pas sans faire du mal à l’éléphant.*

*pour votre propre bien ainsi que le sien, n’essayez pas de rentrer un éléphant dans un frigo

En voulant créer un cadre de travail alternatif au modèle en cascade, Scrum est devenu la chose même qu’il comptait détruire : une machine à planifier qui ne permet pas de faire ce qui est utile, mais de faire ce que dit la méthode.

De ce point de vue là, Scrum est l’antithèse d’Agile. Tout autant que n’importe quelle variation du cycle en V.

Scrum a complètement délaissé le fondement même d’Agile : le principal témoin d’avancement d’un projet de développement est un logiciel opérationnel.

Pas le nombre de tickets effectués en 2 semaines.

Pas le nombre de livrables.

Un logiciel opérationnel.

Être agile sans Scrum

Devinez quoi ? C’est possible !

Il suffit juste de prendre tout ce qu’a apporté Scrum et de le jeter par la fenêtre, pour revenir aux principes du manifeste.

Arrêtez de faire des sprints. Axez le développement autour de ce qu’il faut livrer, pas autour de blocs de temps.
N’essayez pas de faire des estimations. Une tâche est faisable ou elle ne l’est pas.
Récoltez du feedback de manière régulière.
Gardez votre code simple et clair.
Faites du refactoring. Éliminez la dette technique quand vous la trouvez. N’attendez pas que votre code se transforme en monstre spaghetti géant.
Faites ce qui produit de la valeur.
Ne faites pas ce qui n’en produit pas.

Agile n’est pas un tableau Jira.

Si cela a du sens pour vous d’utiliser Jira, utilisez Jira.

Sinon, utilisez autre chose. L’important, c’est que ça marche.

Maintenant que vous êtes libéré des contraintes de Scrum, vous pouvez vous concentrer sur ce qui apporte le plus de valeur, dans cet ordre-là :

Faire quelque chose qui fonctionne
Le faire proprement
Le faire rapidement

Une 3ème voie

Finissons sur une simple suggestion.

Le modèle en cascade et la méthode Agile comparent tous les deux le développement logiciel à une chaîne de production, à un certain degré.

L’un cherche à planifier la totalité du travail comme on a l’habitude de le faire dans l’industrie, et l’autre s’inspire du Lean.

Seulement, la métaphore est-elle vraiment si pertinente ?

Et si, finalement, le développement n’était pas une chaîne de production, mais un processus créatif ?

Outre le fait qu’un logiciel soit en évolution constante, contrairement à un produit sorti d’une chaîne de production, un logiciel est quelque chose que l’on conçoit et que l’on écrit avant d’être quelque chose que l’on assemble.

Peut-être faut-il simplement cesser de vouloir faire du Taylorisme ou du Lean.

Il n’y a pas qu’une seule façon de piloter un processus créatif.

De plus, le processus créatif de chaque personne et de chaque organisme est différent.

Peut-être que le mieux à faire est encore de s’inspirer de ce qui existe déjà, d’expérimenter, et d’établir sa propre méthode.

Au lieu d’appliquer ce qui est censé marcher, trouvez ce qui marche pour vous et vos collaborateurs.

Ensuite, documentez, et faites évoluer si besoin est.

Refuser de choisir entre le cycle en V et Scrum ne signifie pas que l’entreprise va plonger dans le chaos et l’anarchie pour finir par mettre la clé sous la porte.

Au contraire, cela signifie que l’on se débarrasse d’une quantité astronomique de bullshit pour se concentrer sur la seule chose qui compte pour une entreprise : créer de la valeur.