Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Gabriel () le 30/03/2004 à 08:14. (lien). Évalué à 4.

  L'extreme programming c'est aussi la compilation de toutes les évidences des gens de métier. Quand tu sais rien faire tu deviens chef de projet, et tu comptabilises le temps des autres, puis tu exploses tes temps.
  Parce que pour faire de l'extreme programming il faut savoir un peu travailler. Ton projet mené à la va comme je te pousse s'est planté? Quand tu gères un projet de amnière bien serrée, il se plantera tout autant, au moins l'avantage c'est que tu sais que ça arrive, tu as un joli tableau qui te montre les dérapages.
  Ceci dit c'est vrai que pour un gros machin autant un peu serrer les boulons. Mais dans la plupart des cas, en contexte et en réponse avec des utilisateurs, ça me paraît plus q'indiqué.
  L'extreme programming augmente le nombre d'itérations, et réduit leurs durées; bien sûr il vaut mieux avoir des utilisateurs sous la main- oui je sais pour un informaticien, un utilisateur c'est au mieux un gros mot, au pire une menace - mais franchement quand on sait ce qu'on a, pas besoin de faire des plans de folie pour créer une pyramide, tu as toutes les chances de te retrouver avec une pyramide carrée.
  
  Tu sais ce que c'est qu'un chameau? C'est un cheval dessiné par un comité d'experts.

  --
  Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Cédric Girard (page perso, ) le 30/03/2004 à 13:23. (lien). Évalué à 3.

    Justement XP ne se complait pas dans les specs et comités d'experts. Plutot que de tirer des plans, on fait des essais (spikes), on met une maquette ou une premiere version du projet dans les mains du client, afin qu'il vérifie que les devs ont compris son besoin, et qu'il vérifie lui même qu'il a bien exprimé son besoin.
    
    Tu n'as surement jamais pratiqué XP pour en parler ainsi.

    • [^]Re: Rencontre AFUP sur l'Extreme Programming

      Posté par Gabriel () le 30/03/2004 à 14:44. (lien). Évalué à 2.

      j'ai du certainement très mal m'exprimer puisque justement j'essayais de dire que l'XP "ne se complait pas dans les specs et comités d'experts." comme tu le dis.
      En fait ici, où je fais la sieste travaille, on fait de l'XP sans le savoir, coder à deux, avancer par petits bons, doubler les connaissances (quoique..), être absoluement proche des utilisateurs, ne pas se perdre dans les docs.. Alors j'en ai une expérience qui est à la fois proche et naîve (native?), comme Jourdain qui faisait de la prose sans le savoir.
      Avec des conclusions contradictoires. D'un côté, pour répondre au client (à l'utilisateur), pour maintenir et faire évoluer doucement un système d'information, rien de mieux des micro itérations. Mais dès qu'il s'agit de développements qui demandent une certaine maturation avant tout développement, il vaut mieux pas être drivé par les utilisateurs. Uu si tu es dans un cycle un peu long de devs, c'est la panique.
      De plus cela dépend du codeur: le malin prévoit les refactoring à venir, l'idiot attend que ça plante pour refactoriser. Le malin prévoit un tout petit peu les dévelppements futurs de l'appli.
      Encore une fois, c'est une expérience bizarre que j'ai puisque d'un côté elle a beaucoup en commun en pratique avec l'XP et rien en théorie (les méthodes de travail ici n'ont pas été théorisées)
      
      J'ai lu ce midi et adoré la revue du livre "XP Refactored" sur ./ dont parle anonyme512.
      http://books.slashdot.org/article.pl?sid=04/03/24/2118215(...)
      ça m'a ouvert les yeux sur pas mal de choses sur cette méthode et en même temps sa critique la rend plus crédible.
      La revue met l'accent sur la gurutisation de cette pratique et de ce que cela peut avoir de dangereux. Je me demande si c'est pas cela le plus grand danger, tout prendre de l'XP. D'un autre côté l'article montre avec humour que tu as le droit de tout faire dans XP, et que cela reste de l'XP, sauf que quand ça ne marche plus c'est que tu n'as pas suivi les Recommandations et que ce n'est plus de l'XP...
      Mais bon, qq citations qui vont dans mon sens (ou plutôt dans le sens que j'aurais dû donner à mon post si je l'avais pas écrit avec mes genoux)
      
      Combine flexibility with actual design and risk control. Perhaps not surprisingly, this method resembles a lot what you'll often find small teams of skilled programmers doing on their own. And if you asked them what methodology they were using, they might even say eXtreme Programming, even though they aren't.
      
      They also point out that most of XP is a pretty good mode in which to maintain already developed and mature software.
      
      Now I know people are going to read this and indignantly retort that XP is based on some good ideas, and I fully agree. XP's starting assumption, as explicitly stated by Kent Beck, is that if a little of something is good then as much of it as possible is even better. I like chocolate, but I'm not going to eat to exclusion.
      
      Et la conclusion :
      
      Frankly, I got a better feel for the actual strengths of XP from Refactored than I did from any of the pro-XP books, including Explained. Which is pretty good for a book whose stated purpose is to deflate XP.

      --
      Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par Cédric Girard (page perso, ) le 30/03/2004 à 16:08. (lien). Évalué à 1.

        Vrai que la critique est toujours interessante, même si les extraits que j'ai lu du livres (sur le pair programming) semblent plus vouloir tourner XP en dérision (genre citer des posts sur usenet avec des fautes de frappes ou de grammaire - et les faire remarquer).
        Si j'ai un peu d'argent en trop, je lirai le livre.
        
        Ceci dit, il est évident que les pratiques s'appuient les unes sur les autres, et je ne vois pas le soucis la dedans.
        Pour ce qui est du "malin", je travaille tous les jours en essayant de faire de l'XP au plus proche, et je prévois rarement mes refactoring, ça empeche pas d'avoir du code propre, qui passe les tests, et évolutif.

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Philippe Fremy (page perso, ) le 30/03/2004 à 12:07. (lien). Évalué à 4.

  Ben moi j'ai deja vu des projets reussir (bien que|parce que|où) on avait applique une partie des methodes d'extrem programming. De la conclure que la methode a elle seule ne peut en rien garantir ni le succes, ni l'echec d'un projet, il n'y a qu'un pas qu'apparamment, tu ne franchis pas.
  
  On peut planter ou reussir n'importe quel projet donc quelle que soit la methode de dev utilisee si on y met la volonte qu'il faut: un mauvais manager, des developpeurs qui s'en foutent ou imcomptents, des problemes qui ne sont pas remontes a temps, ... Dans ce cas, c'est pas Extrem Programming ou le methode machin-chose qu'il faut blamer.
  
  > c'est un chateau de cartes constitué par toutes les mauvaises
  > pratiques du développement logiciel
  
  Je ne suis pas du tout d'accord. On parle bien de la meme methode la ? Ce que j'ai retenu d'XP:
  - une tres forte pression sur les tests
  - faire des releases courtes centrees sur le fonctionnalites les plus importantes pour le client
  - de la transparence: faire une remontee tres rapide vers le client
  - des tests encore
  - faire un suivi pousse de la realisation des taches
  
  Pour moi, ces methodes ne meritent pas le qualificatif "mauvaises pratiques de developpement". Au contraire, je pense qu'elles sont garantes de robustesse et pas mal de projet libre devrait s'en inspirer.
  
  Pour l'instant, j'ai surtout applique le principe des tests a toutes les sauces, et tous mes projets logiciels en sont sortis plus fiables. J'ai commence sur un projet de 5000 lignes ou on a trouve un bug en 6 mois (pour l'implementation d'un protocole de transport). Le fais d'avoir fait des tests de toutes les couches de transport m'a permis de simuler des conditions normalement difficilement realisables par une approche de test 'classique' et m'a permis de lever des bugs assez sournois.
  
  La, je suis sur un projet de 100 000 lignes a peu pres. Je suis tout seul et je dois avancer le plus vite possible sans pour autant me gourer. Mes partenaires apprecient _beaucoup_ mon emphase sur les tests et sont rassures quant a la qualite du projet justement a cause de ca. Ca m'a permis aussi de leur trouver beaucoup de bugs sur leur partie, qui ont ete mis en evidence la encore par les tests.
  
  Bref, pour moi, XP a permis de faire des projets beaucoup plus solides et je n'envisage pas de developper sans reflechir en meme temps aux tests et aux fonctionnalites.

  --
  phil.freehackers.org

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Cédric Girard (page perso, ) le 30/03/2004 à 13:21. (lien). Évalué à 3.

    Praticien XP depuis presque un an, je ne peux que soutenir Philippe. Que l'on me prouve que les tests, le dialogue fréquent, le fait de se concentrer sur le code plutot que sur des montagnes de documents sont de mauvaises pratiques.
    
    Pour plus d'infos sur XP, ya un wiki et une liste de discussion
    http://xp-france.net(...)

    • [^]Re: Rencontre AFUP sur l'Extreme Programming

      Posté par deftones_chris () le 30/03/2004 à 14:35. (lien). Évalué à 2.

      Que l'on me prouve que les tests, le dialogue fréquent, le fait de se concentrer sur le code plutot que sur des montagnes de documents sont de mauvaises pratiques.
      Mais cela n'est pas une particularité de l'XP.
      Perso, je ne connais pas l'XP mais ce qui tu écrits est ce que l'on m'a enseignée pour être analyste programmeur. A part la définition de "se concentrer sur le code" que je ne suis pas sûr de saisir (veux tu dire que le code passe avant l'analyse ? car si c'est ça alors je ne suis pas un X programmer ;) )
      
      Sinon en lisant les commentaires, j'ai l'impression que l'XP c'est un peu faire du développement en "balle tracante", non ? - développement des fonctionnalités au fur et mesure et à la demande, et non commencer toutes les fonctionnalités en même temps. un exemple pour être plus clair : tu fais un programme de gestion de comptes en banque, tu fais d'abord tout ce qui tourne autour de la gestion des comptes sans te préoccuper des opérations. Tu testes et valide et une fois que cela est fait tu passes à la gestion des opérations bancaires. C'est goody ou je suis à l'ouest avec le principe de l'XP ?

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par Cédric Girard (page perso, ) le 30/03/2004 à 16:13. (lien). Évalué à 1.

        Je prenais les pratiques qui me venaient à l'esprit. XP ne revendique pas de les avoir inventé, elles sont logiques et devraient être appliquées partout, mais XP me semble t'il en fait un tout cohérent.
        Ensuite en XP l'anayse est faite, mais pas forcemment dans les détails les plus précis. On ne passera pas 3 mois à ne faire que de l'analyse, pour ensuite se mettre à coder, se basant sur l'idée que quel que soit l'analyse, elle sera fausse un jour : on ne peut pas tout savoir au démarrage d'un projet, les besoins évoluent. On utilise l'experience acquise pour redéfinir le projet. Rien de sorcier, simplement XP l'ecrit dans des livres.
        
        Pour ce qui est de l'ordre des taches, on fait d'abord le plus important/urgent. Ce qui permet si le projet s'arrete d'avoir un programme qui implemente les fonctionnalités vitales, au lieu d'avoir un beau squelette qui ne fait rien.
        
        Je rappele que les réunions XP ont justement pour but d'expliquer ce qu'est XP, et qu'elles sont ouvertes.

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par Philippe Fremy (page perso, ) le 31/03/2004 à 08:49. (lien). Évalué à 2.

        Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
        
        Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
        
        Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
        
        XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
        
        Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
        
        C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.

        --
        phil.freehackers.org

        • [^]Re: Rencontre AFUP sur l'Extreme Programming

          Posté par anonyme512 () le 31/03/2004 à 10:05. (lien). Évalué à 1.

          Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
          
          Encore une fois, les tests ne sont pas le propre de XP. En méthode classique il devrait y avoir:
          1- des tests unitaires avant tout commit CVS (pour vérifier que la fonctionnalité implémentée fonctionne), et si le code produit n'est pas immédiatement testable (ce qui est le cas quand on développe les couches les plus profondes du logiciel - métier, accès base de données par exemple), il faut le préciser dans le commit CVS et revenir dessus ultérieurement (lors de l'implémentation de la partie de la couche de présentation/interface correspondante)
          2- une phase de tests et d'intégration lourde en fin de palier de développement (correspondant à un livrable)
          
          la phase numéro 2, en particulier, doit comporter un mélange de tests automatisés (qualité de code, tests de charge, etc.) et de plan de tests pour un testage manuel.
          et ce n'est pas que de la théorie, dans ma boite on a toujours travaillé comme ça (sauf l'aventure XP, sur laquelle ont avait pas la main, en fait), et ça marche.

          • [^]Re: Rencontre AFUP sur l'Extreme Programming

            Posté par Philippe Fremy (page perso, ) le 31/03/2004 à 12:27. (lien). Évalué à 2.

            Je n'ai pas pretendu que XP avait invente les tests. En revanche, la methode a popularise ou repopulairser les suite de tests automatises. La seule methode academique de dev dont j'ai entendu parle (ma formation est plutot pratique) est le diagramme en V ou on specifie les tests dans la partie descente, on code en creux du V et on fait tourner les tests dans la remontee du V. Dit comme ca, les tests sont ecrits apres le code et ne pourront pas etre utilise par le developpeur pendant son cycle de developpement. Dans cette methode classique, les tests sont repousses a la fin, ce qui garantit des gros problemes d'integration. Tout ca pour dire que dans certaines methodes "classiques", les tests ne jouent pas un role aussi important que sous XP, d'ou la distinction.
            
            Je tiens aussi a attirer l'attention sur le fait que "faire un test" n'a pas la meme signification pour tout le monde. Pour beaucoup, ca signifie avoir lance le logiciel et teste manuellement quelques patterns. Pour moi, ca signifie avoir developpe une suite de test que n'importe qui peut lancer pour valider ce tout marche. Donc quand on dit "mais je fais deja des tests", il est possible qu'on ne parle pas de la meme chose.
            
            Sinon, je suis heureux de voir que ta boite a deja une bonne politique de tests. Cela qui contredit ta remarque initiale comme quoi XP est la somme des mauvaises pratiques du metier.
            
            > si le code produit n'est pas immédiatement testable
            
            C'est beaucoup beaucoup plus rare qu'on ne pense. Pour l'instant, je n'ai pas encore rencontre de situation ou c'est le cas. Pourtant, je travaille dans la carte a puce ou la seule facon de tester du code (avec une approche naive), c'est de le mettre dans un emulateur a 10000 euro et de lancer le debugger. Mais on a reussi sans probleme, avec un peu d'imagination, a tester toutes les couches de notre systeme d'exploitation pour carte a puce et tous les outils logiciels qui l'utilisent. Et en bonus, on a des tests securitaires impossible a mettre en place sur une vraie carte.
            
            C'est possible de tester du code meme quand les couches basses ne sont pas encore disponibles et la-dessus, je suis sur que vous pourriez vous ameliorer. Evidemment, ca demande de repenser en general un peu l'architecture, mais le logiciel dans mon experience en sort grandement ameliore, en plus d'etre plus fiable. Je suis a ta disposition pour tout conseil si ca t'interesse (c'est gratuit)

            --
            phil.freehackers.org

        • [^]Re: Rencontre AFUP sur l'Extreme Programming

          Posté par deftones_chris () le 01/04/2004 à 10:03. (lien). Évalué à 1.

          ok, je saisis un peu mieux, même si pour etre franc, j'ai l'impression qu'on a fait une méthode avec les choses (qui devraient être) de bases de la programmation.
          
          Par contre, y a quelques trucs qui me chiffonne et quelques remarques dans ce que tu écris:
          Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
          Je rappelle qu'UML n'est pas un outil d'analyse :) C'est juste un langage.
          Et le truc sur les 6 mois, je ne vois pas bien: si tu codes pendant 6 mois et que le client change d'avis ? T'es aussi dans la mouise... Sauf si pour toi l'analyse se fait dans un bureau sans contact avec le client. Normallement, l'analyse est là pour répertorier et analyser les besoins du client et il serait stupide que ce dernier n'y participe pas :) C'est ce qu'on apprend en Analyse Conceptuel de Système d'Informations mais il est vrai que certains se prennent pour des dieux et ne veulent pas supporter "ces clients qui ne sont jamais contents et qui changent toujours d'avis" car ces clients n'ont pas le savoir qu'eux ils ont. Mais là, ça doit plus être un problème de comportement :)
          
          Par contre, il est vrai que certains clients aiment voir l'appli visuellement. Mais souvent, en parallèle de la phase d'analyse, des protos sont justement réalisés permettant de montrer et de controler si tout le monde se comprend :)
          
          Que mes propos ne soit pas mal interprétés :) je ne dis que l'XP c'est pas bô car je ne connais pas particulièrement et comme toute méthode, cela doit être très bien dans certains cas et pas adaptée pour d'autre (tout comme qu'elle doit convenir à certaines personnes mais pas à d'autres). Mais cela à l'air interessant, ayant eu ma paie je vais me commander un bouquin décrivant précisément l'XP :)

          • [^]Re: Rencontre AFUP sur l'Extreme Programming

            Posté par Philippe Fremy (page perso, ) le 02/04/2004 à 10:19. (lien). Évalué à 1.

            Le terme analyse est mal adapte. Ce dont on parle, c'est l'idee que se font certains professionnels du metier que a partir du moment ou tu as les specs, tu peux faire ta conception UML, et a partir du moment ou ta conception UML marche, le produit est pratiquement developpe. Je pense que cette approche ignore de nombreux facteurs importants, comme le fait que le client ne sait pas ce qu'il veut, qu'il change d'avis, que les specs ne sont pas parfaites et que les bugs sont incontrolables.
            
            > si tu codes pendant 6 mois et que le client change d'avis ?
            
            Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
            
            Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
            
            Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
            
            Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
            
            Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
            
            Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.

            --
            phil.freehackers.org

            • [^]Re: Rencontre AFUP sur l'Extreme Programming

              Posté par deftones_chris () le 06/04/2004 à 07:43. (lien). Évalué à 1.

              Ca fait une grosse difference avec la methode UML
              Ce n'est pas une métode :) Et ce n'est pas être tatillon de le dire ou faire un troll. UML est un complément de méthodes pour les représentations. Par exemple, il est utilisé avec les Unified Process (qui peut se faire sans UML). Méthode qui repose d'ailleurs sur un pricincipe d'itérations incrémentales qui à l'air très proche du XP.
              
              Mais comme tu le dis en début de post, certaines personnes ont une image erronée de ce que doit être l'analyse et/ou la conception en générale. Et pour ces personnes, quoiqu'on fasse , peu importe les méthodes, c'est d'abord une remise en cause qu'elles doivent faire :)

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par anonyme512 () le 30/03/2004 à 13:48. (lien). Évalué à 1.

    J'ai fait un résumé du résumé, il va de soit que je suis plus que simpliste... mais je pointe un lien vers l'article qui détaille tout et que je t'engage à lire.
    
    Si tu me dis que parmi les points préconisés par XP il y a des trucs pas trop mauvais, voire bons, je suis d'accord (personnellement, je suis plus nuancé que le lien que je pointe).
    
    Mais nul besoin de faire d'XP pour faire des tests. Ceci doit etre inclus dans un cycle de développement plus traditionnel.
    De même, les releases courtes sur les fonctions clés, cela peut exister aussi sous une autre forme dans le développement "traditionnel", on appelle ça le maquettage, et c'est aussi préconisé sur les gros projets.
    La transparence, c'est aussi conseillé en mode de développement traditionnel, mais il vaut mieux la faire en général sur les points que le client a une chance de comprendre, et il faut lui expliquer clairement, dans les termes de son métier, pas en utilisant de métaphores stupides (ou alors ce sont des points absolument pas métier, mais très techniques, et en ce cas, aucune métaphore ne permettra de lui expliquer de manière suffisament pertinente les choses).
    
    En revanche, le système des fiches de tâches, du développement en binome (bien en théorie, ridicule en pratique), l'absence de design général de l'application (XP déconseille l'utilisation d'interfaces - au sens java du terme, au profit du refactoring permanent, ce qui rejoint aussi le fait que l'optimisation ne doit s'effectuer qu'à la fin), appropriation collective du code (souvent au détriment de sa documentation, et même lorsqu'un projet fait plusieurs dizaines de milliers de lignes de code), et la gestion de la relation avec le client (présence permanente, tests, planning game). Tout ça c'est absolument n'importe quoi, et encore, j'oublie des trucs.
    
    Bref, en général, XP c'est une méthode qui est poussée par des gens qui n'y comprennent rien au développement logiciel, et qui ont trouvé une bonne occasion de glander un peu plus (ben oui, parce que du coup le boulot des chefs et directeurs de projet est très sensiblement allégé, puisque la majeure partie des taches qui leur incombent est effectué par les développeurs directement, avec la qualité qu'on imagine).
    Reste que, dans certains cas particuliers (développeur indépendant, etc.), ça peut présenter certains intérêts.
    
    Dernière remarque: sur le codage proprement dit (pas la gestion de la relation avec le client, qui est pourtant une des parties les plus importantes d'un projet logiciel), XP propose finalement quelque chose qui se rapproche (pas complètement toutefois) de la méthode de développement "bazar" utilisé par la plupart des LL. Comme quoi, tout n'est pas forcément à jeter dans XP, mais je vous incite à la plus grande prudence !

    • [^]Re: Rencontre AFUP sur l'Extreme Programming

      Posté par Cédric Girard (page perso, ) le 30/03/2004 à 16:26. (lien). Évalué à 4.

      As tu pratiqué XP? As tu au moins essayé les pratiques que tu critique? Moi je les utilise tous les jours, malgré quelques réticences au départ, et je te garantis que le pair programming, les taches, le client sur site, la simplicité, c'est vraiment bien.
      
      Pour le client faut arreter de le prendre pour un con, c'est en général un professionel métier compétent, parfaitement capable de comprendre quand on lui demande d'exprimer ses besoins, parfaitement capable de discuter avec des développeurs parlant une langue humaine plutot qu'un langage informatique. Je bosse avec des biologistes, ce sont eux les clients, et ils suivent sans problemes.
      
      Je n'ai jamais vu un livre ou un message sur XP déconseillant les interfaces, je connais même des praticiens XP convaincus qui en font pas mal, des interfaces. Ce qui est déconseillé c'est l'interface pour le plaisir d'en faire une, la complication inutile. Mais quand c'est utile, pourquoi pas?
      
      Quant au design général, sur tous les projets que tu as fait, est ce que le design initial a été bon du premier coup? Je veux dire : analyse, dev, et pop on est bon. Moi, jamais, et pourtant on y a passé du temps. Donc un design qui évolue, voire qui emerge selon les besoins me semble plus réaliste.
      
      L'appropriation marche très bien, de même que laa transmission de savoir (je bosse avec un profil plus electronique/bas niveau, alors que je suis plus BD/gestion de données, et en binome on apprend tous les deux)
      
      A propos du bazar, XP et le développement LL sont toutes deux reconnues par l'Alliance Agile comme des methodes agiles de dev. Mais bon, planent un peu à l'alliance agile, faut s'accrocher pour les suivre.
      
      Vient nous voir à une réunion, elles sont ouvertes, suffit de s'incrire sur le wiki, on pourra discuter et essayer. Parce que parler n'apporte pas grand chose, il faut toucher les pratiques du doigt sans a-priori hérité de cours ou de livres.

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par anonyme512 () le 31/03/2004 à 08:25. (lien). Évalué à 1.

        Pour faire court:
        1- oui, j'ai déjà utilisé XP (sur un projet de taille moyenne), et j'ai également été témoin de l'utilisation d'XP sur un gros projet
        2- un biologiste c'est un scientifique. maintenant, quand ton client c'est un commercial (par exemple), je te garantis que si il y a pas de phase de specifications, tu te plantes
        3- pour les interfaces, je cite le bouquin (qui cite des posts usenet je crois)
        4- pour le design général, on s'est jamais plantés. maintenant, on s'est en gros arrêtés au schéma de la base de données, et on a jamais eu à modifier le nombre de tables (rajouter des colonnes, en revanche, oui). encore une fois, je suis pas non plus un fan du "tout-UML" à l'extrême.
        5- l'appropriation ne marche pas, en particulier lors d'un remplacement d'équipe entre deux versions (évidemment). ce qui est un truc courant sur des projets un peu gros.
        En gros, fais attention, tu ne fais pas la meme informatique que la mienne (clients scientifiques et bas niveau, alors que moi c'est plutot clients "littéraires" et assez haut niveau, gestion de l'information). Je reviens donc sur ce que je disais: tout n'est pas à jeter dans XP, mais il y a clairement pas que du bon.

        • [^]Re: Rencontre AFUP sur l'Extreme Programming

          Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 31/03/2004 à 10:23. (lien). Évalué à 2.

          Je pense qu'il faut modérer tes critiques sur le "Pair-programming" (i.e. la programmation en binôme). J'avais pondu une chtite synthèse sur XP y'a deux ans et les études sur le pair programming que j'avais pu lire étaient fort intéressantes.
          
          Notamment, sur la fiabilité du code produit, l'auto-motivation des programmeurs (meilleure rentabilité pour le patron), la relecture de code automatique, ou encore l'effet de brainstorming..
          
          Evidemment ça n'a d'intérêt que si les programmeurs se mettent en binôme pour les parties de code critique, et se séparent pour ce qui est plus facile.
          
          ps: aussi, tous les programmeurs ne sont pas forcément compatibles avec un tel mode de développement, certains étant assez individualistes ou trop habitués à coder en solitaire.

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Cédric Girard (page perso, ) le 30/03/2004 à 13:25. (lien). Évalué à 1.

  XP n'est pas une méthode miracle, mais un ensemble de pratiques cohérentes qui individuellement n'ont rien de nouvelles (les tests, le dialogue, le refactoring, ...) mais qui toutes ensembles rendent les projets gérables et humains.
  Au lieu de croire les autres, viens te faire ton idée lors d'une réunion XP, à voir sur le wiki un peu plus bas.

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Cédric Girard (page perso, ) le 30/03/2004 à 16:33. (lien). Évalué à 1.

  Accessoirement j'accompagne Laurent sur la présentation XP Afup, donc, si vous voulez venir pour discuter...

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par grafit () le 31/03/2004 à 21:21. (lien). Évalué à 1.

  Extreme Programming, c'est un chateau de cartes constitué par toutes les mauvaises pratiques du développement logiciel
  
  oui... c'est un point de vue. En voici un autre:
  
  XP c'est les méthodes de dévelopement Open Source appliquées à l'entreprise.
  
  La contrainte principale est la non publicationdu code.
  La deuxième est qu'elle à des resources limitées (notamment les resources humaines)
  
  Relis la cathédrale et le bazar avec ces deux contraintes en tête. Puis relis "XP", un petite impression de déjà vu, non ?
  
  - distribuer souvent, et au plus tôt
  --> prototypes, builds fréquents, mis en commun du code,
  
  - être attentif aux retours des utilisateurs
  (en plus du fait que le developeur open source étant très souvent utilisateur lui même)
  --> proche collaboration avec les utilisateurs (intégrés dans l'équipe de dev)
  
  - le plus de personnes liront le code, le plus de chance les disfonctionalités apparaitront évidentes.
  --> peer programing
  
  - une armée de béta-testeurs
  --> tests unitaires automatiques (unit tests)
  
  - ...

Re: Rencontre AFUP sur l'Extreme Programming

Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par a_jr () le 30/03/2004 à 10:37. (lien). Évalué à 2.

  Rythme soutenable : Afin d'éviter de surcharger l'équipe, elle ne fait pas d'heures supplémentaires deux semaines de suite. Si le cas se présentait, cela signifierait qu'il faut redéfinir le planning. (extrait de http://fr.wikipedia.org/wiki/Extreme_programming(...))
  
  Par contre, pour les sensations fortes: http://www.extremeironing.com/.(...)
  http://www.extremeironing.com/modules.php?set_albumName=ReadersIron(...) est pas mal :)
  
  Le bonjour chez vous,
  Yves

Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par xilun () le 30/03/2004 à 12:43. (lien). Évalué à 2.

  Ce qui se concoit bien...
  
  Le problème c'est que je n'ai jamais trouvé de documentation vraiment pertinante sur ce qu'_EST_ l'XP. C'est donc bien que même ceux qui connaissent n'ont pas d'idée précise de ce dont il s'agit.
  
  http://xp-france.net/cgi-bin/wiki.pl?ExtremeProgramming(...) est le meilleurs truc que j'ai lu sur le sujet, mais reste entaché d'un pseudo discours decideur compliant sans interet (voir http://xp-france.net/cgi-bin/wiki.pl?LeCourage(...) ) qui me font me demander si l'XP c'est un mode de vie et de valeurs mélangé à un discours politique ou une vrai méthode de devel. A mon avis je ne pourrais avoir la réponse qu'en m'en rendant compte par moi même. Mais jusqu'alors, comment juger d'une méthode dont les meilleurs explication soit relèvent de l'évidence, soit sont inutiles, soit incomprehensibles ?

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Cédric Girard (page perso, ) le 30/03/2004 à 13:29. (lien). Évalué à 1.

    C'est la mise en groupes des pratiques évidentes et de concepts simple qui fait d'XP une méthode efficace (tests, remaniement, code simple, recherche de qualité) et sympa (communication).
    
    Le courage, c'est simple, c'est assumer. Ne pas se proteger sans cesse (on a un praticien qui bosse dans le secteur bancaire, où chaque personne passe plus de temps à se protéger de possibles problemes avec le client ou d'autres équipes qu'à faire avancer le projet).
    
    Les réunions de praticiens sont là pour faire découvrir et discuter, voir sur le wiki pour cela. Tu y seras le bienvenu.

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par wilk (Jabber id, page perso, ) le 30/03/2004 à 13:31. (lien). Évalué à 3.

    A mon avis que je me partage, l'XP c'est un peu comme la prose, on en fait sans s'en rendre compte.
    
    L'avantage de l'avoir mis sur papier c'est qu'on ne culpabilise plus lorsqu'on travaille avec le client et non pour le client, qu'on n'essaye pas de prévoir l'imprévisible, qu'on fait des tests unitaires au lieu de preuves théoriques, qu'on fait évoluer une application alors qu'elle n'est pas encore finie, qu'on fait des releases très fréquentes etc.
    
    Il ne faut pas s'obliger à faire de l'XP, ou autre, il faut regarder ce qu'on fait et ensuite chercher si d'autres font pareil, et ainsi comment améliorer sa méthode.

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Cédric Girard (page perso, ) le 30/03/2004 à 13:33. (lien). Évalué à 1.

    Je conseille XP Explained, traduit en français Extreme Programming La Reference, est excessivement clair pour comprendre XP, la philosophie sous jacente.

Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par wilk (Jabber id, page perso, ) le 30/03/2004 à 14:10. (lien). Évalué à 1.

  Question : vous faites des tests unitaires en PHP ? si oui, avec quoi ?
  
  Oui, avec python ;-)
  
  Non, sans blague, c'est vrai, il y a des librairies très pratiques pour tester n'importe quel serveur web. Je m'en sert même pour tester si des sites statiques passent le validateur.
  
  http://wwwsearch.sourceforge.net/(...)
  
  Il y a aussi http://webunit.sourceforge.net/(...) mais je n'ai jamais essayé.

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Stéphane TRAUMAT (page perso, ) le 30/03/2004 à 15:00. (lien). Évalué à 1.

    ok merci, mais je parlais plus des fonctions métiers car je ne teste que ça ;)
    
    en J2EE, j'ai des ejbs de session ou sont mes fonctions métiers et des tests unitaires pour chacune d'entre elles....

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Cédric Girard (page perso, ) le 30/03/2004 à 16:30. (lien). Évalué à 1.

  J'utilise phpunit, tout simplement ;-) la 0.6.2 pour php4, la 1 pour php5 (la v1 marche plus en php4, du fait des améliorations sur l'objet)
  
  http://pear.php.net/package/PHPUnit(...)
  les autres outils sont sur http://xp-france.net/cgi-bin/wiki.pl?ListeDesOutilsDeTest(...)

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Stéphane TRAUMAT (page perso, ) le 30/03/2004 à 17:16. (lien). Évalué à 1.

    Ou mets tu tes fonctions métiers ? dans des classes séparés ?
    et le domaine des données ? requete SQL ?

    • [^]Re: Rencontre AFUP sur l'Extreme Programming

      Posté par Cédric Girard (page perso, ) le 30/03/2004 à 20:47. (lien). Évalué à 1.

      Les fonctions métiers dans des classes ou des librairies, avec pour chaque une classe de test. Plus une classe est simple et plus ses fonctions sont centrées sur un seul but et plus le test est facile à écrire, et plus le code est réutilisable ailleurs.
      Les données sont dans une base SQL, et j'ai développé une petite lib pour rentrer des données dans une base de test, et vérifier ce qu'il y a.
      Voir MyUnit sur http://plcoder.net/?doc=1288&lang=fr&rub=101(...)
      
      Si tu veux on parle autour d'un code?

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par Stéphane TRAUMAT (page perso, ) le 30/03/2004 à 21:05. (lien). Évalué à 1.

        ok... c pas mal du tout... mais c vrai que j'aime bien mes ejbs :)
        
        j'habite à angoulême :) si tu veux passer voir un bout de code à la maison :D

      • [^]Re: Rencontre AFUP sur l'Extreme Programming

        Posté par Stéphane TRAUMAT (page perso, ) le 30/03/2004 à 21:08. (lien). Évalué à 1.

        Finalement, on habite pas loin :) et je me déplace sur ta ville de temps en temps !
        donc, si tu veux qu'on se voit, cela sera possible, on se battera pour savoir qui de java, php, ou delphi est le mieux :D

        • [^]Re: Rencontre AFUP sur l'Extreme Programming

          Posté par Cédric Girard (page perso, ) le 30/03/2004 à 23:51. (lien). Évalué à 1.

          Je parlais déjà par mail ou sur un forum, mais sans problème si tu passe dans le 92, ou même si tu peux venir à une réunion.

          • [^]Re: Rencontre AFUP sur l'Extreme Programming

            Posté par Stéphane TRAUMAT (page perso, ) le 31/03/2004 à 08:15. (lien). Évalué à 1.

            Ok :)
            
            tu n'as qu'a contacté la société scub par mail ( www.scub.net ), c moi qui recervait le mail !

Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Bossavit Laurent (page perso, ) le 30/03/2004 à 20:33. (lien). Évalué à 1.

  Merci, ça me touche. :)
  
  J'ai beaucoup appris de l'époque MultiMania, par exemple qu'un demi-million d'utilisateurs inscrits, ça se traduisait en un nombre conséquent de "tests unitaires" pour les parties du portail les plus visitées: quand on introduisait un bug, on avait un feedback presque immédiat via le support utilisateur ! C'est vers la fin de cette glorieuse période que je me suis intéressé à l'idée d'automatiser ces détecteurs de bug, plutôt que de laisser ce boulot aux utilisateurs.

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Cédric Girard (page perso, ) le 31/03/2004 à 06:49. (lien). Évalué à 2.

    Comment cela? Tu n'es pas arrivé dans le monde de l'informatique tout armé de bonnes pratiques ;-) J'aime bien ta définition des tests unitaires côté client.
    
    Cédric

  • [^]Re: Rencontre AFUP sur l'Extreme Programming

    Posté par Karles Nine (page perso, ) le 31/03/2004 à 14:09. (lien). Évalué à 1.

    Arg
    
    Tu me retire le pain de la bouche !
    
    Enjoy
    
    Karlesnine

Re: Rencontre AFUP sur l'Extreme Programming

• [^]Re: Rencontre AFUP sur l'Extreme Programming

  Posté par Bossavit Laurent (page perso, ) le 31/03/2004 à 14:35. (lien). Évalué à 1.

  J'étais sur Lille la semaine dernière, pour un Apéro PHP consacré à l'Extreme Programming !
  
  http://xp-france.net/cgi-bin/wiki.pl?PraticiensDeLille(...)
  
  La bonne nouvelle, c'est qu'il y en aura d'autres.