PourquoiXpEstSiPeuPratiquéEnFrance

XP, et de façon plus générale les méthodes Agiles emergent lentement, voire très lentement en France. Effectivement, il y a un risque pour que seules les pratiques de dev soient appliquées, mais alors ce n'est pas du XP, juste de l'amélioration de pratiques de Dev, point-barre. Peut-être est-ce là l'argument permettant de briser le cercle vicieux.

La SeanceDePlanification? modifie profondement la relation au client et implique/responsabilise activement celui-ci dans le processus de production logicielle. Le côté bénéfique de cette modification n'est pas forcément perçu : la perte d'une certaine maîtrise du code ("Code Ownership") et des plannings, respectivement pour le développeur et pour le ChefDeProjet? traditionnel, peuvent induire un sentiment de perte de pouvoir. Ce sentiment reste encore à dépasser, pour la plupart des cas. C'est très significatif du changement d'état d'esprit que XP demande pour jouer GagnantGagnant.

Finalement, ce ne serait pas les clients les plus réticents à la mise en place d'XP, car finalement ils y gagnent beaucoup -- il reste quand même à leur présenter les choses sous le bon angle. Sans compter que l'on peut diminuer un peu leur disponibilité requise, si c'est vraiment necessaire. Pour une mise en oeuvre réelle d'XP, coté MaîtriseOeuvre? traditionnelle, les changements sont plus drastiques. Si les changements de pratiques de travail passent mieux quand ils améliorent la qualité de vie du développeur et la qualité du produit en général, les changements de méthode sont, quant à eux, plus difficiles à faire passer : les bénéfices à long terme sont peu visibles à court terme, la prise de risque semble plus grande et les facteurs humains comme la résistance au changement interviennent de façon significative.

Enfin, tout ceci se heurte aux ancrages fort des pratiques "lourdes" en France, principalement Merise et la nouvelle vague du RUP/modélisation UML systématique enseignée un peu partout.

Un XP "vrai" reste cependant tout à fait applicable en France, en particulier sur les projets nouveaux et dans certaines niches ou les clients sont très sensibles à leur implication dans le projet. Cela est moins évident pour les projets de maintenance ou pour des projets ayant des liens importants avec des tiers non-XP. N'oublions pas de valider les CritèresFavorablesPourXP? avant de le mettre en oeuvre sur un projet !

Je parlais hier avec Wiki:JimShore, de passage à Paris, et on a abordé la question d'XP en France. Je racontais qu'à une époque, je trouvais étrange qu'il y ait si peu d'activité dans la communauté, comparée aux rencontres régulières des groupes britanniques (XTC) ou hollandais (XP-NL). Mon schéma d'explication était le suivant: il y a peu de projets XP en France, donc il n'y a pas une communauté très active. Depuis quelques temps, je pense qu'il faut inverser ce schéma. La communauté XP en France n'est pas très active, c'est pourquoi il y a peu de projets qui pratiquent XP. -- lb

Qu'est-ce qui te fait penser qu'il faut inverser ton schéma initial de compréhension ? Quelles nouvelles clefs de compréhension cette inversion t'apporte ? --eg.

Les modèles de Wenger sur l'apprentissage social: http://www.ewenger.com/theory/index.htm

Il existe en France de nombreux exemples de projet "agiles". J'en croise très régulièrement. En revanche, il est vrai qu'il ne sont pas XP. Je ne suis pas convaincu que les francais soient plus fan de méthodologies lourdes que les autres. Je dirais qu'à priori, ca serait même plutot le contraire si nous comparons notre culture méditeranéenne au rationnalisme anglo-saxon (pour rester dans les clichés).

Donc, a mon humble avis, je crois qu'il s'agit d'un problème de communication et/ou de marketing.

On y voit que les Francais essayent plus que d'autres de controler leur incertitude. Cela reviendrait à contractualiser, spécifier beaucoup et aimer les méthodes lourdes. Par ailleurs, le francais serait plutot individualiste => pas tres enclin à mettre le fruit de ses competences dans une équipe. D'où peut être un probleme pour partager le code et les lauriers.

