Discussion:Extreme programming

Graphique

Le graphique "Le cycle de l'Extreme Programming" est intéressant mais trop large. Sur mon écran 1000x700, je ne l'ai pas en entier. Et tt le monde n'a pas cette résolution. --FvdP 12 nov 2003 à 20:24 (CET)

Très bonne remarque... Traroth 12 nov 2003 à 20:29 (CET)

Voila, je l'ai passé de 1080 à 750 de large. C'est mieux (suffisant) ? Ca devrait même aller en 800x600, là, je crois, en supposant que quelqu'un utilise encore cette résolution.

Merci ! (il y a aussi ceux qui ne mettent pas leur browser en plein écran...)

Et également ceux qui naviguent depuis un PDA ou smartphone..

Fondement ?

Ce qui est présenté ici sous le nom d'"extreme programming" ressemble étrangement à ce qui est fait depuis longtemps en développement de logiciel depuis l'apparition des méthodes objet. D'où question : l'appellation a-t-elle un fondement, où s'agit-il juste d'une tentative marketing de quelques professionnells et/ou universitaires pour essayer de se faire de la pub ?

Détaillons :

• La communication : c'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens de mémorisation ;

On n'a jamais vu de cycle de développement ne comprenant pas de très fréquents meetings, même au plein coeur des années 60.

• Le courage : il est nécessaire à tous les niveaux et de la part de tous les intervenants, notamment chez les développeurs (quand des changements surviennent à un stade avancé du projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses demandes) ;

L'habitude prise depuis les années 70 face à quelques clients indélicats et mauvais payeurs a été de garder avec le client un contact aussi étroit que possible afin d'éviter les malentendus, et surtout de présenter lors de meetings suivis de compte-rendus écrits (en lui faisant signer le compte-rendu) toute déviation même mineure aux plans initiaux.

• Le retour d'information (feedback) : les itérations sont basées sur les retours d'informations du client, permettant une adéquation totale entre l'application finale et sa demande ;

Il n'est tout simplement pas possible de travailler autrement, et depuis au moins 30 ans.

• La simplicité : en Extreme Programming, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir préalablement des évolutions futures n'a pas de sens.

C'est précisément ce qui a amené à introduire les méthodes objet dès que Simula a commencé à être un peu connu, donc à partir de... 1967 !

Le graphique même est celui que l'on voyait partout depuis les années 60, à ceci près qu'il était présenté sous forme d'ordinogramme et non de graphe, la seule autre innovation ayant été de le disposer en horizontal au lieu de vertical.

Le nom de la méthode suggère aussi son peu de fondement : faute de pouvoir la caractériser par une fonctionnalité bien claire, comme jadis la programmation structurée ou la programmation objet, on se résume à lui adjoindre un adjectif passe-partout et valorisant ("extreme") qui ne semble avoir d'autre signification que "notre méthode (si méthode il y a) elle est plusse mieux". Ca ne semble vraiment pas sérieux et soit il s'agit de simple esbroufe, soit il y a du fondement et il faut en ce cas en faire une présentation plus sérieuse. 212.198.57.87 3 oct 2004 à 09:02 (CEST)

Contrairement à ce que les deux usager ci-dessus crois, le Extreme programming est une méthode populaire et reconnue. Il est certain que pris individuellement chaque principe n'a rien de révolutionnaire, mais combinés, l'approche est intéressante. Il y a beaucoup de livres sur le extreme programming et il est enseigné dans plusieurs cours universitaires. Je vous suggère d'ouvrir un de ces livres pour élargir votre culture. Pour ce qui est de la page, je ne l'ai pas lu en profondeur. Il y a surement des détails à ajouter. Pfv2 17 août 2005 à 01:31 (CEST)

L'auteur lui même le dit : il n'y a rien de révolutionnaire dans la méthode. Par contre on essaie d'appliquer tous ces principes à l'extrème et de bénéficier de leurs renforcements mutuels. Vous dites que ces valeurs sont présentes depuis des dizaines d'années, mais consultez les principes de la méthode. À ma connaissance ils sont loin d'etre appliqués par l'industrie du logiciel. Les tests? Certains en font, mais en XP on n'ecrit pas une ligne de code sans avoir un test correspondant. Le feedback est important? En XP le client rejoint l'equipe de développement et on livre une nouvelle version toutes les mois. La communication entre développeurs est important? On les fait travailler en binôme. Les valeurs rejoignent evidemment celles de tout projet de développement, mais en pratique le développement est très différent. Effectivement il faudrait peut etre faire ressortir ça dans l'article. Piglop 5 juin 2006 à 12:48 (CEST)

J'ai commencé la réécriture des valeurs. Piglop 9 juin 2006 à 22:10 (CEST)

De toute façon une chose est sûr, l'extreme programming est reconnue. En tout cas, elle est enseignée dans des école d'ingénieur en informatique logiciel, je suis bien placé pour le savoir...De plus, il n'y a aucun rapport avec le fait de parler de programmation structurée ou objet, certe l'extrême programming se prête mieux à la POO mais il s'agit avant tous d'une méthodologie de génie logiciel, de gestion de projet et non d'une méthode ou paradigme de programation. --Maniak 5 juillet 2006 à 20:28 (CEST)

Il faut rester simple dans ce débat: cette méthode XP dite de "Programmation eXtrème" (je suis francophile) doit être replacée également dans le temps, hors il me semble qu'une personne ici se sente gênée parce qu'il n'y a pas d'innovation dans cette méthode. Elle n'en est pas pour autant inutile... Lors de la création de cette méthode (début des années 2000) les chefs de projets sentent bien la toute-puissance des mastodontes de la gestion de projet. Cette bureaucratie et toute la paperasserie qui y est associée mène à des échecs de projets qui auraient vu le jour autrement.

Cet article de Wikipédia n'a pas pour but de dire si la méthode est bonne ou non, ni si elle est un plagia. Tout au plus ceci peut être indiqué (ou reproché) au sein même de celui-ci. Ainsi le sigle de non pertinence me semble déplacé et n'est à mon avis pas mérité.

--Thomas BAECKEROOT 16 août 2006 à 19:23 (CEST)

J'ai ajouté le sigle de non pertinence dans une section précise. Malheureusement le modèle le place aussi en haut de l'article. Il ne concerne que la partie "Une méthode qui ne fait pas l'unanimité". Voir la discussion (enfin, mon point de vue plutot) ci-dessous ("Inadaptation à l'environnement économique et autres critiques"). J'attendais des réaction avant de remplacer cette partie. Piglop 16 août 2006 à 20:52 (CEST)

Article de qualité

Je trouve que pour un article de qualité, celui-ci a un défaut rédhibitoire : son titre n'est pas en français. On m'expliquera peut-être que c'est une notion trop subtile pour qu'on puisse l'exprimer en français. Je note aussi dans le texte : refactoring, partner, relooking, driver, feed-back et j'en passe, sans compter dans le schéma planification release. Somme-nous bien dans une encyclopédie en français ? Spedona 6 jan 2005 à 08:43 (CET)

Si on choisit d'avoir des articles un peu techniques, il faut également en accepter le vocabulaire spécifique. Il reste à vérifier que les termes utilisés sont expliqués ailleurs dans le cas où un simple dictionnaire ne suffirait pas. Et que je sache, personne n'a jamais critiqué le titre de l'article "management"...

Je pense que le "planification release" n'est pas excusable dans la figure. Ni "relooking". D'ailleurs, il y a une faute dans la figure "scénarii". Il faudrait la corriger. Et il faudrait décrire textuellement la figure. Ce n'est pas correct de balancer une figure comme ça et de ne pas l'expliquer. Je ne crois pas que ça mérite un article de qualité. Pfv2 15 août 2005 à 19:17 (CEST)

Ok pour ces remarque mais cela reste un article informatique donc il me semble normal qu'il soit composé de mot anglais communément utilisé dans la litérature spécifique francaise.

La moindre des choses pour pouvoir prétendre au titre d'article de qualité serai au moins de proposer une traduction française, quitte à en discuter ensuite ici-même. A ma connaissance aucun terme informatique n'a de traduction française, dans le cas présent:

Extreme programming = Programmation extrême ou méthode XP

refactoring = re-conception ou ré-écriture

feed-back = retour d'information

driver = pilote

etc...

Conclusion: suggérer au moins une traduction.

--Thomas BAECKEROOT 16 août 2006 à 19:35 (CEST)

Lien

voici un lien qui me parait bien résumer la programmation en pair : peut etre peut il aider la réflexion de certains, ou peut etre serait il bien de le placer à la fin de l'article

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

Radicalité

Je ne suis pas d'accord avec ce passage : "L'Extreme Programming est parfois critiqué pour sa radicalité. En effet, si on en croit les chantres de cette méthode, et notamment ses auteurs, on ne fait de l'Extreme Programming que si l'on met en place toutes les pratiques de la méthode, ce que certains trouvent trop contraignant et contraire à l'esprit agile, qui doit justement permettre d'assouplir l'aspect méthodologique des projets informatiques."

Kent Beck ne dit jamais dans son livre qu'il faut appliquer toutes les pratiques pour faire de l'extreme programming. Il dit que "chacune des pratiques est insuffisante en soi (à l'exception peut-être des tests)", donc qu'il faut au moins appliquer plusieurs pratiques pour tirer profit de la méthode. Mais il n'est pas indispensable de toutes les appliquer pour faire de l'XP. On peut très bien ne pas avoir de client sur site par exemple, ou ne pas faire d'intégration continue ni coder en binôme. Dans ce cas on perd certains avantages de la méthode, mais pas tous. La seule pratique probablement indispensable c'est les tests. Toutes les pratiques en tirent profit, et certaines ne fonctionnent simplement pas sans tests. Piglop 5 juin 2006 à 12:04 (CEST)

Inadaptation à l'environnement économique et autres critiques

"On reproche aussi parfois à cette méthode d'être mal adaptée à l'environnement économique : comment prévoir la durée et le coût d'un projet ?"

Avec le jeu du planning. Si les délais sont courts (réalisation d'un devis sous huitaine par exemple), Kent Beck suggère une variante du jeu où les estimations sont plus larges.

Les remarques de la partie Une méthode qui ne fait pas l'unanimité ne me paraissent pas très pertinentes. Elles semblent provenir de personnes peu documentées sur l'XP. Je suggère de supprimer cette partie, ou de la remplacer par une partie qui dresserait les cas où l'XP est difficilement applicable (grosse équipe, blocage culturel ou environnement inadapté).

Piglop 5 juin 2006 à 18:45 (CEST)