Comprendre les projets informatiques
et le digital interne d'Entreprise
Il existe une pléthore de méthodes pour conduire vos projets informatiques. Reste à savoir laquelle est la plus adaptée à votre contexte projet.
Le but ici n'est pas de vous proposer une formation aux méthodes, mais de faire le focus sur trois postures projet principales : le cycle en V, les méthodes agiles, et CMMI.
Les projets informatiques
Les méthodes
-
Stabilité du besoin : si les besoins initiaux du projet ne sont pas stables et risquent fortement d'évoluer, une méthode agile est préférable au cycle en V classique, pour permettre la prise en compte des évolutions
-
Profil du projet : on ne fait pas des projets en agilité avec tout. Je doute que l'airbus A380 ait été fait en SCRUM, avec les spécifications moteurs qui évoluent pendant qu'on conçoit la structure.
Ne pas se tromper
Il arrive souvent que des équipes passent aux méthodes agiles après avoir vécu un échec sur des projets "classiques" en cycle en V.
Parce que le client n'a pas retrouvé dans la livraison ce qu'il attendait, les équipes passent aux méthodes agiles dont la promesse est d'améliorer ce point.
La question à se poser dans ce cas, c'est : "est-ce la faute de la méthode" ou "est-ce un défaut dans la phase de conception" ?
Autrement dit, la livraison était-elle différente des attentes à cause de la méthode du cycle en V (et le fameux effet tunnel) ou tout simplement parce que la description de la cible n'a été ni précise, ni partagée par les acteurs ?
Pour le dire autrement, en cycle en V, la conception du projet doit être particulièrement soignée. A l'issue de cette phase, toutes les parties doivent partager une description claire, précise et très visuelle de la cible finale. Ce qui sous entend des spécifications lisibles et compréhensibles par tous, et qu'elles soient validées par la maîtrise d'ouvrage.
Si on part de spécifications claires représentant parfaitement et concrètement la cible, le respect de ces descriptions par la MOE n'est qu'une question de rigueur et de professionnalisme.
Partons d'un postulat de base : aucune méthode n'est magique. Aucune ne garantit la réussite d'un projet. Sinon, depuis que l'informatique existe, tous les projets informatiques seraient de brillantes réussites, ce qui n'est pas le cas. Mais alors, parmi toutes les méthodes qui existent, laquelle choisir pour vos projets ?
La querelle de clochers
J'ai lu des articles ici et là, j'entends parler les uns et les autres, et je vois apparaître deux camps qui s'affrontent : les pro-méthodes agiles, et les pro-cycle en V. Entre les deux la guerre fait rage. Dans un article que j'ai lu récemment, un expert Scrum indiquait que le cycle en V était fini : place aux méthodes agiles.
Je trouve cette querelle est un non sens. Cela reviendrait à dire à tous ceux qui ont un vélo qu'il est stupide de ne pas passer à la moto. Or tout le monde n'est pas capable de rouler en moto, et tout le monde n'a pas besoin d'une moto.
La meilleure méthode est celle qui répond au mieux au contexte
Il ne faut pas choisir une méthode parce qu'une méthode est plus à la mode qu'une autre. En gros, il y aurait les "loosers" avec leur cycle en V, et les "winners" avec leurs méthodes agiles.
Il faut choisir la méthode qui correspond le mieux au contexte de votre projet. Les critères de choix peuvent être (en gros) les suivants:
-
Profils et disponibilités des acteurs : est-ce que les acteurs projets sont compatibles avec une méthode agile ou pas ? Si votre maîtrise d'ouvrage se campe sur une position de client / fournisseur, sans pouvoir se mobiliser à quasi temps plein sur votre projet, la méthode agile est à oublier
-
Priorités sur le projet : si la priorité de la maîtrise d'ouvrage est la livraison à jour J heure H, avec le budget B sans marge d'erreur possible, la méthode agile (incluant la prise en compte des évolutions en cours de route) n'est pas forcément une bonne idée
La bonne raison
Le cycle en V
Description
La charnière du projet cycle en V, c'est le codage ; il y a des étapes avant, et des étapes après le code. Le principe de la représentation du cycle en V est de faire correspondre à chaque étape amont du codage des étapes de vérification après le codage. Pour avoir une vue plus précise de chaque étape, consulter l'onglet "les étapes".
Cette méthode permet d'avoir une vue assez réaliste du planning et du coût du projet avant son développement, puisque toutes les fonctionnalités auront été décrites et spécifiées avec précision. Aucune modification ne peut être apportée au périmètre du projet une fois le projet lancé.
La méthode repose en tout cas dans une relation « client / fournisseur » assez prononcée, puisque la maîtrise d’ouvrage a une position claire de « cliente » responsable du seul périmètre du besoin, face à une maîtrise d’œuvre responsable du seul périmètre de la réalisation.
Il reste cependant possible d’intégrer au sein de cette démarche quelques comportement « agiles » qui permettront aux différentes phases du projet, d’optimiser la charge ici ou là.
Cette méthode de développement est la plus classique et la plus connue. Elle tient son étrange appellation de la représentation qu'on lui donne, avec un déroulement vous la forme d'un V :
Contexte
Difficile de tracer le contexte précis qui correspond à la méthode. On peut cependant dire que globalement, la méthode du cycle en V est bien adapté aux contextes suivants :
Profils et disponibilités des acteurs :
Les équipes MOA et MOE sont distantes à la fois au sens propre comme au sens figuré. Les équipes sont sur des sites différents, et hiérarchiquement, elles sont fortement cloisonnées. Votre maîtrise d'ouvrage a peu de temps à vous consacrer. Votre relation est purement du type "client / fournisseur". Il est donneur d'ordre : vous êtes exécutants. Un travail en tandem très proche est impossible pour plusieurs raisons : humaines, hiérarchiques, ...
Priorité sur le projet :
Votre maîtrise d'ouvrage met un point d'honneur sur le respect des dates et du budget qui ont été validés en amont, dans la phase d'engagement. Vous devez coûte que coûte respecter l'un et l'autre, ce qui sous entend que vous devez avoir un plan de vol en ligne de droite, parfaitement balisé dès le début.
Stabilité du besoin :
Au cours de la réalisation du projet, le besoin est plutôt stable. Il n'y a de grands risques que des évolutions majeurs interviennent en cours de route.
Profil du projet :
Votre projet peut être difficilement découpé en plusieurs lots autonomes. C'est un projet assez important en taille, avec des interactions avec d'autres systèmes.
Les échanges MOA / MOE pendant le projet (de manière schématique) :
Avantages & inconvénients
Chaque méthode a ses avantages et ses inconvénients.
Commençons par les avantages...
L’avantage du projet « cycle en V », c’est sans aucun doute possible la clarté des responsabilités de chacun, et la netteté du périmètre de chacune des étapes.
En résumé, la MOA est responsable du besoin, et la MOE, de sa mise en œuvre. Le découpage des étapes est assez net, et assez logique. Chacune des étapes est là pour verrouiller la démarche. En gros, on ne passe pas à l’étape suivante tant que l’étape courante n’est pas complètement finalisée, stabilisée et validée.
C’est une méthode particulièrement bien adaptée aux projets qui ne peuvent pas se permettre de flottements dans sa réalisation. C’est aussi bien adapté lorsqu’il y a pléthore d’interlocuteurs : le verrouillage de chaque étape nécessite l’adhésion de tous, ce qui réduit par la suite les risques de conflit ultérieurs (sous condition : ce verrouillage peut aussi en provoquer - rien n'est simple) !
Le cycle en V, c’est aussi une certaine garantie pour la maîtrise d’ouvrage et la maitrise d’œuvre. Pour la maîtrise d’ouvrage c’est la garantie du respect du périmètre fonctionnel validé au départ du projet, le respect du planning et de l’enveloppe budgétaire validés au lancement. Pour la maîtrise d’œuvre, c’est la garantie que le périmètre fonctionnel pour lequel elle s’en engagée restera stable au cours du projet.
Voyons maintenant les inconvénients...
L’inconvénient, c’est que les avantages cités ci-dessus ne sont pas toujours au rendez-vous.
Pour la maîtrise d’ouvrage, le projet et le planning ne sont pas toujours respectés par la maîtrise d’œuvre. Côté maîtrise d’œuvre, le périmètre fonctionnel peut se révéler finalement variable, avec des conflits à la clé ; car bien souvent, de nouvelles fonctionnalités sont « poussées » en cours de route, mais avec toujours l’obligation de respecter planning et devis.
En fait, les inconvénients de ce mode projet font les avantages de la méthode agile, puisque le principal défaut du cycle en V c’est l’absence d’agilité, c'est-à-dire l’incapacité contractuelle de prendre en cours de route de nouvelles fonctionnalités (sauf à modifier planning et chiffrage en conséquence). Et c’est bien logique puisque le cycle en V repose sur des engagements de planning et de budgets incompatibles avec cette démarche.
L’inconvénient c’est aussi le fruit de la nette séparation des responsabilités MOA / MOE qui font que les deux entités se regardent quelquefois avec défiance, dans un mode « client / fournisseur » du plus beau style. Du coup, il n’y a pas (souvent) cette forte relation qui existe entre MOA et MOE dans le cadre d’un projet agile, ou l’un et l’autre sont partenaires pour atteindre un objectif commun.
L’autre inconvénient, est que dans cette démarche, la MOA est moins impliquée dans son projet que dans un projet agile. Moins impliquée ne signifie pas qu’elle s’en désintéresse, mais qu’elle a moins participé à l’élaboration de la solution, ne participant qu’à la validation de la solution proposée par la maîtrise d’œuvre en réponse à ses besoins.
Mes conseils
De la même manière qu’une équipe n’est pas « obligée » de suivre à la lettre une méthode « agile » officielle pour faire de l’agilité, il n’y a pas non plus de loi universelle interdisant aux acteurs projets de faire preuve de bon sens, en intégrant de l’agilité dans certaines étapes du projet.
On peut faire un projet agile sans le savoir, en associant de façon forte la maîtrise d’ouvrage à la conception de la solution. En faisant cela, on réduit le besoin ultérieur d’évolutions, et on s’affranchit alors d’un développement « type agile » pur, c'est-à-dire intégrant des évolutions en cours de route : cela permet de faire de notables économies.
Mais bien entendu, il n’y a aucune règle générale. Chaque projet est différent, parce que chaque besoin est différent, chaque acteur du projet a une personnalité différente, une implication différente, et une culture projet différente. Et la réussite d’un projet en « cycle en V » dépend de la bonne alchimie entre tous ces ingrédients.
Les méthodes agiles
Relations MOA / MOE
C'est un lecteur du site qui m'a inspiré cette rubrique. Il m’a posé une question très intéressante : est-ce que les méthodes agiles de développement informatique améliorent les relations Maîtrise d’ouvrage – Maîtrise d’œuvre ? Vaste question, à laquelle je donne une réponse en deux temps.
Dans la théorie, oui
Les méthodes agiles « académiques » (Scrum, …) érigent en principe de base le fort partenariat qui doit (devrait toujours) exister entre maîtrise d’ouvrage et maîtrise d’œuvre, autant dans les méthodes que dans les relations entre acteurs. Par exemple, cela se traduit de façon très concrète par rassembler les acteurs MOE et MOA dans un même lieu (plateau projet) où tous travailleront ensemble à la réalisation du projet. Tous sur le même bateau, en quelque sorte.
A force de travailler ensemble, de former non pas deux équipes rivales (MOE et MOA) mais une seule équipe confrontées en même temps aux mêmes questions, oui, les méthodes agiles permettent d’améliorer les relations MOA / MOE.
Mais ce n’est que théorique, et à condition que les acteurs MOE et MOA connaissent, comprennent et acceptent la méthode agile et en suivent scrupuleusement toutes les règles, et pas seulement celles qui les arrangent. Malheureusement, ce sont plus généralement les acteurs MOE qui suivent des formations aux méthodes agiles ; rarement les acteurs MOA.
Au final, il est commun de ne retenir de l’agilité que les points séduisants (faire plus vite, avec moins de document…) en oubliant les contraintes (MOA et MOE travaillant en même temps sur le même plateau, la main dans la main, et sur le même rythme).
Dans la vraie vie, pas forcément
Contrairement à la croyance populaire, un projet informatique n’est pas seulement qu’une histoire de technologie et de méthode ; c’est surtout une aventure humaine. Un projet, ce sont des hommes qui apportent leurs connaissances et compétences à d’autres hommes pour réussir un projet informatique commun.
La qualité du projet dépend donc beaucoup de la qualité des hommes : compétences dans leurs métiers respectifs, mais pas seulement. Leurs qualités humaines entrent aussi fortement en compte : capacité à communiquer, à expliquer, à se faire comprendre, à comprendre l’autre et à se mettre à sa place, à accepter les compromis, à s'estimer mutuellement. Capacité à mettre son égo de côté, à trouver des solutions…
Ceci étant posé, les méthodes agiles ne sont pas des séances de psychologie de groupe ; elles ne sont donc pas une solution pour répondre à tous les problèmes relationnels entre MOE et MOA.
Ce que je veux dire, c’est que si parmi les acteurs du projet se trouvent des personnes qui n’abordent les relations MOA / MOE que sous l’angle d’une relation « client / fournisseur » exclusivement « gagnant / perdant », les méthodes agiles ne vont améliorer en rien les relations entre MOE et MOA. Bien au contraire. Ce ne sont donc pas les méthodes qu'il faut changer dans ce cas là, mais les acteurs.
Gardez à l’esprit que pour certains, « challenger un projet », c’est essentiellement piloter la MOE sous forte pression. Pour ceux là, un projet qui se passe dans une bonne ambiance, ce n’est pas bon signe ; c’est que la MOE n’est pas assez pressurisée. Solidarité, compromis, échange ne sont pas des mots de leur répertoire. Avec eux, prudence : le recours à l’agilité est souvent une tentative pour rajouter des contraintes supplémentaires sous l’excuse du nom d’une méthode : dans ce cas, le projet est bien mal engagé.
Si une telle relation néfaste existe déjà entre la MOA et la MOE dans le cadre d’un projet « non agile », il y a peu de chance que les méthodes agiles changent quelque chose. Je pronostique plutôt un désengagement rapide et un retour en « mode classique » des deux équipes, avec plus de problèmes que dans un cycle en V classique qui aurait apporté ici quelques sécurités pour les deux parties. Et retour rapide à la rivalité et à la défiance pour les deux acteurs du projet.
Certains acteurs MOA se lancent à corps perdu dans les méthodes agiles, soit pour briller auprès de la hiérarchie, soit parce qu’elles ont connu des échecs (relationnels, projets, …) avec leur MOE dans les autres méthodes plus conventionnelles (Cycle en V). Dans ces cas typiques, la bonne question n’est pas de changer de méthode, mais bien de comprendre à quoi sont dus ces problèmes. On découvrira alors potentiellement des problèmes de personnes, de compétences, de maturité projet. Faire l’économie de cette « psychanalyse projet », c’est s’exposer aux mêmes problèmes relationnels en mode agile.
L'agilité est pour moi tout d'abord une posture avant d'être une méthode. C'est une orientation définitive de l'informaticien vers l'efficacité et la satisfaction de son client et de ses utilisateurs.
Le principe
Dans un projet agile, on parlera plutôt de besoins fonctionnels plutôt que d'exigences. La différence de langage que j’introduis ici n’est pas fortuite.
Tout d’abord, parler de besoins plutôt que d’exigences montre que la demande initiale de la maîtrise d’ouvrage n’est pas immuable, ni dans les moyens, ni dans l’objectif, puisque le projet peut encore évoluer dans le temps. Enfin, en parlant de besoins, on revient sur les fondamentaux, c'est-à-dire le service que l’outil doit rendre à l’utilisateur, en se laissant toute latitude pour identifier les moyens les plus efficaces d’y parvenir.
Mais le projet agile, c’est surtout un partenariat très fort entre la maîtrise d’ouvrage et la maîtrise d’œuvre. La relation « client / fournisseur » qui est de rigueur dans les projets en « cycle en V » devient une relation de partenaires de travail, avec des objectifs communs.
Dans une telle relation, les équipes MOA & MOE travaillent de concert, physiquement. La réunion de travail typique, c’est le chef de projet maîtrise d’ouvrage, assis à côté d’un développeur en train de discuter de l’ergonomie de l’écran en cours de réalisation.
Le projet agile, c’est aussi et surtout un projet dont le périmètre fonctionnel peut bouger en cours de réalisation (sous certaines limites, en procédant par versions). En cycle en V, la maîtrise d’ouvrage ne doit pas demander d’évolution de son besoin entre le moment où elle valide le cahier des charges et le moment où le produit lui est livré. Elle essaie bien d’en faire passer quelques unes, mais c’est généralement le conflit assuré.
Dans ce cadre, les critères de réussite du projet ont donc changé.
Le critère de réussite, ce n’est plus le respect de l’immuable triptyque « coût, délai, qualité », mais plutôt « réactivité, qualité ». En d’autres mots, le but est d’être réactif et agile en acceptant des évolutions de périmètre dans le projet, et livrant un produit de qualité dans les meilleurs délais possibles.
Par la suite, certains éléments permettront de réduire les délais de réalisation notamment dans les étapes de conception, développement et déploiement.
Les échanges MOA / MOE pendant le projet (de manière schématique) :
Les méthodes
Par rapport à l’histoire de l’informatique, l’agilité est une notion récente. Elle prend naissance dans les années 80 avec la méthode RAD, complétée en 1994. C’est en 2001, aux USA, que nait officiellement une démarche agile structurée et organisée. Cette année là, dix-sept figures éminentes du développement logiciel se sont réunies pour unifier les méthodes existantes. De cette réunion est né un texte : Agile Manifesto (http://agilemanifesto.org)
Ce manifeste identifie quatre valeurs fondamentales de l’agilité, et douze principes :
-
L’interaction avec les personnes plutôt que les processus et les outils.
-
Une production opérationnelle plutôt qu’une documentation pléthorique.
-
La négociation avec le client plutôt que le respect d’un contrat.
-
La collaboration au changement plutôt que le suivi du plan.
Tout cela pour expliquer que la démarche agile n’est plus aujourd’hui une démarche « rebelle » réservée à ceux qui veulent fuir la rigidité du cycle en V. La chasse aux sorcières est finie : vous ne serez plus jetés aux flammes du bûcher en tant qu’hérétique du cycle en V.
Il existe plusieurs méthodes officielles qui apportent chacune leurs avantages et inconvénients. La meilleure des méthodes est à coup sûr celle qui s’adapte le mieux à votre organisation, à vos projets, à vos attentes. Mon objectif ici n’est pas de vous les présenter une à une : d’une part, je n’en aurais pas la connaissance suffisante pour donner un avis pertinent, et d’autre part, mes confrères sur le Web feront ça en détail avec bien plus d’efficacité que moi.
Voici une liste de méthodes :
-
Rapid Application Development (RAD)
-
Dynamic systems development method (DSDM)
-
Extreme programming (XP)
-
Adaptive software development (ASD)
-
Feature Driven Development(FDD)
-
Scrum
-
Crystal clear
-
Processus Urbanisant les Méthodes Agiles (PUMA (http://www.entreprise-agile.com/))
-
Rapid Application
Votre propre méthode !
Les méthodes officielles d’agilité ne manquent pas.
Mais l’agilité, c’est plus un état d’esprit qu’une certification. On peut être agile sans le savoir. A vous de trouver la bonne recette en dosant juste ce qu’il faut d’agilité, en fonction des besoins, et en fonction des possibilités de votre équipe, et de celle de la maîtrise d'ouvrage.
Mais l’agilité commence dès lors que vous osez sortir des sentiers battus et des processus officiels pour trouver ici et là des gains de productivité et d’efficacité. Ca comporte un risque : vos documents ne sont plus « iso », votre processus n’est pas « dans les normes ». La direction qualité risque de ne pas laisser passer.
En d’autres mots, votre agilité, vous pouvez la faire vous-même, en vous inspirant de méthodes plus officielles qui sont issues de l’expérience d’autres groupes de professionnels. Il n’est pas nécessaire de dérouler une méthode de A à Z pour se prévaloir d’être agile, même si la revendication d’une méthode reconnue (exemple : scrum) apporte quelque part de la reconnaissance, de la légitimité, et une facilité d’explication.
Même dans le cadre d'un projet en "cycle en V" vous commencerez à mettre un pied dans la démarche agile par exemple, si vous pensez à faire votre première recette chez le fournisseur en charge d’une prestation au forfait. Vous serez agiles si vous arrivez à convaincre votre maîtrise d’ouvrage de participer aux réunions de travail sur l’ergonomie des écrans. Vous serez agiles en mettant en place au sein de vos équipes des outils de développement efficaces, ou des outils de gestion de la connaissance.
Avantages & inconvénients
Les méthodes agiles ont des avantages indéniables, mais aussi des inconvénients qu'il faut connaître.
Voyons d'abord les avantages
Les gros avantages des méthodes agiles, c'est de fludifier l'interaction entre la maîtrise d'ouvrage et la maîtrise d'oeuvre. Dans ce mode, la relation "client / fournisseur" qui peut tant poser problème s'estompe pour laisser apparaître un esprit d'équipe entre ceux qui savent à quoi la cible doit ressemble (la MOA) et ceux qui savent comment atteindre technique l'objectif (la MOE). Dans la théorie, les relations devraient donc être meilleures (lire cette page).
Mais le principal avantage est de voir concrètement le projet avancer et se construire. Les briques s'ajoutent les unes aux autres, et dans des délais assez courts, les premières briques utilisables peuvent être mises en place, en parallèle de la réalisation de la suite. Dans ce mode, l'effet tunnel n'existe plus puisque le client a très rapidement un livrable réel.
Voyons les inconvénients
Les méthodes agiles ne sont pas magiques ; ce n'est pas la réponse aux problèmes que l'on a rencontré dans des projets "classiques". Il y a des risques, comme par exemple celui des projets "dichotomiques".
Rappel de la définition du mot dichotomie, extrait du site Wikipedia : "La dichotomie (« couper en deux » en grec) est, en algorithmique, un processus itératif ou récursif de recherche où, à chaque étape, on coupe en deux parties (pas forcément égales) un espace de recherche qui devient restreint à l'une de ces deux parties."
Je m'explique. Partant du principe que les méthodes agiles permettent la modification et les évolutions (sous certaines limites), la phase de réflexion sur le besoin pourrait être réduite à sa simple expression, non pas parce que le besoin risque de changer, mais parce que l'effort à réfléchir à ce qu'il faut comme cible n'a pas été fait en amont, comme cela se fait dans le cadre d'un projet cylcle en V. Au final, sous prétexte de la prise en compte des évolutions, on risque d'avancer à tâton, jusqu'à trouver la bonne formule, alors qu'une réflexion en amont aurait peut être permis d'identifier la cible plus tôt. Entre temps, des développements auront été faits, et ces développements ont un coût.
Autre risque, les problèmes qui peuvent survenir en fin de projet. Pour rappel, le projet se construit au fil de l'eau : les briques sont ajoutées les unes aux autres, jusqu'à former l'application dans son ensemble. Mais rappelez-vous : l'étude fonctionnelle traditionnelle et globale que l'on fait dans un cycle en V n'est pas faite. Au final, en fin de projet, en voulant ajouter la dernière brique, on peut se rendre compte qu'un point majeur n'a pas été pris en compte dans les briques précédentes, ce qui nécessitera une possible refonte de l'application. Dans les méthodes agiles comme dans toutes les autres méthodes, rappelez vous que les évolutions ne sont pas gratuites : elles sont un coût et présentent des impacts (régressions, ...), méthodes agiles ou pas.
Dernier risque important : la greffe MOA / MOE en mode agile qui ne prend pas. Ca peut se traduire par une MOA qui n'a plus la disponibilité pour s'investir sur le projet comme la méthode le voudrait. Petit à petit, toute l'équipe repasserait en mode cycle en V qui ne dirait pas son nom, faute de synergie entre les principales maîtrises.
Les conseils
Les méthodes agiles apportent des gains évidents dans les projets informatiques : elles rapprochent les maîtrises entre elles, elles permettent d'améliorer la solidarité et les synergies, elles réduisent les risques de "hors sujet" en fin de projet, elles permettent de délivrer des services au fil de l'eau, et non en fin de projet, etc.
Personnellement, je suis "agile" dans ma conduite de projet depuis bientôt dix ans, même si je ne déroule pas du Scrum dans sa forme académique.
Gardez cependant à l'esprit que l'agilité ce n'est pas une méthode, mais surtout un état d'esprit, que ces méthodes présentent des contraintes (disponibilté, ...) qu'il faut assumer. Surtout, on ne fait pas "agile" avec tous les sujets, ni avec n'importe qui. Il faut donc être prudent avant de se lancer dans cette méthode, au risque de rencontrer quelques déboires.
Pour en savoir plus sur la posture "agile", je vous recommande la lecture de mon livre "Penser autrement vos projets informatiques".
C M M I
Dans les années 80, les grandes administrations des états occidentaux se sont inquiétés des échecs rencontrés lors de projets informatiques. Des sommes colossales étaient gâchées en pure perte, avec un taux d'échec de près de 50% des très gros projets.
Ces échec étaient imputables, on pas à des erreurs technologiques, mais à des difficultés de communication, de compréhension des besoins, et de management des personnes.
C'est du DOD (Département of Defense américain) qu'est venue l'initative de faire quelque chose pour tenter de remédier à ce problème. En réponse a été créé l'institut "SEI" en 1984 (Software Engineering Institut". Un concours a été organisé auprès des grandes universités américaines, et c'est le Camegie Mellon qui l'a remporté. En 2000 était publié CMMI 1.0.
Plus de vingt ans plus tard, les statistiques montrent que le problème reste d'actualité, avec (en 2004) 29% des projets qui réussissent, 53% des projets dont le succès est contesté (livré en retard ou avec des fonctionnalités inférieures à ce qui était prévu), et 18% des échecs (jamais livrés)
Dynamique
d'amélioration continue
CMMI permet de pouvoir mesurer le niveau de maturité d'une projet, ce qui permet d'améliorer la prise de conscience de la qualité de management. Cette prise de conscience permet d'anticiper les risques, et de pouvoir améliorer les faiblesses, en se basant sur l'expérience des contributeurs à la méthode. Cette méthode s'inscrit dans une démarche d'amélioration continue.
Cette méthode profite de l'expérence des autres utilisateurs au travers d'une accumulation d'expériences sur les projets. C'est un ensemble de bonnes pratiques à respecter. Les procédures écrites sont des composants importants dans la démarche : les normes ISO en particulier permettent également d'utiliser un langage connu et clair entre tous les acteurs.
5 niveaux de maturité
Il existe deux approches de la méthode : étages (le niveau de maturité se détermine en fonction de la maîtrise des niveaux inférieurs) et continue (on mesure alors le niveau de maîtrise de chaque domaine de processus).
La maturité se mesure sur 5 niveaux :
-
NIVEAU 1 - INITIAL : plutôt que de l'appeler "niveau 0 = vous êtes nul", ce niveau est le numéro 1 (un bon point). Tout le monde est par défaut au minimum à ce niveau. C'est celui des projets qui dépendent du seul savoir-faire de quelques personnes clés. C'est une étape appelée "l'ère des héros", car tout repose sur l'implication de quelques personnes, sans possibilité de reproduire une réussite
-
NIVEAU 2 - REPRODUCTIBLE : c'est un niveau où les bonnes pratiques de gestion de projet sont utilisées. Le développement est planifié, suivi. Il y a une bonne gestion des coûts et des délais
-
NIVEAU 3 - DEFINI : l'équipe utilise des processus bien définies et bien comprises par les acteurs. Les processus intègrent les bonnes pratiques
-
NIVEAU 4 - MAITRISE : on introduit ici des notions de tableaux de bord, de métriques, et de statistiques. Les processus sont mesurés, et les risques sont anticipés
-
NIVEAU 5 - OPTIMISE : on utilise l'ensemble des éléments dont on dispose, et en particulier les mesures, et on réalise des opérations de recherche d'optimisation.
CMMI en détail
Mon objectif n'est pas ici de décrire en détail CMMI. Ce serait parfaitement inutile puisqu'il existe par ailleurs des sites complets spécialement dédiés à la question, dont en particulier le site ci-dessous, qui est le site de l'organisme qui a créé la démarche :
Une démarche pour
les gros projets
Dans sa forme de base, CMMI est une démarche qui s'adresse aux gros projets informatiques. J'ai pu bénéficier d'une formation, et le simple fait de faire "vivre" la démarche de façon complète représente une charge conséquente, difficilement compatible avec un petit projet.
Il n'empêche, s'intéresser à la démarche, prendre connaissance des conseils et des bonnes pratiques permet de gagner en connaissance et en expérience sur d'autres projets.
Même s'il n'est pas envisageable de déployer la grosse usine CMMI sur vos petits projets, beaucoup des enseignements apportés par CMMI restent applicables, tout simplement parce qu'elles sont pleines de bon sens.
Un langage commun
L'avantage de CMMI, comme pour les normes ISO, c'est de poser un contexte connu entre différents acteurs qui ont acquis les connaissances nécessaires. Dans une telle démarche, les acteurs du projet partagent des valeurs communes, des vocabulaires bien définis, sans ambiguïté.
Il n'est donc pas étonnant que cette démarche soit petit à petit adoptée par les SSII.