Je pense aussi qu'en France, les managers sont trop protectionniste(Hofstede nous donne d'ailleurs une distance hierarchique plutot elevée). Ils tentent de controler le plus possible pour se sécuriser, mais n'ayant pas connu autre chose que les methodes lourdes (ou pas de méthodes) ont peur des nouvelles methodes. En Scandinavie, les managers ayant beaucoup moins d'emprises sur leurs équipes(faible distance hierarchique), ces équipes peuvent plus facilement s'autodiriger vers une méthodologie Agile. -- bv

Même si l'aspect culturel joue probablement un rôle clé et nous ne reviendrons sur l'aspect gaulois des choses, le facteur économique est tout aussi important.

Sur le papier lorsqu'on analyse les avantages d'XP on se demande tout simplement pourquoi effectivement tout le monde ne l'utilise pas. Bizarrement on préférerait utiliser des méthodes dont tout le monde connaît les limites en sachant par avance que l'on va dans le mur ? Les choses ne sont pas si simples tout le monde s'accordera là dessus.

Ce qui nous gouverne tous, d'un point de vue professionnel cela s'entend, c'est le business requirement. Or ce dernier a me semble-t-il un seul et unique but : faire de l'argent et de la façon la plus facile qui soit.

Ainsi, j'ai eu l'occasion de sonder aussi bien d'anciens collègues que des candides sur les problèmes liés aux projets logiciels. Le constat est souvent celui que nous connaissons tous. Or, j'ai tenté d'expliquer - peut être fort mal - comment de "bonnes pratiques" pouvaient améliorer les choses de façon spectaculaire. Résultat : les développeurs comprennent aisément mais considèrent tout cela trop "utopiste" au regard des contextes dans lesquels ils évoluent, les candides ne comprennent pas très bien, habitués qu'ils sont aux méthodologies complexes et immatérielles. Seuls les arguments "client sur site" et "tests clients" les font réagir car là ils en saisissent immédiatement les différents impacts. Ceci est quand même un bon début.

Impacts positifs : Participer à la production de LEUR SOLUTION, pouvoir en assumer le contrôle et ne pas se rendre compte quelques mois plus tard qu'ils n'ont pas ce à quoi ils s'attendaient, pouvoir prendre des DECISIONS et avoir le COURAGE de reconnaître s'être trompés tout en sachant que l'équipe pourra corriger le tir et reprendre le bon CAP.

Impacts négatifs : Les coûts bien sur. La programmation en binôme n'apparaît dans un premier temps comme un coût supplémentaire. En l'expliquant cette réticence s'estompe car ils en saisissent là aussi l'utilité. Le client sur site les fait frémir aussi (et nous retombons là dans ce qui a déjà été dit à savoir le rôle du management) tant d'un point de vue financier que politique. Pourtant, TOUS sont convaincus - au moins pour la partie qui les implique directement - qu'effectivement la mariée est belle.

Alors si tel est vraiment le cas, pourquoi ...? En grande partie parce que les traditionnels projets utilisant des "Cycles en V" rapportent beaucoup plus d'argent. Ils permettent de "voyager lourd" et d'avoir beaucoup de gens impliqués sur un projet. D'allonger les délais, en clair d'en donner au client pour l'argent qu'il pense avoir correctement budgété... Or la connivence est générale surtout sur un secteur arrivant à maturité où l'heure est plutôt au regroupement des acteurs principaux. Le client vache à lait est donc devenu une cible de prédilection. Et comme ce dernier est encerclé par la même meute de loups, entendant ainsi le même discours, il finit par accepter cette fatalité en tentant de limiter les dégâts au niveau de son porte-monnaie.

