Reprise du message précédent :

si tu parlais de puces adn j'aurais repondu mais je sais même pas ce que c'est ton truc

ptain mais le gros biologiste de merde ...
heureusement que t'es plus en France

Et merde

Google suggest t'affiche une liste discréte qui te suggère des recherches en fonctions de ce que tu as écrit. ça permet de lancer ta recherche plus rapidement quand tu cherche un truc long et ça t'aide quand tu n'est pas sûr de l'orthographe.  
Sur le site ça t'affiche bêtement la recherche sur les caractères dans la textbox en virant tout ce qu'il y avait sur  la page. Tu peux m'expliquer l'utilité d'avoir les résultat de la recherche sur "Ajax sear" ?
 
L'ajax est souvent utilisé pour des effets cosmétique sans que ça apporte quoi à l'ergonomie. Pire c'est aussi utilisé pour faire des choses inutiles tien que pour mettre le label "Ajax powered"

T'as des exemples de trucs ajax qui puent des pieds ?

C'est le mien. Les cravatés sont vraiment persuadés qu'un mec doué mis en pair-programming va être aussi performant, tout en rendant ses collègues doués et utiles, et qu'au final on gagne du temps et de l'argent.  

yen a plein l'ajaxian blog

 
Je suis foutu. /o\
 
Je suis super indépendant, et je déteste avoir quelqu'un sur le dos quand je bosse. Ca ne veut pas dire que je n'aime pas bosser en équipe, ou que je n'aime pas qu'on regarde/contrôle mon travail, au contraire je suis convaincu qu'il faut faire des points réguliers, discuter des projets, etc.
Mais le pair-programming je haïrais ça, j'aurais l'impression de me sentir ralenti, restraint.

XP c'est bien quand tu n'as pas la chance ou les moyens de t'offrir une équipe d'ingénieurs de bon niveau (ce qui n'est pas si courant actuellement).
Le techos incapable de suivre correctement des specs rédigées mais qui code comme il envoie des textos, tu le fou avec un autre plus posé mais moins inventif et comme ça tu peux en faire quelque chose de tes gars qui séparément ne produirait pas grand chose de valable.

   ------
  d[ -_- ]b
     \    /

C'est marrant en fait, le seul du topic à avoir réellement essayé l'xp ça doit être nraynaud, et pourtant tout le monde donne son avis, limite je me sens même plus expert en tout après ça
 
Et le Waterfall vous en pensez quoi

Tiens ce matin, quelqu'un demandait le smiley perceval :
 
 

 
J'en ai déjà fait quelques jours, il y a 5 ans. Je sais que c'est mince comme expérience en la matière, mais je comptais les heures et à la fin de la journée, je me tirais à 17h sur le point de craquer.
Peut-être avais-je le mauvais partenaire.

   
J'en ai fait plus de 3 ans on&off. Et on a fait différentes façons de faire du XP (du naïf au début, au RUP-in-XP, en passant par le XP cross-teams).
Et je persiste et signe: dans mon équipe de mecs talentueux, le pair-programming n'était valable qu'en phase initiale de design, en phase d'écriture active des tests (là, c'est imparable), et dans certaines tâches de debuggage.  
 
Pour le refactoring, l'implémentation de base, les tâches répétitives, la doc, et l'augmentation de couverture des tests, ça ne sert à rien.  
 
Les cycles courts, je suis accroc. Le release-early/release-often aussi si c'est faisable. Le calcul par "difficulté" et l'application d'un coefficient de vélocité aussi.
 
