Quelle est la différence entre le développement itératif et incrémental ?
Dans mes cours de formation, je remarque souvent que les étudiants confondent le développement itératif et le développement incrémental (IID). L'objectif de cet article est d'expliquer la relation entre le développement incrémental et le développement itératif.
Je commencerai par une comparaison entre une approche en cascade et une approche agile, en utilisant comme exemple la livraison d'une application de paiement. Un mini-webinaire correspondant sur ces approches est également inclus. Dans la seconde partie de cet article, je positionnerai la cascade et l'agile dans une matrice montrant l'intersection du développement incrémental et itératif, en expliquant les quatre quadrants de la matrice.
Agile contre Cascade : Le développement d'une application de paiement
L'approche en cascade
Si cette application exemple est développée selon un modèle traditionnel en cascade, les étapes suivantes peuvent être observées dans la figure 1.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Figure 1 : Ce schéma montre un cycle de vie typique en cascade, utilisant l'exemple de la livraison d'une application.
Lancement du projet
Tout commence avec un commanditaire du projet issu du département marketing, qui a pu débloquer les fonds nécessaires à cette application. Il partait du principe que l'application améliorerait la fidélisation des clients et l'acquisition de nouveaux clients. Il avait imaginé trois grands groupes de fonctions.
Une fois le projet approuvé, un chef de projet est désigné et une équipe projet est constituée. Après de nombreuses discussions et des ateliers de collecte des besoins, il a été convenu de livrer une application de paiement avec 250 fonctionnalités. Toutes ces fonctionnalités sont consignées dans un document de spécifications logicielles très détaillé et signé par le commanditaire du projet et le représentant du client (ainsi que les autres parties prenantes clés).
Phase de conception du projet
À l'étape suivante, l'équipe projet traduit les besoins en un design pour l'application. L'architecte vérifie le design par rapport aux principes de conception. Il s'assure que tous les attributs de données requis sont également disponibles dans le système backend.
Nous en sommes maintenant à deux mois d’avancement et le client n’a encore rien vu fonctionner, seulement quelques rapports d’avancement. Et ces rapports d’avancement impliquent probablement une certaine forme de rapport « pastèque », laissant le client dans l’incertitude quant au bon déroulement ou non du projet.
Phase de développement du projet
Le développement de l'application prend six mois et, une fois terminé, on demande au représentant du client de fournir des personnes pour réaliser un test d'acceptation utilisateur. Lors de ce test, il devient évident que plusieurs fonctionnalités ne fonctionnent pas.
L'équipe projet ne comprend pas pourquoi. C'est exactement ce qui était décrit dans le cahier des charges. Cela mène à de nombreuses discussions, des reprises et des retards, et les clients ne sont pas satisfaits du résultat. De plus, si l'on regarde le résultat final, on se rendra compte que nombre des exigences développées ne sont pas ou rarement utilisées par le client.
La situation pourrait être pire. Supposons que le développement de l’application ait pris 1,5 an et qu’une autre banque lance une application de paiement alors que vous êtes à mi-chemin. Que feriez-vous à ce moment-là ? Auriez-vous encore un business case valable pour poursuivre et terminer votre propre application ?
En regardant la figure 1, il apparaît clairement qu’avec une approche en cascade, la portée et les critères de qualité sous-jacents sont figés pour une livraison unique. Toutes les étapes sont réalisées une seule fois pour l’ensemble du projet et le pilotage est axé sur le coût et le temps. La valeur n’est délivrée au client qu’à l’issue du déploiement de l’application complète.
L'approche Agile
Si nous développons l’application selon une approche de gestion de projet agile, nous observons le schéma suivant :
- L’équipe de développement affirme être capable de livrer les deux premières fonctionnalités priorisées par le product owner lors de la première itération.
- L’équipe projet livre toutes les trois semaines (sprint, itération ou timebox) un incrément du produit.
- Après les premières livraisons ou incréments, on observe un client qui a confiance dans la réussite du projet. Il dispose déjà d’une application fonctionnelle et comprend qu’elle n’a pas encore toutes les fonctionnalités prévues, mais les fonctions disponibles fonctionnent.
En observant la dernière livraison et les fonctionnalités fournies, le client mentionne une toute nouvelle fonctionnalité. Une fonctionnalité à laquelle personne n’avait pensé au début du projet, mais qui pourrait rendre la vie du client plus productive.
Après chaque incrément, les retours clients aboutissent à de nouvelles capacités fonctionnelles (qui n’étaient pas sur la liste initiale) ou à des ajustements de fonctionnalités potentielles. Le produit devient de plus en plus mature. À chaque incrément, le client reçoit une nouvelle version et en est plus satisfait.
Figure 2 : Le diagramme montre le cycle de développement agile, avec le même exemple de la livraison d'une application.
Si nous regardons la figure 2, nous observons un flux de livraison régulier dans une durée fixe et en utilisant des équipes agiles permanentes (ce sont des coûts fixes). Le périmètre et les critères de qualité sous-jacents sont flexibles (dynamiques) avec de petites livraisons fréquentes (ce sont les incréments).
Toutes les étapes destinées à livrer une fonctionnalité ou une user story sont effectuées de manière répétée (ce qui la rend itérative) jusqu'à ce que la qualité requise soit atteinte. Le contrôle de gestion se concentre sur la livraison de valeur au client. La livraison de valeur au client intervient après chaque déploiement d'un incrément.
Cascade vs Agile : Résultats de Livraison
Si l'on regarde de plus près les deux produits issus à la fois de l'approche en cascade et de l'approche de développement logiciel agile, on observe un produit avec 250 fonctionnalités et un client peu satisfait, et un produit avec seulement 150 fonctionnalités et un client très satisfait (voir figure 3).
Figure 3 : Ce diagramme compare les différences de temps, de nombre de fonctionnalités et de satisfaction client entre les approches cascade et agile.
Et si l'on regarde encore plus en détail le produit livré par l'approche agile, on ne voit qu'un sous-ensemble de 100 fonctionnalités issues de la liste originale et 50 fonctionnalités nouvelles ou modifiées. Cela correspond à quelques principes importants du Manifeste Agile, notamment :
- La simplicité, c'est-à-dire l'art de maximiser la quantité de travail non effectué : seulement 150 fonctionnalités au lieu de 250
- Accueillir des exigences changeantes, même tard dans le développement : s'adapter aux retours des clients après chaque itération et chaque incrément
Les processus agiles de développement exploitent le changement pour l’avantage concurrentiel du client (50 fonctionnalités nouvelles ou modifiées ont été livrées). Et, par conséquent, le client est très satisfait. La priorité la plus haute de l’équipe est de satisfaire le client grâce à la livraison précoce et continue de systèmes logiciels à forte valeur.
Mini-webinaire : Livraison Cascade vs Agile
Voici un bref webinaire expliquant davantage les différences entre la livraison cascade et agile.
Différences entre développement itératif et incrémental
Maintenant que j'ai exposé les différences entre une approche en cascade et une approche agile à l’aide de l’exemple de la création d’une application de paiement, je vais positionner cascade et agile dans une matrice comparant le développement itératif et incrémental.
Comme dernière étape, je vais développer sur le produit minimum viable (MVP) et le produit minimum commercialisable (MMP) et montrer où ceux-ci s’intègrent dans les différentes approches et une story map. J’ai également inclus un mini-webinaire correspondant.
Matrice du Développement Itératif et Incrémental
Comme mentionné, j’ai constaté que les étudiants confondent souvent itératif et incrémental. Dans la figure 4, on trouve quatre cadrans, issus d’une ligne horizontale représentant l’incrémental ou non et d’une ligne verticale croisée représentant l’itératif ou non. Consultez cette vidéo YouTube pour une version très simple de cette figure.
Figure 4 : Cette matrice présente différentes approches de développement et si les membres d’équipe qui suivent ces approches doivent itérer et/ou travailler par incréments.
Cadran inférieur gauche
Dans le coin inférieur gauche, on observe l’approche sans itérations ni incréments. Il s’agit de l’approche en cascade. Toutes les activités (conception, analyse, construction, test et déploiement) sont réalisées une seule fois pour l’ensemble du projet.
Dans ce cas, on voit une seule livraison du produit final basée sur un périmètre fixe. La valeur client ne peut être atteinte qu’après la livraison du produit final. L’un des objectifs clés de cette approche est la maîtrise des coûts.
Cadran inférieur droit
Dans le quadrant inférieur droit, nous voyons une approche incrémentale sans itérations. Il s'agit d'une livraison par étapes ou incrémentielle de petites parties du produit. Toutes les activités d'une étape donnée (conception, analyse, construction, test et déploiement) sont réalisées une seule fois.
Pour une étape donnée, le périmètre est fixe, mais le produit final est basé sur un périmètre plus dynamique ou flexible. La valeur client peut être obtenue après chaque livraison du produit. L'un des principaux objectifs de cette approche est la rapidité de la livraison.
Quadrant supérieur gauche
Dans le quadrant supérieur gauche, nous observons une approche en spirale ou itérative sans incréments. C'est une livraison unique où le produit final est créé au travers de plusieurs itérations. Un bon exemple de cette approche est le design thinking. Dans le graphique, vous voyez une séquence d'activités : cadrage, analyse, génération d'idées, réalisation et réflexion.
Cette séquence sera exécutée de manière répétée ou itérative, à chaque itération vous rapprochant du produit final, correct ou requis. Dans de nombreux cas, ce produit final est un prototype ou un modèle. Dans cette approche en spirale, nous avons un périmètre dynamique ou flexible. La valeur client ne peut être obtenue qu'après la livraison du produit final. L'un des objectifs clés de cette approche est l'exactitude de la solution.
Quadrant supérieur droit
Dans le quadrant supérieur droit, nous retrouvons l'approche agile qui combine incréments et méthode itérative. Scrum en est un bon exemple.
À la fin de chaque incrément, souvent appelé sprint ou timebox, une partie du produit est livrée. Cet incrément est le résultat de nombreuses itérations pour développer de petites parties correctes, souvent nommées user stories ou éléments du backlog, du produit. Le projet itératif final sera livré morceau par morceau.
Dans cette approche agile, nous avons un périmètre dynamique ou flexible. La valeur client peut être obtenue après chaque livraison du produit. Un des objectifs principaux de cette approche est d'apporter de la valeur au client via des livraisons fréquentes et des retours utilisateurs.
MVP ou MMP ?
Sur la figure 4, vous trouverez aussi les acronymes MVP et MMP. MVP signifie produit minimum viable (Minimum Viable Product) et désigne une version d’un nouveau produit ou service qui permet à une équipe d'obtenir un maximum d'apprentissage sur ses clients et de valider ses hypothèses avec le moindre effort. Le MVP du service Dropbox était un simple film. Cela signifie que le P de MVP pourrait être un produit totalement différent de celui qui sera le produit final.
Un exemple illustrant MVP et MMP
J’utilise souvent l’exemple suivant d’un nouveau produit financier. Un responsable commercial enthousiaste a une idée géniale concernant un nouveau produit financier. Il pense qu'ils peuvent en vendre au moins 100 000.
Avec quelques experts financiers, ils conçoivent le produit en quelques mois. Une équipe de développement est affectée et il leur faut 4 mois pour développer le produit. Parallèlement, des brochures commerciales sont créées et le produit est lancé lors d’un grand événement.
Malheureusement, seules quelques personnes achètent le produit. Si nous suivons l’approche MVP, nous pourrions supposer que 10 % des utilisateurs web sont intéressés par ce produit. Nous développerions alors un MVP pour tester cette hypothèse.
Dans ce cas, le MVP pourrait être un simple bouton sur la page d’accueil. Si vous cliquez dessus, vous voyez un écran avec un message concernant ce nouveau produit et la possibilité d’ajouter votre adresse email si vous êtes intéressé. Supposons que moins de 1 % des visiteurs aient cliqué sur le bouton : le produit ne serait pas développé et l'entreprise économiserait beaucoup de ressources précieuses.
Si l’on regarde de plus près la figure 4, on voit l’utilisation potentielle des MVP dans tous les quadrants. En utilisant une approche en cascade, vous pourriez créer un MVP dans la première phase de conception logicielle afin de vérifier s’il existe une justification commerciale au projet.
Il en va de même pour la première phase du premier incrément dans le cadre d’une livraison par étapes. Dans certains cas, le résultat de votre approche de design thinking pourrait être un MVP. Le MVP peut également être bénéfique au début d'une approche agile.
Beaucoup de personnes considèrent que le premier produit livré à la fin de votre livraison par étapes est le MVP. Cela peut être le cas, mais dans la plupart des cas, il ne s'agit pas d'un MVP mais d'un MMP. MMP, ou minimum marketable product, est le plus petit produit qui peut apporter de la valeur à votre client.
À quoi ressemble la livraison agile ?
Maintenant qu'il est clair que les modèles incrémentaux et itératifs ne sont pas identiques et que nous comprenons l'utilisation de MVP et de MMP, nous pouvons explorer plus en détail l'apparence d'une livraison incrémentale et itérative.
Vous avez probablement déjà vu le célèbre exemple de Jeff Patton de la Joconde où la peinture est créée morceau par morceau (livraison par étapes). Une autre façon de faire est de commencer par le premier incrément dans lequel seul un croquis grossier est réalisé, puis d’ajouter plus de détails à chaque nouvelle itération, jusqu’à obtenir finalement la peinture finale (livraison incrémentale et itérative ou agile).
Dans la première situation, vous devez déjà avoir une idée précise du produit final et dans la seconde, il vous suffit d’un aperçu général, car il est beaucoup plus facile d’apporter des modifications. Si nous regardons la figure 5, nous voyons une story map pour un nouveau produit appelé ABC.
Figure 5 : Un exemple de story map pour un produit spécifique.
Le product owner a imaginé sept fonctionnalités pour ce produit. Les quatre premières fonctionnalités sont indispensables. Les fonctionnalités 5 et 6 sont des "devrait avoir" et la dernière fonctionnalité est un "pourrait avoir". Beaucoup appellent cela la priorisation MoSCoW (must-haves, should-haves, could-haves et won’t-haves).
Chaque fonctionnalité peut à son tour être découpée en parties plus petites. Dans la figure, vous voyez des fonctionnalités ou des user stories avec les statuts must, should et could have. Une fonctionnalité peut être indispensable, mais cela ne signifie pas que toutes les user stories sous-jacentes le sont aussi. Ou une fonctionnalité peut être un "devrait avoir" mais, si vous implémentez cette fonctionnalité, certaines user stories sont indispensables et d'autres sont des "devrait" ou "pourrait avoir".
Pour mettre en œuvre ce produit ABC, vous voyez cinq incréments ou versions. La première est le produit minimum commercialisable. Ce MMP se compose des deux premières user stories indispensables de la fonctionnalité 1, et de la première user story indispensable des fonctionnalités 2 et 3.
La deuxième version contient les deux user stories indispensables suivantes des fonctionnalités 1, 2 et 3 (développement itératif). Le développement du produit se poursuit en implémentant les versions suivantes. À chaque version, la valeur pour le client augmente.
Après la cinquième version, le product owner arrête l’implémentation des user stories. Les retours du client lui ont montré que le produit ABC est « adapté à l’usage » et il applique le principe de simplicité du manifeste Agile en arrêtant tout développement supplémentaire.
Mini-webinaire : Développement itératif et incrémental
Voici un webinaire approfondi sur le développement logiciel itératif et incrémental.
Réflexions finales
Votre équipe de développement logiciel maîtrise-t-elle la différence entre développement itératif et incrémental ? Comment l’appliquez-vous dans vos méthodologies agiles ou en cascade ?
Dites-le-nous dans les commentaires, ou rejoignez notre programme d’adhésion DPM et discutez-en avec d’autres membres sur notre forum exclusif !
