Cascade ou Scrum : comment choisir la façon d'exécuter votre projet

Dans presque tous les premiers échanges revient la même question, parfois formulée, parfois non : allez-vous faire cela en cascade ou en agile ? Derrière, il y a souvent une expérience passée. Soit un projet en cascade qui a livré, un an plus tard, quelque chose qui ne servait plus ; soit un projet « agile » qui n'a jamais abouti parce que chaque Sprint changeait de cap.

Les deux fonctionnent ; ce qui échoue, c'est d'exiger d'une intégration avec le système central qu'elle se révèle en cours de route, ou d'un canal digital qu'il se signe par phases. Le choix dépend de trois choses : le degré de définition du périmètre, la personne qui peut prioriser et la façon dont chaque livraison sera acceptée. Cet article est fait pour bien choisir.

La question qui tranche

Avant de parler d'étapes ou d'événements, répondez à ceci : pouvez-vous écrire dès aujourd'hui, avec suffisamment de précision, ce que le système doit faire une fois terminé ?

• Si oui —parce que c'est dicté par une norme, un contrat, un processus qui existe déjà ou un système à remplacer—, il convient d'avancer par étapes. La valeur tient à ne pas se tromper, et chaque étape réduit le risque de la suivante.
• Si non —parce qu'il s'agit d'un nouveau produit, d'un canal digital ou d'une idée à tester avec des utilisateurs—, il convient d'avancer par cycles courts. La valeur tient à apprendre vite, et chaque cycle corrige le cap avec ce qui a déjà été vu.

D'autres signaux poussent d'un côté ou de l'autre :

Par étapes : le cycle en V

C'est une cascade : six étapes, l'une après l'autre, chacune avec un livrable qui est examiné avant de passer à la suivante. Ce qui en fait un cycle en V, c'est le moment où l'on définit les tests : non pas à la fin, mais dès le début.

Il y a six étapes :

1. Origine. Le besoin métier s'écrit sous la forme d'une histoire : ce que l'on veut obtenir, pourquoi, ses limites et la personne qui décide. Cela ressemble à une formalité et c'est ce qu'il y a de moins cher dans le projet : ici, un malentendu coûte une conversation ; plus tard, le même malentendu coûte une reprise de travail.
2. Analyse. Nous mesurons l'existant : processus, systèmes, données et règles, y compris celles que seule une personne de l'équipe connaît. Dans les systèmes anciens, c'est l'étape qui surprend le plus, car des règles que personne n'avait écrites apparaissent souvent.
3. Conception. Nous modélisons d'abord le métier, puis la technologie. C'est ce que l'on appelle la conception pilotée par le domaine (DDD) : les composants du système portent les noms et les frontières du métier, et non ceux de la base de données. De là sortent l'architecture, les matrices de règles et les cas de test avec leur résultat attendu. C'est le point qui importe le plus à celui qui paie : dès la conception, il sait selon quels critères il acceptera.
4. Construction. Nous programmons sur la base de cette matrice. Chaque composant arrive avec ses tests unitaires et, lorsqu'il se connecte à un autre système, avec des tests de cette connexion que chacun peut rejouer, comme des collections Postman ou des scripts, sans dépendre de nous. Ces tests restent chez le client.
5. Tests. Deux passes distinctes. Lors de la passe qualité (QA), une revue indépendante de ceux qui ont programmé exécute la matrice complète. Lors de la recette utilisateur (UAT), les équipes du client valident dans leur propre environnement, avec leurs cas réels. Que ce ne soit pas celui qui l'a fait qui teste n'est pas de la défiance : celui qui a programmé a déjà décidé de ce qui était important, et c'est pourquoi il ne voit pas ce qu'il a laissé de côté.
6. Mise en production. Passage en production avec un plan de retour arrière convenu, un manuel d'utilisation et d'exploitation, et un accompagnement durant les premiers jours.

Pourquoi on dit « en V »

Dans une cascade menée de façon linéaire, les tests tendent à se concentrer après la construction, quand une erreur coûte déjà cher. Dans le cycle en V, chaque test se définit à l'étape qui l'origine et s'exécute plus tard : les tests unitaires et d'intégration pendant la construction ; la matrice qualité et la recette, à l'étape des tests, avant la mise en production. Le V désigne la forme de la lettre, non un chiffre :

