Articles « Info » : Chef de projet

Bon ok, l'article est long... très long. Il est subdivisé en paragraphes directement accessible et l'essentiel en est souligné, ce qui devrait vous permettre de le survoler.
De plus, il est rigolo à lire... sisi, j'vous jure. Et il est commenté, avec des renvois vers d'autres articles de ce site afin de le relier à des sujets déjà décrits et connus.

Rq : vous avez pu arriver sur cette page depuis la page du cycle en... V (?) de la section des blagues, mais je peux vous dire que :
- cet article fait bien partie de la section Chef de projet ;
- depuis mars 2000, date de publication de cet article, vous n'avez pas idée du nombre d'ingénieur informaticien un peu expérimentés (8-10 ans d'expériences ou plus) qui m'ont affirmé que tout ce qui est décrit dans cet article est vé-ri-di-que... et ça fait froid dans le dos !

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design
    Phase d'Implémentation
    Phase instructive de délire mental
    Conclusion
    En 1970, Dr. Winston a publié un article intitulé « Managing the Development of Large Software » (gérer le développement de projet informatique important). Il est couramment admis que cet article est à l'origine du développement dit "en cascade" des projets informatiques, où l'on croyait qu'un projet pouvait être complètement analysé (spécifié) avant d'être conçu, , complètement conçu avant d'être codé et complètement codé avant d'être testé : Waterfall.
    Je serais le Professeur Royce, je considérerais avec horreur la fait que Waterfall a de façon si méthodique et inextricable imprégné la communauté du développement logiciel.. Il n'est pas surprenant, même de nos jours, d'entendre des chefs de projet réprimander leurs développeurs en leur rappelant de bien tout concevoir avant de coder. Cela leur permet de dessiner un "X" tout au long de la phase de conception.
    L'article de Royce décrit ce que nous appellerions aujourd'hui un processus de développement itératif et incrémental, où la phase d'analyse (spécification) doit être nuancée par des impératifs de conception, comment la conception nourrit en retour l'analyse, et comment les problèmes d'implémentations se répercutent sur la conception. Il décrivait également le processus incrémental de réalisation d'un projet, où chaque incrément possède ses propres phases d'analyse, de conception, de codage et de test.
    Manifestement, l'idée de départ de Royce est "saine" : subdiviser un gros problèmes en de plus petits, chacun étudié et réalisé selon des étapes qui interagissent l'une avec l'autre.
    Cool. Laurent Bossavit insiste d'ailleurs sur l'aspect
    Le problème (dans les années 80), c'est que dans le monde hyper-professionnalisé des États-Unis, les chefs n'ont retenu de ce principe qu'un mot magique : incrémental. Mal interprété (c.à.d. "étape par étape"), il est magique car il permet à tout chef (américain ou français) d'exercer ce qui représente 90% - bon, ok, j'exagère un peu - de son activité.
A savoir, prononcer la phrase : «C'est pour quand ???».
    En clair, imaginer qu'un projet n'est qu'une succession de quatre phases bien distinctes (analyse, conception, codage, test) permet d'y mettre 4 dates bien déterminées et de s'y tenir.
    En France, même si de telles procédures existent, les développeurs de base connaissent la musique : les délais sont plus flous et les process bien moins définis, pour coller à l'image de débrouillardise et d'indiscipline française. Évidemment, cela a considérablement évolué ces dernières années (fin 90), mais bien avant cette période, dès les années 80, on pouvait assister aux États-Unis aux dérives et autres abus d'un tel process rigoureux poussé à l'extrême.
    Ce qui suit décrit un projet imaginaire(?, pas tant que cela!) qui serait managé selon ce principe. Tout le style comique de cette savoureuse description est à porter au crédit de Robert C. Martin.

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design
    Phase d'Implementation
    Phase instructive de délire mental
    Conclusion
    Tout commence le 2 janvier, et votre tête souffre encore de vos dernières orgies. Vous êtes assis dans une salle de conférence avec plusieurs managers et quelques uns de vos collègues. Vous êtes un chef d'équipe (présenté dans ce site comme Chef de Groupe). Votre patron (un Chef de Projet) est là et il a amené avec lui tous ses chefs d'équipe. Son patron (un "directeur de service informatique") a décidé de cette réunion.
    « Nous avons un nouveau projet à développer! », dit le patron de votre patron. Appelons-le BB (pour BigBoss, sans doute!). Ses dents sont si longues qu'elles rayent le parquet (traduction de "The points in his hair are so long that they scrape the ceiling" : les pointes de ses cheveux sont si longues qu'elles balaient le plafond!!!). Les dents de votre patron commencent tout juste à pousser, mais il attend impatiemment le jours où il pourra laisser des marques de dentifrice sur le lino (traduction de "he eagerly waits the day when he can leave Brylcreem(TM) stains on the accoustic titles" : le jour où il pourra laisser des tâches de gel pour cheveux sur les tuiles acoustiques du plafond. Brylcreem est une marque des années 1930 de SanFrancisco Soap Company(TM) puis J.B. Williams(TM), devenue aujourd'hui : ,du même acabit que "Wildroot Creme Oil" et aussi connue à l'époque que Nestlé ou Coca !).
