Agilité : Mythe ou Réalité

1.  Les Modèles de Développement Logiciels

L’utilisation d’une méthodologie a normalement pour but d’assurer qu’une approche consistante et reproductible soit appliquée à un projet. Pour de nombreuses entreprises l’adoption de méthodologies n’a pas toujours donné les résultats espérés. La principale critique des méthodes « traditionnelles » c’est qu’elles sont trop lourdes pour faire face aux développements de nouvelles activités.

Les méthodologies dites « agiles » s’appuient sur deux concepts clairs :

  • Produire du code rapidement
  • Travailler en équipe dans un esprit de « goodwill ». C’est ici l’acception classique du terme qu’il faut voir, c’est-à-dire la création d’un « fond de commerce » commun au travers du travail de toute une équipe qui vise des perspectives de retours sur investissements collectifs

1.1.       Les Approches Traditionnelles

Le développement logiciel décrit les étapes qui consistent à concevoir, analyser, créer, implémenter et tester un agrégat de code dont la finalité consiste à remplir une mission. Un cycle de vie ou modèle de processus représente alors le modèle de planification des étapes de réalisation. Les cycles de vie sont à la source de la création de la plupart des produits logiciels existants à ce jour.

Si les cycles de vie se proposent de gérer et de séquencer un ensemble de taches les méthodologies revendiquent l’intégration d’outils de modélisation et de techniques ayant pour objectif de focaliser sur le contenu informationnel. L’idée sous-jacente attachée à l’utilisation d’une méthodologie consiste à réduire les risques et à défendre trois points essentiels :

  • Fournir un produit fini de meilleure qualité
  • Intégrer un meilleur processus de développement
  • Standardiser les processus

Les principales critiques des méthodes « traditionnelles » concernent l’incapacité à faire face au « time to market », à réduire les temps de développements, à réduire les couts de production, à changer rapidement pour s’adapter dans un marché qui bouge vite. Les arguments militants contre les méthodologies « lourdes » sont :

  • L’incapacité à définir exactement ce qu’est une méthodologie, fait surprenant au demeurant puisque l’objectif des méthodologies est la précision
  • Le déplacement de l’objectif. Le temps est plus utilisé à adhérer et à définir les points clés de la méthode qu’a produire le logiciel
  • L’incapacité à reconnaitre que les méthodologies ne peuvent s’appliquer de manière universelle
  • L’incapacité à intégrer des facteurs sociologique de succès comme la créativité, l’implication et la capacité à transgresser les « règles » canoniques
  • Le manque de flexibilité face au dogme

1.2.       Les Approches Agiles