Dessinée, la descente (origine, analyse, conception, construction) forme un côté de la lettre V et les tests remontent de l'autre, chacun face à l'étape qu'il vérifie. C'est le modèle que nous préférons là où une erreur coûte cher, car chaque exigence est reliée aux tests qui la vérifient. Nous l'utilisons dans une version allégée : sans documentation qui n'apporte rien.

Ce que cela vous demande : du temps à l'origine et à l'analyse, et la signature de la matrice de tests lors de la conception. Si cela est bien fait, la construction demande moins de votre temps, hors décisions ou changements importants.

Son risque : que le métier change pendant la construction. Il s'atténue avec des étapes courtes : mieux vaut livrer par tranches de quelques semaines qu'en un seul bloc d'un an.

Par cycles : Scrum

Scrum organise le travail en Sprints d'une à quatre semaines ; nous préférons deux ou trois. Chaque Sprint livre un incrément terminé et testé, et non des avancées dans une présentation.

Les événements sont peu nombreux et chacun a sa raison d'être :

• Planification du Sprint (Sprint Planning). Toute l'équipe convient de l'Objectif de Sprint, et ceux qui construisent choisissent, dans le Product Backlog, ce qu'ils peuvent terminer pour l'atteindre.
• Daily Scrum. Quinze minutes pour l'équipe afin de vérifier l'avancement par rapport à l'Objectif de Sprint et d'ajuster le plan de la journée. Il sert à débloquer, non à informer un supérieur.
• Revue de Sprint (Sprint Review). C'est une séance de travail sur ce qui a été construit, en fonctionnement, aux côtés de celles et ceux qui vont l'utiliser ; à partir de ce que l'on apprend, le Product Owner ajuste la liste.
• Rétrospective de Sprint (Sprint Retrospective). L'équipe examine sa façon de travailler et change une ou deux choses pour le cycle suivant.

Et deux éléments à soigner : le Product Backlog, dont l'ordre est décidé par le Product Owner et qui est visible de tous, et la Definition of Done (définition de « terminé »), qui décrit la qualité que doit atteindre chaque incrément pour être considéré comme terminé ; chaque histoire, en outre, entre avec ses propres critères de recette.

Ce que cela vous demande : un Product Owner disponible et ayant l'autorité de décider. C'est l'exigence la plus sous-estimée. Sans cette personne, Scrum devient une équipe qui livre toutes les deux semaines des choses que personne ne passe en revue.

Son risque : confondre agile et improvisé. Agile n'enlève ni les tests ni les critères de recette : chaque histoire entre avec les siens et sort avec ses tests, comme par étapes.

Quand utiliser les deux

En pratique, beaucoup de grands projets ont les deux natures. Une compagnie d'assurance qui lance un canal digital de vente a besoin par étapes de l'intégration avec son système central de polices d'assurance et avec l'ERP, où une erreur coûte de l'argent et expose à la réglementation. Et elle a besoin par cycles de l'expérience client dans le canal, dont la réussite ne s'obtient qu'en testant avec des utilisateurs.

Elles peuvent se combiner sans chaos avec trois règles :

1. Une frontière claire. Les interfaces entre les deux parties se conçoivent et se figent par étapes ; derrière cette frontière, chaque côté avance à son rythme.
2. Un seul responsable qui voit les deux parties et les place dans le même calendrier.
3. La même exigence de qualité. Les deux parties sont acceptées sur la base de tests écrits avant de construire chaque composant.

L'espace partagé

Une méthodologie apporte peu si les questions mettent une semaine à parvenir à la personne qui les résout. C'est pourquoi, par étapes comme par cycles, il convient de travailler dans des espaces partagés dès le premier jour : un canal de conversation directe avec l'équipe qui construit (Slack, Microsoft Teams ou celui que votre entreprise utilise déjà) et un tableau où l'on voit les tâches, leurs responsables et leur statut (ClickUp, Jira ou autre). Ainsi, le client voit le projet en direct, et non dans un rapport à la fin du projet, et les décisions sont consignées avec leur date et qui les a approuvées.

Comment décider dans votre cas

Une règle pratique : reprenez le tableau du début. Si la plupart de vos réponses tombent dans une colonne, commencez par cette façon ; si elles se répartissent, il vous convient probablement de les combiner. Et si vous ne savez toujours pas laquelle vous convient, c'est normal : la réponse dépend de la partie de votre projet qui pèse le plus. Lors d'un premier échange, nous l'examinons avec vous et nous vous disons comment nous l'exécuterions, tranche par tranche.