Agile, iteration, iterative development, Uncategorized

Le développement itératif (French only)


 

Définition

 Le développement itératif consiste à livrer des parties d’un système ou d’une application à des intervalles réguliers. Ces intervalles sont appelés Itérations. Une itération est donc une succession d’activités couvrant l’analyse des besoins, la conception des parties du système, leur implémentation ainsi que leurs tests qui, activités, aboutissent à la livraison d’une ou plusieurs fonctionnalités qui feront partie du produit final.  

Approche classique (par étapes ou Waterfall en anglais) comparée à l’approche par itérations

 Par exemple, imaginons que nous avons un projet de développement d’une application en ligne qui offre 20 fonctionnalités différentes (20 scénarios). Dans une approche par étapes : 

  • On effectue une analyse complète pour élaborer et détailler tout les scénarios,
  • L’architecte livre une architecture détaillée de toutes les composantes de l’application,
  • L’analyse fonctionnelle et le document d’architecture sont transmis aux développeurs qui implémentent la totalité des 20 scénarios
  • On effectue les tests d’assurance qualité sur les 20 scénarios
  • On livre le produit au client pour des tests d’acceptation,
  • On fait les changements demandés par le client,
  • On livre le produit final

 Notez l’avant dernier point : Pour passer au produit final, il est rare que le client ne demande pas des changements. Cela souvent provoque des retards dans la livraison ou/et des fins de semaines sacrifiées à travailler sur les dernières demandes du client. Dans une approche itérative, on garde les mêmes étapes que celle de l’approche précedente sauf que ces dernières se produisent en dedans d’une itération dont la durée est fixe et de ce fait, se répètent autant de fois qu’il y a d’itérations. Par exemple, on pourra décider que les scénarios 1, 10 et 15 vont être développés dans l’itération 1. Pour l’itération 2, nous aurons probablement des correctifs sur les scénarios 1, 10 et 15 plus quelques autres scénarios tirés de la liste complète etc… 

Avantages du développement itératif

 L’approche de développement par itérations offre les avantages suivants : 

  • Elle s’adapte mieux aux changements. En fait cette approche considère le changement comme faisant partie du cycle de développement d’une application et non pas comme un événement intempestif,
  • Elle nous permet de détecter les risques très tôt dans la vie du projet,
  • Elle permet d’ajuster les choix en termes d’architecture ou de conception graphique par exemple, très tôt dans le processus et non pas après que ces derniers aient été complètement réalisés (et donc les heures déjà consommées),
  • Chaque itération est une expérience qui nous permet d’apprendre d’avantage sur les challenges que représente le projet. Par exemple, il est fréquent de revoir les estimations faites au début du projet après la fin des premières itérations,
  • On donne la chance au client de visualiser le résultat des itérations et donc l’occasion pour lui d’exprimer des ajustements au fur et à mesure que le projet avance et non pas à la fin uniquement lors des tests d’acceptation,
  • Le contrôle de la qualité se fait à la fin de chaque itération.
  • Les développeurs restent concentrés sur une partie des fonctionnalités qui font partie de l’itération courante. Tout changement ou correction qui s’ajoute à la liste des tâches, doit être planifié dans les itérations subséquentes. Comme la durée d’une itération est relativement courte, généralement, les clients et chefs de projets acceptent d’attendre ce délai
  • Le client est rassuré car il peut voir concrètement la progression du projet à travers la manipulation ou l’exécution de cas d’utilisations réels de sont produit

  

Règles de gestion des itérations

 Afin de gérer au mieux les itérations, il est important d’observer quelques règles dont les plus importantes sont : 

  • Fixer la durée des itérations au début du projet : Une itération doit avoir une durée entre 2 et 3 semaines. Il est fortement conseillé que la durée soit calculée en semaines pour que ca soit facile à mémoriser
  • Au début de chaque itération, tout les intervenants dans le projet, y compris le client, doivent se réunir pour discuter des l’expérience de l’itération précédente et déterminer le contenu de la prochaine itération
  • l’équipe de production doit présenter un produit à la fin de l’itération. On entend par produit, un ensemble de fonctions qui seraient utilisables telles quelles même si, dans la plupart des cas, on n’ira pas en production sans le reste des fonctions. La présentation se fait en utilisant l’application (il ne s’agit pas de présenter des Power Point par exemple)

 Évidement, il existe des exceptions à ces règles, surtout en ce qui concerne la dernière, dans le cas par exemple du développement d’une application serveur qui ne présente pas d’interface utilisateur et qui serait difficile à présenter partiellement. Aussi, typiquement, la première itération « Set Up » et la dernière « Livraison » sont un peu différentes des autres itérations. Dans la première, le nombre de rencontres entre les différents intervenants est souvent élevé et les livrables sont de type « documentation ». Dans la dernière itération, on s’afférera à corriger les derniers bogues et focaliser sur les procédures de déploiements (création d’une application de déploiement par exemple).   

Conclusion


Les avantages d’une approche par itérations sont évidents mais l’application d’une telle méthodologie nécessite plus de discipline qu’une approche classique ou les intervenants (équipe de production) ont une certaine durée pour livrer la totalité d’un produit, et en dedans de cette durée, il n’y a pas de moyen de mesurer de manière précise la progression du projet.

 À la question du gestionnaire de projet « Êtes-vous dans les temps? » les développeurs vont avoir deux réponses, dépendamment du temps restant. Soit un « Oui » si on est encore loin de la date de livraison. Soit un « Non » si on est à quelques jours seulement de la livraison. La marge de manœuvre est alors quasi nulle et il est trop tard pour agir ou négocier des délais supplémentaires avec le client. En se mettant des points de contrôles à la fin des itérations, le gestionnaire de projet peut évaluer lui-même la progression du projet et sa marge de manœuvre sera d’autant plus grande qu’il aura détecté les dépassements dans les premières étapes du projet. Aussi, cette approche permet de mieux intégrer les demandes de changements et les commentaires du client. Le fait de ne pas les recevoir tous d’un coup à la fin des tests d’acceptation permet au gestionnaire du projet de mieux planifier leur impacte sur la date de livraison du produit final.  

Lire aussi l’impact qu’a eu SCRUM sur notre équipe: https://bellouti.wordpress.com/2008/12/04/how-scrum-helped-our-team/

Advertisements

1 thought on “Le développement itératif (French only)”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s