Un projet utilisant un développement itératif a un cycle de vie comportant plusieurs itérations. Une itération comporte
une série plus ou moins consécutive de tâches de modélisation métier, d'exigences, d'analyse et de conception,
d'implémentation, de test et de déploiement, dans des proportions diverses selon le stade du cycle de développement où
se situe l'itération. Les itérations des phases de création et d'élaboration mettent l'accent sur les activités de
gestion, d'exigences et de conception ; les itérations de la phase de construction se focalisent sur la conception,
l'implémentation et le test ; et les itérations de la phase de transition s'intéressent plus particulièrement au test
et au déploiement. Les itérations doivent être gérées de façon jalonnée, ce qui signifie que le planning d'une itération doit être considéré
comme fixe, et que la portée du contenu de l'itération doit être gérée de façon active pour respecter ce planning.
Il est probable que la conception initiale soit imparfaite par rapport à l'une de ses exigences clé. Une découverte
tardive d'anomalies de conception entraîne des dépassements coûteux, et dans certains cas, peut avoir pour effet
l'annulation du projet.
Tous les projets possèdent une série de risques. Plus vous vous assurerez tôt que vous avez évité un risque, plus vos
plans pourront être exacts. De nombreux risques ne sont même pas découverts avant que vous ne tentiez d'intégrer le
système. Vous ne pouvez jamais prévoir tous les risques, quelle que soit l'expérience de l'équipe de développement.
Dans un cycle en cascade, vous ne pouvez pas vérifier que vous avez évité un risque avant un stade avancé du cycle de
vie.
Dans un cycle de vie itératif, vous sélectionnez l'incrémentation à développer dans une itération basée sur une liste
de risques clé. Dans la mesure où l'itération produit un exécutable testé, vous pouvez vérifier si vous avez limité les
risques ciblés ou non.
Une approche itérative est généralement supérieure à une approche linéaire ou en cascade pour de nombreuses raisons
distinctes.
-
Les risques sont limités plus tôt, car les éléments sont intégrés de façon progressive.
-
Le changement des exigences et des tactiques est accepté.
-
L'amélioration et le perfectionnement du produit est facilité, ce qui amène un produit plus solide.
-
Les organisations peuvent apprendre de cette approche et améliorer leurs processus.
-
Le potentiel de réutilisation est accru.
Voici l'opinion d'un client : "Avec l'approche en cascade, tout semble aller très bien jusqu'à ce que le projet soit
presque terminé, parfois jusqu'au milieu de l'intégration. Puis tout s'écroule. Avec l'approche itérative, il est
difficile de cacher la vérité très longtemps."
Les chefs de projet sont souvent réfractaires à l'approche itérative, la considérant comme un piratage constant. Dans
le Rational Unified Process, l'approche itérative est très contrôlée, les itérations sont programmées selon leur
nombre, leur durée et leur objectif. Les tâches et les responsabilités des participants sont définies. Des mesures
objectives de progression sont consignées. Il est nécessaire d'effectuer des retouches d'une itération à une autre,
mais ce travail est également minutieusement contrôlé.
Une approche itérative vous permet de limiter les risques plus tôt, car de nombreux risques sont seulement découverts
et traités pendant l'intégration. Lorsque vous progressez dans l'itération de départ, vous passez par toutes les
disciplines, en utilisant de nombreux aspects du projet : outils, logiciels standards, compétences des salariés, etc.
Les risques perçus peuvent ne pas se produire, et de nouveaux risques imprévus apparaîtront.
L'intégration n'est pas un soudaine, les éléments finaux sont incorporés de façon progressive. En réalité, l'approche
itérative est une intégration presque continue. La tâche qui auparavant était longue, incertaine et difficile, prenait
jusqu'à 40% du temps d'effort d'un projet ; et était difficile à prévoir de façon correcte, est à présent divisée en
six à neuf intégrations plus petites devant intégrer bien moins d'éléments.
L'approche itérative vous permet de prendre en compte les exigences changeantes qui évolueront pendant le
projet.
Les changements d'exigences ont toujours été d'importantes sources de problèmes pour un projet, entraînant des
retards de livraisons, des délais manqués, des clients mécontents et des développeurs frustrés. Il y a vingt-cinq ans,
Fred Brooks a écrit : "Prévoyez d'en jeter un, vous devrez le faire de toutes façons.". Les utilisateurs changeront
d'avis pendant le projet. Il s'agit de la nature humaine. Forcer les utilisateurs à accepter le système comme ils l'ont
imaginé à l'origine est une mauvaise idée. Ils changent d'avis parce que le contexte change - ils obtiennent plus
d'informations sur l'environnement et la technologie, et ils voient une démonstration intermédiaire du produit pendant
son développement.
Un cycle de vie itératif permet aux responsables d'effectuer des changements tactiques sur le produit. Par exemple,
pour gérer la concurrence avec des produits existants, vous pouvez décider de sortir plus tôt un produit avec des
fonctions limitées afin de contrer l'action d'un concurrent ou vous pouvez choisir un autre fournisseur pour une
technologie donnée.
L'itération permet aussi d'effectuer des changements technologiques pendant le projet. Si une technologie change ou
devient standard lors de l'arrivée d'une nouvelle technologie, le projet peut en profiter. C'est le cas en particulier
des changements de plate-formes et des changements d'infrastructure de plus bas niveau.
Une approche itérative donne lieu à une architecture plus solide car les erreurs sont corrigées sur plusieurs
itérations. Les premières anomalies sont détectées au fur et à mesure de la maturation du produit pendant les premières
itérations. Les goulots d'étranglement en terme de performance sont découverts et peuvent être réduits, plutôt que
d'être découverts la veille de la livraison.
Si l'on adopte un développement itératif, plutôt que d'exécuter des tests une fois à la fin du projet, on obtient un
produit testé plus en profondeur. Les fonctions primordiales ont pu être testées sur plusieurs itérations, et les tests
eux-mêmes, et tout logiciel de test, ont eu le temps d'arriver à maturité.
Les développeurs peuvent apprendre au cours du projet, et les différentes compétences et spécialités sont employées de
manière plus complètes pendant la totalité du cycle de vie.
Plutôt que de passer longtemps à se contenter d'élaborer des plans et de peaufiner les compétences, les testeurs
commencent à tester tôt, la rédaction technique commence tôt, etc. Les besoins de formations supplémentaires ou d'aide
externe peuvent être détectés lors des premières revues d'évaluation d'itération.
Le processus lui-même peut être amélioré et précisé lors de son développement. L'évaluation à la fin d'une itération
n'examine pas seulement le statut du projet du point de vue du planning du produit, mais analyse également ce qui doit
être modifié dans l'organisation et le processus afin d'obtenir de meilleures performances lors de la prochaine
itération.
Un cycle de vie itératif facilite la réutilisation. L'identification de parties communes est plus facile au moment où
elles sont partiellement conçues ou implémentées, que si cette identification doit avoir lieu au départ.
L'identification et le développement de parties réutilisables est difficile. Les revues de conception dans les
itérations ultérieures permettent aux architectes logiciels d'identifier une réutilisation potentielle non prévue, et
les itérations suivantes leur permettront de développer et de mûrir ce code commun plus en détails.
L'utilisation d'une approche itérative permet de mieux profiter des produits commerciaux standards. Vous avez plusieurs
itérations pour les sélectionner, les intégrer, et vérifier qu'ils correspondent à l'architecture.
|