Les méthodologies agiles ont pour objectif de supprimer l’inefficacité, la bureaucratie et tout ce qui n’a aucune valeur ajoutée pour le produit. Les principales valeurs de cette approche sont synthétisées dans le « manifeste des techniques agiles » (http://agilemanifesto.org/) :

  • Compter sur les interactions entre individus pour faciliter le partage d’informations, les changements rapides de processus lorsque nécessaire et réduire au maximum la documentation (paperasserie)
  • Utiliser dés que possible des parties de logiciels opérationnels pour avoir rapidement des résultats mesurables et des retours d’expériences
  • Mettre les clients dans la boucle en considérant que les clients (interne et externe), les utilisateurs et les développeurs sont dans la même équipe. Ceci à pour bénéfice de fusionner leurs expériences et expertises pour s’adapter rapidement aux changements de directions et fournir un résultat final bien plus adapté aux demandes du marché
  • Il est plus important de se concentrer sur les changements de réalités que sur des plans dépassés. Il n’y a donc pas de planning (au sens strict et pluri-mensuel du terme) puisque la planification est par définition dépassée dés qu’elle est finalisée

Cette approche à donc donnée naissance à quatre attributs clés :

  • Itératif : un projet doit avoir de nombreuses itérations
  • Incrémental : un projet n’est jamais livré en un seul morceau mais est constitué de couches successives
  • Auto-organisé : les équipes sont responsables pour déterminer le meilleur moyen pour aboutir à leurs fins
  • « Emergente » : les processus, les principes de pilotage et les structures organisationnelles émergent durant la vie du projet

Toutefois les approches agiles ont montré leurs limitations dont :

  • Une capacité très réduite à gérer des équipes distribuées (multisites)
  • De grosses difficultés à intégrer des individus temporairement (CDD, sous-traitants, intérimaires), éléments allogènes à l’équipe en place. Ce facteur est particulièrement critique puisque, à la base des méthodes agiles, l’équipe est réduite et, par construction, experte
  • Grandes difficultés à construire des composants logiciels réutilisables comme des librairies ou des référentiels sans entrevoir la nécessité de phase importante de refactoring
  • Difficulté non surmontée à gérer des équipes de plus de 10 personnes
  • Incapacité à produire des applications à très grande diffusion
  • Grandes difficulté à produire des logiciels à longue durée de vie impliquant un support et de la maintenance sur de longues périodes (plusieurs années)
  • Inadaptation au re-développement d’applicatifs vieillissants
  • Très mauvaise capacité à documenter le développement

Même si la tendance actuelle tente de démontrer que ces limitations peuvent être contournées par un bon management et des équipes expertes et soudées, rien n’a réussi à ce jour à éviter les dérives ci-dessus mentionnées.

2.  Le Bon Équilibre ?

Il apparait donc que les deux approches présentent des failles conceptuelles et contextuelles qui, si elles ne sont pas gérées, conduisent à des difficultés majeures. Le grand challenge consiste probablement à trouver un système équilibré qui puisse tirer avantage des deux théories de manière à compenser les faiblesses réciproques.

La solution se trouve certainement et de manière intuitive aussi bien que démontrée par de nombreuses analyses, dans les organisations hybrides qui appliquent l’une ou l’autre approche avec plus ou moins de profondeur en fonction de 5 critères :

  • La taille de l’équipe, du projet. Cette dimension est fortement influencée par le nombre de clients, la durée de vie du produit, la couverture fonctionnelle et donc métier
  • La criticité du projet
  • Le dynamisme de l’équipe
  • Les compétences en présence
  • La culture de l’entreprise de manière générale

Boehm et Turner (2004) ont rassemblé ces 5 dimensions dans la rosasse ci-après et nous constatons comment un projet de développement peut être positionné dans un mode agile ou traditionnel.

Pour ce qui est du choix d’une méthode il est alors question de gestion du risque qui est classé en trois catégories :

  • Environnemental : qui résulte de l’environnement général du projet
  • Agile : qui résulte de l’utilisation d’une approche agile
  • Traditionnel : qui résulte de l’utilisation d’une approche traditionnelle

Catégorie de risques

Nom du risque

Description du risque

Environnemental

Technologie

Incertitude technologique

Coordination

Beaucoup d’intervenant à coordonner

Complexité

Système complexe

Agile

Taille

Difficulté à adapter la taille des équipes et/ou la criticité

YAGNI

(You Are Not Going to Need It)

Utilisation de conception simple ou YAGNI

Compétence

Pas suffisamment de personnes formées et expérimentées

Brassage

Trop de turnover dans les équipes

Traditionnel

Changement

Changements d’orientations trop rapides

Vitesse

Besoin de résultat rapidement

Emergence

Possibilité d’émergence en cours de route de besoins non spécifiés initialement

Compétence

Pas ou peu de compétence en pilotage et planification

3.  Conclusion

Les observations menées à travers le monde montrent que les méthodes agiles ou « disciplinées » (traditionnelles) ont, quoi qu’on en dise, la même finalité : satisfaire les attentes des clients dans des coûts et des délais appropriés. De même aucune des approches n’est infaillible et il faut être en capacité de mixer les deux pour tirer partie de leurs forces respectives tout en abolissant leurs faiblesses. La plus grande difficulté consiste alors à supprimer au sein d’une organisation (ou entreprise) les barrières suivantes :

  • Les processus de développement qui doivent relever du bon sens et non du dogme
  • Les processus business qui doivent intégrer forces et faiblesses de l’une ou l’autre approche pour peu que l’information soit clairement établie et diffusée. Ceci concerne la disponibilité des moyens, la fixation des objectifs de ventes, les possibilités de croissances, etc …
  • Les processus internes autres qui doivent intégrer une plus ou moins grande flexibilité. Il est totalement illusoire de vouloir adopter une approche agile dans une société très hiérarchisée et très bureaucratique par exemple
  • Les conflits entre individus qui doivent être gérés dans le contexte posé par l’approche de développement choisie. En effet, méthodes agiles ou traditionnelles induisent l’acceptation de règles du jeu différentes
  • L’explicitation de ces règles du jeu aux membres de l’équipe pour qu’elles soient comprises et acceptées. Il faut avoir en tête que les formes de créativités, d’initiatives, de contrôles, de relation avec les clients et de réalisation du travail de manière globale sont fortement influencés par la méthode mise en place
  • L’acceptation de la diversité des méthodes au sein d’une même organisation avec, encore une fois, l’obligation pratique de clarification des règles d’interactions entre les deux modèles lorsqu’ils doivent coexister

4.  Références

1) Galal H. Edeen, A.E. Riad and M. Seyam, « Agility versus Discipline : Toward a Middle Ground », Proceedings of the 37th International Conference on Computers and Industrial Engineering, October 20-23 2007, Alexandria, Egypt

2) Philip Bradley Website (Phil Bradley est un spécialiste de l’information mondialement reconnu dans le monde de la publication électronique depuis 20 ans. Il enseigne dans des domaines comme les moteurs de recherche ou les conséquences de l’internet. Enfin c’est l’un des rares « Microsoft Search Champions » dans les TIC)

3) Alex Iskold, « The Future of Software Development », ReadWriteWeb, October 16, 2007

4) B. Boehm et R. Truner, « Balancing Agility And Discipline : A Guide For The Perplexed », Addison-Wesley, Boston

5) Robert A. Small, « Where is The Discipline in Disciplined Agility ?  », Systems and Software Consortium Presentation, April 2007, www.systemsandsoftware.org

6) Jim Highsmith, « What Is Agile Software Development ?  », Cutter Consortium, The Journal of Defense Software Engineering, October 2002

Advertisements

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