La façon dont votre projet logiciel est mené détermine le coût d’un changement d’avis plus tard. Le développement logiciel agile maintient ce coût bas. Dans un plan Waterfall traditionnel, une nouvelle exigence au quatrième mois signifie une demande de changement et une nouvelle estimation. En Agile, l’équipe l’ajoute au prochain bloc de travail de deux semaines. Quelques réunions et un nouveau plan de sprint suffisent pour que les fonctionnalités ou les changements dont vous avez besoin soient implémentés rapidement, avec des perturbations minimales.
Le développement logiciel agile construit un produit par cycles courts, généralement d’une à quatre semaines. Chaque cycle se termine par quelque chose qui fonctionne et que vous pouvez voir, de sorte que le plan s’adapte à mesure que vous apprenez. Cette approche convient aux projets dont les exigences vont bouger, et elle convient mal lorsque le périmètre est verrouillé par contrat ou par la réglementation dès le premier jour.
Ce guide explique ce que signifie l’agilité en termes simples, comment elle se compare au Waterfall, et ce que sont réellement Scrum et Kanban. Il détaille aussi à quoi ressemblent deux semaines de travail, jour après jour. Nous développons nous-mêmes des logiciels de cette manière, le plus souvent avec une équipe de développement dédiée qui rejoint le processus existant du client, si bien que les exemples présentés ici viennent de projets que nous avons livrés, pas de la théorie.
Ce que signifie vraiment le développement logiciel agile
Vous trouverez la méthodologie agile expliquée de dizaines de façons différentes. Sous les frameworks et la terminologie, tout se résume à une habitude qui se répète. L’équipe construit une petite partie du produit, la montre aux personnes qui vont l’utiliser, et laisse leur réaction définir la suite. Cette boucle continue jusqu’à ce que le logiciel soit terminé.
Trois éléments soutiennent cette habitude :
- Des cycles courts, pour qu’une erreur de direction coûte deux semaines au lieu d’un an
- Quelque chose qui fonctionne à la fin de chacun d’eux, plutôt qu’un rapport d’avancement
- Un plan mis à jour ouvertement, volontairement, avec vous dans la pièce
Un mythe mérite d’être écarté avant d’aller plus loin. L’Agile ne supprime pas la planification, il la revisite toutes les quelques semaines, à la lumière de ce que le dernier cycle a appris à tout le monde. Les équipes qui sautent purement et simplement cette étape ne sont pas agiles, elles sont simplement désorganisées, et la différence se voit dès le troisième mois.
Ce que l’Agile n’est pas :
- Une règle qui rend la documentation optionnelle
- L’autorisation de commencer à construire avant que quiconque s’accorde sur ce à quoi ressemble le succès
- La promesse que les échéances bougeront dès que cela arrange l’équipe
Un cadrage structuré vient toujours en premier sur la plupart de nos projets. Une phase de découverte définit l’objectif, les utilisateurs, les contraintes et la forme approximative du travail. L’Agile décide ensuite comment cette forme se remplit, et il accepte que certaines de vos hypothèses de départ se révéleront fausses.
Ce que les clients apprécient le plus, c’est que nous n’avons pas besoin d’une spécification finalisée pour être productifs. Beaucoup d’entreprises qui viennent nous voir savent exactement quel résultat elles veulent. Le logiciel qui le produit est la question ouverte, alors nous la résolvons ensemble à mesure que le projet avance. Personne n’a à inventer des réponses juste pour remplir un document.
Agile ou Waterfall : quand chaque approche a du sens
Le Waterfall déroule un projet en une seule longue ligne. Vous validez le périmètre complet, puis vous le concevez, puis vous le construisez, puis vous le testez, puis vous le livrez. Chaque étape se termine avant que la suivante commence, ce qui explique pourquoi vous ne voyez généralement un logiciel fonctionnel que vers la fin.
Cette approche n’est pas absurde, et elle n’a pas disparu. Les appels d’offres publics à prix fixe, la certification de sécurité et les dates de lancement de matériel récompensent tous le fait de connaître toute la réponse à l’avance. Ce que le Waterfall gère mal, c’est la découverte. Les problèmes commencent quand ce que vous apprenez tard dans la construction contredit un choix fait au départ. Revenir dessus signifie plus de paperasse, un prix révisé et une conversation inconfortable.
Périmètre
Validé en totalité avant le début du développement
Validé dans les grandes lignes, puis détaillé cycle par cycle
Quand vous voyez un logiciel fonctionnel pour la première fois
Vers la fin
Toutes les une à quatre semaines
Coût d’un changement au quatrième mois
Élevé, généralement une demande de changement formelle
Normal, il part dans le cycle suivant
Ce que cela exige de vous
Des exigences détaillées en amont
Quelques heures par semaine, chaque semaine
Cas d’usage idéal
Contrats à prix fixe, produits certifiés, échéances matérielles
Produits qui évoluent en continu avec leur marché
Risque principal
Construire correctement la mauvaise chose
Un périmètre qui dérive quand l’objectif est flou
Choisir entre le développement logiciel agile et le Waterfall tient rarement à la méthode qui paraît la plus moderne. Tout revient à une seule question : quelle part de ce produit connaissez-vous vraiment déjà ? Si la réponse honnête est presque tout, le Waterfall ne vous fera pas de mal. Si la réponse est environ la moitié, des cycles courts vous feront économiser de l’argent.
On vous demande une spécification complète avant même de vous remettre un devis ? Notre guide sur les spécifications et l’estimation de projet explique ce que ce document peut et ne peut pas vous apporter, et d’où viennent les chiffres qu’il contient.
Scrum ou Kanban : les deux frameworks dont on vous parlera
L’Agile est l’idée. Scrum et Kanban sont deux manières courantes de la mettre en pratique, et la plupart du jargon que vous croiserez appartient à l’un ou à l’autre.
Scrum organise le travail en cycles fixes appelés sprints, généralement de deux semaines chacun. L’équipe s’engage sur un ensemble d’éléments au début, examine le résultat à la fin, puis recommence. Il nomme aussi quelques responsabilités, dont une personne qui porte les priorités et une personne qui veille à l’honnêteté du processus. Le Scrum Guide officiel fait environ une douzaine de pages, ce qui vous dit à quel point le framework est léger sous l’industrie qui s’est construite dessus.
Kanban abandonne le cycle fixe. Le travail est posé sur un tableau visible, se déplace de gauche à droite au fur et à mesure de son avancement, et un nouvel élément ne démarre que lorsque l’équipe a de la place pour lui. Le Kanban Guide est encore plus court. Sa règle centrale est un plafond sur le nombre de choses qui peuvent être en cours en même temps, et c’est la discipline que la plupart des équipes ont le plus de mal à tenir.
Rythme
Cycles fixes, généralement de deux semaines
Continu, un nouveau travail démarre quand de la capacité se libère
Planification
Engagée au début de chaque cycle
Reprioritée chaque fois que l’élément suivant est pris
Rôles
Définis, dont un responsable des priorités et un facilitateur
Aucun requis, chacun garde son poste actuel
Convient à
Construire un produit selon une roadmap
Support, maintenance et files de demandes imprévisibles
Indicateur principal
Ce que l’équipe termine par cycle
Le temps qu’un élément met entre la demande et la livraison
Échec fréquent
Les réunions survivent et le feedback s’arrête discrètement
Aucun plafond sur le travail en cours, donc tout se bloque en même temps
De nombreuses équipes utilisent un mélange des deux, et il n’y a rien de mal à cela. Nous avons tendance à utiliser des sprints pendant la construction d’un produit, parce qu’un rythme de deux semaines donne à chacun un moment prévisible pour regarder, décider et corriger. Pour du travail de maintenance au long cours, où les tickets arrivent quand ils arrivent, un tableau basé sur le flux correspond mieux à la réalité.
À quoi ressemble vraiment un sprint de deux semaines
Le mot sprint fait penser à une course, mais ce n’en est pas une. Un sprint est simplement une tranche de temps fixe avec un objectif convenu, et deux semaines est la durée sur laquelle la plupart des équipes s’arrêtent. Cela représente 10 jours ouvrés, qui se déroulent ainsi :
- Le jour 1 est consacré à la planification. L’équipe et la personne qui porte les priorités s’accordent sur ce qui sera livré au jour 10, et écrivent ce que signifie « terminé » pour chaque élément. Tout ce qui est trop flou pour être testé est découpé ou renvoyé.
- Les jours 1 à 10 commencent tous par un court point d’équipe. Il dure 15 minutes, et chacun répond à trois questions : ce qui a avancé hier, ce sur quoi je travaille aujourd’hui, ce qui me bloque. Ce n’est pas une réunion de reporting pour les managers, mais un moyen de faire remonter un obstacle le jour où il apparaît plutôt qu’une semaine plus tard.
- Les jours 2 à 9 sont le travail lui-même. Les développeurs et les testeurs travaillent en même temps au lieu de se succéder, si bien que rien ne compte comme terminé avant d’avoir été vérifié. Cette seule règle évite la pile de code non vérifié qui transforme le dernier mois d’un projet Waterfall en crise.
- Le jour 10 accueille deux conversations. L’équipe montre d’abord ce qui fonctionne réellement, à l’écran, avec des données réelles. Puis elle revient sur le déroulement du processus et choisit une chose à changer.
Les équipes qui sautent cette seconde conversation gardent les réunions mais cessent de progresser, et finissent par pratiquer le développement logiciel agile de nom seulement.
Ce qu'un sprint attend de votre côté
L’Agile n’est pas une façon d’acheter du logiciel sans y prêter attention. Il demande quelques heures par semaine à quelqu’un de votre côté qui peut répondre aux questions et prendre des décisions. Cette personne doit aussi assister à chaque démonstration. Donnez à une équipe un interlocuteur absent et le cycle continue de tourner pendant que le produit dérive.
Le bénéfice, c’est que rien ne reste caché longtemps. Vous voyez l’avancement toutes les deux semaines, et vous pouvez changer de direction au début de n’importe quel cycle. Un calendrier qui glisse se signale aussi assez tôt pour agir. Ce feedback devient plus net quand le travail atteint de vraies personnes, et notre article sur l’implication précoce des utilisateurs finaux détaille les moyens pratiques d’y parvenir.
Ce rythme passe à l’échelle mieux que ce que l’on imagine. Sur le projet Justin Alexander, nous avons fusionné quatre sites distincts en une seule plateforme multimarque pour une entreprise de robes de mariée qui vend via plus de 1 500 revendeurs agréés. Dix développeurs, trois chefs de projet et quatre ingénieurs QA ont travaillé à ce même rythme sur une stack Python et Django. Le site accueille aujourd’hui plus de 30 000 visiteurs par mois.
Agile et MVP : construire la plus petite version qui vous apprend quelque chose
Un MVP, ou produit minimum viable, est la plus petite version de votre idée avec laquelle de vrais utilisateurs peuvent réellement faire quelque chose. Pas un prototype, pas une présentation, mais un logiciel fonctionnel avec l’unique tâche pour laquelle il existe. Son but est de vous dire si vos hypothèses sont vraies avant que vous engagiez le reste du budget.
L’Agile et un MVP vont naturellement ensemble, parce que tous deux traitent vos suppositions comme des choses à tester plutôt que comme des faits. Construisez le cœur, mettez-le devant des utilisateurs, puis laissez leur comportement classer la suite. La plupart des listes de bénéfices du développement logiciel agile commencent au même endroit : l’argent non dépensé sur des fonctionnalités que personne n’a utilisées.
Nos services de développement de MVP livrent un lancement en 12 semaines, ce qui est assez court pour garder le périmètre honnête. Décider ce qui appartient à cette première version est la partie difficile, et c’est là que se concentre l’essentiel du débat. Notre guide sur comment construire un MVP explique comment réduire une liste de souhaits à quelque chose que vous pouvez livrer et dont vous pouvez apprendre.
Là où l'Agile atteint ses limites, et comment y remédier
L’Agile ne convient pas à tous les projets, et tout prestataire qui vous dit le contraire cherche à vous vendre quelque chose. Trois situations le rendent réellement plus difficile, et chacune a une solution de contournement raisonnable :
- Un contrat à prix fixe verrouille le périmètre. Peu importe le nom donné au processus de livraison, tout valider en amont revient à un accord Waterfall. Vous pouvez toujours travailler par cycles à l’intérieur, mais vous avez cédé la liberté de changer de direction. Quand des clients veulent les deux, nous nous accordons sur l’objectif et le budget, gardons les détails ouverts, et les revoyons ensemble toutes les quelques semaines.
- Le travail réglementé exige une piste d’audit. Un processus approximatif n’en produira pas, ce qui n’exclut pas pour autant les cycles courts. Des organismes publics pratiquent le développement logiciel agile à grande échelle, et le GAO Agile Assessment Guide existe pour aider les auditeurs fédéraux à l’évaluer. Nous avons travaillé sur Current avec la Change & Innovation Agency. C’est une application web qui traite les demandes des citoyens pour des programmes administrés par l’État, construite sur Angular, ASP.NET Core et Azure. La logique métier de Current a continué d’évoluer par cycles pendant que les obligations de documentation étaient respectées en parallèle.
- Personne de votre côté ne peut relire le travail. Une équipe sans personne à qui faire la démonstration prendra ses propres décisions, et certaines seront mauvaises. Si votre organisation ne peut pas libérer un décideur quelques heures par semaine, dites-le avant le début du projet. La réponse honnête peut être une mission plus courte, un business analyst de notre côté, ou un report jusqu’à ce que quelqu’un puisse en prendre la responsabilité.
Comment Redwerk mène ses livraisons agiles
Notre modèle par défaut est une équipe dédiée travaillant en sprints de deux semaines, avec une démonstration à laquelle vous assistez à la fin de chacun et un accès direct aux développeurs entre les deux. Les clients nous disent que la communication est ce qu’ils remarquent en premier, et c’est délibéré. Pas de résumé hebdomadaire écrit par quelqu’un qui n’était pas dans le code.
La plus grande différence est là où nous acceptons de commencer. Beaucoup des projets qui nous parviennent n’ont aucune spécification complète, et quelques-uns arrivent sous la forme d’une base de code à moitié terminée que quelqu’un d’autre a abandonnée. Ni l’un ni l’autre ne nous arrête, car un premier sprint peut tout aussi bien produire une évaluation de ce qui existe déjà qu’une tranche fonctionnelle de logiciel neuf. Notre travail de conseil en développement logiciel commence souvent exactement là, par un regard clair sur le terrain avant que quiconque s’engage sur un plan.
L’Agile fonctionne parce qu’il part du principe que vous n’aurez pas toutes les réponses le premier jour. Vingt ans de construction de produits nous ont appris à prévoir exactement cela. Un processus qui s’améliore à mesure que vous apprenez vaut mieux qu’un processus qui casse quand les exigences changent. Les cycles courts n’aident que si vous regardez le résultat et agissez sur ce que vous voyez. Pour discuter de la façon de travailler qui convient à votre prochain projet, dites-nous ce que vous construisez.
FAQ
Qu'est-ce que le développement logiciel agile ?
Le développement logiciel agile est une approche qui livre du logiciel par cycles courts, généralement d’une à quatre semaines, avec une version fonctionnelle passée en revue à la fin de chacun. Les exigences sont censées changer, donc le plan est réexaminé régulièrement au lieu d’être figé au départ. Scrum et Kanban sont les deux frameworks que les équipes utilisent le plus souvent pour le mettre en œuvre.
L'Agile est-il meilleur que le Waterfall ?
L’Agile est meilleur pour les produits dont les exigences vont changer, ce qui couvre la majorité des logiciels commerciaux aujourd’hui. Le Waterfall convient encore aux contrats à prix fixe, aux produits certifiés et aux projets liés à des dates matérielles. La question décisive est de savoir quelle part du produit vous connaissez vraiment avant de commencer. Si c’est presque tout, le Waterfall ne vous coûte rien.
Faut-il utiliser Scrum ou Kanban ?
Utilisez Scrum quand vous construisez un produit selon une roadmap et que vous voulez un rythme prévisible de deux semaines pour la planification et la revue. Utilisez Kanban pour le support, la maintenance et toute file où le travail arrive de façon imprévisible et où les priorités changent chaque jour. Beaucoup d’équipes utilisent les deux, avec des sprints sur les nouveaux développements et un tableau de flux pour les tickets entrants.
Quels sont les bénéfices du développement logiciel agile ?
Les principaux bénéfices du développement logiciel agile sont une visibilité plus précoce, des corrections de trajectoire moins coûteuses et moins d’argent dépensé sur des fonctionnalités que personne n’utilise. Vous voyez un logiciel fonctionnel toutes les quelques semaines plutôt qu’à la fin, donc une mauvaise hypothèse coûte un cycle au lieu d’un projet. Les retards apparaissent aussi tôt, quand vous avez encore de la marge pour réagir.
Peut-on démarrer sans spécification complète ?
Oui, et la plupart de nos clients le font. Une phase de découverte établit l’objectif, les utilisateurs et les contraintes, ce qui suffit pour commencer à construire sans document d’exigences finalisé. Le détail se règle cycle par cycle, à mesure que du logiciel réel remplace les suppositions. Cela demande en revanche que quelqu’un de votre côté soit disponible pour répondre aux questions chaque semaine.
Découvrez comment nous avons aidé AWE Learning à migrer de l'infrastructure sur site vers le cloud, et à atteindre des utilisateurs au-delà des États-Unis en mettant en œuvre une solution SaaS évolutive
