XpEnSsii

Un article de Agora2ia.


... ou Comment mettre en place XP dans une SSII ?


Sommaire

Contexte

Pratiquant XP depuis plus de 4 ans, je me demandais pourquoi il n'était pas promu par ma SSII...


L'amorce sur XP-France

Afin d'obtenir des pistes, j'ai donc envoyé un mail sur la mailing liste d'XP-France


La question

Cela fait quelques temps déjà que je m'interroge sur le sujet, et notamment :

  • Pourquoi XP n'était pas "vendu" par ma SSII ?
  • Mais aussi et surtout comment y remédier ?

La question avait déjà été posée lors de la rencontre AFUP de l'Extreme Programming du 7 avril 2004.

J'ai récemment discuté avec ma commercial qui m'a alors signalé qu'elle avait de plus en plus de clients qui lui parlaient d'XP. De plus, elle était apparemment intéressée pour approfondir le sujet.

C'est donc le moment ou jamais !


Les réponses

En clair, se sont les mails des membres de la mailing-liste, et en gras se sont mes réponses au fil de l'eau...


Perrick Penet (message n° 4283)

Co-fondateur de la société http://www.noparking.net ("éditeur de logiciels") :

  1. Lire des livres => Lesquels ?
  2. Maîtriser XP dans le contexte cible (Comment faire des tests unitaires, des tests release dans l'environnement cible...)
  3. Faire un XpGame => Sensibilisation, "éducation" du client
  4. Etre à l'écoute : « c'est souvent trop facile d'arriver en disant 'j'ai LA bonne solution' ».


Christophe Thibaut (message n° 4286)

  • En commençant par examiner soigneusement et de manière approfondie la faisabilité de ce projet en regard de l'état de la SSII en termes déontologiques.
  • Les pratiques gagnant/perdant sont florissantes dans les SSII, de par la nature des obligations contractées, qui n'est pas adaptée à la nature du développement logiciel.
  • Dixit un commercial (20 ans d'expérience) : "Tu prend connaissance du budget, tu propose légèrement en dessous. Au milieu du projet tu profite des demandes de changement pour renégocier le contrat ou créer des avenants. Tu peux passer du simple au double." Dans ce type de société, le passage à XP est quasiment impossible.
  • Exemple d'unsigne clair que XP ne marchera pas dans votre boîte : il y a au moins deux versions du planning, celle qui est exposée en comité avec le client, celles qui est discutée en "privé" avec l'équipe. => Exemple de révélateur.
  • En agissant pour qu'à terme il n'y ait plus aucune différence comptable entre ce qui est "vendu" et ce qui est réalisé. Ou si tu préfères entre les jxh constatés et jxh "produit".


Balbous Tremeur (message n° 4287)

  • Je pense qu'il faut tenir des contextes particuliers:
    • Si tu es en régie, la SSII peut vendre une compétence agile (une personne maîtrisant XP) qu'elle que soit la place dans l'équipe. Mais dans ce cas, le client doit être demandeur : déjà agile ou bien vouloir le devenir.
    • Si tu es en régie-forfaitise, (une équipe complètement issue de la SSII mais présente chez le client) la SSII peut proposer /imposer/ la méthode, mais dépendra toujours du "client", à moins d'avoir une "émulation" du client dans l'équipe. Dans ce cas là il faut bien connaître le métier, mais surtout, le contrat doit prévoir qu'on ne livrera pas forcement la réalisation exacte du cahier des charges fourni ! => Approfondir l'aspect contractuel : p191 du livre de Dominic sur l'Extrem Programming
    • En forfait, la problématique du "client" est toujours présente, accentuée par le fait que l'équipe n'est pas chez le client. Et il y a toujours le problème du contrat.
  • Je pense que contrairement à un éditeur ou un "client", la SSII n'a pas le contrôle de la méthode qui est mise en place (lorsqu'il y en a une). => Pourquoi notre devoir / métier de conseil, notre compétence ne pourrait être QUE technique et pas aussi méthodologique ???
  • De plus, même s'il y a un buzz autour de l'agilité, il est clair que les choses bougent lentement en France et que ça n'est pas dans notre mentalité de "tester". Il faudrait appliquer le pattern XP à l'organisation complète. On définit l'organisation que l'on veut obtenir, on fait la chose la plus simple qui marche, on test, on modifie, on recommence. Mais cela implique une plus grande souplesse d'esprit et une volonté que peu de gens possède (ou exprime)
  • J'ai aussi le sentiment que le rapport entre SSII et client n'est pas toujours gagnant-gagnant et que chacun se méfie de l'autre. La SSII hésite à aller vers XP ! (pas d'explication sur cette mentalité de tireur de couverture)
  • Je ne doute pas que si XP devient populaire, les SSII n'hésiteront pas à se lancer. Mais attention aux dérapages !


