Concept: Démontrer la valeur des itérations
Ce principe démontre la valeur d'un développement itératif.
Description principale

Introduction

Ce principe explique pourquoi le développement itératif d'un logiciel est très avantageux. Un processus itératif facilite la gestion des changements, permet d'obtenir un retour d'informations et de s'en servir au sein du projet afin de réduire les risques au plus tôt et d'ajuster le processus de manière dynamique.

        
Avantages
  • Réduction précoce des risques
  • Prévisibilité accrue tout au long du projet
  • Confiance parmi les parties prenantes
Pattern
  1. Permettre un retour d'informations en fournissant des valeurs utilisateur incrémentielles dans chaque itération.
  2. Adapter vos plans à l'aide d'un processus itératif
  3. Prendre en compte et gérer les changements
  4. Traiter de manière précoce les risques liés à la programmation, les risques métier et techniques majeurs
Anti-Patterns
  • Planifier de manière détaillée l'ensemble du cycle de vie, faire le suivi des écarts par rapport au plan (peut en fait aboutir à l'échec du projet).
  • Evaluer l'état du projet au cours de ses deux premiers tiers en se fondant sur l'examen de spécifications plutôt que sur des résultats de tests et des démonstrations de fonctionnement du logiciel.

Discussion  

Plusieurs impératifs sons sous-jacents à ce principe. Le premier impératif consiste à  fournir une valeur incrémentielle afin de permettre un retour précoce et continu des informations. La division du projet en un ensemble d'itérations peut permettre d'atteindre cet objectif. Dans chaque itération, l'application est soumise à des exigences, conçue, implémentée et testée, ce qui aboutit à un livrable se rapprochant de la solution finale. Cela permet de montrer l'application aux utilisateurs finals et à d'autres parties prenantes, ou de les faire directement utiliser l'application afin d'obtenir un retour d'informations rapide sur la qualité du travail. Sommes-nous dans la bonne direction ? Les parties prenantes sont-elles satisfaites du travail réalisé jusqu'à maintenant ? Devons-vous changer les fonctions implémentées jusqu'ici ? Enfin, quelles fonctions supplémentaires doivent être implémentées pour ajouter une valeur métier ? En répondant de manière satisfaisante à ces questions, il est plus facile d'établir un climat de confiance entre les parties prenantes dont le système en cours de développement est censé satisfaire les besoins. Il est également moins probable que l'approche du projet souffre d'une surenchère technique ou d'une volonté d'ajouter des fonctionnalités qui ne sont pas utiles pour l'utilisateur final.

Le deuxième impératif consiste à tirer profit des démonstrations et des retours d'informations afin d'ajuster les plans. Plutôt que de se fonder sur l'évaluation de spécifications, comme les spécifications d'exigences, les modèles de conception ou les plans, il est nécessaire d'évaluer la manière dont le code développé jusqu'ici se comporte réellement. Cela signifie qu'il faut utiliser les résultats de test et les démonstrations de fonctionnement de code faites aux parties prenantes pour déterminer la qualité du travail effectué jusqu'ici. Cela permet de bien appréhender l'avancement du travail, la vitesse de progression de l'équipe et la nécessité d'effectuer des corrections de trajectoire pour terminer le projet avec succès. Ces informations peuvent ensuite être utilisées pour mettre à jour l'ensemble du plan pour le projet et pour développer de nouveaux plans détaillés pour la prochaine itération.

Le troisième impératif sous-jacent consiste à prendre en compte et gérer les changements. Aujourd'hui, les applications sont trop complexes pour que les exigences, la conception, l'implémentation et les tests soient parfaitement alignés dès la première fois. Les méthodes de développement d'application les plus efficaces prennent donc en compte le caractère inévitable des changements. Grâce à un retour d'informations précoce et continu, il est possible de savoir comment améliorer l'application et l'approche itérative offre la possibilité d'implémenter ces changements de manière incrémentielle. Tous ces changements doivent être gérés avec les processus et les outils en place pour une gestion efficace qui ne nuise pas à la créativité.

Le quatrième impératif sous-jacent est la nécessité de traiter les risques clés tôt dans le cycle de vie, comme illustré dans le diagramme ci-dessous. Il est nécessaire de traiter les risques liés à la programmation, les risques métier et techniques le plus tôt possible, au lieu de les traiter à la fin du projet. Une évaluation continue des risques et le traitement des risques majeurs restants lors de la prochaine itération peuvent permettre de répondre à cet impératif. Les projets qui réussissent se caractérisent par des itérations précoces et l'implication des parties prenantes su r des exigences de haut niveau, y compris en ce qui concerne la conception architecturale, l'implémentation et le test afin de limiter les risques techniques. Il est également important de conserver les informations requises pour savoir quelle décision prendre en ce qui concerne les actifs réutilisables majeurs ou les logiciels commerciaux (COTS) à utiliser.

Diagramme illustrant qu'un processus itératif peut réduire rapidement les risques contrairement à un processus en cascade

Profils de réduction des risques pour des développements en cascade et itératifs.

L'objectif majeur d'un développement itératif est de réduire les risques de manière précoce. Cela est possible et analysant, en hiérarchisant et en traitant les risques majeurs à chaque itération (voir : Matériel de support : Développement itératif).  Vous trouverez des instructions supplémentaires sur la manière d'organiser le cycle de vie du développement avec des itérations dans  Concept : itération  Concept : phase.