eXtrem Programming (XP) et développement itératif

1 Les limites du modèles en V

Schéma du cycle en V.

De nombreux projets sont basés sur le cycle en V.

Le cycle en V est, depuis de nombreuses années, critiqué par les informaticiens, pour (entre autre) les raisons que je vais exposer mainteant.

1.1 Tests retardés

Le premier reproche qui peut être fait au modèle en V est d'écrire et d'effectuer les jeux de Tests Unitaires¹ après la réalisation des Objets à tester.

Si on réalise les tests après la réalisation de l'Objet :

• Le test est écrit (consciemment ou inconsciemment) en fonction de l'Objet réalisé et non en fonction des spécifications de l'Objet. Ainsi, si un développeur réalise un Objet qui n'est pas tout à fait à la hauteur de la tâche demandé, il sera tenté d'établir un jeu de tests couvrant les capacités de son Objet et non l'ensemble des capacités données dans ses spécifications. On parlera de test avec a priori.

• Souvent écrits en fin de projet, les tests sont ''sacrifiés'' s'il y a dépassement des délais. Les Objets n'étant pas ou mal testés, les objets ''incorrects'' n'ont pas été détectés. Donc, les efforts d'intégration peuvent devenir démesurés (Il est difficile, voire parfois impossible, de faire le ''vrai'' en assemblant des éléments dont une partie est ''fausse'')

1.2 Intégration finale : l'épée de Damoclès

L'intégration de l'ensemble des composants en phase finale est un réel problème pour les chefs de projet.

Cette intégration :

• est génératrice d'erreurs (bugs) importantes,

• peut poser des problèmes d'optimisation. Les composants ayant été créé séparément, il n'est pas sûr que :

  • l'ensemble puisse fonctionner immédiatement,

  • et au mieux de la somme de leur, capacités.

De plus, cette manière de travailler oblige le chef de projet à travailler avec un risque maxima (l'impossibilité d'assembler correctement le logiciel et donc de pouvoir le livrer) en toute fin du projet.

1.3 Effet tunnel

Dans le système en V, le client ne reçoit le logiciel qu'en toute fin de projet.

Il ne peut donc :

• Constater les dérapages, tant fonctionnels que techniques, de l'équipe de développement,

• Corriger ses spécifications si :

  • Il a fait une erreur d'appréciation de ses besoins,

  • Le développement de certaines fonctionnalités lui permet de penser et de faire ajouter, en cours de projet, d'autres fonctionnalités.

• Commencer à intégrer, en test interne, un produit en cours de développement pour :

  • Avoir un retour utilisateur sur le produit, dès le début du développement, afin de corriger les erreurs de ses spécifications²,

  • Faire entrer le logiciel dans les esprits des utilisateurs finaux (lutte contre l'opposition au changement). Cela peut éviter les rumeurs sur le logiciel tel que la possibilité de ''dégraissage'' à l'arrivée du nouveau logiciel. La possibilité pour le personnel de découvrir une version, même non finalisée, démystifie le logiciel évite les rumeurs et les pertes de productivité.

Ce problème est appelé l'effet tunnel.

2 Les modèles itératifs : programmation agile

On part d'une ébauche de la définition et d'une solution grossière pour accomplir le but principal...
Je suis persuadé que la conception descendante est l'innovation la plus importante de la décennie en matière de formalisation de la programmation.
Frederick P. Brooks.
'père' du système IBM/360
Médaille internationale de la technologie
BROOKS, F.P. Jr. Le mythe du mois-homme. International Thomson Publishing France – 08/1996. 296 p. ISBN: 2-84180-081-4
page 121

Il existe deux façonsde construire une maison : Une méthode itérative et une méthode non-itérative.

La solution non itérative consiste à construire indépendamment, du gros-oeuvre au petit-oeuvre, chaque pièce, puis à les assembler en fin de projet.

La solution itérative consiste à :

• construire complètement le gros-oeuvre

• le valider

• construire complètement le moyen-oeuvre

• le valider

• construire complètement le petit-oeuvre

• le valider

La méthode non itérative peut paraître absurde quand elle est appliquée au monde du bâtiment.

Car :

• l'intégration de pièces construites, indépendamment peut demander des modifications lourdes :

  • tuyauterie non-placée au même endroit,

  • sens de l'ouverture de porte mal placé,

  • jointure (et système) de la moquette entre deux pièce inadaptée,

  • ....

• La validation ne peut se faire que pièce par pièce, d'où :

  • les problèmes d'intégration repoussés en fin du projet ,

  • l'impossibilité de modifier les spécifications du moyen-oeuvre et du petit oeuvre puisqu'il est impossible de valider le gros-oeuvre dans sa totalité

Sans aller si loin il paraît évident que cette méthode est vouée à l'échec.

Pourtant, la méthode non-itérative est utilisée depuis plus de 20 ans, et l'est encore en développement logiciel.

Depuis environ 5 ans, les informaticiens ont développé des modèles de développement itératif.

La philosophie en est la suivante :

Pour développer un programme, il faut d'abord :

• Développer rapidement toute ''l'ossature³'' du logiciel.

• Valider cette ''ossature''

Puis :

• on peut développer les fonctionnalités du logiciel.

• dès qu'une fonctionnalité est finalisée :

  • elle est testée

  • et intégrée immédiatement à l'ossature du logiciel.

L'ossature étant validée dès le départ :

• L'intégration de la fonctionnalité est très ''légère'',

• Le risque de problème d'intégration n'est pas reporté à la fin du projet mais traité fonctionnalité par fonctionnalité,

• Les problèmes de dépassement (temps, budget) deviennent indépendants pour chaque fonctionnalité.

De plus, l'ossature de logiciel étant déjà fonctionnelle, toute fonctionnalité intégrée est utilisable immédiatement par le client.

Cette méthode de développement permet d'obtenir très rapidement⁴ une version client utilisable, même si elle est limitée en fonctionnalités⁵.

Elle permet également, de livrer, tout au long du projet, selon une fréquence donnée, des versions Client utilisables.

Des outils de développement techniques (Pattern Design) et conceptuelq (Programmation par contrat, carte CRC) ont grandement aidé à l'émergence des méthodes itératives.

Les Objets ''Bidon'' décrits en Partie 2, chapitre 2, sont aussi un outils permettant de créer rapidement des ossatures de programmes.

La méthode de développement itératif permet donc :

• de produire un logiciel rapidement disponible et testable par le client ,

• de réduire les risques d'intégration,

• de déplacer les risques d'intégration au plus-tôt.

Méthode de développement non-itérative

Méthode de développement itérative