Franck Magnan (message n° 4288)

  • Comment fais-tu pour agir de l'intérieur sur ce genre de choses. Quand une personne hiérarchiquement supérieure te demande de ne pas (oh, surtout pas!) divulguer ce planning interne au client ? => Très bonne quesion !...
  • Et puis, honnêtement (je ne sais pas si ce terme est vraiment approprié à une SSII), dans un mode régie, plus le travail est long à faire et plus il rapporte à l'entreprise prestataire. Dans ce contexte, pourquoi s'améliorer ? Je n'ai pas une grande expérience des SSIIs mais le peu que j'en ai vécu m'incite à croire que la qualité logicielle ne leur rapporte pas. Si une SSII fait du mauvais boulot, elle reviendra sur son code et facturera la maintenance.
  • Peut-être existe-t-il des SSII avec un autre comportement ?

Remarque de mon responsable client : « Si c'est buggé, la facturation d'une éventuelle maintenance est à voir, et de plus, il est clair qu'il n'y aura pas de prochaine fois ! »

D'un autre côté, on ne peut pas reprocher aux SSII d'appliquer XP : « faire le plus simple qui fonctionne »... Le plus qui simple qui marche pour une SSII, c'est simplement faire du bénéfice !

Pour ma part je rapprocherais cela aux tests en XP : c'est un investissement au départ, c'est du temps à prendre dans un premier (considéré comme certain comme une "perte" de temps), qui s'avère rapidement payante dés le moyen terme (moins de temps passé en debug, en correction et beaucoup plus de confiance dans les remaniements, les évolutions transverses dans le code...).


Christophe Thibaut (message n° 4290)

> Comment fais-tu pour agir de l'intérieur sur ce genre de choses.
> Quand une personne hiérarchiquement supérieure te demande de ne pas (oh,
> surtout pas!) divulguer ce planning interne au client ?

Il y a peu de marge de manoeuvre mais tu n'es pas obligé d'intérioriser une exigence qui ne serait pas conforme à ce que dicent le bon sens (où la loi) en matière de probité. Face à la demande que tu décris ma réponse serais sous forme écrite :

<mail> Suite à notre conversation de ce matin, et afin de clarifier la portée de la consigne que tu m'as donnée et de la faire appliquer au mieux, pourrais-tu préciser :

  • quels documents relatifs au projet peuvent/doivent être communiqués

au client

  • quels documents relatifs au projet doivent rester strictement

confidentiels dans l'équipe et jusqu'à quelle date/jalon/échéance

  • ce qui motive la consigne de confidentialité
  • quels documents l'équipe utilise-t'elle pour le pilotage du projet

Merci d'avance, cordialement. </mail>

Ceci à le mérite d'être une réponse alors que moi je n'en ai pas. Mais si on n'est déjà pas dans une relation gagnat-gagnat avec son responsable, ça promet !

> Et puis, honnêtement (je ne sais pas si ce terme est vraiment
> approprié à une SSII), dans un mode régie, plus le travail est 
> long à faire et plus il rapporte à l'entreprise prestataire.

<fun>Le Pointy Haired Boss de Dilbert loue les services d'un consultant payé à l'heure. Il lui demande : - et quel processus mettrez vous en place pour parvenir à votre diagnostic ? - un ............ pro .... ces.....sus........as....sez ......long </fun (c)Dilbert>

C'est à double tranchant en fait. On me demande d'assurer un service de développement en régie, pour un certain nombre de mois +- 10 jours. Je décide de multiplier cette durée par deux en trouvant des prétextes au fur et à mesure (on en trouve toujours). Il n'est pas sûr que le client va me garder tout ce temps. Et s'il me garde, dépité, est-ce qu'il me reprendra pour une nouvelle mission ?

N'est ce pas là une piste de réponse : identifier so oui ou non une SSII est conservée, voire reprise, lorsque le travail fourni est insatisfaisant, ou si les amitiés, les réseaux d'influence, les listes de référencelent ou les arrangements commerciaux sont les seuls critères.

Et si de mauvais résultats entrainent bien peu ou plus de nouvelles missions pour la SSII responsable, le mettre en évidence auprès de la direction (de ma direction). Cette tâche, si elle s'avère pertinente me semble à elle seule valoir les 12 travaux... d'Obelix ;o)

Pourquoi ne pas faire une enquête de satisfaction auprès des clients de ma SSII ?... « Etes-vous satisfait ? », « Etes-vous de plus en plus satisfait ? », « Que voudriez vous de différent ? »... ???...

