Journal du Net > Solutions >  Crise et renouveau des méthodes. Dernier Acte: les principes de "l'eXtreme programming"
Article
 
05/09/2001

Crise et renouveau des méthodes. Dernier Acte: les principes de "l'eXtreme programming"

  Envoyer Imprimer  

Suite de l'Acte II : la découverte du "peopleware"


Parlez-en
sur le Forum
(rubrique Solutions e-business)

Pour la plupart des gens, l'intérêt pour ces méthodes agiles est d'abord une réaction à la bureaucratie générée par les démarches monumentales. Ces nouvelles méthodes proposent une balance équilibrée entre "pas de démarche" et "trop de démarche", imposant juste ce qu'il faut de discipline pour attendre un retour sur investissement [en temps et en effort] immédiat et intéressant. Les méthodes agiles ont apporté un changement significatif dans l'orientation des objectifs par rapports aux méthodes lourdes. La différence la plus évidente réside dans la réduction radicale de la production de documents. Les méthodes lourdes impliquaient la production d'une documentation importante à chaque phase du projet. Les méthodes légères seraient plutôt focalisées sur le code des applications aboutissant à un postulat où le code source serait la partie essentielle de la documentation !

Adaptées au monde réel
Néanmoins, l'absence ou la quasi-absence de documentation, aussi spectaculaire qu'elle soit, n'est sans doute pas le point clé qui caractérise les méthodes agiles. Il s'agit plutôt un symptôme de deux différences bien plus profondes :

1. Les méthodes agiles sont "adaptatives" plutôt que prédictives.
Les méthodes lourdes tentent de dresser un plan du processus de développement logiciel dans le détail et pour une longue période de temps. Cela fonctionne bien jusqu'à ce que les prédicats de base ou même le contexte ne change. Ce type de changement arrive tout le temps dans les projets. Or, leur nature est de résister au changement. A contrario, les méthodes agiles accueillent favorablement les changements, elles s'adaptent aux modifications du contexte jusqu'à changer elles-mêmes !

2. Les méthodes agiles sont orientées sur les personnesplutôt que sur les processus.
Elles prennent le parti explicite d'essayer de tenir compte de la nature humaine plutôt que de tenter de la combattre (et c'est une bonne chose car les mauvais côtés de la nature humaine triomphent toujours de toutes les bonnes théories !) et font en sorte que le développement logiciel soit une activité agréable plutôt qu'un cauchemar bureaucratique…

Une nouvelle vague
Dans cette nouvelle vague des méthodes, on peut citer XP (eXtreme Programming), ASD (Adaptative Software Development), SCRUM, FDD (Feature Driven Development) et DSDM (Dynamic System Development Method). La plus populaire semble bien être XP. Les principes de XP XP est basée sur 4 principes : communication, simplicité, feedback et courage. XP met en oeuvre certaines pratiques "frappées au coin du bon sens" et en les portant à un niveau "extrême". XP s'adresse à des projets petits ou moyens.

Pour fixer les idées, XP s'adresse à des équipes de quelques programmeurs, de l'ordre de la dizaine maximum. XP s'adresse à la fois aux "développeurs" et aux "clients". Développeur entre guillemets car il s'agit de programmeurs/testeurs mais aussi concepteur/architecte ; client également, au sens "personne habilitée à définir les besoins et leurs priorités". Les principes :

1. Communication
La communication joue un rôle essentiel dans le développement. A l'inverse, un manque de communication entraîne souvent des problèmes. XP distingue deux types de communication : communication entre programmeurs et communication entre programmeurs et clients. Plusieurs pratiques dans XP, comme le pair programming ou la définition des tests fonctionnels par les clients, facilitent et encouragent la communication. Les principes :

2. Simplicité
L'idée à la base de XP est ici la suivante: il vaut mieux faire simple aujourd'hui, quitte à changer demain, plutôt que de faire tout de suite compliqué sans être absolument certain de l'utilité de ce que l'on développe. Les principes :

3. Feedback
Des retours par rapport à l'état du système sont essentiels. Plus on a un feedback, plus on a matière à communiquer. Le feedback intervient à plusieurs niveaux dans XP. Par exemple, avec les évaluations "instantanées", le client a donc un retour immédiat sur ses exigences. Autre exemple, les tests systématiques permettent de disposer d'une information permanente sur l'état du système. Enfin, c'est par les retours ou réactions que l'on peut mieux "ajuster" le développement. Les principes :

4. Courage
Communiquer et regarder son système en face demande quelquefois du courage. Reconnaître une grave erreur de conception, décider de tout jeter et de recommencer demande du courage. De même, faire simple demande aussi du courage: ne pas utiliser à tout prix la caractéristique compliquée de telle ou telle API.

En plus de ces principes, deux pratiques importantes sont vraiment au cœur de XP : les tests et le "pair programming". Les tests jouent un rôle primordial dans XP. Les développeurs sont responsables des tests unitaires qui sont écrits avant le développement. Le client écrit les tests fonctionnels qui permettent de valider le système. Au passage, ces tests constituent aussi un raffinage des besoins client. Programmation à 2 ou pair programming. Avec XP, le code est développé à 2 : c'est-à-dire une machine pour 2 développeurs. Cette pratique permet une revue de code continuelle. Pendant que l'un a le clavier, l'autre développeur peut participer en commentant, en proposant ; il peut aussi réfléchir à ce qu'il aura à coder prochainement.

Pour en savoir plus sur XP, je recommande les sites Web suivants :
- XP-France
- Extreme Programming A Gentle Introduction.
- An Extreme Programming Resources site

L'apparition et le développement d'XP est significatif d'un renouveau des méthodes après l'impasse des démarches traditionnelles. Pragmatisme et orientation humaine sont les axes majeurs de cette nouvelle vague qui, entre autre intérêt, est bien en phase avec le mouvement Open Source (comme par hasard !) : focalisation sur le code source et utilisation intelligente des efforts des participants. Sachez tirer parti de l'un (méthodes agiles) comme de l'autre (mouvement Open Source) car il s'agit des éléments structurants de notre profession pour les prochaines années.

[Alain Lefebvre, Vice-président du Groupe SQLI ]


JDN Solutions Envoyer Imprimer Haut de page

Sondage

Votre entreprise évolue-t-elle vers une informatique bimodale ?

Tous les sondages