Le test-first est plutôt dur à faire quand tes interfaces et tes données ne sont pas encore bien définies, donc c'est une grosse option. Par contre, l'utilisation des test-unitaires, je suis pour (d'ailleurs on codait toujours en utilisant le programme de test-unitaire comme target, plutôt que le composant lui-même).
 
Les 8h/jours, ça me fait rire.
 
La connaissance globale du projet et le fait de toucher à tous les composants, c'est utopique et infaisable dans la plupart des projets.
 
Voili-voilo.

xp, tu disais ?

spa un peu contradictoire ça?

moins moins > oui ? c'est quoi le bleme ? un mec pas doué pour lire des specs, ben on le met sur de l'XP car pas de word dans tous les sens...
C'est un peu le principe de base et c'est un peu le reproche qu'on peut faire à l'XP. On peut arriver à un déficit de docs.

Lam's> Donc ça peut se révéler utile pour tout ce qui nécessite de la réflexion (pour le débogage de trucs difficiles, je suis certains que ça peut aider), et c'est de la perte de temps pour tout ce qui et besogneux, en somme.

ben, c't'à dire que pour ce que je crois connaitre d'xp - et je peux completement me tromper ou confondre - on y écrit justement pas de specs kilométriques en amont.
et si c'est pas moi qui me trompe ou confond, alors tu fais peut etre l'amalgame entre xp et pair-programming ?

c'est à peu près mon avis aussi, mais c'est un à priori - d'un autre côté, on devrait aussi avancer dans le sens où on devrait avoir moins de travail "besogneux" à faire, donc, l'un dans l'autre ..

Nope. RUP n'est qu'un "framework de processus". Si tu ne prends que certaines parties. Et que tes artefacts c'est juste le produit des phases de design (en gros: une photo numérique des tableaux-blancs avec les schémas UML), ça colle. Et ça permet de se brancher sur le reste (les phases de req, et les phases de livraisons).
 

Yup. Mais d'un autre côté, il y a aussi tout intérêt à s'éviter les trucs besogneux (fini le vi+grep). Notes aussi que c'est toujours "utile": tu ne fais jamais moins bien en pair-programming. Le problème, c'est que tu payes 2 gars pour faire le boulot d'un seul...

Je parlais du pair-programming oeuf corse. Les trucs comme la doc, ça sera tjrs nécessaire "malheureusement". Enfin je dis malheureusement, parce que je ne connais rien de mieux pour réfléchr aux données du pb que d'écrire une doc à l'avance. Au lieu de fumer des architectures à partir de rien en espérant qu'elles seront suffisamment souples pour s'adapter au pb, on se concentre sur le pb lui-même et les contraintes, et l'architecture vient assez naturellement. Encore faut-il que les desiderata des clients ne changent pas tous les 2 mois, mais là, il faut justement essayer de prévoir le changement.

Euh, ne serais-tu pas en train de répéter ce que j'ai écris sans t'en rendre compte ?...  

ché pas, j'bataille avec des saucisses à la cuisine, là

La question en fait c'est surtout de voir ce que ça donne qualitativement, parce que si en production tu paies 2 gars pour faire le boulot d'1, si derrière tu as ne serait-ce que 30% de débugging en moins tu risques d'y gagner (à moins que tu fasses complètement sauter le débugging parce que les délais ont explosé sur ton projet waterfall )

Tais toi

alors tu l'as reçu ton Mac ?  
Par curiosité combien tu l'as payé

Bon, déjà, l'énorme majorité des projets sont cycliques/en itératifs de nos jours.  
 
J'ai pas l'impression que tu aies une grosse augmentation en qualité à faire les trucs en pair-programming. Ce qui fait énormément monter la qualité, c'est d'une part, de coder "proprement" (avec assert, exceptions, tests unitaires, etc.). D'autre part, de communiquer très fréquemment avec les autres pour vérifier les choix prix (les valeurs commencent à 0, la table X est dans la base Y, le message Z sera asynchrone, etc.).  
Et ces 2 trucs là, XP y répond d'une certaine façon, mais pas forcément de la manière la plus efficace.

J'ai peur
 
Bon c'est bien beau tout ça sur la méthode XP ou pas, mais, je ne suis pas convaincu de l'XP sur des projets d'envergure.
On peut appliquer certains points à certains moments, mais les limites sont vites atteintes je pense.
Enfin, on cherche une méthode miracle alors que le problème aux projets qui foirent sont souvent les mêmes.
1. Un Cahier des charges non approuvé et signé par les clients finaux.
2. Des specs peu claires, imprécises, ambigues.
3. Une équipe projet peu compétente et non motivée.
 
Le reste, pour moi, c'est presque du décor.

y'a pas qqun qui veut faire du pair-cuisining, là, j'ai un peu de mal avec les specs

 
en XP, tu n'as ni 1), ni 2), ni 3)

moins moins > tiens ça tombe bien non ?

ben c't'à dire que, j'imagine, le client doit comprendre XP aussi, ça ne doit pas etre juste un truc interne.
enfin, bon je parle dans le vide, sans trop savoir.

Voilà. T'imagines Microsoft faire du pair-programming en demandant à tous ses clients de venir à Redmond pour faire les specs  de Vista ?

de 48, des six jour ou du Liban ?

travaux / déménagement / lol / 0 HP / Dormir

moi, je trouve que le pair-programming, ca a une influence négative sur les temps de décisions

+1 et mon impression est que plus le projet est complexe, plus les specs doivent être détaillées, quitte à être modifiées par la suite si besoin, - et c'est sûr que ça changera en cours de route -, mais au moins l'architecte technique sait précisément où il va.  
A l'instar du capitaine d'un navire. S'il a une bonne carte et une bonne boussole et un bon sextant, il peut caler sa direction précisément vers sa destination et corriger si nécessaire. Mais si la direction est vague au départ, et sa carte tjrs aussi imprécise en cours de route, à l'arrivée, il ratera son île de 1000 milles marins. Si le trajet est court, une direction peu précise n'aura pas de conséquences dramatiques, mais s'il entreprend de traverser la moitié du globe, c'est autre chose. Pour continuer avec l'analogie marine, il faut quelques escales de temps en temps. En XP, elles sont rapprochées, sur un gros projet, les releases sont plus espacées, mais sont tout autant une nécessité.
 
Merci de votre attention

Pourtant ça fait 15 ans que ça dure. Ou bien tu ne parlais pas de cet OS là ?

ça s'rait bon. votre copie gratuite de vista en échange de 2 heures de brainstorm

boulax needs food badly.

D'ailleurs je vais plus à goncourt, j'ai trouvé un chouette meilleur appart à Voltaire
(et les vacances au pays basque, caitai coule )

A partir d'une certaine taille (à partir de plusieurs centaines de j.h), j'aime à penser qu'un projet informatique s'apparente aux grands chantiers du BTP --- genre le Big Dig de Boston    dont j'ai vu un documentaire sur la 5.
Du moins en ce qui concerne le travail de préparation avant de poser la première brique.
Sinon, pour revenir en arrière, les coûts sont prohibitifs.
Faire de l'XP dans ces conditions est disons suicidaire.  

tu peux développer chacun de ces points STP ? (j'ai laissé que ce qui m'intéresse de ta réponse)