Historique de l'eXtreme Programming
Un constat alarmant
La naissance d’une nouvelle méthode arrive rarement sans raisons. Elle fait plutôt suite à une période difficile...
Les 3 plaies du développement logiciel
D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté les délais et le budget initial et, pire, 32 % n’ont jamais abouti.
Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues enveniment le développement d’applications.
La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heures sup. Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’un cahier des charges mal étudié ou incomplet.
Tout cela implique des changements au cours du développement, d’autant plus si le client décide de modifier le produit, après une première maquette par exemple. Enfin, le dernier problème concerne la livraison finale du produit qui est parfois buguée.
La difficulté de réalisation
Pour cause la conception d’un software n’est pas, contrairement à son nom, souple en raison de la quantité de travail engendrée traditionnellement par une modification, même minime du cahier des charges. Pour exemple, une simple demande exige la remise en question des tests prévus et une modification parfois très importante de l’architecture du logiciel. On considère alors que le coût du changement croit exponentiellement avec le temps.
Avec près de 80% des projets, toutes tailles confondues, qui ne respectent pas les contraintes de départ de temps et de budget, les chefs de projet s’interrogent de plus en plus sur leurs méthodes.
Historiquement, lors du développement d'applications et de projets e-business, chaque développeur se voit confier une partie du travail, le tout étant ensuite assemblé. Or, cette organisation fait perdre du temps, car tous les participants au projet ne travaillent pas de concert. Par la suite, on essaye plusieurs solutions dont les résultats ne sont que rarement concluant. La première est de tenter de rattraper du retard grâce à des heures supplémentaires, mais la qualité en souffre et le moral des participants aussi. La deuxième est de toute façon de se conformer aux objectifs qualités coûte que coûte en tentant de rallonger le délai ou de choisir consciemment de ne pas livrer une partie du projet. Dans ces cas, le client n’est que rarement content... Enfin, une dernière solution est de tenter de requérir plus de ressources mais tous les responsables savent que c’est difficile, et le mot est faible... Ainsi, soit vous ne les obtenez pas, ce qui vous met en mauvaise position face à votre responsable, soit vous les obtenez et les coûts administratifs vous enterrent...
A l’approche des dates butoires, on a donc un certain stress qui amène à prendre certaines décisions qui, le plus souvent, entraînent un mécontentement du client.
Le père d’XP : Kent Beck
XP est né lors d’une récente vague de création de nouvelles méthodes parallèlement à l’explosion de l’informatique dans les entreprises et de l’émergence du freeware.
Lors de cette vague, sont essentiellement apparues des méthodes qualifiées d’agile dont XP fait partie.
Chrysler, le berceau d’XP
Si l’on recherche plus précisément le berceau de la méthode, on tombe sur un grand projet du groupe Daimler Chrysler datant du milieu des années 90 et nommé le « Chrysler Comprehensive Compensation » ou « C3 ». Celui-ci consistait à remettre à jour le système de paie de tout le personnel gérant plus de 10 000 personnes. Le logiciel d’origine contenait 2000 classes Smalltalk et 30 000 méthodes dont les modules transmettaient des données faussent, bien que le programme réponde aux spécifications et cela malgré 18 mois de développement et des millions de dollars investis... Quand Kent Beck (un gourou reconnu du monde Smalltalk) repris le projet en 1996 accompagné de Ward Cunningham, ils ont préféré dire à la responsable informatique de Chrysler, Sue Unger, de repartir à zéro plutôt que continuer sur de mauvaises bases. Cette dernière, en concertation avec ses collègues, décida de se lancer dans cette « monstrueuse » aventure. Toutefois, elle confia le projet à Beck qui lui dit pourtant : « Vous ne comprenez pas, je suis consultant, je ne vais pas sur le terrain », auquel elle a répondu : « Vous ne comprenez pas, je m’appelle Sue Unger, et vous irez sur le terrain »...
Beck, un chef de projet novateur
Beck sorti alors de sa manche un bon nombre de méthodes qu’il avait auparavant testées mais il se rendit compte qu’aucune lui permettrait de venir à bout de ses contraintes et il devait innover... “C’était un mélange de préparation soigneuse et de panique », disait-il. Tout d’abord, le projet devait se dérouler en petites itérations définies par le client et testées systématiquement pour montrer l’avancement. Le temps étant compté, réaliser les tests avant le code allait permettre de réaliser des économies de temps et de personnel puisque l’équipe « assurance qualité » devenait inutile en raison de la correspondance de la production avec la demande. Souhaitant encore faire des économies de temps, la programmation en tandem fut choisie. En effet, à deux le déboguage est instantané et la rédaction de la documentation est facilitée : « Si un programmeur parvient à communiquer clairement ses idées à un autre programmeur travaillant à ses côtés, il y a de grandes chances pour que celui qui vérifiera le programme deux ans plus tard n’ait aucun mal à le comprendre ».
Au fur et à mesure de l’arrivée de ses idées, Beck devenait persuadé du bien fondé de sa méthode. “Au bout de quinze personnes, c’était devenu tout à fait concevable”, se souvient-il. Durant l’été 1996, il décida de baptiser son concept. Puisque les autres méthodes donnaient la priorité au planning sur la programmation, Beck décida que “programmation” devrait faire partie du nom. “J’avais alors besoin d’un adjectif attrayant, suffisamment descriptif et défendable.” Il décida alors de nommer sa méthode “extreme programming”, après avoir découvert la puissance des athlètes de l’extrême. “Je voulais que mes équipes aient le même sentiment d’invulnérabilité face aux défis à relever.” De plus, les pratiques sur lesquelles est bâtie XP sont « autant de boutons de contrôle qu'il pousse au maximum ». Ainsi, cette méthode est la réunion cohérente de pratiques peut-être simples mais portées à un point extrême.
Et finalement, sa méthode fut un succès et en 1997, Chrysler avait un nouveau système de paie, et Beck, assisté de son collègue et ami Ron Jeffries, écrivait le premier ouvrage d’une série sur la “méthode XP” tout en s’appliquant à faire des adeptes
C’est donc ce projet qui est à l’origine d’XP et qui a vérifié et testé ses grands principes, en tirant des enseignements des erreurs de management précédentes.
Un développement rapide dans le monde
La méthode est née réellement en 1997 après la parution du premier livre de Kent Beck : « eXtreme Programming Explained ».
Un développement international facilité par internet
La toile a alors joué depuis un grand rôle dans le développement de la pratique d’XP. Pour preuve, il existe de nombreux forums de discussion qui lui sont directement consacrés, comme par exemple, pas moins de 71 « Yahoo Groups » internationaux.
Parmi eux, le plus connu et le plus populaire a été créé en décembre 1999 et possède aujourd’hui près de 3400 membres avec une moyenne de 1850 messages postés par mois.
On commence ainsi à trouver XP dans des la plupart des domaines comme l'électronique (développement des pilotes de matériels), la banque, le transport et les télécoms.
La méthode fait aussi une incursion chez certains éditeurs ou dans les entreprises de secteurs scientifiques et techniques, pour leurs projets de R&D. Quelques sociétés de services, dont des agences web, s'y intéressent également, voyant dans XP un moyen de raccourcir leurs délais. Un auto-recensement international des projets en XP est d’ailleurs fait à cette page : http://c2.com/cgi/wiki?ExtremeProgrammingProjects
Voici quelques exemple :
- Bayerish landes bank, Credit swiss life, First union national bank
- Daimler-Chrysler, Ford Motor Company, BMW
- CSEE transport
- Nortel
- AGF
XP s’installe progressivement en France
En France, pour l'heure, les premières mises en oeuvre se limitent essentiellement à des projets réduits ou non stratégiques. La méthode ne semble en effet pas assez connue par les directions. Pour preuve, dans un sondage 19 septembre 2002 du JDNet, plus de la moitié des visiteurs n’ont jamais entendu parlé de la méthode...
Mais la communication va bon train et on voit même apparaître de plus en plus de formations à XP et des cours dans des universités (Université d’Artois, de Genève...) et des grandes écoles, notamment à l’INSA Lyon ou à l’école des mines de Nancy, qui sont tout de même des références dans le monde informatique.
On voit aussi apparaître des sociétés françaises qui se vantent de maîtriser la méthode afin d’attirer le client...
La communauté des XPiens française est bien existante et communique sur son « Yahoo groupe » : extremeprogramming-France comptant environ 250 membres. Les co-auteurs, Laurent Bossavit et Dominic Williams, du livre francophone « L'eXtreme Programming : Avec deux études de cas », participent d’ailleurs activement aux discussions.
XP est donc encore à ses débuts, en terme de connaissance mais est en phase de devenir une référence mondiale. A suivre...
Situation par rapport aux autres méthodes
Le but de cette partie est de situer XP par rapport à d’autres méthodes et en aucun cas de présenter d’autres méthodes.
XP : une méthode agile
Les méthodes agiles sont des méthodes de gestion de projets informatiques et de développement qui se positionnent en réaction à des méthodes traditionnelles jugées trop lourdes. XP fait partie de cette catégorie dont la première idée a été de réagir face à la bureaucratie où toute démarche exige une grande quantité de temps. C’est aussi la plus populaire des méthodes agiles mais on peut aussi citer : ASD (Adaptative Software Development), SCRUM, Crystal, FDD (Feature Driven Development) et DSDM (Dynamic System Development Method) qui peuvent chacune être adaptée à une situation particulière, fonction de la taille de l’équipe.
Depuis le mois de février, les figures de proue des méthodologies de développement agiles ont constitué l'Agile Alliance.
En avril 2002, le PUMA (Proposition pour l’Unification des Méthodes Agiles) naît poussé par Jean-Pierre Vickoff, consultant formateur, directeur de projet et architecte de SI, auteur de nombreux ouvrages sur les méthodes et expert RAD.
XP vs Méthodes traditionnelles comme UML
Par rapport aux autres méthodes plus traditionnelles comme RAD et Unified Process (qui s'appuie sur UML), Jean-Louis Bénard, Directeur Technique du groupe Business Interactif indique qu’il serait une erreur de les opposer aux méthodes agiles. « Les méthodes agiles essayent de formaliser le bon sens et le pragmatisme que des équipes mettent déjà en oeuvre dans le cadre de projets dits traditionnels ».
D’ailleurs, XP peut être vu comme une déclinaison de Unified Process (UP), en ayant bien en tête cependant que c’est le client qui rédige les spécifications en XP contrairement à UP où les spécifications sont une retranscription par l’informaticien de ce qui a été compris. Aussi, les itérations qui sont un des principes des deux méthodes sont environ 6 fois plus fréquentes en XP.
Ainsi, les écoles classiques et « agiles » sont complémentaires.
UML qui est une méthode de modélisation n’est par essence pas « menacé » par l’engouement pour XP qui est une méthode de réalisation, d’organisation.
D’ailleurs, XP utilise le langage universel qu’est UML pour communiquer. Toutefois, par sa volonté de rapidité, XP reste prudent sur l’utilisation d’UML. Pour cause, les diagrammes UML sont trop longs à réaliser alors que la conception en XP étant très courte et réalisée au fur et à mesure. La documentation par les diagrammes UML est aussi déconseillée en raison du volume de ces derniers, par rapport aux quelques pages préconisées dans XP.
Site créé par Adrien Machado - Copyright reserved ©
|
