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 stucturé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)

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)

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. - Heureusement c'est un mot anglais il doit rester avec ce titre à mon avis. > Je note aussi dans le texte : refactoring, partner, relooking, driver, feed-back et j'en passe, sans compter dans le schéma planification release. - 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.

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.