Quelques infos sur l'eXtreme Programming

{publié le 28/04/2004 sur nzn.fr.delphi par Henry}
//***********************************************

C'est une manière de travailler qui a été élaboré par des consultant chez
Ford il y a quelques années.

Il s'agissait de sauver un projet à la dérive.

Pour cela ils ont analysé les dysfonctionnements des relations entre les
parties prenantes du projet,
et pas seulement du point de vue technique : le const at habituel est
- un utilisateur qui sait ce qu'il veut (mais qui change souvent d'avis
parce que son environnement change)
- qui veut être opérationnel au moins sur une partie du projet sans attendre
le tout
et de l'autre côté des développeurs qui souhaitent réaliser un logiciel
global.
Donc, la cas classique, c'est l'utilisateur qui s'exprime au début, puis
l'informaticien qui développe pendant des mois,
et quand ils se retrouvent, la demande a changée, le logiciel ne se présente
pas comme souhaité.
De plus si on avait su certaines choses plus tôt (introduire Internet par
exemple), des choix plus judicieux aurait été faits.

Ces consultants ont donc par l'eXtreme Programming énoncé un certain nombre
de règles qui font que ça marche.
Au final, le projet a été sauvé. Cette méthode a été appliquée depuis avec
succès aussi bien sur des projets très techniques
(serveur de télécommunication par exemple) que sur des projets de gestion.

Voici quelques-unes de ces règles, sans être exhaust if (d'autres
complèteront) :
1- passage continu du prototype à l'opérationnel : au départ, on prototype
avec des données réelles,
autant de modules que possible, de manière indépendante (exemple :
montée en charge d'une base de données)
ergonomie utilisateur, etc.
2- on définit avec les utilisateurs les cas d'utilisation (au sens UML). et
l'utilisateur va être présent dans l'équipe
de développement tout le temps du projet (il participe au moins à une
réunion quotidienne, et mieux, il participe aux tests)
3- très vite, on isole un ensemble fonctionnel qui puisse être utilisé
effectivement sans attendre l'ensemble de la livraison.
4- pour cela, il faut donc travailler avec des méthodes qui vont assurer que
l'on progresse d'une version à l'autre.
c'est pourquoi, les tests sont primordiaux : on parle de tests unitaires.
Chaque module a sa batterie de tests et
les tests sont utilisés pour valider toute livraison (typiquement une fois
par jour).
On écrit même les tests avant tout développement. On développe ensuite. Au
début, les tests doivent dire que ça ne marche pas.
Et progressivement, ils vont assurer que chacun des points fonctionne. Les
tests doivent donc être automatiques.
C'est long à écrire, mais cela donné une sacré sécurité sur le produit
final.
5- Travail à plusieurs (pair programming) : le top, c'est 2 personnes sur le
même micro :un qui regarde et l'autre qui fait,
à tour de rôle. Les binômes sont formés chaque matin. ça paraît cher, mais
cela donne une très grande souplesse et une grande réactivité
à l'équipe. Au final, on est gagnant. Et cela permet une plus grande
permanence dans la continuité (mutations, congés, etc.).
Cela implique évidemment un bon relationnel (comme on dit). Toute personne
peut intervenir dans tout le code.
6- Pas de documentation : un code bien écrit doit être lisible. Si des
conditions d'exécution, des assertions sont à prendre en compte,
elles doivent l'être dans le code. (On utilise beaucoup d'Assert et de
point de contrôle : par exemple tout module contrôle
ce qu'il reçoit et ce qu'il produit). De plus, les tests fournissent et
implémentent des cas d'utilisation : fort utile pour les reprises de code.
7- Pas plus de 35 h. (à adapter selon les tropiques) de développement par
semaine.
(En cas de bourre, pas plus de 10 jours). On ne développe bien que si l'on
est en forme.
8- Etre en mesure de fournir un délivrable à tout moment
9- Pas d'engagement de délai : mais engagement de date précise de production
de version opérationnelle : on y trouvera ce qui a eu
le temps d'être développé correctement et de passer les tests. (ça au
moins, c'est réaliste)
10- contrepartie : l'utilisateur peut rompre le contrat à tout moment (il
trouve que ça va trop lentement, ou son besoin a changé).
l'utilisateur part alors avec ce qui fonctionne.

ah, j'oubliais, une règle qui tient plus du folklore US, (IMHO) : les
réunions quotidiennes ont lieu debout (pour que ça ne s'éternise pas).
mais nous on est latin...(tout de même pas romains) : on adaptera.

En y regardant de près, ces règles ont une cohérence interne :
Pour pouvoir partir avec ce qui fonctionne (10), dans un contrat qui peut
être rompu à tout moment, il faut être en mesure
de fournir un délivrable à tout moment (8). La qualité de délivrable ne peut
être assurée que si l'on peut faire tourner les tests
sur tous les points fonctionnels (4), et ceux-ci doivent être automatisés
pour qu'ils soient fait au jour le jour (ça permet de prendre le café).
Ils doivent être modulaire pour permettre des livraisons partielles. Tout le
monde peut intervenir partout (4 toujours).
La cohérence est garanti par les tests.
La doc est toujours à jour :-)) (elle est dans le code : nom long de
var iables, assert, etc.)

Tout cela me paraît bien pensé, réaliste et efficace.

Dans ma pratique, cela coûte environ le double de ce qui est prévu au départ
d'un projet qui serait développé par des méthodes
classiques. .....je précise : _que le double_ (alors que le projet classique
finit par coûter jusqu'à plusieurs fois le montant prévu initialement).

Donc ça commence à se savoir, et à générer une demande, d'où la présence
dans les annonces.