Discussion :

[mmz]

Salut,
y'a-t-il quelqu'un qui pourrait m'aider à comprendre le processus de l'Extreme Programming, j'ai lu quelques documents sur la méthodologie mais j'ai des questions à poser, j'espère que quelqu'un m'aiderais pour que je puisse appliquer la méthodologie XP dans des projets réels
merci d'avance pour vous.

[Invité]

Quelles sont les questions que tu te poses ?

[Eowyn]

On veut bien t'aider, mais si tu n'es pas plus précis... ça va être difficile !

[mmz]

plusieurs questions comme:
Est-il possible d'appliquer la méthodologie dans mon cas (je suis le seul à travailler sur tous le projet) ?
Est-ce qu'il faudra utiliser des diagrammes UML (par exemple les use-cases dans les user stories)?
Je n'ai pas bien compris aussi la partie des tests unitaires, sont-ils spécifiques pour chaque langage de programmation( parcequ'on parle dans cette partie de "JUnit" pour java)?
je suis dsl pour toutes ces questions et merci d'avance pour ton aide.

[mathk]

Bein les test unitaire sont pas forcement spécifique a un language. Ta question n'a pas beaucoup de sense (dsl).

JUnit et un outil pour lancer tes test en smalltalk c'est SUnit en C# c'est NUnit ...

Les Test sont un moyen de s'assurer que chaque foncitonnalité que t'implèment ne casse pas du code.

Ils servent aussi de documentation

[Eowyn]

plusieurs questions comme:
Est-il possible d'appliquer la méthodologie dans mon cas (je suis le seul à travailler sur tous le projet) ?

ben si tu ne travailles pas en direct avec un user, je ne vois pas l'intérêt de faire de l'XP

Est-ce qu'il faudra utiliser des diagrammes UML (par exemple les use-cases dans les user stories)?

Je ne crois pas que XP préconise un language ou un autre. UML reste très pratique pour les use-cases...

Je n'ai pas bien compris aussi la partie des tests unitaires, sont-ils spécifiques pour chaque langage de programmation( parcequ'on parle dans cette partie de "JUnit" pour java)?

Il est évident que selon le language utilisé, tu ne vas pas faire de tests unitaires (les tests unitaires sont réservés aux languages 'Objet' ce me semble).
Par contre tu feras des tests fonctionnels (chaque élément séparément du reste fonctionne), chaque éléments avec le reste fonctionne,
des tests de non-régression (lorsque j'intègre un nouvel élément, le reste fonctionne toujours et sans erreur)
et c'est souvent pas mal de faire des tests de performence et/ou de stress system. (comment réagit ton programme et les machines quand tu les pousses un peu, beaucoup ?)

Ce sont les principaux tests préconnisés, il y en a encore un paquet possible...

XP est le plus souvent utilisé en Europe pour de cours projets, quand on est vraiment à la ramasse ou à l'arrache (voir le site... ). Lorsque les utilisateurs peuvent vraiment être disponibles pour travailler avec le développeur, les développeurs en fait. Cela permet de travailler très vite, avec un maximum de sécurité si l'on prend tout de même le temps de faire la doc et les tests.

A dispo....

[mmz]

merci bien pour ton aide,
pour mon cas, le client n'est pas toujours disponible pour me contacter, je suis le seul à travailler sur le projet,
me propose-tu une autre méthodologie à suivre pour concevoir mes projets?
je précise que je travaille dans le développement web

[ypicot]

Tu peux jeter un coup d'oeil à RUP (rational unified process), qui complète (et recouvre parfois) l'XP.

Les méthodos sont pour moi des points de départ. Difficile de faire du pair programming, car je suis seul (moi aussi). Par contre, j'ai découvert avec ravissement les uses-case (attention, les uses-case d'XP sont beaucoup plus fins que les uses-case d'UML). Donc, tu peux piocher et te construire ta propre approche.

Un conseil cependant : n'essaie pas dès le début de faire du "tout XP" ou "tout RUP". Sans formation et accompagnement, c'est la plantade assurée, ou presque.
Commence plutot par adopter un point (par exemple le développement piloté par les tests), puis un autre (par exemple les uses-case) dans le projet suivant, etc...

Yvan

[Marc Lussac]

A lire sur l'extreme programming :

http://medina.developpez.com/cours/extreme-programming/

et : http://lagace.developpez.com/extreme-programming/

[TonioLeRital]

Je pense que RUP est plus approprié dans ton cas, cependant il faut savoir que XP est une méthode qui pousse de nombreuses pratiques de RUP à l'extrème.
Nous utilisons RUP dans nos projets, mais également certaines pratiques d'XP en complément, Voici ces pratiques:
- le développeur n'est pas une m.... comme dans un processus en cascade : il participe en plus du développement, à la capture des besoins, à la conception, et à certaines phases de test (sauf ceux de recettage)
- test-unitaire systématique (de préference avant le codage)
- relecture et refactoring du code.
- n'en faire pas plus que ce qu'il n'en faut.
- Résoudre un problème en cherchant la solution la plus simple (qui est toujours la + difficile à trouver)
- pas de commentaires de code, si il y a besoin de mettre un commentaire c'est qu'un découpage fonctionnel peut encore avoir lieu... -> bien souvent cette approche vous amène à scinder une seule et même méthode initiale en plusieurs sous-méthode interdépendantes, ce qui porte fréquemment à la création d'un objet regroupant la responsabilité de la méthode initiale, cela affine d'autant votre modèle objet, et enfonce le clou de la maintenabilité.

Par contre, je trouve que l'étape dl'analyse d'XP qui court-circuite les Use cases est beaucoup trop poussé. Une analyse sous-forme de scénarii me semble vraiment insuffisante car bien que je préconise de rédiger intégralement les scénarii que comportent un use case, un use case reste un support important pour le découpage de vos itérations UP, un support pour la conception de vos objets "control" du modèle, et surtout un excellent support visuel pour dialoguer avec le client grace à leur diagramme.

Un autre point : L'idée de faire relire son code par plusieurs personnes est également très intéressante mais de là à détacher une ressource uniquement pour surveiller ce que le poto combine c'est à mon avis assez ralentisseur, par contre lire le résultat final ça oui c'est enrichissant pour le code et le développeur, cela permet la simplification permanente du code, de faire tourner des pratiques de programmation intéressantes (patterns) et qui plus est sur des cas concret, bref cela facilite l'apprentissage en communauté et amène l'equipe à un niveau de compétence à peu près equivalent, et croyez-moi on y gagne beaucoup en efficacité !!

voilà, pour ma part.
bon courage,