La conférence sera présentée par Laurent Bossavit l'un des auteurs du livre "Extreme Programming" édité par Eyrolles. L'AFUP vous invite à découvrir l'Extreme Programming, méthode agile de développement et de gestion de projets.
Vous pourrez discuter avec des praticiens qui livreront leurs retours d'expérience, après une présentation des bénéfices de la méthode en termes de qualité, maîtrise des délais et gestion de la relation client, notamment dans le cadre des projets Web.
Aller plus loin
- Reservation (1 clic)
- L'AFUP (3 clics)
- Le livre écrit par le conférencier (4 clics)
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . Évalué à 7.
http://books.slashdot.org/article.pl?sid=04/03/24/2118215(...)
pour résumer: Extreme Programming, c'est un chateau de cartes constitué par toutes les mauvaises pratiques du développement logiciel, et qui tient debout parce qu'on les as agencées de telle manière que chaque mauvaise pratique en contre une autre. mais comme personne n'arrive jamais à suivre la totalité de ces mauvaises pratiques, le projet foire immanquablement (du moins la raison avancée au foirage du projet par les experts d'extreme programming est qu'un certain nombre de préceptes n'y ont pas été scrupuleusement suivis), ce qui n'est pas si grave vu que, selon les promoteurs d'extreme programming, la seule issue possible à un projet logiciel est l'annulation.
bref, du n'importe quoi absolu, et, pour avoir déjà vu un certain nombre de projets se casser la gueule à cause de cette soit-disant méthode miracle, je dirais qu'il y a plus qu'un fond de vérité... mais c'est pas si grave, du coup ça nous donne du boulot, quand il s'agit de reprendre les débris et d'en faire quelque chose.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Gabriel . Évalué à 4.
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.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 3.
Tu n'as surement jamais pratiqué XP pour en parler ainsi.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Gabriel . Évalué à 2.
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.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 1.
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 F (site web personnel) . Évalué à 4.
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.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 F (site web personnel) . Évalué à 2.
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.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . Évalué à 1.
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 F (site web personnel) . Évalué à 2.
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)
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par deftones_chris . Évalué à 1.
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 F (site web personnel) . Évalué à 1.
> 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.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par deftones_chris . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par grafit . Évalué à 1.
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
Posté par Nÿco (site web personnel) . Évalué à 2.
http://fr.wikipedia.org/wiki/Extreme_programming(...)
Le wiki de l'asso XP France :
http://xp-france.net/cgi-bin/wiki.pl(...)
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par Colin Leroy (site web personnel) . Évalué à 0.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par a_jr . Évalué à 2.
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
Posté par Tutur . Évalué à 1.
Il est marrant de voir que la plupart des gens ne savent pas de quoi ils parlent.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par xilun . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 1.
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
ou mettez vous la logique métier ?
http://about.me/straumat
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par wilk . Évalué à 1.
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 (site web personnel) . Évalué à 1.
en J2EE, j'ai des ejbs de session ou sont mes fonctions métiers et des tests unitaires pour chacune d'entre elles....
http://about.me/straumat
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
et le domaine des données ? requete SQL ?
http://about.me/straumat
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
j'habite à angoulême :) si tu veux passer voir un bout de code à la maison :D
http://about.me/straumat
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
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
http://about.me/straumat
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Cédric Girard (site web personnel) . Évalué à 1.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
tu n'as qu'a contacté la société scub par mail ( www.scub.net ), c moi qui recervait le mail !
http://about.me/straumat
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par Karles Nine (site web personnel) . Évalué à 1.
Quel chemin depuis gore développeur chez multimania.
Bravo.
Karles
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Bossavit Laurent . Évalué à 1.
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 (site web personnel) . Évalué à 2.
Cédric
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Karles Nine (site web personnel) . Évalué à 1.
Tu me retire le pain de la bouche !
Enjoy
Karlesnine
# Re: Rencontre AFUP sur l'Extreme Programming
Posté par raynox . Évalué à 0.
Toujours tout pour les Parisiens et jamais rien pour Lille. Franchement ca commence a me pet... les cou... :-(
Y a que du favoritisme
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Bossavit Laurent . Évalué à 1.
http://xp-france.net/cgi-bin/wiki.pl?PraticiensDeLille(...)
La bonne nouvelle, c'est qu'il y en aura d'autres.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.