Surtout qu'il faut relativiser : les missions ayant une méthodologie classique ne sont pas toutes des échecs... En quelle proportion au fait ?... Encore un travail pour Hercule !


Ce qui sauve un prestataire passable (ou malhonnête), c'est que c'est "partout pareil". On en vient à croiser des prestas qui disent "oui, c'est de mauvaise qualité, mais rends-toi compte : si il n'y avait plus de bugs, on n'aurait plus de travail". Ma réponse tient en trois mots : Ah,Ah,Ah. On imagine pas la quantité d'évolutions fonctionnelles qui dorment dans les catalogues de demandes des maîtrises d'ouvrage. C'est incroyable. Les responsable de maîtrise d'oeuvre sont obligés de freiner, de refuser, d'invoquer les budgets. Il reste encore une foule de chose à informatiser, ou à informatiser mieux.

C'est effectivement un très bon contre-argument que je n'avais pas envisagé !

> dans un mode régie, plus le travail est long à faire et plus 
> il rapporte à l'entreprise prestataire.
> Dans ce contexte, pourquoi s'améliorer ? Je n'ai pas
> une grande expérience des SSIIs mais le peu que j'en ai vécu
> m'incite à croire que la qualité logicielle ne leur rapporte pas. 
> Si une SSII fait du mauvais boulot, elle reviendra sur son code 
> et facturera la maintenance.

C'est une façon de gagner de l'argent, la rente. Une autre consiste à gagner des parts de marchés, en faisant la différence. C'est tout un programme ;-)

> Peut-être existe-t-il des SSII avec un autre comportement ?

Oui, celles que vont monter plus tard les jeunes qui pratiquent une meilleure qualité logicielle dès leur formation.


Laurent Bossavit (message n° 4291)

> Oui, celles que vont monter plus tard les jeunes qui pratiquent une
> meilleure qualité logicielle dès leur formation.

Celles que *pourraient* monter plus tard... Ton réseau d'inférence n'est pas complet, il montre seulement [formation qualité] => [salubrité des pratiques business] alors que d'autres arcs contribuent, positivement ou négativement, à la salubrité du métier.


Perrick Penet (message n° 4292)

> Bonjour Perrick,
> Parmi les autres éditeurs que tu rencontres, quels sont ceux qui ont
> une implication dans le monde XP ou comme toi dans le monde du libre ?

J'ai connais effectivement qq'unes. Parfois j'entends qu'elles font du XP et si je demande quelles sont les pratiques mises en place, je trouve trop souvent de "un peu de tests unitaires"... et c'est presque tout :-(

Autrement sit, dire que l'on fait de l'XP n'est pas tout : il faut le prouver... On ervient à l'XP Game, avec implication des XP-iens de la société.

> J'ai l'impression que la masse d'info sur le net cache la visibilité
> des petites sociétés. Ou bien peut-être n'ont-elles pas envie d'être
> trop visibles ? Qu'en penses-tu ?

C'est juste qu'une petite structure demande qu'on aille la chercher : elle n'aura jamais les moyens de faire sa pub sur autre chose que son produit. Quand elle y arrive.