Résultat des courses nous venons de passer ces deux dernières années avec des investissements en chute libre. La chasse aux coûts est lancée. Phénomène contradictoire lorsque les entreprises cherche à se doter d'armes efficaces pour les réduire et que l'informatique ne devrait donc être que partiellement touchée. On va bientôt virer les PC des entreprises parce que des petits malins ont calculé que sur 1,3M de machines la moyenne d'utilisation était de 2h15mn par jour. Les grosses SSII, pour garantir leurs marges et prévenir une situation similaire les prochaines années ont fait appel à une arme visant à réduire leurs coûts. Cela s'appelle joliment l'Offshore avec les conséquences que l'on connaît aux USA et qui ne va pas tarder à nous tomber dessus. Les heures s'annoncent sombres, mais pour autant je pense que c'est justement cette situation qui peut pousser XP sur le devant de la scène. Je suis donc d'accord avec Laurent lorsqu'il préconise de voir les choses sous un angle différent et je rejoins ceux qui sous-entendent que le problème est d'ordre marketing.

Il faut donc réussir à vendre le "produit" XP. Sur un marché de ce type, M.E.Porter préconiserait une stratégie de différenciation. Techniquement cela est déjà le cas pour le "produit" XP. Mais peut être faudrait-il avoir dans un premier temps une stratégie de concentration orientée vers une cible stratégique particulière. Cela sous-entend d'orienter ses efforts vers des entreprises capables d'intégrer le changement et non pas celles qui en en ayant les capacités financières n'en auront sans doute jamais la volonté politique parce que cela les pousseraient au conflit d'intérêt. En clair c'est un peu comme si l'on axait la totalité de ses efforts à convaincre Bill Gates d'axer son activité sur l'Open Source! Maintenant qu'un nombre important d'acteurs optent pour ce type de solution, la peur des gens de Microsoft de louper le coche fait qu'ils y viennent petits à petits et y viendront probablement de plus en plus. Le marché n'a pas besoin d'eux pour survivre car il est en pleine expansion et ne craint pas ce type d'acteur puisque son ouverture s'est justifiée par la présence de ce dernier ou de ses concurrents. Ils y sont donc contraints par la règle dictée par la demande. S'adapter ou mourir...

Appliqué à notre contexte eco-socio-culturel cela débouche sur le fait qu'il faudrait COMMUNIQUER plus et notamment en utilisant UNE METAPHORE plus proche du décideur-client-payeur, en clair "attaquer" sur le terrain économique avec des données comparatives précises et pertinentes. Celui qui finance se moque éperdument du mode opératoire, de la méthodologie utilisée (car de toute façon il n'y entend rien - chacun son métier), ce qu'il veut c'est une solution à sa problématique, au prix le plus juste et qui respecte certaines règles (plate-forme technique, plan qualité etc.). Une démarche "agressive", sans demi-mesure, parce que la voie médiane ne provoque qu'enlisement, me paraîtrait appropriée. Lorsque j'ai recherché ce type d'information économique, j'ai été surpris de constater son absence totale ou la médiocrité de se pertinence.

Kent Beck aborde le problème de la négociation contractuelle sans pour autant - pauvre de nous ;-)) - donner de solution miracle. Pourquoi ? Parce qu'à mon avis - et je rejoins le côté culturel des choses - on ne fait pas du business de la même façon d'un pays à l'autre ou d'une activité à l'autre. Faire de l'adaptif et non du prédictif n'est pas forcément très simple, économiquement parlant.

Mais c'est aussi à chacun d'entre nous, en fonction de sa propre expérience, de mettre à disposition de la communauté XP les "outils" de son ambition. Comment ? En donnant du FEEDBACK sur son expérience, en ayant le COURAGE d'analyser en commun ses échecs ou ses difficultés, de COMMUNIQUER des informations capitales, cela en toute SIMPLICITE sans arrière pensée élitiste. Ainsi pour l'exemple lorsque l'on croise régulièrement des projets XP une des premières choses à faire serait de communiquer des informations, non confidentielles bien sur, (taille du projet, objectifs, ...) à la collectivité. Cela permettrait peut être d'avoir une cartographie sur les pratiques à 100% XP et celles qui tendent vers cela. A moins qu'effectivement l'on ne soit vraiment dans un contexte protectionniste préconisant le grand secret.

