| Témoignage |
 Écrivez à AILES ! |
 Retour vers le dossier Chef de projet |
 Illustrations |
Et il a des choses à dire, Laurent, plein de choses. Il en a écrit une grande partie dans [publicité mode ON] cette eX-cel-lente Publication [XPLB] que je ne peux que vous recommander vivement (non, je n'ai pas d'intéressement... hélas... snif!) [publicité mode OFF], mais il a aussi élaboré des réfleXions Profondes sur de vastes sujets : - le métier d'informaticien depuis ces 30 dernières années; - la nature humaniste du processus XP; - et enfin la conduite de projet. Et en plus j'arrête les jeuX de mots Pourris avec des X et des P dedans, promis. Mes "questions" sont en italique rouge. Les renseignements essentiels de cet entretien sont en bleu. L'entretien date du 29 juin 2002, à la terrasse d'un petit café parisien... [c'était l'après-midi... y faisait pas très bô, mais au moins il faisait chaud :) voilà, voilà... ] |
Partie I : halte au cargo
!
Partie II : XP, un
processus humain pour une qualité humaine
Partie III :
les projets en SSII et XP... problèmes
 |
En gros, quel est votre
parcours ? En fait, je viens du monde des start-up avec son cortège de "projet commandos". Mais avant ce parcours professionnel, j'ai eu une expérience pré-professionnelle. En 1989, j'ai programmé pour un certain Bertrand Meyer, celui avec des notions claires et précises sur la programmation orientée-objet, claire, raisonnée, s'appuyant sur un paradigme complet... Et puis après, j'ai débuté professionnellement en... C! Ou en assembleur, ou en Pascal. Et les ennuis ont commencé. |
Heu... quels ennuis ? Vu mon parcours (start-up), j'ai été soumis a de multiples contrastes forts entre ma toute première expérience (la programmation objet rigoureuse de Meyer) et : - des langages de plus bas niveau (C, assembleur, ...); - des rythmes de travail insensés et peu maîtrisés ; - des habitudes de travail en solo (surtout lorsque je bossais pour une petite start-up californienne qui comptait 2 personnes, moi et le fondateur, chacun séparé par un océan). Tous ces contrastes participeront à pousser plus loin ma découverte d'XP, mais avant il y a eu le culte du cargo. Le culte du cargo ??? Dans votre site, vous avez un ingénieur de 30 ans qui affirme que cela fait 30 ans que l'on fait la même chose. Il parle des domaines fonctionnels, du métier (banque, assurance) dont l'activité demeure constante sur 30 ans, même si l'informatique qui soutient ces activités est en constante évolution. C'est bien. Mais le drame, c'est la façon dont nous informaticiens faisons notre métier. Certes les technologies évoluent mais nous nous y prenons toujours de la même façon, comme par une sorte de vénération aveugle à un culte du cargo : on analyse (au sens "expression des besoins"), on rédige un cahier des charges, on passe à la conception technique et au codage... avant de tenter désespérément de tester le biniou... si on a le temps. Évidemment, les délais sont très fréquemment dépassés. Bref, aucune vraie innovation dans notre savoir-faire... Alors, c'est quoi, ce culte ? Le culte du cargo fait référence à certaines tribus polynésiennes qui, durant la seconde guerre mondiale, voyaient les blancs (américains) construire des pistes d'atterrissage et des tours de contrôle. Une fois ces installations construites, ... magie : des avions-cargo atterrissaient avec vivres et divers richesses. Ces tribus se sont donc logiquement mises à construire des pistes d'atterrissage et des tours de contrôle factices en bois... en espérant bénéficier de la venue des mêmes avions ! Jusque ici, cela prête à sourire. Mais là où l'on ne rigole plus du tout, c'est lorsque l'on réalise que ces tribus, voyant bien l'échec de leurs démarches, s'en sont bien vite retourné à leur mode vie initial. Les informaticiens ont formalisé en 1970 une "méthodologie" rigide connue plus tard sous le nom de Waterfall, ou "développement en cascade" (d'abord l'analyse, puis la conception, puis le développement, puis les tests...). Et depuis 30 ans, ils ont le plus grand mal à vraiment changer de mode de fonctionnement ! Ce Waterfall fait référence à l'article du professeur Royce Winston, non ? Non, il fait référence à l'image que les informaticiens se sont faite de cet article. Royce décrit un processus beaucoup plus orienté itératif, mais il illustre aussi son process de références liées au monde industriel du hardware dont il est issu. Ainsi, il insiste sur l'importance de la documentation qu'il estime devoir être 10 fois plus importante pour un software que pour un hardware (soit 240 pages de documentations par millions de $). Il prévoit déjà l'existence des prototypes et du prototypage. Il insiste aussi sur la nécessité d'impliquer le client ! alors que, justement, le Waterfall est souvent utilisé pour ne pas impliquer le client, en lui proposant une simple façade de milestones au sein d'un processus "bien défini". [c'est le principe de la boite noire, par opposition à une boite blanche d'un modèle cybernétique à la XP, évoqué plus bas] Et surtout, il insiste sur l'importance à donner aux tests, pour lesquels il faut prévoir le budget ou les ressources les plus importantes, car il s'agit d'un "goulot d'étranglement" très probable. Le problème vient de l'origine et des références industrielles qui sous-tendent la démarche de Royce : dans l'industrie, le feedback itératif intervient peu en cours de production et l'on est tenté de poursuivre l'analogie hardware vers software en raisonnant en terme de "phases industrielles" (conception puis développement puis tests...) bien trop rigides, passant à côté de l'apport majeur de l'article de Royce. Il dénonce en effet un Waterfall "pur", qui serait (je cite) "risqué, et voué à l'échec" en précisant que sans prototypage, on risque d'avoir un retour en arrière brutal, de la phase de test à celle de la conception voire d'expression des besoins. Quelle est la conséquence d'une façon de travailler "à la Waterfall" depuis 30 ans ? Elle est fondamentale et constitue une des origines de XP : Personne n'est content. - Le client n'est pas content parce qu'il n'a pas ce qu'il veut dans les temps et souvent ce qu'il souhaite ne correspond plus à son souhait d'origine ! [Cela rejoint en effet la Loi n°1 des grands projets informatiques... ou encore les remarques du slide n° 12 de la présentation "Prestataire en SSII"] - le management du projet (la société, le chef de projet, les commerciaux qui ont vendu le projet) ne sont pas contents, car leurs objectifs ne sont pas atteints ; - les prestataires informaticiens ne sont pas contents, car ils détestent la façon dont se pratique leur métier. Or le drame, c'est qu'ils sont venus à ce métier, et y restent... par passion ! (cf. Nature et objet d'une organisation et Informaticien et Français ? - Verticalement - Dur!). Évidemment, les 2 sentiments (passion et mécontentement) entrent en conflit et se créent leurs propres problèmes... ce qui, par analogie, illustre la fameuse citation qui affirme que "l'informatique a besoin de plus en plus de puissance de calcul pour résoudre les problèmes qu'elle a elle-même contribué à créer. [Cela rejoint aussi la conclusion ironique de notre ingénieur de 30 ans qui rappelle que ce métier contribue à sa propre continuation en se créant toujours plus de complexité ! Autre exemple de projet "trop complexifié" avec cet ingénieur.] |
|
Partie I : halte au cargo !
Partie II : XP, un processus humain pour une qualité humaine
Partie III : les projets en SSII et XP... problèmes
| Alors, maintenant que
l'on a vu ce qui a pu te pousser vers XP (travail en solo,
paradigme de bas niveau, process à la Waterfall, ...), sur quoi
se base XP ? Avant tout, XP se base sur l'humain. A l'inverse de ce qui vient d'être décrit, tout le monde doit être content. En particulier, le prestataire informaticien doit être fier de ce qu'il fait. Pour arriver à ce - petit - miracle, XP propose un processus piloté par "l'analyse", c'est-à-dire par l'examen du problème et l'expression des besoins du client . Plus simplement, est jugé "allant dans la bonne direction" tout ce qui satisfait le client... simple, non ? Il s'agit donc de faire enfin du travail de qualité ! |
 |