Autres aspects, les "complexes" de la petite boîte :

  1. Soit on fait un bon produit et on se demande comment les autres ne font pas aussi bien.
  2. Soit on fait un super produit (mais qui est ultra-top- secret parce qu'on a peur de se le faire prendre) et dans ce cas on en parle pas.

En tout cas il y a des choses qui font que les méthodes agiles peuvent y fleurir : pas de hierarchie trop lourde, pas de département "méthodologies obligatoires", des petites équipes légères et réactives, etc...

Apparté car je suis intrigué... et peut-être naif : * Peur de se faire racheter, * Ou peur du « plagia industriel » : si c'est top et facil ca serait déjà fait, donc si c'est pas fait, c'est qu'il n'y a pas de danger ?!


Thomas C Granier (message n° 4313)

Dans ma boite (SSII aux USA/UK), nous pratiquons exclusivement les methodes Agiles (c'est a dire du XP modifie pour coller aux contraintes specifiques du client et les caracteristiques du projet - nous preferons marketer sur le terme Agile que sur le terme XP pour indiquer notre volonte de rester pragmatique ("taylorer" notre approche aux besoins du client) et aussi exprimer que l'on peut conduire avec succes des projets de toute taille suivant une approche Agile ie: pas seulement des petits/moyen projets - bien sur il y a plusieurs points sur lequels nous ne transigeons pas comme les tests automatises ...) dans un contexte de regie-forfaitise (le plus souvent les equipes sont 50% client 50% SSII ) ou nous controlons ou co-controlons la conduite du projet (au bout d'un moment, pas toujours au debut evidement).

Voilà une des principales problématiques d'XP : être extremiste ou plus cool !.

Avec le recule, j'ai l'impression qu'un des pronlèmes d'XP est de devoir s'insérer dans les différentes dimensiosn d'un projet client : * A la fois dans le temps (pas forcément dés le début du projet), * Mais aussi l'espace : je me rappelle que, "à l'époque", Coach avait du faire un document pour prouver que notre projet/équipe/méthodologie s'intégrait bien dans le macro projet dans son ensemble.

Comment nous en sommes arrive la ? En creant une culture de communication ouverte et de courage de se tromper parfois, avec tres peu de hierarchie, et avant tout une reconnaissance que le coeur de notre activite est de produire du code qui delivre un benefice au client. De la l'idee de reunir des developpeurs brillants et passiones et d'encourager une culture technologique et pragmatique tres forte dans toute la companie (par exemple nous n'avons pas d'architectes qui ne developpent pas et nos senior developpeurs ont autant de poids que nos project managers).

Argument de vente et ligne de conduite !!!

C'est pourquoi quand XP est arrive, nous l'avons adopte spontanement, sans nous poser beaucoup de questions.

Bien sur tout ca ne s'est pas passe en France. Mais ce que je pense c'est que ce n'est pas le fait d'avoir des clients externes qui soit le plus grand barrage pour XP dans une SSII. C'est avant tout la culture de la boite comme dans n'importe quel autre boite. Et je ne pense pas que XP puisse changer la culture d'aucune boite - c'est la culture qui doit changer d'abord. Si la direction et la base ne veulent pas changer les choses ensemble, je changerais de boite et economiserait mon energie pour un terrain plus fertile.

C'est une façon de voir, et je la note ! Mais pour l'instant je reste persuadé que tout ce qui ne me tue pas me rend plus fort !...

Par contre cela n'est pas toujours vrai chez le client : mon n+3 est pour XP mais pas son n+1... Et on en fait !

Pour ce qui est des clients - meme en France - je suis convaincu que on peut les convaincre de la meme maniere que nous avons convaincu des client anglais ou americains. "Business is business" apres tout, au moins profitons des aspects positifs de la dite mondialisation. Bon peut-etre que cela fait trop longtemps que je n'ai pas travaille en France, et je me fais peut-etre des idees. Je suis interesse d'entendre des avis contraires :)


Christophe Thibaut (message n° 4325)

> > Oui, celles que vont monter plus tard les jeunes qui pratiquent une
> > meilleure qualité logicielle dès leur formation.
>
> Celles que *pourraient* monter plus tard... Ton réseau d'inférence
> n'est pas complet, il montre seulement [formation qualité] =>
> [salubrité des pratiques business] alors que d'autres arcs
> contribuent, positivement ou négativement, à la salubrité du métier..

Oui, je crois que si cette inférence seule comptait, nous serions déjà dans un marché plus sain ;-). C'est sûrement un facteur parmi tant d'autres.


Christophe Thibaut (message n° 4326)

> Dans ma boite (SSII aux USA/UK)...

Hello Thomas,

Quelque chose me frappe dans ce que tu écris là : nous sommes (en tant que prestataires en SSII) parfois à nous demander si les clients sont prêts pour XP; nous nous demandons où sont les clients agiles, alors qu'en fait c'est nous qui ne sommes pas prêts à constituer une offre XP et à démarcher des clients /quelconques/ avec cette offre agile.

Ouaih ! Le fait que ma commerciale me sollicite car des clients lui en parle, alors que ma Direction Technique ignore mes relances...

Ca me fait penser à la mise en place de CMM dans ma SSII : c'est suite à une propal perdue sur un projet pour non "certification" CMM que le PDG a décidé que l'on devait s'y metttre !

A chaque fois que nous disons "le marché n'est pas prêt", est-ce qu'il n'y a pas une forme de frilosité (ou de saine prudence), de notre part en tant que fournisseurs ? Le Directeur des Opérations qui dit "nous allons faire XP, mais nous ne ferons pas pair programming, parce que le client ne comprendrait pas" n'a effectivement pas encore changé de culture de ce point de vue : il continue de croire (ou de feindre) que le travail de développement est en général moins productif à deux que seul, bien que des expériences, des chiffres, des récits puissent infirmer ce principe, sinon démontrer le contraire. Il ne lui viendrait pas à l'idée, par exemple, de suggérer le P.P. à son client; il "sait" déjà la réponse.

