La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail….
Chronique à paraître dans 01 Informatique
La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail. Il en existe deux grands types : la cascade (ou cycle en V) et la construction incrémentale pilotée par les tests. Dans une cascade, l’accent est mis sur le produit, que l’on considère comme descriptible dans un cahier des charges, puis des spécifications détaillées. Il est ensuite codé et enfin testé. Dans une approche incrémentale, l’accent est mis sur le process : il n’est pas nécessaire de décrire exhaustivement le produit mais plutôt ses grandes lignes, puis on développe cas d’usage par cas d’usage, en montant progressivement en complexité. Chaque cas d’usage est associé à des tests de recette qui seront automatisés, donc rejoués à coût marginal.
La cascade représente 99% du portefeuille projet des grandes entreprises, l’incrémental 99% des projets Open Source et des sites Web grand public les plus connus (Amazon, Telemarket ..). L’observation des faits devrait aiguiller votre choix : la cascade échoue dans ses grandes lignes[1], l’incrémental piloté par les tests permet la maîtrise de logiciels aussi complexes que ceux des grands éditeurs[2]. Cette observation semble manichéenne, mais elle ne fait que corroborer la théorie du Defect Cost Increase énoncée par Barry Boehm dans les années 80 : Le coût de correction d’un défaut croît exponentiellement à chaque phase du cycle de développement dans laquelle il est détecté. Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides.
Alors comment expliquer que malgré ces faits, votre choix se portera très vraisemblablement sur la cascade ? J’y vois trois facteurs : un mythe fondateur, l’insouciance d’une jeune industrie dispendieuse, et un système de valeur hérité du Fordisme.
Commençons par le mythe fondateur du cahier des charges : pour réussir un projet de développement, il suffit de rassembler les besoins dans un document complet et exhaustif, puis d’écrire un logiciel qui soit conforme à cette spécification. Le philosophe Wittgenstein nous avait pourtant mis en garde dans les années 50 contre cette fausse assertion héritée du positivisme. Tout exercice du langage qui n’est pas étayé par des cas concrets finit en abîme de sens. Il n’y a pas de » beauté « , il n’y a que l’expérience que chacun s’est forgé de la beauté. Ainsi Wittgenstein démontre à quel point seul des tests dans des cas concrets peuvent cerner un sens exprimé : » c’est beau quand c’est jaune « , » c’est beau si c’est rond » …
L’insouciance : à l’image de l’industrie automobile qui a mis plusieurs décennies avant de réaliser qu’elle polluait et tuait quand même beaucoup, l’industrie informatique a encore beaucoup de mal – tant ses apports ont été spectaculaires – à réaliser l’impact de la non-qualité. Les chefs de projet sont jugés sur les coûts et les délais. Point. La griserie procurée par la vitesse occulte ainsi souvent les problèmes de freinage et d’airbag que rencontreront les utilisateurs ou les équipes de maintenance et d’exploitation…
Enfin, la grande entreprise place la spécialisation et la fongibilité des ressources au centre de son système de valeur. Tout processus tend à être découpé en phases et en tâches, auxquelles sont rattachées des équipes spécialisées. Cette vision s’applique à merveille dans certaines chaînes de valeur industrielle, mais très mal dans un processus de construction logiciel, par essence risqué donc requérant des cycles courts, sans circulations hiérarchiques. Construire du logiciel, sera donc avant tout construire une équipe intégrée, ce qui reste compatible avec l’informatique d’entreprise, massive et interconnectée.
Fort de ce constat, nous pouvons proposer 4 conseils au dirigeant soucieux d’améliorer l’efficacité de son entreprise, en permettant aux chefs de projet de faire un autre choix que la cascade :
- demander à ce que tout cahier des charges ne dépasse pas 5 pages et soit assorti de tests dans des cas concrets,
- mettre en place et suivre les mesures de qualité du développement (couverture de tests, homogénéité, taux de duplication), au même niveau que les mesures de coûts et de délais,
- au-delà de trois mois de travaux, reconsidérer l’idée de forfait, ce mode de travail désastreux qui repose sur une bien hypothétique maîtrise de la complexité; et préférer des contrats d’engagement de moyens contrôlant fréquemment la performance (vélocité & qualité) d’équipes intégrées,
- diffuser ces pratiques, en les améliorant encore et encore, pour obtenir des chaînes de réalisation où le temps entre une demande cadrée et sa mise en production sans régression ne cesse de diminuer … plutôt qu’augmenter comme c’est trop souvent le cas aujourd’hui.
[1] Standish Group : le taux de projets en échec ou mitigés, est passé de 84% à 71% en 10 ans …
[2] Un peu d’auto-promotion : Octopus MicroFinance Suite, plus de 100 000 lignes de code, plus de 20 000 tests automatisés (soit plus que la complexité moyenne des logiciels de gestion en entreprise), 300 demandes tracées et toujours pas de cahier des charges.
9 commentaires sur “Pourquoi les méthodes agiles peinent-elles à pénétrer l’entreprise ?”
Parce qu'aujourd'hui, bousculer les méthodes de travail représente un risque individuel pour celui ou ceux qui seront à l'origine de cette initiative.
Si la mise en oeuvre d'un projet informatique représente un investissement financier conséquent pour le donneur d'ordre, elle représente, pour le maitre d'oeuvre, un risque sur son déroulement de carrière. Alors comment, en cas d'échec, justifier d'avoir travaillé selon une méthode utilisée par seulement 1% des grandes entreprises. Mieux vaut encore utiliser une méthode qui permettra d'aboutir, même laborieusement, à un produit conforme à une 'expression de besoins'. Mettre en oeuvre une méthode agile, c'est entrer en dissidence avec l'ordre établi. Ce qui conduit forcement à l'échec dans les structures hyper hiérarchisées de nos grandes entreprises.
Pour le moment, ce type de méthode ne peut séduire que de petites ou moyennes structures dirigées par des individus impliqués dans l'opérationnel, n'ayant pas forcement une forte culture informatique mais dont les objectifs dépassent la simple délivrance d'un outil.
Avoir la possibilité de s'abriter derrière une méthode éprouvée en cas d'échec est une idée à chasser de nos entreprises françaises.
Notre culture considère Généralisme et Pragmatisme comme l'absence de Méthode et d'Expertise. Cette mauvaise hiérarchie de valeurs constitue certes un bon moteur à promotions sociales pour les Experts IT$ mais contribue à amonceler les Projets en déroutes : il y a très souvent une relation directe entre réussite de l'individu qui a conduit le Projet (Promotion Peter's) et résultat catastrophique pour l'utilisateur.
DG et DSI doivent avoir pour objectif, certes de limiter l'exotisme méthodologique (objectif atteint) mais aussi et surtout de savoir créer le terrain de l'innovation réelle.
Contrairement a des idées reçues, passé les strates des DG, la culture prédominante est bien celle du Moyen et non celle du Résultat : 'Quelle méthode allez vous utiliser ? ; 'Quel référentiel nous amènera à bon port ?' ; 'Que dit la Qualité ? ? ;-)
Cette culture du Moyen sclérose donc les grands projets et la valeur Courage a quitté les grandes entreprises et ses managers. Il est d'ailleurs symptomatique de voir a quel point les méthodologies dites éprouvées introduisent un niveau élevé de complexité. Cette complexité permettra a chacun d'oublier les mots PRAGMATISME et EFFICACITE et déouvrir le parapluie ITIL/CMMI/RUP/? quand la pluie (l'utilisateur) viendra.
Que dois-je faire ?
? Faire preuve de Courage : Le courage n'est ni l'ennemi de la raison, ni synonyme de dissidence
? Multiplier les acteurs transverses afin de gommer les dégâts que provoquent les hiérarchies en mode Projet
? Manager les unités de facon à ne pas faire disparaitre la valeur Courage
? Inverser les ratios entre armée de Spécialistes et bons généralistes
L'espoir réside donc sur la capacité des Managers à recruter et positionner de bons généralistes pragmatiques et courageux. Il est à noter que ces profils ne sont pas de futurs spécialistes, mais bel et bien des anciens (et généralement des très bon).
Les amateurs de Jazz feront facilement le parallèle du sujet avec la musique éprouvée (Le classique) et la musique Agile (Le Jazz).
Eric K.
[email protected]
'...Il est à noter que ces profils ne sont pas de futurs spécialistes, mais bel et bien des anciens (et généralement des très bon)...'
Je dirais même plus, ils ont aussi une bonne expérience de la gestion d'équipes, de projets et de la relation avec les donneurs d'ordres. Ils ont cessé de se développer en profondeur (ce qui est la caractéristique des experts) pour se développer en largeur afin d'étendre leur spectre d'intervention.
? ?Faire preuve de Courage? ?
Je n'aime pas cette notion, elle mène directement au sacrifice. Je préfère dire qu'il faut faire preuve de détermination, de ténacité pour atteindre les objectifs assignés dans des environnements mouvants.
Merci de vos réactions. Nous sommes à la recherche de leviers de changement actionnables. Eric, peux-tu nous précser ce que tu entends par 'acteurs transverses', veux-tu dire 'multi-compétents' ? Au-delà de la valeur courage, comment valoriser des profis généralistes/multi-compétents dans une organisation ultra-spécialisée ? Merci.
Définissons par convention l'acteur transverse :
? Il est multi-Compétent
? Bien que multi-Compétent, il n'est pas à le plusieurs petits spécialistes en un ?
? Il est doté d'empathie (ou à défaut il compense par son petit frère moins noble: la flexibilité)
? Il reconnait ? leur juste valeur les savoirs faire des experts qui l'entourent
? Il est réellement compétent et reconnu comme tel par les experts techniques qu'il accompagne
Mais l'essentiel repose sur sa capacité de mise en perspective des choses (cet ajout littéral de dimensions ne sera d'ailleurs pas sans générer de l'angoisse pour son entourage qui jusque la vivait dans un monde de certitudes).
Très bien mais tout cela reste très abstrait me direz-vous et Comment introduire un tel Coach dans une équipe chez un client, comment valoriser sa VA et ne pas le résumer à un cout supplémentaire pour le projet ?
Inutile de se baigner d'illusion, le marché nous impose d'attaquer le sujet par le R.O.I. Il aurait été plus satisfaisant et plus juste de l'attaquer sur les pans de la Qualité et de la Satisfaction Utilisateurs mais malheureusement l'idée de cout supplémentaire est trop présente dans l'esprit de 90% des dirigeants pour ne pas l'attaquer de front.
Mais alors comment une personne supplémentaire (10 à 15 HJ/mois) sans expertise technique pointue pourrait rendre mon projet moins cher ?
Tout simplement parce qu'elle sera le gardien du pragmatisme générale (qui aura vite fait de se perdre que cela soit côté MOE ou côté MOA) et que l'absence de pragmatisme dans un projet a un cout important :
1. Son absence aura un impact sur les délais
Combien de temps faut-il à une équipe DBA de Production faut-il pour s'accorder avec une équipe de développement ?
Il faut longtemps pour la simple est bonne raison que l'essentiel ne pourra être discuté qu'a l'issue d'une première phase qui va consister en une présentation (par confrontation) mutuelle des cultures des deux partis. Bien que le consensus finira irrémédiablement par s'instaurer passée cette première étape de sociabilisation, mais le mal sera déjà fait : on a perdu x HJ
2. Son absence aura un impact sur la qualité
Qui pilote globalement la problématique de la Qualité ?, certes la Sous-qualité est généralement pilotée car sanctionnée par les Tests et encouragée par le mode forfait. En revanche, la sur-qualité (généralement en début de projet) est un vrai problème dans la mesure où cette sur-qualité consommatrice sera compensée par la diminution du niveau sur un autre domaine de l'application. Nous avons tous compris que nous ne sommes pas en retard en présence d'une zone de sur-qualité, mais que la présence d'une zone de sur-qualité fait descendre de facto la qualité globale d'un projet à l'heure. (Chacun définira la non-qualité en fonction des phobies de son environnement Projet)
Le Chef de Projet peut-il efficacement faire dialoguer des équipes de Production avec des équipes des études, piloter la qualité ?
Peut-être le pourra t'il, mais j'ai tendance à penser que la conduite de projet est un numéro de duettiste : Le CP doit rassurer les commanditaires et fixer les jalons, il a la responsabilité de créer le cadre à l'intérieur duquel le Coach/Architecte pourra animer les ressources en présence. Les expériences pluriculturelles (Build, Production, MOA, CP, ?) de ce dernier lui permettront d'optimiser un planning en raccourcissant les délais d'intermédiations et de rites de passages.
[email protected]
Précisions utiles. Si je reformule, l'acteur 'transverse' possède plusieurs talents reconnus par ses pairs, et qui lui permettent de créer une vision d'ensemble dans l'équipe. Cette vision d'ensemble permet d'éviter de nombreux écueils et agit sur délais et qualité. Cependant elle se heurte à la culture du pilotage par les coûts qui n'en reconnait pas facilement les gains.
Je reconnais là un phénomène récurrent duquel on s'extraie parfois en renversant la priorité entre coûts et délais : et si notre objectif n'était pas de maitriser les coûts, mais d'abord de maîtriser les délais ? Nous agirions au passage sur la maîtrise des risques puisque nous allons livrer plus souvent au lieu d'attendre d'avoir 'toute' la commande... souvent décevante en termes 'd'adapté' ? l'utilisateur et 'd'adaptable' pour l'équipe de maintenance.
Ce discours fonctionne du coup très bien dans des contextes d'innovation où le time to market et le flou prévalent. Pourtant il s'applique à merveille dans l'usine aussi ... mais cela prend plus de temps pour la convaincre.
? ?Faire preuve de Courage? ?
Je trouve que c'est un peu gros de parler de courage... En effet, un projet se gère avec des Homme qui ont tous des qualités et des défauts. Parler de valeurs pour un projet est totalement 'bête', il faut plus parler de résultat. Comme on le dit si bien, il n'y a que le résultat qui compte.
Eric, au fait, en parlant de courage, il faudrait penser à alimenter le site 'eaichannel.com' car oui, alimenter un blog, ça en demande pas mal !
Enfin, comparer la musique classique au jazz est une abération. En effet, quand vous atteignez un certain niveau en musique classique, vous pouvez interpréter une oeuvre comme bon vous semble, voire même se laisser quelques libertés! Un peu comme en jazz. De plus, la trame est la même (une bonne vieille partition...).
A bon entendeur !