Discussion:Extreme programming

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

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)

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.