BB décrit l'essentiel du nouveau marché identifié et du produit à développer pour l'exploiter.
(Rq : dans tous projet d'importance, il y a un aspect politique très important entre les différents responsables aux différents niveaux : des primes et promotions sont en jeu et le jeune programmeur de base ignore trop souvent cet aspect important...)
    « Nous devons avoir ce produit sur le marché pour le 4 ème trimestre : le 1er octobre! », exige BB. « Comment cela vous prendre-t-il de temps pour faire l'analyse ? ».
    Vous levez votre main. Votre patron essaie de vous arrêter, mais son crachat vous manque et vous n'êtes pas conscient de ses efforts.
    « Monsieur, nous pouvons pas vous dire combien de temps prendre l'analyse tant que nous n'avons pas un cahier des charges (traduction de "requirements", dans la mesure où le cahier des charges représente l'expression du besoin du client. Ici, le client est la société elle-même, mais elle ne vient que d'esquisser son besoin, d'une manière informelle au cours d'une réunion).
    « Le cahier des charges ne sera pas prêt avant 3 ou 4 semaines », dit BB, ses longues canines tremblantes de frustrations. « Alors, imaginez que vous ayez déjà le cahier des charge devant vous maintenant. Combien de temps avez-vous besoin pour l'analyser ? ».
    Personne ne respire. Tout le monde se regarde pour voir si quelqu'un a une idée.
    « Si l'analyse dépasse le 1er avril, alors on a un problème. Pouvez-vous finir l'analyse d'ici-là ? ».
    Votre patron rassemble son courage et déclare : « On trouvera un moyen, Monsieur! ». Ses canines grandissent de 3 mm; et votre mal de tête augmente de 2 Tylenol.
    « Bien. ». BB sourit. « Maintenant, combien de temps pour la conception ? »
    « Monsieur, » dites vous. Votre patron pâlit visiblement. Il est clairement inquiet quant à ses 3 mm. « Sans une analyse, il n'est pas possible de vous dire combien de temps prendra la conception. »
    L'expression de BB se durcit. « IMAGINEZ que vous ayez déjà l'analyse! », dit-il, tout en vous fixant de ses petits yeux ronds. « Combien de temps cela vous prendra pour la phase de conception ? » [Cf. illustration concrète de Christophe Thiry]
    2 Tylenol ne suffiront pas... Votre patron, dans une tentative désespérée de sauver la récente croissance de ses canines bredouille : « Hé bien, Monsieur, dans la mesure où il ne reste plus que 6 mois pour finir le projet, la conception ne devrait pas dépasser 3 mois. »
    « Je suis heureux que vous approuviez ce choix », affirme BB, rayonnant. Votre patron se détend. Il sait que ses canines sont en sécurité. Il commence à fredonner doucement le jingle du dentifrice (c.à.d, dans la version anglaise, le jingle de Brylcreem! Mais si, souvenez-vous :
Brylcreem, a little dab'll do ya !
Brylcreem, you'll look so debonair !
Brylcreem, the gals'll all pursue ya !
Just to rub a little in your hair ! ou Just hope to get their fingers in your hair !
... mais si, hyper connu, j'vous dis - enfin, si vous êtes américain baby-boomer! - écoutez plutôt! -*** merci à soundamerica et à mediaplanet; en cas de problème, cf. leur FAQ et vérifiez votre CODEC ***- aussi connu que :
Go ahead! douse your hair with water But protect them agains dry scalp each day!
Use Wildroot Creme Oil, Charley It keeps your hair in trim
Get Wildroot Creme Oil Charley It's made with smoothing Lanolin!)
    BB poursuit : « Donc, l'analyse sera prête pour le 1er avril, la conception pour le 1er juillet, et cela vous donne 3 mois pour coder le projet. Cette réunion est un excellent exemple du bon fonctionnement de notre nouvelle politique d'accords et de délégation (heu... pour "consensus and empowerment"). Maintenant, dégagez et commencez à bosser. Je veux les plans-qualité et la répartition des fonctions (heu.. pour TQM plans and QIT assignments) sur mon bureau pour la semaine prochaine. Oh, et n'oubliez pas votre réunion d'équipe multi-projets et les rapports qui seront nécessaires pour les audits-qualité des mois à venir. »
(Voilà un projet qui vient de démarrer et qui est déjà encombré par un monceau de paperasse et autres rapports à rédiger. Exemple typique où la soi-disante "qualité" se pose en ennemi du travail... Depuis, les mentalités ont évolué et les facteurs de réussites et d'échecs sont mieux connus).
    « Oublions le Tylenol », pensez vous alors que vous vous en retournez vers votre "open-space" (ou "cubicle", espace de travail délimité par "murs" de 1.5 mètre de haut, sans porte). « J'ai besoin de bourbon ».
    Visiblement excité, votre patron vient vers vous et dit : « Quelle fantastique réunion! Je pense que l'on va vraiment faire quelque chose de révolutionnaire avec ce projet! ». Vous approuvez d'un hochement de tête, trop dégoutté pour faire quoique ce soit d'autre...
    « Au fait, » continue votre patron, « j'ai failli oublier. » il vous tend un document d'une trentaine de pages. « Vous vous souvenez que le SEI (Software Engineering Institute) vient faire une évaluation la semaine prochaine. Voici le guide d'évaluation. Vous devez le lire entièrement, le mémoriser puis le détruire. Il vous indique comment répondre à n'importe quelle question que le SEI pourrait vous poser, il vous indique également quels endroit du bâtiment vous pouvez leur montrer et ceux que vous devez éviter. Nous devons obtenir le niveau 3 pour juin! »
(Cette... heu... "pratique" est tout à fait courante et actuelle, même si elle est également connue des auditeurs)

    Introduction
    Waterfall
    Phase d'Analyse (ou spécifications : Besoin et Analyse)
    Phase de Design
    Phase d'Implémentation
    Phase instructive de délire mental
    Conclusion
    Vous et vos collègues commencez à travailler sur l'analyse du nouveau projet. C'est difficile dans la mesure où vous ne possédez aucun cahier des charges. Mais, avec les 10 minutes d'introductions données par BB en ce matin fatal, vous avez quelques idées de ce que le logiciel est supposé faire.
    Le cahier des charges arrive le 15 février.
(Ce qui revient à décaler le T0, le départ du projet qui aurait dû se situer au moment de la réception de ce cahier des charges, alors qu'ici, le projet a démarré depuis 1 mois et demi! Il s'agit bien là d'une des causes fréquentes des dérives de projets informatiques)
Puis le 20, le 25 et toutes les semaines suivantes. Chaque nouvelles versions contredit la précédente. Visiblement, les gars du marketing qui l'écrivent, bien qu'ils aient toute la délégation de pouvoir nécessaire, ne trouvent pas d'accord.
(allusion au "empowerment and consensus policy" évoquée précédemment)
[Rq, dans la vraie vie, Christophe Thiry offre un témoignage parmi d'autres d'une situation similaire!]
    En dépit de tout cela, vous et vos collègues poursuivez votre travail d'analyse. Et un miracle se produit!!!
    Le 1er avril, vous avez fini l'analyse!!
    Vous allez trouver votre patron et gémissez : « Comment avez-vous pu dire à BB que nous avions fini l'analyse ??? »
    « Avez-vous regardé un calendrier dernièrement ? c'est la 1er avril! »
    L'ironie de la date ne vous échappe pas. « Mais nous avons encore tant de points à éclaircir et analyser! »
    « Qu'est-ce qui vous prouve que vous n'avez pas fini ? » demande impatiemment votre patron.
    « Quuuooiiii ???? ...»
    Mais il vous coupe par un : « L'analyse ne peut pas continuer indéfiniment, elle doit s'arrêter à un moment donné. Et puisque c'est la date à laquelle elle devait s'arrêter, elle est donc finie. Maintenant, retournez à votre bureau et commencez la conception. »
    Alors que vous vous traîner vers votre bureau, vous commencez à considérer les avantages de garder une bouteille de bourbon dans le tiroir à dossier de votre bureau.

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design (ou conception : Conception)
    Phase d'Implémentation
    Phase instructive de délire mental
    Conclusion
    Ils ont organisé un pot pour célébrer la fin dans les temps de l'analyse. BB a prononcé un interminable discourt sur la délégation. Et votre patron, ses canines plus grandes encore de 3 nouveaux millimètres, a félicité sa troupe pour sa cohésion et son exceptionnel esprit d'équipe. Finalement, le CIO (directeur informatique) monte sur l'estrade et annonce que l'audit du SEI s'est très bien passé et a remercié tout le monde pour avoir bien étudié puis détruit le guide d'évaluation.
    Alors que les semaines s'écoulent, vous et votre équipe commencez la conception du logiciel. Bien sûr, vous découvrez que l'analyse sur laquelle la conception est censée se baser n'est pas sans défauts. Mais lorsque vous annoncez à votre patron que vous avez besoin de renforcer l'analyse sur ses points faibles, il déclare simplement : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! »
    Alors, vous et votre équipe dégrossissez ("hack the design") la conception du mieux que vous le pouvez, sans vraiment savoir si le cahier des charge a été correctement analysé ou non. Bien sûr, cela n'a pas grande importance dans la mesure où de nouvelles versions du cahier des charges continuent de s'amonceler semaine après semaine.
    A mi-chemin en plein dans la phase de conception, le département marketing annonce qu'il a repensé le cœur du système. Leur nouveau cahier des charges est complètement restructuré. Ils ont éliminé quelques domaines fonctionnels majeurs, et les ont remplacés par des fonctionnalités que des études de marchés auprès de clients potentiels ont montrées plus en adéquation avec les attentes de ces-dits clients.
    Vous annoncez à votre patron que ces changements signifient que vous devez re-analyser et re-concevoir la plus grande partie du logiciel. Mais il vous répète : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! » Et vous y retournez...
    Dégrossir, hacher, trancher, couper... vous essayez de créer une sorte de document de conception qui reflète vaguement le nouveau cahier des charges. Toutefois, les évolutions de ce document ont simplement augmenté en fréquence et amplitude.
(Le tableau est un peu sombre concernant ce pôv cahier des charges! En principe, il se stabilise un minimum, ne serait-ce que parce que le chef de projet a noué des relations de confiances avec le client suffisamment solides pour leur faire comprendre l'absurdité de tout changement radical de ce document. Toutefois, dans ce cas, le client étant un autre département de la même société, les relations sont plus délicates et "politisées". Et si ce type de document change trop souvent au début, il faut toujours s'attendre à une refonte radical un jour ou l'autre...)
    Vous tracez votre chemin avec obstination au travers de ce cahier des charges.
    Et le 1er Juillet, un miracle fut!
    Vous avez fini la phase de conception!
    Plutôt que d'aller trouver votre patron pour vous plaindre, vous commencer à stocker dans le tiroir-dossier de votre bureau des bouteilles de vodka.

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design
    Phase d'Implémentation (ou codage : Codage)
    Phase instructive de délire mental
    Conclusion
    Ils ont organisé un pot pour célébrer la fin dans les temps de la conception, et leur promotion au niveau 3 CMM. Cette fois, vous trouvez le discourt de BB si interminable que vous devez allez aux toilettes.
    Il y a des nouvelles bannières et de nouvelles affiches sur les murs de tous les bureaux. Ils montrent des aigles et des alpinistes, et ils parlent d'esprit d'équipe et de délégation. Ils se regardent mieux après quelques scotches. Cela vous rappelle que vous devez faire de la place dans votre bureau pour le brandy.
    Vous et votre équipe commencez à coder. Mais vous découvrez rapidement que la conception est inexistante dans plusieurs domaines importants. vous convoquez une session de conception dans une des salles de conférence afin de résoudre les points les plus critiques. Mais votre patron vous surprend et disperse la réunion par un : « La phase de conception est terminée. La seule activité autorisée est le codage. Maintenant, retournez-y ! »
    Votre patron engage un consultant afin de construire des outils permettant de conter le nombre de lignes de code produites. Il affiche sur le mur un graphique en forme de thermomètre géant, avec le nombre 1 000 000 au sommet. Chaque jour, il allonge la ligne rouge qui indique combien de lignes ont été ajoutées.
(voici ce que l'on appelle un "Metric" pour le moins dépassé! Cela fait un certain temps que l'on a cessé - heureusement - d'associer "qualité" et "nombre de lignes de code", c.a.d."quantité")
    Trois jours après l'apparition du graphique, votre patron vous arrête dans le couloir : « Le graphique ne progresse pas suffisamment vite. Nous devons atteindre un million de lignes pour le 1er octobre. »
    « M... Mais nous n'sommes mêm'pas sûr k... kk... k'le projet a b'soin d'un million d'lignes » prononcez-vous péniblement.
    « Nous devons atteindre un million de lignes pour le 1er octobre. », répète votre patron. Ses canines ont encore grandi et le dentifrice qu'il utilise dessus leur donne un aura d'autorité et de compétence. « Êtes-vous sûr que vos blocs de commentaires sont suffisamment grands ? »
(Truc à la noix bien connu pour augmenter le nombre de lignes de code!)
    Puis, dans un flash de génie du management, il déclare : « Ca y est, je sais! Je veux que vous instituez une nouvelle politique de développement dans votre équipe d'ingénieurs. Aucune ligne de code ne devra excéder 20 caractères. Toute ligne trop longue devra être coupée en deux ou plus - de préférence plus -. Tout le code existant doit être réécrit selon ce nouveau standard. Voilà qui devrait augmenter votre nombre de ligne produit! »
(Pfff... ça, c'est même pas un "truc à la noix", c'est carrément naze...)
    Vous décidez de ne pas lui dire que cela va requérir deux mois/homme non planifiés. Vous décidez de ne rien lui dire du tout. Vous décidez que des injections sous-cutanées d'éthanol pure représentent la seule solution. Vous faites les arrangements nécessaires.
    Dégrossir, hacher, trancher, couper... vous et votre équipe codez comme des fous. Au 1er août, votre patron, regardant d'un air soucieux son graphique, impose une semaine obligatoire de 50 heures.
    Dégrossir, hacher, trancher, couper... au 1er septembre, le thermomètre géant indique 1.2 millions de lignes de code et votre patron vous demande d'écrire un rapport expliquant pourquoi vous avez dépassé le budget de codage de 20%. Il impose les samedi obligatoires.
    Dégrossir, hacher, trancher, couper... Les esprits s'échauffent, les gens démissionnent, le département qualité fait pleuvoir les rapports d'anomalies chez vous, les clients demandent des guides d'installation et d'utilisation, les vendeurs demandent des previews pour des clients particuliers, le cahier des charges continue d'évoluer et le magasin d'alcools n'accepte plus votre carte de crédit. quelque chose doit se passer. Le 15 septembre, BB convoque tout le monde.
    Alors qu'il entre dans la salle, ses canines dégoulinent de sang (pour "his points are emitting clouds of steam" : de ses pointes de cheveux sortent des nuages de vapeurs. Il est colère, quoi!). Lorsqu'il parle, les tons graves de sa voix soigneusement posée vous causent des problèmes gastriques immédiats. « Le directeur qualité m'a informé que ce projet implémente moins de 50% des fonctionnalités requises! Il m'a également informé que le système se plante tout le temps, affiche des résultats erronés et se traîne lamentablement. Il s'est également plain de ne pouvoir suivre le rythme avec toutes ces livraisons quotidiennes que vous lui faites. »
    Il s'arrête quelques secondes, visiblement en train de se calmer : « Le directeur qualité estime qu'à ce taux de développement, nous ne seront pas capable de sortir un produit avant décembre! ». En fait, vous pensez plutôt "mars", mais vous n'en dites rien.
    « Décembre!!! », hurle BB. Les personnes baissent leur tête comme s'il leur pointait un fusil d'assaut vers eux. « Décembre est absolument hors de question. Chefs d'équipe, je veux de nouvelles estimations sur mon bureau pour demain matin. Je déclare dorénavant les semaines de 65 heures obligatoires tant que ce projet n'est pas fini. Et il a intérêt à finir pour le 1er novembre! »
    En quittant la réunion, on peut l'entendre murmurer : « accords... délégations, ... pfff, à ch...! »

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design
    Phase d'Implémentation
    Phase instructive de délire mental qui s'en suivit (ou... ou rien : tout est foutu)
    Conclusion
    Votre patron porte un dentier ("your boss his bald" : il est chauve, donc, en anglais, ses cheveux ne risquent plus de frotter le plafond, et en français, ses canines ne risquent plus de rayer le parquet!). Ses dents sont exposées en trophée sur le mur de BB (qu'est-ce que je vous disais ?). Les lumières fluorescentes qui se réfléchissent sur les dents mal mises de son dentier vous éblouissent un moment (en anglais, la lumière se réfléchissait sur "his pate", son crâne).
    « Avez-vous quelque chose à boire ? » Ayant tout juste fini votre dernière bouteille de Bone's Farm, vous extrayez une bouteille de Thunderbird de votre étagère et en versez dans son reste de café. « qu'est-ce que cela va prendre pour finir le projet ? »
    « On a b'soin de figer l'cahier des charges, de l'analyser, de concevoir et de l'implémenter. », dites-vous d'une voix plus que pâteuse.
    « Pour le 1er novembre ??? », dit votre patron, « Impossible! Retournez juste coder ce p... de logiciel! », hurle-t-il avant de partir tout en remettant en place son dentier (en anglais, "scratching his vacant head", grattant sa tête vide, vide de cheveux et aussi d'autres choses, visiblement!).
    Quelques jours plus tard, vous apprenez que votre patron à été transféré au département de Test (cela évolue, certes, mais l'équipe de test n'est que rarement composé des "jeunes et brillants éléments", mais plutôt des gars en "fin de carrière", ce qui donne à ce département une réputation pas très affriolante. Avec la professionnalisation croissante de la réalisation de logiciel, le test prend toute son importance). Le taux de turn-over a atteint des sommets. Les clients, informés à la dernière minute que leurs commandes ne pourront être honorées, ont commencé à les annuler. Le Marketing réévalue si, oui ou non, ce logiciel doit faire parti des objectifs généraux de la société, etc., etc.. Les mémos volent, les têtes tombent, les politiques changent, et le cours des choses est, en général, bien sombre...
    Finalement, en mars, après bien trop de semaines à 65 heures, une version très instable du logiciel est prête. Sur le terrain, le taux de découverte des bugs est élevé, et les équipes de support technique voient leur volonté poussée à l'extrême pour traiter les plaintes et demandes diverses de clients en colère.
    Personne n'est heureux. (le résultat d'un... cycle en V ?)

    Introduction
    Waterfall
    Phase d'Analyse
    Phase de Design
    Phase d'Implémentation
    Phase instructive de délire mental
    Conclusion (de Robert C. MARTIN)
    Bien que cette histoire soit satirique, elle n'est pas si éloignée que cela de la réalité. Les événement décrits ici n'arrivent peut-être pas tout le temps tous en même temps, mais je les ai vu chacun d'entre eux dans différentes compagnies durant les dernières décennies.
    Le problème lié au Waterfall peut être résumé en une phrase : Waterfall ne produit pas d'éléments fiables à partir desquels on pourrait diriger un projet. L'analyse et la conception ne sont pas le genre d'activité dont on peut mesurer le degré d'achèvement, ce qui fait que vous ne savez jamais réellement quand vous en avez fini avec elles. Et si vous ne savez pas quand vous avez fini une activité donnée, alors le planning devrait vous indiquer ce moment!? Et la plupart des chefs (de projet ou au dessus) en déduisent de cela qu'un projet est avant tout une affaire de planning....(cf. ma remarque sur un chef, en début d'article).
    Le codage, en revanche, peut être testé afin de voir s'il répond aux exigences fonctionnelles. Donc, c'est uniquement après le début du codage que les chefs de projets peuvent avoir un aperçu de la validité de leur planning.
    Comme nous l'avons vu, les documents produits par l'analyse et la conception sont également incorrects. Lorsque l'on arrive au codage, il ne ressemble plus vraiment à la conception, et encore moins à l'analyse. Le plus souvent, l'analyse et la conception remplissent des documents énormes qui occupent de la place et prennent la poussière sur des étagères. C'est rare que quiconque s'y réfère.
Ma conclusion :
- pour des petits projets aux process peu définis, ... soyons clairs, on commence tout de suite à coder (ou presque : on réfléchit deux secondes, tout d'même!). L'avantage est que l'on dispose d'outils de modélisation qui nous permettent de faire évoluer une conception qui restera nécessairement en cohérence avec le code, puisque ce dernier est directement généré de la conception!
Mouais... pas très satisfaisant. L'analyse du besoin du client, elle, reste le plus souvent dans la tête des programmeurs, ou sur une feuille de papier (sur une page... voire une demi-page).
- pour de gros projets, si le département commercial fait un minimum sont boulot, il n'est pas rare d'avoir des spécifications qui, aujourd'hui, vont à l'essentiel. Ce sont alors de véritables documents de travail. Si jamais ils manquent... des cauchemars similaires à ceux du Waterfall ne manqueront pas de se produire.

    Attention : en décembre 2001, un ingénieur de 15 ans de métier me confie : « c'est dingue : c'est exactement ça ! J'ai vraiment vécu tout ce qui est écrit dans cet article!!! Pas forcément tout d'un coup, mais presque. »
Ca fait froid dans dos ;)
    Attention bis ! En août 2002, Colin LORRAIN, jeune développeur, confirme une fois de plus ce scénario de ouf!