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

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.

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

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.

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

oui, voilà, tu es exactement compris XP : c'est exactement la contraposé de ce que tu écris.

Bordel, les serveurs dns pour free c'est bien ça non ?

c'est là une des grosses limites, va voir sur unclebob les tentative de faire *lire* du fitnesse à des vrais clients externes ...

+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

c'est pour ça qu'on fait un point tous les jours et qu'un sprint (scrum) ou une itération (les autres) ne fait que 3-4 semaines. on peut pas dériver de plus d'une journée. Par contre, on savait en juin que la date de septembre est impossible à tenir avec le périmètre fixé.

j'en était resté à 212.27.32.5 et 212.27.32.6

(et les vacances au pays basque, caitai coule )

c'est pour ça qu'on fait un point tous les jours et qu'un sprint (scrum) ou une itération (les autres) ne fait que 3-4 semaines. on peut pas dériver de plus d'une journée. Par contre, on savait en juin que la date de septembre est impossible à tenir avec le périmètre fixé.

contraposé

marche bien mieux en effet

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.  

ou il réagit à la blague de mwin mwin de ce matin

normal, juillet-août l'équipe est en vacances

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

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

ben on est passé a un systeme different, plutot que le rapport hebdo en .doc comme initialement, on a un systeme de blog. et donc mon boss a souscrit au rss de chacun de nos blog et voila

ben on est passé a un systeme different, plutot que le rapport hebdo en .doc comme initialement, on a un systeme de blog. et donc mon boss a souscrit au rss de chacun de nos blog et voila

brilliant !  
Avant que je démissionne de ma boite il y a 2 ans, on était tombés bas, très bas suite au nouveau management: on devait chacun faire un slide PowerPoint avec un format spécial (et en particulier, des petites icones vertes/jaunes/rouge). On envoyait ça au P.M. juste avant la réunion, et il nous faisait une jolie présentation.

nous on a un meeting scrum

Tu veux que je développe quoi exactement ?  
 
Sur les 8h par exemple: quand il y a livraison parce que le client attend, je suis pas sûr que ça le fasse rire si t'annonces qu'il devra attendre 15 jours de plus pour utiliser son beau testbed simplement parce que t'es en XP. Dans les télécoms et dans la finance, les clients recoivent et testent le week-end.  
 
Le refactoring: quand t'as 30 minutes/1 heures de global search&replace multi-fichiers à faire, ou quand tu dois remettre en forme des tests parce que le code a changé, c'est assez pénible de faire ça à 2. Déjà qu'un cerveau, c'est de trop pour cette activité, alors 2 cerveaux...
 
Quand au fait de bosser sur tous les aspects d'un projet, chez nous ça impliquerait que le gars devienne spécialiste en threading, en communication inter-composants, en BDD, en procédures stockées, en GUI, en EJB/JMS, en C++, en XSD, etc. Et un gars spécialiste en tout ça, c'est rare et cher.

brilliant !  
Avant que je démissionne de ma boite il y a 2 ans, on était tombés bas, très bas suite au nouveau management: on devait chacun faire un slide PowerPoint avec un format spécial (et en particulier, des petites icones vertes/jaunes/rouge). On envoyait ça au P.M. juste avant la réunion, et il nous faisait une jolie présentation.

hum ok.
 
par contre vous avez jetté la conception simple non ?

 
j'ai ça avec des smileys :|

j'ai ça avec des smileys :|

j'dois avouer que cet aprèm' y'avait des refactoring chiants, j'ai pas hésité à me tirer prendre l'air pendant que ma binome les faisait
 
et après, quand j'ai changé de binome, je me suis tiré pendant qu'il virait certains appels.

je fais quoi c'est une certaine Gladys qui porte le meme nom de famille que moi, dont j'ai maintenant le n° de portable et qui:

Tu fais pas de l'XP alors. Parce que tonton Kent Beck l'a dit: pour faire de l'XP, il faut suivre toutes les règles.