Si vous avez lu mes billets sur le Cycle en cascade et le Cycle en V, vous savez pourquoi ces méthodes de travail ne sont pas adaptées à la plupart des projets informatiques, qui réclament une plus grande souplesse. En les appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.
Définition
Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :
- L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
- Le coeur du processus itératif :
- Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
- Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
- Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
- Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
- Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.
Mise en oeuvre
Une part importante du travail n’est pas forcément évidente : l’étape de spécification sert à décider quelles sont les fonctionnalités qui vont être implémentées, mais surtout celles qui ne vont pas l’être. L’intérêt du cycle itératif est justement de se concentrer sur l’essentiel, puis de raffiner à chaque « tour de boucle ». Si vous pouvez analyser précisément les besoins, pour en dégager le découpage des 2 ou 3 cycles itératifs (quelles seront les fonctionnalités à implémenter durant chaque cycle), cela veut dire que vous êtes capable d’implémenter et de livrer rapidement les grandes lignes du projet.
En plus de cela, l’étape d’évaluation vous permet de reprendre la main sur le projet. Une fonctionnalité soumise à débat ou un développement trop laborieux a été laissé de côté pendant le développement ? Un module a été désactivé parce que la validation a montré qu’il était buggué ? Ce n’est pas un problème fondamental. L’évaluation va vous permettre de reprendre ces éléments et de comprendre ce qui vous a empêché d’aller jusqu’au bout ; puis vous les réintégrerez dans l’étape suivante de spécification.
Et ainsi de suite jusqu’à ce que le produit corresponde aux besoins exprimés par le client et qu’il soit exempt de bug.
Mon expérience
La mise en place de cette méthode de travail est souvent satisfaisante. Que ce soit dans de petites équipes ou de plus grosses structures, elle permet d’obtenir un fonctionnement quasi-optimal, là où l’utilisation de méthodes de gestion de projet plus classiques (plus ou moins dérivées du Cycle en V, souvent de manière inconsciente) ne générait que retards, frustrations et énervements.
Je vous parlerai bientôt des « méthodes agiles », qui sont à la mode depuis quelques années. J’ai tendance à considérer les méthodes agiles comme les enfants directs du cycle itératif : elles mettent l’accent sur la satisfaction du client, la réactivité de l’équipe et les livraisons fréquentes de nouvelles versions du produit dans le but de l’améliorer rapidement.
Tous ces buts peuvent être atteints en mettant en place une méthode itérative plus classique, telle que présentée ici. C’est d’ailleurs ce que je conseille aux équipes qui rencontrent une difficulté lorsqu’elles tentent d’utiliser une méthode agile : de nombreux freins peuvent apparaître, souvent du fait de personnes qui ont du mal à se faire à ce genre d’organisation (sans qu’il s’agisse de mauvaise volonté pour autant). Dans ce cas, l’emploi du cycle itératif aura souvent les mêmes avantages, tout en offrant un cadre plus classique et mieux accepté.
Quel outil pour gérer ses projets de manière itérative ?
Pour gérer vos projets de manière itérative, vous pouvez utiliser des logiciels basés sur des tâches. Pour ma part, je vous conseille évidemment de vous intéresser à Skriv, le logiciel que j’ai développé. Il s’adapte à votre manière de faire, qu’il s’agisse de votre process ou de votre terminologie ; il fait tout pour être transparent, sa prise en main se fait facilement.
Profitez de la période d’essai gratuit de 30 jours pour vous faire une idée.
attention, incrémental et itératif ce n’est pas la même chose.
incrémental: projet qui évolue, auquel on ajoute des fonctionnalités petit à petit (add onto)
itératif: plusieus itérations successives, produit qui grandit par ajout de fonctionnalités finies. (re-do). On ajoute brique par brique, mais chaque brique doit être complète avant l’ajout
C’est une distinction purement théorique. En pratique, on utilise le cycle itératif/incrémental (je persiste à ne pas faire de distinction) pour faire avancer les projets petit à petit, en s’assurant constamment que l’on colle au plus près aux besoins du client.
Après, les discussions concernant la taille que chaque « brique » doit avoir avant d’être inclue dans une itération sont à se poser à chaque itération. C’est ce qui va justement déterminer si on fait une petite ou une grande incrémentation.
À la base, « incrémental » veut dire qu’on ajoute des choses, qu’on fait avancer le projet. Alors que « itératif » signifie qu’on va effectuer plusieurs passes.
Mais qu’il s’agisse d’ajouter des fonctionnalités supplémentaires, ou d’améliorer celles déjà présentes, chaque itération va bien servir à faire avancer le projet.
Bonjour,
Comment peut-on schématiser un planning sur ce type de cycle ?
Merci
C’est effectivement très compliqué. Le but étant de développer les bonnes fonctionnalités (celles dont a vraiment besoin le client) de la bonne manière (qui satisfasse le client), il est quasi-impossible de prédire à l’avance le périmètre fonctionnel qui sera développé à un instant donné. Car à chaque itération, on met de côté les développements qui sont mal spécifiés ou qui n’ont pas prouvé leur utilité pour le client, quitte à les réintégrer lors d’une itération future.
Il faut donc que le client (qu’il soit interne ou externe) soit prêt à jouer le jeu, à perdre en visibilité sur le futur en échange d’une promesse de plus grande satisfaction.