Discussion :

[virgile04]

Bonjour à tous, j'ai lu dans l'intitulé du forum qu'il parlait entre autre de l'eXtreme Programming (XP, et aucun lien de parenté avec un certain microsoft!!!). Travaillant avec cette méthode depuis presque un an, je me suis dis que ce serait bien de faire un poste pour demander si certains d'entre vous seraient interessés par la méthode ou si certains avaient des questions.
voila, bonne journée.

[senke]

J'ai déjà du en faire, (une fois). T'as de la documentation?

[Epictète]

Travaillant avec cette méthode depuis presque un an, je me suis dis que ce serait bien de faire un poste pour demander si certains d'entre vous seraient interessés par la méthode ou si certains avaient des questions.
voila, bonne journée.

Avec quel langage ? quel outil ?

[virgile04]

Alors en ce qui concerne les références, il y a le premier bouquin en français sur XP qui est paru il y a un mois ou deux:
"L'eXtreme Programming : Avec deux études de cas"
de Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams
chez eyrolles.
Sinon, il existe d'autres bouquins en anglais seulement, que vous pourrez trouver facilement.
Sinon il n'existe pas de doc qui circule sur le net.

Dans mon cas précis on développe en C++ (et donc cppUnit) et un peu de Python (et donc pyUnit).

voila pour les infos

[virgile04]

en fait ça va bientôt faire un an que je fais parti d'un équipe XP en tant que développeur au sens XP du terme et nous mettons en place l'ensemble des pratiques que tu as cité.
Jusqu'à aujourd'hui je n'ai été déçu par aucune, bien au contraire!!
Si on les reprend rapidement une par une:
- écriture les tests avant le code : excellent chose que tout le monde devrait faire même sans appliquer le reste de la méthode. En faisait ça on définit entièrement l'interface de la classe que l'on va faire, on s'assure qu'une fois terminer elle fera exactement ce que l'on demande (car les tests passeront tous) et elle n'en fera pas plus qu'a notre seul but en ecrivant le classe elle même se sera que de faire passer les tests. Enfin on est sûr que des tests seront écrits, et pas plus tard si on a le temps, ce qui revient à dire dans la majorité des cas jamais. En fait le but est d'avoir un jeu de tests que l'on complete au fur et a mesure de l'avancement du projet ce qui permet de verifier le non regression suite a ce qu'on vient de faire. Mais le sujet est vaste!!
- la programmation en binome: elle permet une integration rapide d'une personne sur le projet, on a toujours deux avis sur la conception d'une classe, relecture du code instantanée, partage des connaissances facilité (nivelement vers le haut de l'équipe), et comme les binomes tournent regulierement, et que tout le monde travaille sur l'ensemble du code, personne ne devient indispensable, donc pas "ben je sais pas c'est pas moi qui fait ça, celui qui s'en occupe est malade/en vacances", et enfin une responsabilite collective du code.
-plannification: en fait nous fonctionnons sur des iterations de 2 semaines, donc planning game à la même fréquence, les objectis sont plus courts, et donc plus facile de voir tout derapage dans le temps et de le corriger tres vite. C'est la que l'on voit l'un des roles du client qui est de choisir les implementations a faire en priorite sans pour autant donner de delai, ce qui est le role des developpeurs.
- le refactoring: permanent, donc plus simple qu'un gros refactoring en fin de planning, le code est ecrit de la manière la plus simple pour qu'il marche, par exemple on va ecrire une simple classe, si on se rend compte en en ecrivant une autre qu'elles ont beaucoup de choses communes, on va faire un refactoring en creant une classe mère, mais au moment où on en a besoin, pas avant. On écrit les tests de la classe mère qu'on ajoute aux autres, on crée la classe mère, on en fait heriter la premiere classe, on passe tous tests en s'assurant que tout marche necore, et enfin on crée des tests pour la nouvelle classe, puis la nouvelle classe. Enfin on passe les tous les tests. La tache est finie.
- le stand up meetin a lieu chez nous tous les soirs, car le matin tout le monde n'arrive pas a la même heure, il est rapide (5-10 minutes) et permet de connaitre ce qui est en cours, les éventuels problèmes rencontrés, et de prevoir les binomes pour le lendemain ainsi que les taches a demarrer si besoin.

voila, c'est un peu rapide mais parler de tout d'un coup c'est pas simple de faire court. Si tu as d'autres questions ou que tu veux plus d'infos n'hesite pas.

[BarBal]

Je trouve ca intéressant comme méthode.

J'ai découvert XP par hasard sur le web et j'ai découvert 1 ou 2 ouvrages en librairie. Je vais m'intéresser de plus près à cette méthode.

[MelloW]

J’ai eu la chance de faire mon stage de fin d’étude dans une boite qui pratiquait l’XP. Ce qui m’a le plus impressionné c’était l’ambiance qui y régnait. Par exemple : un des boss participait aussi au « pair programming » (alors qu’il ne maîtrisait même pas le langage utilisé)… ce qui avait le mérite de mettre tout le monde sur un même pied d’égalité.
J’aurais voulu connaître ton expérience personnelle en terme d’ambiance, de convivialité, etc. comparé aux méthodes plus classique. Merci ! (je cherche du boulot, cela pourrait orienter ma recherche)

[virgile04]

En ce qui concerne l'ambiance y'a pas photo!!!
dans les open spaces ou l'on ne pratique pas XP là ou je travaille, la lus part des gens ne se parlent pas et le pire c'est que certains bossent avec un walkman, donc pour la communication c'est pas ça. De notre coté, comme l'on travaille en binome, il est facile de comprendre que l'on communique en permanence, le stand up meeting, le planning game font aussi que les gens se parlent echangent leurs points vus. Et comme tout le monde toutche à l'ensemble du cote, il n'est pas rare de demander à un autre developpeur des infos. Si on regarde en dehors du boulot en lui même, on s'entant tres bien, mieux avec certains que d'autres, mais ça c'est normal, on discute de tout, le midi ayant la chance d'avoir un terrain de foot pas loin de boulot on va, une fois par semaine, jouer au foot au faire un ultimate, au debut entre nous, mais plus le temps passe plus on entraine des gens d'autres equipes avec qui on est en contacte pour le boulot.
Ce qu'il faut remarquer c'est que pour avoir un ambiance comme ça, il faut deux choses:
- que la personne qui forme l'équipe puisse choisir les personnes qui la composent, et son choix ne sera pas facile car il faut trouver un groupe homogene (sans parler des capacites techniques j'entends)
- que les personnes adhérent à l'esprit demandé par XP (binomage, forte collaboration).
XP fait qu'il y a une bonne ambiance, voir tres bonne, mais cela demande des efforts à tous pour faire qu'elle reste. De toute façon il serait impossible de travailler avec des gens qui ne se parlent pas et ne s'apprecie pas un minimum.
Pour info, si une personne détruit complétement le groupe, il est préconisé de la retirer de l'équipe.