Complètement d'accord pour l'avoir vécu !... Je pense que beaucoup de gens étant comme Saint Thomas, une démonstration ne serait-elle pas une autre piste de réponse ?... Mais quelle genre de démo : un même projet réalisé par 2 équipes (une XP et l'autre non) ?... Irrealiste !... ???

On a deux formes de raisonnements commerciaux :

  1. Si j'ai quelque chose à vendre -- notre démarche agile -- qui a de la valeur, il faut que j'essaie de trouver des clients.
  2. Cette démarche agile, nous l'adopterons, si les clients la demandent. ... et l'adopterons à sa demande (pas de pair-programming trop couteux, pas de tests car pas de temps...)

Dans le premier nous cherchons à offrir de la valeur (sous une forme nouvelle, future) à des clients. Plus de risques, mais plus d'opportunités. Dans le second cas nous valorisons ce qui est actuellement exprimé en tant que besoin par les clients. Peu de risques, mais quelle concurrence autour de nous !

Autre piste : quantifier combien de clients souhaiteraient de l'XP, quantifier également l'évolution de cette demande... voire les raisons !


Sebastien Douche (message n° 4338)

> On a deux formes de raisonnements commerciaux :
> a) Si j'ai quelque chose à vendre -- notre démarche agile -- qui a de
> la valeur, il faut que j'essaie de trouver des clients.
> b) Cette démarche agile, nous l'adopterons, si les clients la demandent.
> Dans le premier nous cherchons à offrir de la valeur (sous une forme
> nouvelle, future) à des clients. Plus de risques, mais plus d'opportunités.
> Dans le second cas nous valorisons ce qui est actuellement exprimé en
> tant que besoin par les clients. Peu de risques, mais quelle concurrence
> autour de nous !

Trés bon résumé.

Mais au vue de mon expérience j'ai du voir 2 ou 3 personnes ayant le raisonnement a) ! (et toujours des créateurs de société). Pour ma part, je ne peux que reprendre les différentes observations que vous avez faites. Frilosité extrème des SSIIs, frilosité extrème des clients, il est rare de trouver une personne capable de se remettre en cause pour proposer des solutions nouvelles. De manière générale, j'ai l'impression que dans ce milieu (le service informatique), la qualité n'intéresse pas, sauf dans des secteurs bien spécialisés. Mais j'avoue que j'ai perdu un peu la foi dans la capacité à faire bouger les choses ... Bien que je sais pertinament que c'est les petits efforts de chacun qui fera avancer la chose (on se foutait bien de ma gueule en pour Linux 1996 et de Zope en 1999...).

Je ne comprend pas: # Faut quand même du cran pour monter une société, même si ça n'est que pour l'aspect pécunier, alors pourquoi ce même PDG qui a monté une société n'a pas le cran de faire le pari-XP ??? # A note époque, les "premiers développeurs Objet" commencent à devenir des décideurs (chez le client)...

Christophe Thibaut (message n° 4344)

Hello Sébastien,

> De manière générale, j'ai l'impression que dans ce milieu (le service
> informatique), la qualité n'intéresse pas, sauf dans des secteurs bien
> spécialisés. Mais j'avoue que j'ai perdu un peu la foi dans la
> capacité à faire bouger les choses ...

Toute connotation religieuse mise à part, qu'est-ce qui te permettrait de retrouver la foi ?


Thomas C Granier (message n° 4369)

A quand la creation en France d'une SSII par quelques passionnes de XP et des methodes agiles ? (et au moins un client dans leur carnet d'adresse ... !) Je pense qu'il serait relativement facile de mettre sur pied une proposition tres attractive pour les clients potentiels ...


Bernard Notarianni (message n° 4370)

> A quand la creation en France d'une SSII par quelques passionnes de XP et
> des methodes agiles ? (et au moins un client dans leur carnet d'adresse
> ... !) Je pense qu'il serait relativement facile de mettre sur pied une
> proposition tres attractive pour les clients potentiels ...
>
> Thomas

Qu'est ce qui serait très attractif dans cette proposition?

Bonne question/réponse qui je l'espère va amener d'autres "arguments" de vente !

Christophe Thibaut (message n° 4371)

> > A quand la creation en France d'une SSII par quelques passionnes de XP et
> > des methodes agiles ? (et au moins un client dans leur carnet d'adresse
> > ... !) Je pense qu'il serait relativement facile de mettre sur pied une
> > proposition tres attractive pour les clients potentiels ...
> >
> > Thomas
>
> Qu'est ce qui serait très attractif dans cette proposition?

Dans la représentation que se font les clients potentiels de l'offre en termes de méthodes et d'outils, il me semble qu'une proposition très attractive serait en concurrence avec des centaines d'autres propositions passées.

  • Developpez 10 FOIS plus vite avec BiduleDev !
  • Faites PLUS avec MOINS avec MicroTruc !
  • Urbaniser votre SI peut vous faire gagner de l'ARGENT !
  • etc..

Le discours basé sur scénario magique : "nous arrivons, nous évaluons votre problème et produisons une solution rapide et pas chère et de meilleure qualité" ne fonctionne pas, je pense, même si cette prédiction était vérifiable à disons 15% près (du coût, du périmètre ou du délai).

C'est le paradoxe des voitures d'occasions pourries. La voiture d'occasion valable -- la vraie bonne affaire -- est perdue dans le bruit de toute la réclame abusive faite sur les chignoles, et le client ne la trouvera pas, et ne l'achèterait pas s'il la trouvait.

Très intéréssant : il est vrai que les arguments de vente d'XP sont ceux pronés par d'autres, ce qui noie XP parmi ces autres !... On revient encore à l'XP Game !

Autre aspect intéressant : sur le plan "commercial", il faut vendre à un client * Non pas ce que moi (le développeur) aime dans XP, * Mais ce que le client aimerait en XP !... C'est à dire ?!...


Bernard Notarianni (message n° 4372)

> Dans la représentation que se font les clients potentiels...

Dois-je comprendre qu'il n'y aura pas de proposition très atractive?

Quelle sera noyée dans le bruit marketing, et n'attirera donc pas les clients?

Je me demande si en matière de marketing ca ne serait pas un peu comme en logiciel: no silver bullet.


Marc-Antoine Garrigue (message n° 4373)

Bonjour,

Est ce que la question est :

  • Comment vendre XP dans le cadre d'un AO projet? (la ssii fait le projet en mode xp) => Pour ma part, c'est de cela dont je parle !

ou

  • Comment vendre un coach XP?

Dans le premier cas, c'est un exercice difficile, dans la mesure ou le mode forfait chéri par les clients n'est que peu compatible avec XP. Il faut donc convaincre sa pertinence sur le projet, et convaincre en plus sur la pertinence du mode XP. Ceci dit, c'est faisable, l'histoire le prouve.

Dans le second cas, c'est plus 'facile'. L'exercice est plus personnel, c'est au coach de démontrer sa valeur. Il semble que de plus en plus de clients s'interressent à cette compétence double et rare qu'un coach XP possède nécessairement : excellence technique et management/animation d'équipe. La demande existe et va croissante pour ce type de profils.


Vianney Lecroart (message n° 4375)

Je me trompe peut etre mais j'ai l'impression que la seul facon qu'une SSIIXP puisse fonctionner et d'avoir un client, qu'il soit content de la qualité et la facon de produire son projet et de faire jouer le bouche à oreille pour avoir de nouveaux clients.

J'ai discuté de cela pas plus tard que ce matin avec mon coach (client) qui m'a dit que, selon lui, seuls les opérationnels du haut de la pyramide parlaient entre eux (chez différents clients), mais pas forcément avec une connaissance sur la compétence et mérites d'une SSII. Le bouche à oreille n'est pas forcément pertinent.

Toujours pas rapport au bouche à oreille, peut-être que si l'on fait un XP Game, la présence de clients avec les-quels ont a déjà fait le l'XP, est une bonne chose ?!

C'est clair que, comme le dit Christophe, si une SSIIXP se monte et fait la pub avec ce qu'avance XP, il risque de se faire lincher, deja que lorsqu'on parle d'XP avec des dev beaucoup trouvent que XP c'est du Marketing bancal pour une vendre nouvelle méthode qui marche meme pas (non mais franchement, comment ca pourrait marcher, faut faire du binomage! :)


Thomas C Granier (message n° 4379)

Je vois un peu (beaucoup?) de frilosite parmi les abonnes de la liste XP - je me demande ce que ca doit etre pour les autres informaticiens :)

Tout d'abord je crois que je "marketerais" sous la denomination "demarche Agile" et non "demarche XP" - trop restrictive et sujette a controverse quand elle est mal comprise. Qu'on le veuille ou non les methodes Agiles gagnent du terrain, meme en France (recent article dans 01 informatique sur les chefs de projets en fait mention une fois de plus) - et par example en Angleterre, le secteur public (!) a adopte dans quelques services DSDM (National Health Service).

Concernant l'aspect commercial: * Il faut vendre une "démarche Agile" (pour ne pas éffrayer le client ou risquer d'être mal compris) * ou vendre la "Méthodologie XP (en expliquant).

Je crois qu'a terme Agile peut remplacer RUP dans le creneau des methodes de development iteratifs, et reussir la ou RUP, le plus souvent mal compris et mal applique (trop complet ?), a echoue (a mon avis).


A un client, je soulignerais les avantages qui l'impacte directement - pas particulierement le pair programming, qui est juste une technique (justifie) pour produire du code de qualite.

Différence entre ce que JE aime dans XP et ce que LE CLIENT aimerait.

Par example:

  • Nous n'avons besoin que de 2-3 semaines de collaboration intensive avec votre equipe pour une periode d'inception, histoire de mettre en place le projet proprement (business case, solution technique et fonctionelle a un haut niveau, organisation et plan de communication ...) avant de commencer la construction de votre solution. (creer un esprit d'equipe entre MOA et MOE, dynamiser le debut du projet, faire juste assez de preparation pour elaborer une solide vision d'ensemble commune)
  • Vous n'avez pas besoin de rediger un cahier de charge detaille de 500 pages et apres ca attendre 6 mois pour voir le premier resultat - donnez-nous un "subject matter expert" pour 2/3 jours par semaine pour capturer les specs detailles au fur et a mesure et vous allez pouvoir assister a des demos regulieres (des le premier mois) qui vous monterons la fonctionalite qui vous interesse le plus en premier, ou vous pourrez nous donner votre feedback en direct. [ si le client dit pas le temps, je questionerais a quel point le projet est strategique pour lui et/ou comment le projet pourrait reussir avec n'importe quelle approche ] (communication directe, feedback regulier, construction iterative)

... Et ne pas faire un DCD de 500 pages c'est un sacré gain de temps pour le client !

  • Chaque semaine vous saurez tres precisement l'etat d'avancement du projet: quelle fonctionalite est deploye dans l'environement de test (que vous pourrez tester vous meme a chaque iteration si vous voulez); combien de temps il nous faudra pour construire ce qui reste a faire, base sur un plan constament mis a jour qui reflete la realite. (transparence du reporting, pas de fonctionalite "90% finie" mais seulement pret ou pas pret pour etre deploye en production)
  • Vous controlez le perimetre du projet : Au lieu de negocier des avenants a la douzaine a la fin du projet pour avoir une solution qui reflete ce que vous voulez vraiment, avec nous vous pourrez changer la priorite des fonctionalites a construire a tout instant durant le projet et meme changer les specs de ce qui reste a faire si votre comprehension de la solution evolue ou si votre business change de priorite en cours de route. (les etudes montrent que 20-50% de la fonctionalite construite pour une solution n'est jamais ou tres peu utilise en production - parceque le client n'a pas la flexibilite explique ci-dessus)
  • Vous etes interesse mais pas pret a collaborer tout de suite de cette maniere ? pour prouver notre savoir-faire, pourquoi ne pas selectioner un projet de 3mois au forfait (mais dans vos locaux ou proche de vos locaux) on nous demontrerons les avantages de cette collaboration tres etroite - mais avec un controle beaucoup plus strict du perimetre (du a la nature du contrat). => Excellente phase de transition pour le client !

Une fois un climat de confiance etabli, pourquoi ne pas passer au niveau superieur pour beneficier de tout les avantages de la methode ?

(n'oublions pas que tout contrat au forfait est majore de x% par la societe de service juste pour le risque inherent a la nature du contrat - % qui dans un contexte de "regie- forfaitise" pourrait se transformer en un budget de secours, sous le controle du client, a utilise a bonne escient seulement en cas de probleme)

Enfin bon, c'est juste un premier jet. Je suis sur que en reflechissant un peu plus on peux avoir des arguments plus frappant ...


Christophe Thibaut (message n° 4381)

Bonjour Thomas,

Ton argumentation me paraît intéressante et de bon sens; as-tu eu l'occasion de la communiquer à des clients ou prospects ? Quelles ont été leur réaction ?

> Je vois un peu (beaucoup?) de frilosite parmi les abonnes de la liste XP -
> je me demande ce que ca doit etre pour les autres informaticiens :)

Il y a aussi peut être de la résignation.

Mais ne te fie pas à la liste. Tous les développeurs qui suivent ou mettent en place une démarche agile au sein de leur entreprise ou auprès de leur client n'en rendent pas forcément compte ici.

Comme tu dois probablement le savoir, les obstacles à une démarche agile ne sont pas techniques, mais principalement humains : culture d'entreprise, relations interpersonnelles, "politique", résistance au changement. Dans ces matières, les "progrès" sont plus lents à réaliser -- et à discerner -- que le fait d'installer cvs, junit, ou les murs d'informations. Et il est moins facile de parler des problèmes humains que des problèmes techniques.

La raison pour laquelle je me figure que les approches classiques des SSII pour vendre leur service ne marcheraient pas avec XP ou l'agilité, c'est que l'agilité n'est pas une solution, c'est, comme tu le dis une démarche, qui suppose un état d'esprit.

J'ai personnellement adopté la définition qu'Alistair Cokkburn donne du développement de logiciel : un jeu de coopération et d'invention, dirigé vers un objectif et limité par les ressource. http://www.google.fr/url? sa=U&start=2&q=http://alistair.cockburn.us/crystal/talks/sdacg/swdevas acooperativegame060.ppt&e=9707 et je pense que l'approche classique pour vendre des produits ou des services ("vous avez un problème, nous avons la solution") n'est pas compatible avec l'état d'esprit agile. Ce n'est pas tant l'offre qui doit changer (se "repackager") c'est avant tout la demande. Comme le souligne -- involontairement ? -- ton argumentaire, des changements d'objectifs et de conception doivent avoir lieu /chez le client/.

Je pense que tout client censé (et il y en existe beaucoup) est ouvert aux propositions (donc aux changements) lui permettant de tenir ses objectifs et ses budgets.

  • passer à un mode de coopération actif et non attendre une solution
  • piloter le projet au fil de l'eau au lieu d'accumuler les avenants
  • utiliser des capteurs effectifs de l'état réel du logiciel (tests et jalons hebdomadaires) au lieu d'un pourcentage d'avancement théorique

Ce qui ne nous empêche absolument pas d'être ("nous" développeurs) force de proposition ! :-) Aaaaah, enfin !


Dominic Williams (message n° 4382)

> Je crois qu'a terme Agile peut remplacer RUP dans le
> creneau des methodes de development iteratifs, et
> reussir la ou RUP, le plus souvent mal compris et mal
> applique (trop complet ?), a echoue (a mon avis).

Même si RUP fait office de "référence", j'ai lu qu'il n'était pas réellement très répandu, comme UML d'ailleurs.

Ensuite, je ne vois pas comment Agile peut "remplacer" RUP, puisque par définition RUP permet de tout faire, y compris un processus agile.

Enfin, il me semble qu'en ce qui concerne "être le plus souvent mal compris et mal appliqué", XP est assez bien servi aussi. Je ne sais pas si cette situation s'arrangerait si XP devenait plus répandu.

> A un client, je soulignerais les avantages qui
> l'impacte directement.

Tout à fait d'accord.


Christophe Thibaut (message n° 4394)

> http://www.google.fr/url?
> sa=U&start=2&q=http://alistair.cockburn.us/crystal/talks/sdacg/swdevas
> acooperativegame060.ppt&e=9707

mais le lien était inutilisable. thibaut_christophe corrige:

http://alistair.cockburn.us/crystal/talks/sdacg/swdevasacooperativegame060.ppt


Freddy Mallet (message n° 4403)

Je crois en effet qu'il est bon de ne pas trop charger la barque concernant RUP. Pour un certain nombre de praticiens agiles, RUP est considéré comme le meilleur exemple de ce qu'il ne faut pas faire alors que RUP (je me base uniquement sur les bouquins que j'ai pu lire puisque je n'ai encore rencontré aucune entreprise appliquant réellement RUP) est un processus itératif avec il me semble beaucoup de bonnes idées. Le problème c'est quà ma connaissance 90% (au bas mot pour éviter de tomber dans la caricature) des chefs de projets qui disent faire du RUP appliquent en fait un processus en cascade qui intègre uniquement la composante statique de RUP (inception / elaboration / construction / transition). A titre personnel, je reproche à RUP de ne pas assez intégrer la composante humaine (au sens motivation, dynamique d'équipe, responsabilisation) et bien entendu d'être un cheval de troie pour vendre ensuite la suite complète rationnal mais pour le reste, ça me semble tout de même une très bonne méthodologie.

Pour revenir sur les problématique d'adoption des méthodologies agiles pour la conduite de projet au forfait par les SSII, je trouve que le post de Laurent sur son blog concernant le jeu du dilemme du prisonnier est un très bon résumé de la problématique de fond.

Page de Laurent sur le Prisoner's Dilemma.


Bernard Notarianni (message n° 4405)

> Je vois un peu (beaucoup?) de frilosite parmi les abonnes de la liste XP -
> je me demande ce que ca doit etre pour les autres informaticiens :)

Frilosité? Qu'est-ce qui te fait dire ca?

Tout ce que tu dis est très interessant, et nous ne manquons pas de le proposer (entre autres choses) chacun à nos clients, à notre echelle, à chaque fois qu'il est possible de le faire.

Parfois, cela marche. ;-)

Pour ta part, as-tu eu l'occasion de proposer ces idées à tes clients ou ta hierarchie? Comment tout cela a-t-il été acceuilli?

Quels ont été les contres arguments (s'il y en avait)?


Les actions

  • Réunion avec ma commerciale
  • Réunion avec ma Direction Technique
  • Un XP Game : quoi, comment ?
  • L'aspect "contractuel" dans le livre de Dominic