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
|
-
Permettre un retour d'informations en fournissant des valeurs utilisateur
incrémentielles dans chaque itération.
-
Adapter vos plans à l'aide d'un processus itératif
-
Prendre en compte et gérer les changements
-
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.
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.
|