Développement logiciel : Doit on continuer à ignorer l’évidence ?
Nous l’avons constaté encore une fois, une fois de trop sans doute. L’un de nos clients s’est mis tout seul (car les responsables d’une telle situation travaillent bien dans la même entreprise que celle où officie notre interlocuteur) dans une situation perdant/perdant avec son intégrateur dans le cadre d’un projet développé au forfait. Quels sont les faits ? Nous pourrions, sans même lui laisser la parole, nommer une à une toutes les difficultés qu’il rencontre, les yeux fermés, à la manière d’un chapelet qu’on égrène.
Un Appel d’Offre a été émis à destination des principaux intégrateurs de la place car selon la Direction des Achats c’est la seule manière de mener un projet informatique (Nous vous en parlions dans un précédent billet : « Eloge de la qualité« ). C’est, selon les mêmes spécialistes reconnus pour leurs compétences informatiques, un moyen de maîtriser les coûts et les délais, de partager le risque avec l’entreprise choisie et d’avoir un moyen de pression (car bien entendu de superbes clauses de pénalités de retard ont été prévues au contrat). L’intégrateur X est choisi. Pour une grande part, parce qu’il avait une proposition alléchante et savait accepter, sans piper mot, tous les principes de ce « contrat de confiance ». Le décor est planté : une atmosphère de sérénité, une confiance réciproque, l’implication des meilleurs profils de la société X, des desiderata d’utilisateurs pris en compte …
Vous vous en doutez, cette dernière phase est ironique.
Le chef de projet est sous tension, son entreprise lui a affecté 3 stagiaires et demi, un quart d’Architecte car, après d’âpres négociations, l’affaire gagnée se révèle moins rentable que prévu. Et en interne dans la Société X, un projet mal négocié aboutit à l’affectation de développeurs inexpérimentés ( »You pay peanuts, you get monkeys », c’est bien connu). Les acheteurs du client se frottent les mains, ils ont bien mené leur barque. Le chef de projet est contraint de faire travailler tout le monde plus que de raison pour tenir des délais déraisonnables. Le mot « pénalité » se murmure discrètement puis fuse au grand jour dans toutes les réunions de projet, brandi comme la menace suprême. Les services juridiques des deux parties ressortent le contrat et s’y penchent avec beaucoup d’intérêt. Tout le monde passe d’ailleurs plus de temps à voir comment prendre l’autre partie à défaut que de véritablement essayer de résoudre les problèmes ensemble, en toute bonne foi. Et les utilisateurs dans tout ça ? Ils s’inquiètent. L’application qu’ils ont commandée est critique pour l’exercice de leur métier. La MOE leur explique qu’ils ont mal travaillé, que leurs spécifications sont trop floues, que leurs incessantes demandes de modifications sont inacceptables. Ils seraient même pointés du doigt comme deuxième responsable d’un tel chaos, après l’intégrateur, bien entendu.
Ce projet devient vite un puit sans fond. Le client est allé trop loin pour faire machine arrière. On ouvre la boîte de Pandore : les « avenants », le mot est enfin lâché à la grande satisfaction de tous car, in fine, c’est la seule manière de s’en sortir la tête haute des deux cotés. Mais attention, l’usage de tels coups de canif au contrat liant les deux parties doit se faire avec beaucoup de parcimonie bien entendu, car il doit juste permettre à l’intégrateur de réduire « un peu » son déficit sur le projet, là où vraiment on ne peut pas le prendre à défaut. Ce subterfuge lui permet, tout juste, de se maintenir dans un état financier végétatif sur le projet (pertes réduites ou au mieux rentabilité nulle).
Le paradigme du développement logiciel au forfait repose sur des principes (pour ne pas dire des valeurs) falsifiés, malhonnêtes, utopiques, désuets.
Les entreprises qui réussissent comme Google, Amazon et Microsoft, pour ne citer que les plus connues, l’ont compris depuis longtemps. Les méthodes agiles sont une alternative sérieuse. Les principes de ces méthodes sont les suivants :
- Compétence et motivation des équipes
Le personnel mis à la disposition des projets est du niveau de séniorité nécessaire au développement d’applications modulaires, évolutives, performantes, documentées, intégrables et exploitables. Ce personnel s’engage sur le chiffrage et la réalisation de l’application. - Développement itératif
Le développement des projets est itératif. L’effet tunnel est supprimé. Les modules livrés sont immédiatement opérationnels. - Un accueil favorable du changement
La rédaction de spécifications détaillées complètes des mois avant sa livraison se révèle être une utopie. Dans ce contexte, l’acceptation du changement de priorités, de fonctionnalités fait partie intégrante du processus de développement agile de Xebia. - Une collaboration étroite avec les utilisateurs
L’implication forte du management et des utilisateurs tout au long du projet est organisée autour de feedbacks permanents orchestrés par des démonstrations systématiques qui permettent, à chaque itération, de valider le travail effectué et de définir les priorités de l’étape suivante. - Une attention permanente à l’excellence technique
L’hyperspécialisation Java/J2EE permet, dès le début du projet, de mettre en place les meilleures pratiques en vigueur dans l’industrie et cela à tous les niveaux du projet : Architecture conçue par des Architectes expérimentés, politique d’intégration continue, tests de performance, gestion des erreurs, exploitabilité des applications, choix technologiques pérennes, …
Doit on ignorer que cette article est une publicité pour Xebia.
C’est dommage l’article commence par une belle description de tout projet informatique au forfait. Mais par contre nous vendre les méthodes agiles comme la panacée… Ca me rappel quand on vendait les projets avec le processus en Y. C’est clair que la méthode peut éviter de tomber dans des énormes ornières mais je suis sur que cela ne règlera pas tous les problèmes d’incompréhension entre MOE, MOA, et commerciaux.
Bon courage pour votre entreprise, Bonjour à Guillaume.
Je vous remercie pour ce commentaire.
L’objectif initial n’était pas publicitaire mais plutôt de constater encore une fois une situation ubuesque.
Les méthodes agiles ne sont certes pas la panacée mais une partie de la réponse.
De très grandes et très performantes entreprises en ont fait une religion.
Merci de lire notre blog.
Cordialement
Luc Legardeur
Ce constat n’est hélas pas un cas d’espèce. J’ai déjà eu (comme vous) l’occasion de constater la synergie de ces symptomes à de multiples reprises. Cela m’inspire plusieurs reflexions:
1) Ne devrait-on pas commencer à évangéliser les achets, avec leur propre vocabulaire ?
2) Cela ne répond pas à la question du projet au forfait: est-ce quand même possible sans tomber dans ces pièges ? Quel est le mode contractuel évitant ces ecueils ? Existe-t-il une catégorie de projet plus particulièrement destinée aux forfait ? Est-ce possible dans des contextes novateurs, voir exploratoires ?
Bonjour,
Il est effectivement stupéfiant de constater de manière récurente des situations de ce type dans le cadre de grands projets au forfait. De mon exéprience, le bon sens et l’honneteté sont souvent les éléments qui font défaut en plus d’une méthodologie inapropriée. En effet, le métier du projet au forfait est particulier et peu d’entreprises notamment parmis les grandes SSII savent correctement l’appréhender. Loin de moi l’idée de dire qu’elles ne savent pas gérer ce type de projet, mais je dirais plutot que la méthodologie et l’approche « non agile » conduise souvent au genre de situation décrite plus haut.
Pour ce qui est de l’approche agile, pour moi elle présente plusieurs intérets : elle met en avant l’importance d’avoir une équipe de développeurs COMPETENTS et MOTIVES, elle met l’accent sur la communication Client / Fournisseur mais également Client / Client – Fournisseur / Fournisseur. L’intégration du changement comme ingrédient « vital » d’un projet impose également une organisation adaptée, ouverte et en cible sur un objectif commun. (Il est a noter que les développeurs dans ce cadre dispose d’une bien meilleure vision « fonctionnelle » ce qui facilite les échanges et dope d’implication !)
Je dirais pour termier qu’une des difficultés de cette approche est de réussir à mener le projet afin de le faire converger dans les délais et dans les budgets définis. Le chef de projet, averti et « agile » est indispensable !
Voilà
Matthias
Bonjour,
Je ne crois pas que le problème vienne d’un problème de méthode au sens informatique du terme mais plus à un problème d’organisation et d’analyse de la valeur, la vente et/ou l’achat de projet en mode forfait est une activité commerciale qui possede ces propres règles.
Je n’ai rien contre les approches « agiles », elles permettent une meilleure communication au sein des équipes de développement et entre les équipes de développement et le client. Elles s’appliquent surement bien à un certain nombre de contextes où le client est bien identifié et a une bonne idée des fonctionnalités de l’application (application de complexité faible et moyenne), cependant quand les spécifications évoluent au delà du raisonable (les spécifications évoluent toujours mais il ya toujours une limite à l’élasticité) quand le client n’est pas un mais plusieurs avec parfois des besoins contradictoires, les problèmes financiers apparaissent, il n’y a pas une réévaluation du budget du projet à chaque itération.
Posons les faits: l’intégrateur s’engage à réaliser un projet pour un forfait donné.
Dès lors que l’intégrateur devient l’interlocuteur unique du client (contrat signé), c’est à lui de convaincre et d’assouplir la position du client (Achats et MOE), voir même de faire l’interface entre les Achats et la MOE(en utilisant par exemple les arguments listés plus haut).
Le client perçoit que le risque de dépassement de coût est sur l’intégrateur et non pas sur lui. Il faut lui montrer que le risque (et le coût) de son côté n’est pas nul: Coûts pour le métier si retards de livraison…
Tout en justifiant le chiffrage initial, l’intégrateur doit pouvoir fournir un ROI (aux Achats et à la MOE) sur l’intéret d’une démarche itérative, (avec paiement à chaque itération?) en remplacement du coût « final » fixe.
– Le ROI ne doit pas changer le chiffrage initial, mais identifié des risques, et simplement assouplir l’attitude du client: en clair, passer du « perdant/perdant » au « gagnant/gagnant ».
– Si présenté avec diplomatie, l’intégrateur gagnera la confiance du client (Achats et MOE), sinon… hum… ce sera le mur pour tout le monde!
– D’où l’importance d’un chef de projet côté « intégrateur » bon en relationel!
Globalement, le problème n’est pas forcément le fonctionnement au forfait, mais le fait que le marché « SSII » est très concurrentiel, et les marges faibles.
Plusieurs options s’offrent à une SSII
1. se regrouper avec une autre SSII pour augmenter le volume d’affaires
2. se spécialiser dans des niches du marché (créer des pôles de compétence)
3. diminuer les coûts ( »monkeys paid peanuts » ou off-shore)
4. augmenter sa valeur ajoutée globale (multi-compétences comme CapG ou Accenture) et donc sa marge ?
Les SSII favorisent souvent la solution 3, qui est, à mon sens, à la fois, la plus facile et la source des problèmes de qualité, qui vont conforter le client dans l’attitude « je me protège de l’Intégrateur », plutôt que celle « collaboration gagnante/gagnante ».
A contrario, l’excellence, si elle est constatée par le client, a de grandes chances de se traduire, d’une façon ou d’une autre, par un retour financier pour l’Intégrateur.
De fait, c’est effectivement la situation que j’ai trouvée dans les sociétés de services après avoir travaillé (longtemps) dans les labos éditeur, une situation ou les mots les plus récurrents sont « productivité », « tjm », « coût », des concepts liés à la direction des achats et non « qualité », « wow effect », « utilisabilité », « performance », ou d’autres concepts provenant du monde de l’ingénierie. Ce sont deux logiques antinomiques, avec des mécanismes différents.
Lorsque vous décrivez Google ou MS, ne vous attendez pas à voir cette notion de productivité ignorée, mais ce qui compte, c’est l’innovation, la savoir faire, la compétition sur des produits, avec toutes les théories de management que vous aimeriez j’en suis sûr avec sa literature sur le sujet ou sur les produits (à la Christiansen’s the innovator’s dilemma) . Les SSII fournissent des services, avec rarement une innovation véritable. Je ne vois pas de solution à votre postulat. Pour gagner des affaires, les SSII continueront de montrer des beaux slides décrivant la « production » de soft comme si on fabriquait des crayons et non comme un travail intellectuel ayant de la créativité, de l’élégance, et du talent, à baisser les TJM ou les charges, etc …
Merci pour le billet.
[...] un article intitulé “Développement logiciel : Doit on continuer à ignorer l’évidence ?“. Voici les principaux faits avec lequels je suis tout à fait d’accord: [...]
Chez nous (SSII leader sur fr), on fait mieux, on met des débutants et des démissionnaires pour démarrer les projets ! en effet il y a si peu de ressources sur la marché que les préavis ne sont plus écourtés, je vous laisse imaginer ce qu’il se passe lorsqu’un CP démissionaire se barre juste après la validation des spécs…;-)
Mais comme le précise l’article personne n’est blanc ou noir, certains clients vous font des propositions honnêtes (soit on applique les pénalités, soit vous nous faîtes en plus cette liste d’évols gratuites…;-) Voilà un bon procédé de gagnant-perdant…
Libouban dit « Les SSII fournissent des services, avec rarement une innovation véritable. Je ne vois pas de solution à votre postulat. Pour gagner des affaires, les SSII continueront de montrer des beaux slides décrivant la “production” de soft comme si on fabriquait des crayons et non comme un travail intellectuel ayant de la créativité, de l’élégance, et du talent, à baisser les TJM ou les charges, etc »
Je suis à la fois d’accord et pas d’accord. Oui, ce que vous écrivez est bien la réalité d’aujourd’hui. Mais le métier d’une SSII est bien le développement logiciel, même s’il s’agit de développement à la demande du client, avec un e problématique différente des innovateurs tels que Google ou Microsoft.
En ce sens, en tant que professionnels d’un métier qui a plusieurs dizaines d’années d’existence, ces sociétés devraient être capables de savoir ce qui fait réellement l’efficacité et la qualité d’un développement. Beaucoup d’entre elles n’ont jamais réellement cherché à le savoir et sont donc difficilement en mesure de l’expliquer et de vendre la valeur associée. D’où une recherche exclusivement focalisée sur les coûts et les attentes inadaptées mises sur un Off-shore souvent peu organisé et dont les résultats sont fréquemment catastrophiques.
Je pense que ce syndrome est encore plus manifeste en France, où la reconnaissance des métiers techniques est faible, particulièrement en SSII. Mon avis est que le métier maturant globalement (l’industrialisation des métiers de développement logiciel commence à peine), de nouvelles sociétés vont émerger avec des modèles adaptés et certaines plus anciennes, bien qu’importantes, vont connaître des crises majeures.
Cette évolution ne se fera pas sur 3 ans, mais au moins sur une décennie, la première pression venant à mon avis des sociétés OffShore dont beaucoup commencent déjà à comprendre le besoin d’industrialiser les processus, mieux que nos sociétés locales n’ont pu le faire lorsqu’elles auraient dû au cours des vingt années précédentes…
Et tant mieux si ça fait le ménage…
Daniel
La France a beaucoup de retard sur les pratiques Off-shore et celles-ci vont se développer fortement dans les prochaines années, entrainant une logique de coûts et non un logique de reconnaissance de la créativité. Il est naif de penser que l’excellence « technique » va conduire à un retour financier, les métiers du logiciel sont soumis à une logique d’achat et à une classification qui fait table rase du côté spécifique de chaque développeur et c’est dommage. Enfin beaucoup de sociétés OffShore sont certifiées CMMI niveau 3 ou 4 mais il faut voir les conditions de certification qui sont appliquées localement et qui sont assez éloignés de ce que l’on demande en Europe.
Bonsoir Michel, bonsoir à tous,
Tout d’abord merci de vos commentaires.
Une participation à vos échanges, qui je l’espère, aura au moins le mérite de vous faire sourire.
Je ne crois pas à l’Offshore qui est un modèle qui, heureusement pour nous, ne fonctionne pas en France (les gains constaté oscillent entre 20% et 25%, pas de quoi jouer son siège de DSI ou de super Acheteur). Le Nearshore semble prendre le dessus sur l’Offshore pour des raisons 1/culturelles 2/économiques 3/géographiques. Lorsque l’on se sera à nouveau fourvoyé sur ce modèle, on plébicitera le Ruralshore (la logique SSII: développeur à la cambrousse = développeur moins cher). On inventera plein de modèles XXXshore. Le CloseShore (le développeur reste finalement dans les locaux de la SSII, ce qui n’a rien d’innovant mais un nouveau concept et nouvel anglicisme sera né, puis on parlera alors de Homehore (Le développeur reste chez lui donc il ne se déplace pas donc il coûte pas cher en transports, frais de locaux, bref le télétravail).
Quand à la certification CMMI 3 ou 4, cela me fait doucement rire…
A quel titre CMMI se targuerait d’être la Graal de la qualité ?
Je suis un fervent croyant du bon sens que l’histoire (future) nous aidera (nous forcera) à regarder en face.
[...] Luc is the CEO of Xebia France. This is an english translation of one of Luc’s posts on the French Xebia [...]
Le 11 septembre 2007 à 22:36 (), Luc Legardeur a dit :
« On inventera plein de modèles XXXshore. [...] un nouveau concept et nouvel anglicisme sera né »
Bah du côté des méthodes post-modernes nous sommes également gâtés en terminologie : Agile, XP, SCRUM, X-Driven Development à gogo… les différentes tendances qui s’inspirent les unes des autres pour donner naissance à une nouvelle… tendance. On sent bien l’ironie du shore mais celle-ci peut très facilement être retournée.
En quoi cette méthode va nous aider *dans* la pratique quand on fait face à un maître d’ouvrage qui se mêle d’un MCD et qui, après avoir bidouillé Access pour sortir des stats de consultation, conseille de dénormaliser à outrance et de remplacer 30 tables par 1 seule pour simplifier apparemment les requêtes et atteindre des niveaux de performance jamais égalés (wow!), comment cette méthode va nous aider *dans* la pratique quand on fait face à un groupe d’utilisateurs qui change la couleur d’un bouton du bleu au vert, du vert au jaune puis du jaune au bleu, sans parler de la position du bouton, comment cette méthode va nous aider *dans* la pratique quand on fait face à une architecture 3-tier imposée par le client, si ce n’est pas, soyons fou, le langage-à-la-mode-du-moment-du-genre-Ruby car le DSI a lu que c’était /full-object/ avec la souplesse du procédural et les avantages du scripting car facilement inter-opérable avec les autres langages (bien entendu le DSI a pris sa décision pendant la phase de conception du premier livrable), comment cette méthode va nous aider *dans* la pratique quand on fait face à une réglementation bancaire qui vous impose d’implémenter un calcul autrement (3 jours avant la livraison en production) ?
Comment les Agilistes (j’aime le mot) réagissent-ils face à de tels changements (qui sont le lot quotidien des projets informatiques faut-il encore le rappeler) sans augmenter la facture, puisque c’est un des arguments anti-forfaits qui est souvent avancé par les tenants des méthodes post-modernes ?
M. Moderne (sic),
Les situations que vous décrivez relèvent à mon sens de deux cas de figure tout à fait distincts : d’un côté la confusion des rôles – interventionnisme technique d’acteurs non techniciens -, de l’autre la gestion du changement (nouvelles exigences, nouvelles règles, etc.).
La première catégorie relève classiquement de l’absence de méthode, quelle qu’elle soit. Rappelons q’une méthode décrit des rôles, des activités et des productions, et la façon dont ces rôles, ces activités et ces productions s’articulent pour réaliser une tâche particulière, en l’occurrence le développement d’un logiciel. Une méthode est donc une règle du jeu, qui ne peut s’appliquer que si tous les acteurs la comprennent et l’acceptent. Ceci est vrai aussi bien pour les méthodes traditionnelles « en cascade » que pour les méthodes dites agiles – je préfère pour ma part parler de développement itératif et incrémental. L’absence de méthode reste la réalité d’un grand nombre de projets, et l’adoption d’une méthode formelle telle que Scrum peut aider à clarifier les rôles et responsabilités de chacun, et corriger effectivement les dysfonctionnements liés à l’interventionnisme (et je répète : l’acceptation des règles du jeu par TOUS est une condition sine qua non de la mise en place d’une méthode).
La seconde catégorie de situations est différente, puisqu’elle aborde la gestion d’exigences mouvantes : c’est précisément dans ce domaine que les approches agiles prennent tout leur sens, puisque l’un de leurs piliers est que les spécifications ne sont jamais figées ; il y a toujours de la place pour des évolutions ou de nouvelles demandes.
Pour reprendre vos exemples : les utilisateurs sont étroitement associés aux phases de développement, et en particulier des écrans. La couleur et le positionnement des boutons sont donc en principe discutés au moment même de leur création. A supposer que ce mécanisme échoue, une démonstration du logiciel est faite au terme de chaque itération, et la demande de modification de l’ergonomie pourra alors être ajoutée au « product backlog » – elle sera ensuite priorisée selon sa valeur et sa complexité et développée dans une itération ultérieure. Quand à l’évolution réglementaire à quelques heures de la mise en production, il s’agit d’une situation extrème (et peu crédible : j’aimerais savoir quel type de réglementation est susceptible de surprendre à ce point un organisme bancaire) qui ne saurait se traduire par une solution universelle : report de la mise production, mise en production d’une version dégradée, maintien de la version et planification des évolutions, etc. Quoi qu’il en soit, cela reste une évolution, un simple élément dans le product backlog (avec une forte priorité).
Enfin, je vous cite « Comment les Agilistes (…) réagissent-ils face à de tels changements (…) sans augmenter la facture (…)? ». Je crains que cette simple question révèle que vous n’avez pas compris les principes du développement itératif et incrémental : il n’est à aucun moment question de réaliser les développements à coût fixe (ou alors sans engagement sur le périmètre fonctionnel) ; il est question de maitrise des coûts, ce qui est très différent. Je ne peux que vous inviter à mieux vous documenter sur les paradigmes de l’agilité. Le mieux est de commencer par les fondamentaux : http://www.agilemanifesto.org...
Merci Guillaume.
Ce manifeste je l’ai lu il y a quelques années par curiosité. J’ai même lu un livre de référence XP qui date de 2001, wow !, et je lis régulièrement les contributions de « Uncle Bob » [URL_1] que vous devez connaître dans comp.object [URL_0] (je m’attarde parfois il faut dire sur les contributions de TopMind [URL_2]… ouh ! c’est péché) Je ne suis pas encore père mais j’ai quand même des idées sur l’éducation, vous comprendrez par là qu’on peut se permettre d’argumenter sur un /domaine/ qu’on n’a jamais *pratiqué*.
J’apporte quelques précisions sur deux de mes exemples de changements formulés interrogativement (et de manière un peu caricaturale) et vos réactions à leur sujet :
1. « quel type de réglementation est susceptible de surprendre à ce point un organisme bancaire » : Bâle II, ça semble figé mais ça ne l’est pas car il existe nombre de modèles, ce n’est pas tout à fait la réglementation qui évolue, je vous l’accorde, mais des recommandations qui influencent le choix d’une modélisation et en conséquence la conception du moteur de calcul et son implémentation. Pour les « 3 jours avant la mise en production » c’est un peu extravagant de ma part, mais, même si c’est 3 mois avant c’est un changement considérable.
2. « la confusion des rôles – interventionnisme technique d’acteurs non techniciens » : vous reprenez mon exemple d’un maître d’ouvrage qui donne des recommandations sur la modélisation d’une base de données. Oui il y a bien une confusion des rôles (c’est un vaste débat), cependant *dans* la pratique il s’agit bien d’un changement car au final la structure de la base de données est modifiée.
Face à de tels changements vous proposez : « report de la mise production, mise en production d’une version dégradée, maintien de la version et planification des évolutions, etc. Quoi qu’il en soit, cela reste une évolution, un simple élément dans le product backlog (avec une forte priorité). » Cette attitude est-elle Agile ? Je ne crois pas (sauf le terme « backlog »), c’est la réaction de tout un chacun, même chez CMMi, même chez ceux qui n’ont pas de méthode particulière. Qu’est-ce qui fait que le client accepte mieux la mauvaise nouvelle d’un report, car le client est toujours étonné d’apprendre qu’un changement demande du temps et de l’argent, de la part d’un Agiliste que de la part d’un chef de projet lambda, pourquoi ça se passerait mieux ?
Anticiper le changement, mieux l’appréhender, grâce à la proximité du client et surtout des utilisateurs ? Mon point de vue est mieux formulé par Joel Spolsky [URL_3] dans « The Iceberg Secret, Revealed » : « Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. [...] The Extreme Programming folks say that the solution to this is to get the customer in the room and involve them in the design process every step of the way, as a member of the development team. This is, I think, a bit too « extreme. » It’s as if my architect made me show up while they were designing the kitchen and asked me to provide input on every little detail. It’s boring for me, if I wanted to be an architect I would have become an architect. [...] And you’re just going to spend all your design time explaining things in words of one syllable. » Je suis prêt à être convaincu du contraire.
Je n’arrive tout simplement pas à voir en quoi il y a du nouveau, de la solution à des problèmes récurrents, dans les méthodes Agiles (+XP), je ne vois pas cela comme une méthode en fait. Mais plutôt comme une enveloppe marketing (et je ne suis pas le seul) renfermant de bonnes pratiques pas nouvelles du tout (tests unitaires), timbrée de bon sens (communication), cachetée de non-sens (le code est la documentation). Illustration avec une discussion que j’ai eue avec un programmeur-tendance à l’écoute des évangélistes Agiles et autres /Ruby-gurus-ex-Java-gurus/ (genre Bruce Tate) sur les tests unitaires. Je lui expliquais alors comment je m’y prenais, en rédigeant, pour une méthode donnée, /n/ cas de tests une fois le contrat rédigé et avant l’implémentation. Sa réaction fut de m’étiqueté d’Agile, d’adepte du Test-Driven Development ; bah non désolé, rien de tout cela, je rédige et implémente simplement des test unitaires. L’habit ne fait pas le moine, je le précise car je lis de plus en plus souvent les raccourcis « Agile=tests unitaires » et « tests unitaires=Agile » !
Pour ce qui est des coûts : « il n’est à aucun moment question de réaliser les développements à coût fixe ». Je ne parle pas de coût fixe, je mets l’accent sur une constante chez les fournisseurs de services informatiques qui n’échappe pas aux Agilistes, la constante /MEILLEUR_RAPPORT_QUALITE_PRIX_QUE_LES_AUTRES/. Illustration ici : http://blog.xebia.fr/2006/12/04/eloge-de-la-qualite/ , je cite « Nos clients sont heureux. Leurs applications sont maintenables, évolutives, documentées. Et leur coût de la qualité – moins cher que les forfaits mais les paramètres à prendre en compte sont nombreux. » Avec tout le reste de l’argumentation du billet on peut interpréter que le coût des changements est moindre avec les méthodes Agiles ; poudre au yeux !
J’ai déjà des éléments de réponse à mes questions mais je suis impatient de vous lire ou d’autres…
M. Moderne
[URL_0] http://groups.google.com/group/comp.object/topics?gvc=2
[URL_1] http://www.objectmentor.com/
Attention lecteur, dans ces pages nous sommes bien loin de la religion, de l’évangélisation et autres manifestes post-modernes rédigés par des gurus :
[URL_2] http://oop.ismad.com/
[URL_3] http://www.joelonsoftware.com/articles/fog0000000356.html
Je suis la recherche d’une société pour faire développer un logiciel. Si vous êtes interessé, merci de me le faire savoir par mail, je vous enverrai les documents nécessaires votre prise de décision