||||||||||
Heu... mais justement, la "qualité", c'est quoi ? La réponse facile serait : "la qualité, c'est la conformité aux exigences". Celui qui affirmerait cela serait l'équivalent moderne d'un Ponce Pilate : il se laverait les mains des vrais enjeux de la qualité. C'est évident : on ne peut parler d'exigence sans se poser la question : "les exigences de qui ???" Si l'on part sur une définition plus humaniste de la qualité, on obtient naturellement : "ce qui est apprécié par une personne", mais cela ne suffit toujours pas : quelle est cette personne, quand et comment se manifeste son appréciation ??? Pour répondre aux critères de qualité, il faut donc tester au près du client : - si les résultats obtenus sont satisfaisant , - ce que l'on veut définir ou redéfinir comme résultat à atteindre. Il faut également ce demander, une fois ces "intentions" précisées, si l'on sait comment s'y diriger pour satisfaire à ces intentions. Et c'est là la subtilité de la qualité version XP : on ne se rend pas vers un objectif fixe, on se dirige vers un ou plusieurs buts qui forment la "zone de satisfaction du client", zone sans cesse raffinée avec lui (le client). [on retrouve une définition plus affinée de la qualité lorsque l'on aborde plus bas dans l'entretien l'aspect projet. Rq : Colin LORRAIN, un jeune développeur, insiste également sur l'implication du client dans son témoignage. Laurent inclut la notion de qualité dans la définition d'un Bug] Une zone ??? Mais pourquoi ne pas définir simplement un objectif précis ? Parce que la satisfaction du client dépend de critères multiples, définissant chacune une "dimension". On en connaît, les plus classiques de ces dimensions : le coût et les délais. Mais il y en a plein d'autres : la qualité de service (performance, temps d'indisponibilité minimal, etc...). Pour réussir à définir une solution unique qui répond du premier coup à tout ces critères revient à vouloir définir un point et un chemin précis dans un univers (ou hypercube) à n-dimension : c'est vachement compliqué. Il est plus simple de se mettre d'accord sur une "zone" générale de ce même hypercube (dont chacune des dimensions représente un axe binaire de critère de satisfaction client), et de viser cette zone en se définissant un "vecteur" dont on raffinera régulièrement la direction. XP propose donc, pour mettre en oeuvre une telle qualité, de communiquer avec le client, avoir le courage de prendre une direction générale pour aller simplement vers cette zone et vérifier régulièrement auprès du client si l'on va toujours dans le sens qu'il souhaite. De cette dernière phrase découlent les 4 valeurs fondamentales d'XP : la communication, le courage, la simplicité et le feedback. Ce dernier terme - feedback - joue un rôle important dans la définition de la qualité selon XP. Feedback et qualité ? Oui, la qualité revient donc à placer en objectif prioritaire le fait que quelqu'un apprécie son travail. Cette appréciation est mise dans un mécanisme de feedback, sachant que le contenu même du travail reste libre : on fait ce que l'on veut pourvu que l'on ait un retour régulier et une appréciation positive. Si l'appréciation n'est pas positive, il ne faut pas avoir peur du changement. "Embrace change", comme ils disent. Plus simplement, on brise le mythe de conception qui définirait la solution atteignable que via un "process balistique" (on vise, on tire... et on espère atteindre l'objectif initialement visé!) : XP voit la qualité comme un process de pilotage "à tête chercheuse". Mais pourquoi ne pas définir la solution lors de la conception ? On rejoint la difficulté de définir un point dans un espace de contraintes à n dimension. C'est tellement compliqué que cela rappelle la petite nouvelle de Jorge Luis Borges publiée en 1941 et décrivant la mise à disposition de toute la connaissance humaine sous la forme d'une immense librairie sphérique aux chambres hexagonales. La complexité d'un tel classement serait énorme (et c'est un euphémisme).
Alors, si XP n'apporte pas de
"réponse", qu'apporte-t-elle ?
Ah okok... heu... et RUP alors ??? Une première réponse, un peu cynique, serait de considérer XP comme une instance du process de Rational (RUP = Rational Unified Process). C'est cynique parce que cela sous-entend que RUP peut, de par sa taille énorme et ses capacités "infinies" de configuration et d'adaptation, instancier à peu près n'importe quel autre process ! Rational lui-même parle de dX (retournez le symbole graphique "Xp" à l'envers... et vous obtenez "dX" ! humour...), comme un process minimal du RUP. Mais tout cela cache mal les désaccords fondamentaux qui séparent ces 2 processus (même s'ils sont tout deux itératifs) : - la dimension humaine, présente dans XP, est difficile à retrouver dans les dizaines "d'artefact" du RUP; - la démarche d'XP de "maîtrise du chaos" s'oppose fortement à la culture de "process répétable", "maîtrisable", sous forme de recettes et "best practices". XP voit le projet comme une culture, un phénomène social qui, de par sa nature même n'est pas répétable ! Partie I : halte au cargo ! Partie II : XP, un processus humain pour une qualité humaine Partie III : les projets en SSII et XP... problèmes
Mmmm... oui, mais quels sont les problèmes, alors ?
Enfin, il reste le problème de l'implication du management de la SSII dans le process XP : il faut briser le mythe du manager qui "dirige", au sens "interventionniste" du terme. Les dirigeants doivent approuver et valider un process et déléguer, sans intervenir directement. Pourquoi ? Vous avez un exemple ? Oui, tout simple : piquer un membre de l'équipe pour le mettre en urgence sur un autre projet. C'est typique de la vision très "ressource humaine" qu'ont les SSII de leurs collaborateurs. Pour eux, une équipe est souvent composée d'un senior et d'un junior (pour bénéficier d'une formation sur le tas). Et en cas d'inter-contrat, on arrive à toute sorte d'aberration de style "marchand de viande". [un autre cas très similaire est signalé par Colin LORRAIN] C'est oublier la vision organique de l'équipe dans un process XP. Priver l'équipe d'un de ses collaborateur, c'est comme priver un corps humain d'un de ses membres : ça n'est pas anodin. J'ai constaté cette attitude de "marchand de viande" même entre forfaits... entendez par là que tout se fait selon un "prisme" régie, même pour des forfaits : on fournit de la main d'œuvre sur une mission donnée, sans que le collaborateur ait vraiment l'opportunité de s'investir sur un résultat : pour lui, mission (régie) ou projet (forfait) devient alors du pareil au même : il change juste de local, de groupe et de responsable ! Et pour vous, tout cela (groupe, local, responsable) ne permet pas de faire un projet ? Ce n'est pas la même approche ni la même culture : pour moi, XP doit mettre en place une vraie synergie [non, cette fois, ce terme n'est pas utilisé pour jeter de la poudre au yeux ou pour jouer au Business Loto :) .Pour l'anecdote, on avait organisé un "Bullshit Bingo" au discours de fin de XP2002. Nos 5 panélistes, dont l'illustre Kent Beck, ont joué sans le savoir... Par contre on a eu beaucoup de peine à le gagner !] Une équipe n'est pas qu'un "groupe" de développeurs, c'est un tout qui vaut plus que la somme de ses parties. L'illustration la plus frappante de cette approche reste le "pair programming", qui n'aurait aucun sens si c'était uniquement pour produire juste 2 fois plus de travail qu'avec une seule personne. En plus de la productivité accrue, il y a échange de connaissance entre les binômes, et en plus chaque développeur change régulièrement de binôme. Et tout ça en 40 heures par semaine ??? 40 heures, 39 heures, 35 heures, 50 heures... Peu importe. XP préconise avant tout un "rythme durable", c.à.d. une durée journalière et hebdomadaire qui permettent à l'équipe de bien fonctionner. Chaque semaine, on se réunit pour décider si le rythme de travail des jours précédents est tenable pour produire un travail de qualité. Même un "temps de présence faible" est acceptable, car on part du principe que le développeur fait le maximum tout le temps, même chez lui. Pourquoi ? Parce que son intérêt (apprendre et se maintenir à niveau) rejoint celui de son employeur (gagner des sous au travers de la réalisation de projet). Même s'il ne travaille pas directement sur le projet, il a encore suffisamment d'énergie pour apprendre chez lui. Évidemment, ce n'est pas très bien accepté par le management. Je me souviens avoir un fois permis à un développeur de rentrer plus tôt chez lui un vendredi. J'estimais qu'il avait fourni un super boulot et ne voyais pas l'utilité de le retenir pour une nouvelle tâche... et je me suis fait remonter les bretelles par la direction! Merci beaucoup pour toutes ces opinions, M. Bossavit. Rappelons que ce qui précède ne fait qu'effleurer certains aspects d'XP, "cet ensemble de pratique qui couvre une grande partie de la réalisation d'un logiciel". Pour en savoir (beaucoup) plus, vous pouvez utilement vous référer à [XPLB], le livre qu'il a co-écrit sur XP avec Jean-Louis Bénard, Régis Médina et Dominic Williams. |
|||||||||||
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"