[virgile04]

C'est vrai que mon expérience se passe bien et que je crois beaucoup en XP, car ça ne repose en fait que sur le bon sens....
Dans le bureau ou je travaille nous sommes 6 développeurs, un client et un coach.
Pour les tests nous utilisons en effet CppUnit, et ce n'est rien de dire que c'est tres utile ne serait ce que pour le non-regretion car on la decouvre tout de suite et pas des lustres apres ce qui permet de faire la correction necessaire tout de suite et surtout de savoir exactement ce qui l'a causé (si on la decouvre par hasard, va savoir qu'elle est son origine depuis deux mois que cette fonctionnalite n'a pas été essayée). D'habitude les gens n'adherent pas de suite, mais un peu de pratique les convaint généralement assez vite. tu dois avoir à faire à des bretons :o))))))
Nos Itérations débutent le lundi et durent deux semaines. Les releases se font en fonction des demandes du client, donc aucune regularite.
Pour ce qui est d'"ecarter" quelqu'un, non ça ne m'ai jamais arrivé. Tout le monde se plie à peu pret aux regles, et puis comme partout, au sens de l'equipe, tu as des amis et des collegues ;o)

[MelloW]

Merci pour ton feedback!
Les boîtes qui font de l'XP à bxl vont recevoir mon CV

[Air Marty]

C'est vrai que "eXtreme Programming" cela fait très vendeur comme nom.
Ce qui est dommage c'est que cela fait un peu tête brûlé et cela pourrait avoir une connotation négative dans le cadre d'une nouvelle pratique à "vendre" à des dirigeants qui n'y entendent rien à l'ingénierie logiciel.
L'eXtreme Programming est une évolution dans la pratique du développement logiciel qui confirme les tendances d'autres pratiques/méthodes, que ce soit dans des méthodes comme RUP (Rational Unified Process) ou bien les modèles CMM (Capability Maturity Models) du SEI.
Quelles sont ces évolutions et quelles sont ces tendances ?

Premier constat le développeur est l'ouvrier de l'ingénierie logiciel et il fait de la technique. Alors plutôt que de lui demander d'apprendre et de maîtriser une méthode complexe on va plutôt s'attacher à formaliser les bonnes pratiques qui remontent du terrain (Best Practices de CMM).
Ensuite il ne faut pas laisser le développeur livré à lui même, une bonne équipe de développeur moyen sera toujours plus efficace que 2 ou 3 "mercenaires" travaillant chacun dans leur coin. Donc travail en binôme systématique (Pair Programming cela fait mieux), pas de spécialiste et pas de mercenaire.

Simplifier les revues d'avancement et fixer les objectifs à une échelle de temps humaine, pas plus de 15 jours (principe des incréments dans RUP), ce qui permet à chacun d'avoir des objectifs précis et de s'apercevoir de la moindre dérive. Faire les revues d'avancement debout en quinze minutes consiste à formaliser les informations échangées lors des pauses café (ce qui fait partie de la communication informelle dans l'entreprise et dont le contenu peut-être parfois vitale pour l'avancement d'un projet).

Autre principe : être capable de livrer des versions prototypes très tôt et souvent pendant le développement (principe de prototypage itératif qui n'a rien de nouveau), ceci afin de toujours garder un objectif en vue "le travail effectué correspond-il au résultat attendu par le client ?". Détail important mais non négligeable cela engage très tôt client dans son rôle de validation et d'acceptation du résultat. Ce qui a pour conséquence l’implication beaucoup plus importante du client durant le développement.

Ces nouvelles méthodes/pratiques remettent en cause l'approche classique du cycle de vie (cycle en V) du logiciel et les risques de l’effet tunnel (avoir un résultat après plusieurs mois de mise en place d’une architecture).
L'eXtreme Programming n'est ni plus ni moins que la formalisation de pratiques éprouvées qui découlent de l’expérience de nombreux développeurs et chefs de projet.

Bien que ce soit une pratique eXtreme il ne faut pas perdre de vue les fondamentaux : maîtrise de la technique (codage), systématisation de la relecture du code (travail en binôme) et des tests unitaires, communiquer et surtout « faire simple ».

Conclusion : faîtes vous plaisir mettez vous à l’eXtreme Programming.