Développement itératif incrémental

19 avril 2016,
par Romy Têtue

Mots-clefs associés à cet article :

Pour expliquer la différence entre développement incrémental et itératif, l’agiliste américain Jeff Patton a utilisé la peinture de la Joconde, dans cet article fameux de 2008 : Don’t Know What I Want, But I Know How to Get It. Inspirante, sa « Mona Lisa Agile » fait depuis le tour du monde, complétée par d’autres, pour mieux refléter les pratiques.

Développement incrémental (waterfall)

Le développement incrémental, typique de l’approche waterfall (cycle en V), s’appuie sur une idée initiale complètement formée, que l’on construit ensuite morceau par morceau, jusqu’à une livraison finale, complète. L’inconvénient est qu’il faut attendre longtemps avant de voir le résultat final.

Le développement incrémental peut, sous prétexte d’agilité, conduire à un résultat dysfonctionnel, comme l’illustre l’UX designer Charles Lambdin : des morceaux sont livrés successivement, mais sans cohérence d’ensemble. C’est ce qui se passe lorsque les méthodes agiles ne sont pas comprises.

Développement itératif

Le développement itératif, introduit par les méthodes agiles, part d’une idée grossière, qui est affinée par retouches successives, chacune améliorant la qualité. Dès le début, l’effort porte sur l’ensemble, au risque de ne jamais complètement finir.

Dans un processus agile, l’on ne sait pas à l’avance quel sera le résultat final, et c’est ce qui fait sa force : cela permet d’innover constamment. Mais comme l’idée de départ est imprécise, le risque est d’aboutir à tout autre chose, genre Bob l’éponge au lieu d’une Joconde, comme l’illustre l’UX designer néerlandais Joost Verweij dans Agile, design en de Mona Lisa, Joost Verweij (2015).

Si bien que souvent, seules les premières étapes, de conception, sont itératives, ensuite suivies d’un développement incrémental classique plus sécurisant, mais qui ne laisse plus de place à l’innovation, au risque de ne pas répondre correctement aux besoins qui évoluent entre temps.

Développement itératif incrémental

En pratique, les équipes agiles combinent les deux, comme l’explique Steven Thomas, dans Revisiting the Iterative Incremental Mona Lisa (2012) :

Il s’agit de partir d’une idée, d’abord précisée itérativement, ensuite partiellement développée en un incrément fonctionnel, potentiellement livrable tel quel. Chaque incrément suivant étant susceptible d’affiner les fonctionnalités existantes, est également itératif. Cette approche combinée est beaucoup plus puissante.

Vos commentaires

  • Le 12 juillet 2016 à 11:51, par Stéphane En réponse à : Développement itératif incrémental

    Merci pour cette synthèse. On dit que l’agilité est itérative, incrémentale et adaptative, comment représenteriez-vous ce dernier aspect avec la métaphore de la Joconde ?

    Cordialement,

  • Le 21 février à 20:47, par Pierre En réponse à : Développement itératif incrémental

    Bonjour,
    J’ai bossé pendant plusieurs années dans une boite de dev internet et on ne travaillait qu’en incrémental. A titre indictaif, on mesurait nos temps de développement à la minute prés et on tenait toujours les délais. Les exemples données ici ne sont malheureusement pas assez représentatifs de ce que c’est. Tu écris « Dans un processus agile, l’on ne sait pas à l’avance quel sera le résultat final, et c’est ce qui fait sa force : cela permet d’innover constamment ». Justement, non. Et c’est bien là le problème. Au lieu de prendre l’exemple de Mona Lisa, prenons l’exemple de la peinture d’une piéce. En itératif, tu vas poncer le mur 1, puis mettre la couche de préparation du mur 1, puis la première couche de couleur du mur 1, la seconde couche puis la dernière. Tout content, tu vas pouvoir montrer le mur 1 tout fini. Tu vas ensuite faire pareil pour le mur 2, puis le 3 et enfin le 4. C’est quand tu vas mettre la couleur sur le 4, qui a une porte donnant sur une autre piéce que tu vas te rendre compte que le choix de couleur est pas bon. Et tu vas avoir tout à refaire. En incrémental, on va poncer les 4 murs, puis on va mettre la couche de préparation sur les 4 etc... On se repose donc sur des choses pas finies, facile à modifier.
    Un autre exemple typique : la création d’un PPT. En Itératif tu vas faire la diapo 1 avec le titre, la mise en place du titre, choix de la fonte, image, texte etc... Imagine que le titre soit « Création ». C’est court donc tu vas écrire en fonte 50. Tu fais donc toute ta diapo 1 puis tu passes à la 2 (seconde itération). Le titre de la diapo 2 c’est « Gestion » donc tout content tu remets en fonte 50. Bien évidement, Loi de l’Emmerdement Maximum, c’est quand tu vas arriver à la diapo 20 que le titre sera « Construction des schémas en fonction des données principales ».... Et là, pour ton titre en corps 50, t’es bien coincé. En incrémental, tu vas « jeter » rapidement les titres sur toutes les diapo. Puis tu vas choisir la fonte pour toutes les diapos, puis la taille du corps pour toute.
    S’il faut modifier la dispo précédente, tu le feras car elle ne sera pas terminée.
    En fait, l’incrémental évite un GROS problème : un dév informatique, ça évolue comme la course sur la plage, vers la mer. Au départ, tu cours lentement car t’es dans le sable sec. Puis tu accélères quand tu arrives sur le sable humide et là, ça fonce ! Puis tu entres dans l’eau et plus tu avances, plus tu vas lentement. Cela vient du fait que la mise en page de la diapo 1 de ton PPT ne dépend de rien. Mais que la mise en page de la diapo 2 dépend de la mise en page de la 1. La 3 dépend de la 2 qui dépend de la 1 etc... En fait, plus tu avances, plus tu « pédales dans la choucroute ». Même un diagramme de Gantt ne t’aidera pas car le diagramme de Gantt se base sur l’idée que la conception de la diapo 1 dure le même temps que la diapo 20. Or, si en incrémental c’est effectivement le cas, cela ne l’est pas en itératif.
    C’est ça qui explique qu’il y a beaucoup de développement qui sont commencés mais peu qui sont terminés. Et pout ceux qui sont terminés, les délais sont rarements tenus, du fait que l’estimation de temps se base sur le postulat qu’un bout de code prendra le même temps de développement au début ou à la fin du projet, alors que ce n’est pas vrai.
    Cordialement
    PL

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom