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)

Non il n'y a pas de faute dans "scénarii", c'est bien le pluriel de "scénario".

"scénarii" n'existe pas, le pluriel du mot français "scénario" est "scénarios", le pluriel du mot italien "scenario" est "scenarii".

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 pas 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)

J'ai remplacé cette partie. Piglop 27 août 2006 à 03:03 (CEST)

Réaction à "ce qui est présenté ici ressemble étrangement à ce qui est fait depuis longtemps"

Effectivement, XP s'apparente avant tout à un guide de bonnes pratiques dont certains semblent dire qu'elles sont éculées depuis nombre d'années (on parle des annèes 60).

Quand on a la chance de travailler au sein des services informatiques des grandes entreprises françaises (le top 100 par ex.) ainsi que des grandes SSII "leaders", on peut mesurer aisement que notre industrie s'est orientée vers des chemins à l'eXtreme oPposé en matière de gestion de projets de développement et de rapports avec la MOA (utilisateurs).

Savoir les fondements théorique n'est pas synonyme de mise en pratique - loin de là.

Nouvelle version d'XP (2004)

Dans la nouvelle édition de son livre Extreme Programming Explained : Embrace Change, Kent Beck propose un important remaniement de la méthode XP, avec la séparation des pratiques en deux catégories, la suppression de certaines pratiques et l'introduction de quelques nouvelles. Voir http://www.agilexp.org/downloads/TheNewXP.pdf pour plus de détails.

L'article parle uniquement de la première version, il faudrait certainement le mettre à jour et déplacer les pratiques abandonnées vers une section "historique", mais je ne sais pas trop comment structurer ça.

BokC Je pense qu'il serait interressant de décrire un peu plus "Le respect".

Avertissement : neutralité de point de vue

Merci à l'utilisateur Piglop de prendre en compte le fait que tout le monde ne voit pas que des avantages à telle ou telle méthode, et que tous les points de vue doivent être représentés. Y compris le fait, dans un langage plus édulcoré et policé, que la programmation en binôme est par certains aspects déshumanisante, et qu'elle peut induire des pertes de productivité qui réduisent les gains espérés. Concernant la source, dire que 1+1=2 n'a pas forcément besoin d'être sourcé (mais juste d'être dit).

Je suis d'accord qu'il est toujours possible d'améliorer l'expression de certains élements, et comme les autres mes modifications sont améliorables. Mais, ce serait dommage d'en venir à un conflit d'édition à mettre entre les mains d'admins pour simplement respecter une neutralité de points de vue.

Merci.

Gloran 11 décembre 2006 à 12:00 (CET)

Pour moi il y a deux problèmes à ta modification :

• d'abord ça ne concerne que la programmation en binome, donc pour moi il est inutile de le redire ici. On ne va pas mentionner cet aspect de la programmation en binome sur chaque page qui y fait référence. Ni mentionner pour chaque aspect de l'extreme programming qu'il y a des inconvénients : il y a des inconvénients à avoir un client sur site, à écrire des tests, à l'intégration continue, etc. Le fait que chaque chose présente des avantages et des inconvénients est quelquechose qui n'a pas besoin d'etre mentionné, sauf si on précise lesquels. Mais encore une fois, dans l'article approprié.
• Ensuite je n'ai jamais lu nul part qu'il s'agissait d'un problème pour la programmation en binome (mais il faudrait en discuter sur l'article correspondant). Donc j'ai l'impression qu'il s'agit juste de ton point de vue, mais je me trompe peut etre. J'ai cherché rapidement sur le net mais je n'en ai rien trouvé. Si c'est si evident, c'est forcément quelquechose qui ressort des etudes qui ont été faites sur la programmation en binome. Si tu trouves quelquechose je ne verrai aucun inconvénient à ce que ce soit mentionné dans l'article Programmation en binôme.

Et on est bien loin d'un conflit d'édition. Il est inutile de déranger des admins pour si peu.

--Piglop 11 décembre 2006 à 17:22 (CET)

La neutralité de point de vue, c'est une notion assez claire. Si je me permets un résumé basique dans notre contexte, si on met les avantages, on met les inconvénients avec, que ceux-ci soient liés à un aspect précis de l'article ou non. Un minimum de redondance ne nuit pas forcément à l'encyclopédie, si celle-ci augmente la lisibilité : en l'occurrence, je ne redondais pas, je précisais que certains inconvénients étaient décrits dans un autre article. Article qui se positionne ici plutôt comme un sous-article vis-à-vis de cet article principal. C'est pourquoi je révoque cette modification pour cause d'absence de neutralité de point de vue. En cas de nouveau conflit d'édition sur le sujet, je pense que je ferai appel à la Communauté pour le résoudre. Ayant contribué à cet article à ma modeste façon, je comprendrai qu'on pense ici que je suis juge et partie et la Communauté tranchera alors. Bien entendu, tu peux modifier l'article et étayer les pours et les contres à souhait. Gloran 4 janvier 2007 à 10:56 (CET)

C'est surtout un probleme de source et de pertinence. Si tu (re)lis les Principes fondateurs tu verras que la neutralité de point de vue "implique de citer des sources vérifiables et qui font autorité autant que possible". Avec tout mon respect, je ne pense pas que ton point de vue fasse autorité. Quand j'ai écrit le passage sur les environnements défavorables, je me suis basé sur un livre de Kent Beck, l'inventeur de la méthode. Le reste de l'article découle aussi pour beaucoup de cette source qui, je pense, est plus que pertinente pour le sujet abordé. Par contre ce n'est qu'un seul point de vue, on est d'accord, et j'en accepterai volontier d'autres, si on pouvait au moins juger de leur pertinence. Mais ce débat devrait avoir lieu dans l'article Programmation en binôme.

En attendant qu'on ait reglé le problème dans l'article en question, je laisse la mention ici. Mais je la reformule. --Piglop 4 janvier 2007 à 12:55 (CET)

Il existe une limite à la notion de sourçage. Il suffit de regarder certains articles où un contributeur marque chaque mot avec le marqueur source nécessaire. Il existe aussi une notion de base, le bon sens, et même en mathématiques un axiome n'a pas besoin d'être démontré. Par exemple, si j'écris que 2 + 2 font 4, devrais-je sourcer ? Non, évidemment. De même que si j'écris que si je passe les mains sous l'eau elles seront mouillées : le bon sens est ici ma source, la source par défaut : si j'affirme le contraire (2+2=5 ou je ne suis pas mouillé) il faudra là pour le coup que je source ou que j'explique la nature exacte de l'expérience réalisée. C'est la même chose ici : si j'écris que partager le même ordinateur qu'un collègue, c'est aussi mettre en commun des outils de productivité de nature personnelle tel le mail, ce qui ne plait pas forcément à tout le monde, qu'y a-t-il à sourcer, puisque je ne fais que constaster une évidence qui s'impose d'elle même ? A moins que tu ne considère que l'état naturel de l'être humain est d'adorer laisser aux autres le libre accès à son courrier (électronique ou papier d'ailleurs), c'est peut-être une opinion valable mais qui n'est certe pas partagée par l'écrasante majorité des êtres humains. Je m'excuse de devoir aller sur un terrain si philosophique, mais sur Wikipédia comme en tout, un peu de bon sens fait bien les choses et les simplifie aussi. Concernant la remarque sur l'emplacement du débat, je me suis exprimé là-dessus, il n'y a pas de redondances réelles, pas plus qu'ailleurs dans wikipédia. Gloran 4 janvier 2007 à 13:43 (CET)

Les remarques de bon sens n'ont pas vraiment leur place car elles ne sont pas pertinentes car chaque lecteur se les faira tout seul. Et si le lecteur ne se les fait pas tout seul, c'est qu'on s'éloigne trop du bon sens. Plus généralement, remplir un article de remarques de bon sens est un très mauvais moyen de contribuer, basé sur la flemme et les préjugés (je le sais, je m'y laisse aussi parfois aller). Marc Mongenet 4 janvier 2007 à 14:11 (CET)

Il faut rechercher des sources critiquant l'extreme programming et rapporter leur point de vue. Si on ne trouve pas de source critique (m'étonnerait, mais bon...) alors il faut indiquer que l'extreme programming n'a pas fait l'objet d'évaluation critique. Marc Mongenet 4 janvier 2007 à 14:07 (CET)

Source (très) documentée relevant les avantages/inconvénients le l'XP : http://members.cox.net/cobbler/XPDangers.htm (en anglais)

Vectorisation du schema

Bonsoir,

J'ai publié une version vectorisée (par mes soins) du schéma du cycle de l'XP. J'espère ne pas avoir fait d'erreur :P n'hésitez pas à me demander si vous avez des questions. Note : n'ayant fait qu'une vectorisation je publie le schéma sous la même licence que l'original.

XP et Lean

Bonjour à tous,

J'ai récemment lu ce papier de Kent Beck (je suppose sans certitude qu'il date de 2007 car il n'y a pas trace de la source avant 2007). Il met en évidence des points communs entre Lean et XP. Il est également intervenu au Lean IT Summit de 2015 (vous pouvez voir la vidéo sur youtube en cherchant "Extreme Programming 20 years later by Kent Beck"). Tout cela me fait dire qu'une section sur le sujet pourrait donner un éclairage supplémentaire à XP, qu'en pensez-vous ?--Nibbler869 (discuter) 29 juillet 2019 à 19:45 (CEST)