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 !

212.198.57.87 3 oct 2004 à 09:02 (CEST)