Enfin, l'argument de dire que des pratiques XP pourraient être introduites petit à petit ne présente pas de sens. XP est un tout cohérent c'est ce qui fait sa force et son inaltérabilité. La résultante serait alors bien pire puisqu'en perdant sa fibre elle perdrait non seulement de son efficacité mais aussi toute crédibilité.

La création d'un site Web me paraît être la première pierre de l'édifice pour promouvoir XP en France. Il pourrait être financé sur la base de cotisations de L'association XP France. Il permettrait de diffuser de l'information à un plus grand nombre et surtout aux décideurs.... Il pourrait être pluridisciplinaire (infos sur XP, retours d'expérience, promotion via des interviews de décideurs, exemples de code, informations sur les manifestations XP, Forums de discussion, portail pour les décideurs, données économiques, articles de presse, articles techniques mais pas forcément axé sur XP mais par exemple sur des côtés fonctionnels et/ou métier, etc...)

Je suis convaincu qu'un peu de "refactoring" collectif apporterait un début de solution ce en quoi je rejoins complètement l'analyse de Laurent qu'il faut sans doute dégripper la machine. Soyons plus réactifs. Soyons Extrêmes dans notre volonté à changer les choses pour ne pas se retrouver à pisser de la ligne bêtement durant les prochaines décennies.

Désolé d'avoir fait si long...

FB

Joliment dit. Bienvenue sur le wiki! Merci (d'avance) pour les contributions enthousiastes que tu pourras apporter à l'édifice.. ChristopheThibaut

En effet, beaucoup d’idées très intéressantes. Merci pour ton point de vue détaillé.

Je ferais quelques corrections :

L’analyse sur le client entouré par une meute de loups me paraît un peu exagérée. Tout d’abord, parmi les loups, il y en a un bon paquet qui proposent de l’agile. Ensuite, ne présupposons pas que le client est bête. Il sait parfaitement ce qu’il achète, il connaît les risques, et il sait pourquoi il choisi du cycle en V plutôt que de l’agile itératif. (je parle ici du client grand compte).

Enfin, les investissements informatiques ont chutés tout simplement par suite de la crise économique mondiale (éclatement de la bulle Internet et incertitudes géopolitiques), et non pas à la suite de l’échec des méthodologies en V.

Mais revenons aux différences de la France par rapport aux anglo-saxons qui expliqueraient le peu de pénétration de XP chez nous.

La TRES grosse différence est liée à la législation qui protège les travailleurs salariés. Nous savons tous qu’il est très difficile de licencier en France, et c’est d’autant plus difficile que l’on est gros et que l’on gagne de l’argent. Cette situation a conduit à la création d’une économie parallèle très française que nous appelons les SSII (ou marchands de viande pour être plus clair).

En effet, pour une entreprise dont le but n’est pas de faire de l’informatique (banque, industrie, administration), les informaticiens sont un centre de coûts qu’il faut gérer. On pense généralement (mais c’est sûrement là qu’est l’erreur) qu’un informaticien deviens obsolète avec l’age. Donc, d’un point de vue DRH, si l’on recrute de jeunes informaticiens sortis de l’école on ne pourra pas les garder dans cette branche toute leur carrière. Vers la quarantaine, on considère qu’ils sont dépassés par la technologie, et l’on souhaitera, soit les licencier (quasi impossible en France), soit les faire évoluer vers d’autre domaine (et c’est souvent très difficile aussi).

La solution est toute simple, on prend des intérimaires, en régie ou au forfait, que l’on fait tourner en fonction des besoins : accroissement ou réduction du portefeuille de projets, évolutions technologiques, etc…

Nos entreprises françaises (privées ou publiques) se retrouvent donc avec une informatique qui reste stratégique, mais quasiment totalement confiée à une population d’externes. Pour garder le contrôle, une autre population a été créée, elle aussi très franco-francaise : la maîtrise d’ouvrage.

Or, au quotidien, ce rôle de maître d’ouvrage est très difficile à tenir. Ils sont totalement tenaillés entre les utilisateurs qui les assimilent à un centre de coûts, et les informaticiens qui ne voient qu’un parasite entre eux et leurs utilisateurs. Cette population est donc souvent sur la défensive en essayant de justifier son existence auprès des ses deux interlocuteurs.

Nous avons donc trois populations en France pour gérer l’informatique (grand compte) : les utilisateurs qui ne veulent pas gérer les spécificités des profils d’informaticiens, les maîtres d’ouvrage en mal de justification de leur existence, et les informaticiens, externes à l’entreprise.

Toutes les conditions sont réunies pour avoir un cloisonnement étanche des trois populations, qui ne communiqueront que par documents formalisés, et validés en se renvoyant la balle en cas du moindre problème. Nous sommes au royaume de CMM.

Très, très difficile de faire de l’XP dans ce contexte…

Les anglais, par exemple, n’ont pas ces problèmes. Le marché du travail est très fluide, à la décrue comme à la croissance. Il n’existe pas de SSII mais tout une population d’indépendants qui vont de missions en missions. Il existe également des cabinets de conseil lorsqu’il est nécessaire de capitaliser sur un savoir-faire commun (exemple Thoughworks de Martin Fowler).

Leurs rapports à l’informatique sont donc radicalement différents. Ils peuvent se lancer dans des expérimentations à l’aide d’itérations courtes et jeter le projet à la poubelle si ça ne donne pas les résultats escompté. Nous sommes au royaume de l’agile. Donc, ce sont les règles du marché du travail et l’impression que les informaticiens sont frappés d’obsolescence avec l’age qui empêche XP de pénétrer en France.

A mon avis, il nous faudra agir sur l’un ou l’autre des deux aspects pour parvenir à faire de l’XP chez nous.

-- bn

Tu oublies de préciser que ce mécanisme, où les "employés" du département informatique ne sont pas salariés par l'entreprise en question, est en contradiction avec le droit du travail. La relation de subordination ("je te dis quoi faire") se confond avec la notion même de salariat. L'ingénieur devrait donc être considéré par l'URSSAF comme salarié de l'entreprise cliente, s'il prend ses ordres de quelqu'un qui appartient à celle-ci. Comme on ne peut pas coller des amendes à l'intégralité des grands groupes qui ont recours à ce système, on tolère avec une certaine gêne ce système particulier. (C'est un peu comme le cas des intermittents du spectacle.) Il en résulte des "règles" souvent absurdes dans les entreprises en question, par exemple que les "externes" n'ont pas le droit à avoir une adresse e-mail à eux, ou à manger à la même cantine que les employés. L'effet sur la cohésion, et donc la performance, des équipes est parfois désastreux également.

Pour moi, la conclusion est qu'XP intéressera en premier lieu les équipes composées de permanents, dans des environnements où on a peu recours à des "externes". Editeurs de logicels, PME, centres de R&D... sans doute d'autres catégories que j'oublie. -- lb

Je suis d'accord avec toi Laurent. D'autant plus que les premières expèriences XP identifiées en France semblent bien se dérouler dans ces environnements, non? -- bn

La où je travaille, la règle officielle est que nos noms (je suis presta.) ne doivent en aucun cas figurer sur un quelconque document; à leur place on doit écrire un code composé des initiales de la société et de nos initiales. La règle n'est bien sûr appliquée nulle part. Lorsque le responsable souhaite que nous assistions un "test de place" jusqu'à 20h, il n'a pas le droit de nous le demander par écrit, officiellement. Pour résoudre ces conflits, l'entreprise a "forfaitisé" tous les contrats de prestation. Mais bien sûr, les contrats ne décrivent que très sommairement les livrables à fournir. En fait, j'aimerais bien assister à un litige sur ce type de contrat, par curiosité...--ct