Retour à l'accueil
accueil renseignements diffusion
Recherche
avancée
 Numéro 8, Avril 1996 
Une gestion de projet efficace pour des logiciels de qualité Version Imprimable  Version imprimable
Le modèle (deuxième partie)

Jean-Guy Dubois  (CCDMD)

4. Sois maître dans ta maison

Bonhomme! Tu n'es pas maître dans ta maison quand nous y sommes!

 

Il y a perte de maîtrise d'un projet lorsqu'on a perdu le contrôle sur certains responsables des tâches à exécuter, lorsqu'on ne peut plus s'engager réellement sur une date de livraison, lorsque la qualité du produit en développement nous échappe, lorsqu'on ne peut détecter à temps les écarts de délais, de coûts ou de conformité du produit aux spécifications.

 

Ne croyez pas qu'une telle perte de contrôle sur le développement d'un projet ne peut arriver à un service comme le nôtre. Hélas! cela s'est trop souvent produit dans le passé! Je ne le sais que trop : à mes débuts au CCDMD, j'ai hérité de quelques projets qui se trouvaient dans un tel état.

 

Ce n'est pas tant l'insuffisance des moyens mis en oeuvre qui est en cause, que leur mauvaise utilisation. À celle-ci correspond une absence de méthode d'estimation et de planification des charges, ou le non-respect de ces dernières. Faute de temps, nous n'appliquons pas encore de véritables méthodes d'ingénierie du logiciel, même si nous avons l'intention d'y arriver. Sont aussi reliés à ces méthodes, l'apprentissage d'outils pour l'identification des différentes activités d'un projet, l'estimation des charges, des délais et des coûts associés, la planification des travaux, le suivi et le contrôle de leur bon déroulement.

 

Le responsable de projet est un véritable chef d'orchestre, qui doit savoir bien mesurer, attribuer et coordonner les travaux des principaux intervenants. Une baguette ne lui suffit pas toujours! Il doit savoir quelquefois jouer du tambour et de la trompette! Si les cuivres ne suivent pas les violons, ce sera la cacophonie dans la maison!

 

La partition à orchestrer tient plus de la symphonie que du concerto. L'espoir qu'un virtuose de la programmation viendra sauver la situation tient plus du mythe que de la réalité. Il ne faut pas trop y compter : les artistes géniaux sont rares, coûteux et très peu disponibles. La conduite de projet demande de raisonner en industriel plus qu'en artisan talentueux.

 

Bonhomme! Sais-tu jouer de ce violon-là?

Et en avant la musique! pour la danse à cinq temps d'une gestion de projet professionnelle 1 :

 

1. S'accorder sur les composantes du projet

 

Dans un premier temps, on étudie les caractéristiques du projet : sa définition, son environnement, ses acteurs, ses différents états au cours de son cycle de vie, les types de tâches à prendre en charge. On en déduit les choix de méthodes, de techniques et d'outils à utiliser. On détermine ainsi, au démarrage du projet, la nature des actions à entreprendre pour le mener à bien.

 

2. Découper pour estimer

 

Devide ut regnes! Cette maxime politique énoncée par Machiavel, qui fut celle de Louis XI et de Catherine de Médicis, s'applique tout à fait à la gestion de projet : la division est une obligation si l'on veut bien estimer les délais, les charges et les coûts d'un projet logiciel, et ensuite régner sur eux. L'un des moyens pour ne pas oublier de tâches importantes est de disposer d'un cadre méthodologique fournissant une liste exhaustive des tâches à accomplir.

 

Un projet comprend un ensemble d'activités de conception et de réalisation, un ensemble d'activités de conduite de projet et un ensemble d'activités de contrôle de la qualité. Ces trois blocs évoluent de façon spécifique lors de chacune des phases du projet, au sein de chaque lot de tâches qui les constitue.

 

3. Estimer pour planifier

 

Évaluer avec une précision correcte les charges, les délais et les coûts d'un projet, afin d'en optimiser les ressources, constitue l'objectif principal d'une bonne méthode de conduite de projet. Pourquoi estimer? Les raisons sont multiples : pour bien cerner la durée du projet, pour déterminer avec plus de justesse les ressources humaines et matérielles à mettre en oeuvre, pour mieux évaluer la faisabilité technique du projet, pour améliorer la productivité des principaux réalisateurs, pour éviter les dérives de coûts, pour appuyer plus objectivement une négociation avec un sous-traitant, etc.

 

La notion d'estimation est un concept que l'on peut facilement comprendre et justifier de bien des façons. Cependant, la mise en oeuvre des techniques qui y correspondent n'est pas si simple. Voici quelques-uns des principaux obstacles à une bonne estimation : l'absence de spécifications claires et complètes, la difficulté de définir une unité d'oeuvre adéquate correspondant à une somme de travail quantifiable, le choix d'un découpage de qualité permettant une organisation efficace des travaux, le syndrome de la sous-estimation, trouvant sa source dans le désir de plaire ou d'impressionner, les facteurs déviants de l'environnement projet, provenant principalement de ceux qui y participent, et qui sont souvent imprévisibles, etc.

 

4. Ordonnancer les actions dans le temps

 

Voilà, nous sommes en pleine planification. L'ordonnancement des activités et des ressources dans le temps définit le cadre nécessaire pour le suivi et le contrôle du projet. Même si tous, ou presque, reconnaissent la nécessité d'un bonne planification, en pratique, il faut vaincre bien des résistances. La planification se pratique avec succès dans plusieurs secteurs industriels, mais les équipes informatiques trouvent encore bien des raisons pour y appliquer les freins.

 

Certains diront que le nombre et la diversité des opérations, ainsi que leur complexité, rendent cette démarche pratiquement impossible. De plus, ils diront que ce processus demande trop d'itérations, d'affinements successifs et une consommation de temps excessive pour le résultat rapporté. Certains encore diront que c'est pour les autres : les grosses boîtes, qui réalisent des projets à coup de millions. D'autres aussi diront que la planification, c'est le contrôle, et on tient tellement à sa liberté. Arrêtons-nous là, il est si facile de justifier son manque de professionnalisme, même au nom du professionnalisme!

 

5. Suivre et contrôler l'avancement

 

Le suivi et le contrôle de l'avancement d'un projet présupposent un travail préalable d'estimation et de planification. Leur objectif principal est la réactualisation permanente de la situation, afin de déterminer les points d'intervention et de réajustement nécessaires.

 

On a le sentiment que de telles pratiques prendront beaucoup de notre précieux temps. En effet, la mise en place d'un suivi et d'un contrôle efficaces exige quelques activités supplémentaires : des réunions formelles, des comptes rendus, l'actualisation du planning et du budget, etc. Ces activités de gestion restent cependant nécessaires et ne devraient pas être perçues comme non productives. C'est le prix à payer pour rester maître dans sa maison!

 

5. Les cinq paliers de la sainteté

Il n'y a pas de remèdes miracles aux problèmes vécus dans le domaine du développement logiciel. La qualité d'un produit logiciel dépend fortement de la qualité du processus appliqué pour le réaliser. Je vous présente brièvement un modèle permettant de qualifier les niveaux de maturité d'un tel processus : le Carnegie Mellon University Software Engineering Institute's (SEI) Capability Maturity Model (CMM), initialement développé par Watts S. Humphrey 2 et ses collaborateurs pour évaluer la capacité des fournisseurs du United States Department of Defense. Tout ce qu'il y a de plus sérieux!

 

Le modèle du SEI décrit cinq niveaux de maturité que l'on peut caractériser de la manière suivante :

 

1. Niveau chaotique ou non structuré

 

Le processus de développement est empirique, au sens où on n'applique pas de procédures formalisées de conduite de projet. Aucune étude de faisabilité des projets n'est faite et aucune gestion des risques n'est appliquée. Les produits n'atteignent généralement pas la qualité voulue, les délais et les coûts sont souvent dépassés. Le succès reste cependant possible, basé sur la compétence et le travail de quelques individus talentueux, plutôt que sur l'infrastructure organisationnelle du processus. La plupart des entreprises se retrouvent à ce niveau (70%, selon le SEI); la Section de l'informatique du CCDMD aussi. On y vit dangereusement, quelquefois héroïquement, un peu à la façon de saint Augustin avant sa conversion!

 

2. Niveau reproductible ou orienté projet

 

À cet état du processus, des techniques de planification des tâches et des ressources sont présentes pour certains projets. La notion de phase et de validation en fin de phase apparaît. L'ébauche d'un contrôle de la qualité s'instaure au niveau des produits, mais pas à celui de la production elle-même; en particulier, il y a toujours des réticences à documenter le processus de développement. Par imitation, le processus est répété sur d'autres projets. À ce niveau, on aspire à la sainteté : certains commandements de la sainte Église SEI sont suivis, mais sans conformité aux canons établis.

 

3. Niveau défini ou orienté processus

 

À ce stade, le processus organisationnel est bien établi, à partir duquel le processus de développement de chaque projet est défini. Ce processus organisationnel est caractérisé et bien documenté. Des méthodes standardisées de conception sont appliquées, les normes SEI sont bien incorporées. On est au monastère, sous la règle de saint Benoît de Nursie ou de saint Ignace de Loyola; on peut espérer la béatification.

 

4. Niveau maîtrisé ou intégré

 

On accède, à ce stade, au processus industriel contrôlé et intégré de fabrication. Des actions périodiques d'amélioration du processus sont exercées. Les outils CASE (Computer-Aided Software Engineering) sont intégrés à la conception et à la réalisation. On atteint un degré de perfection digne des plus grands mystiques; on peut espérer la canonisation.

 

5. Niveau optimisé ou pleinement intégré

 

La performance du processus organisationnel est mesurée; le contrôle devient quantitatif. Afin de rencontrer les besoins stratégiques de l'organisation, le processus est optimisé en permanence. On atteint une perfection séraphique, qui n'est réservée qu'aux anges. Selon le SEI, seulement 0,2% des entreprises y parviennent.

 

Devant ces paliers de la sainteté, quelle stratégie de changement adopter? Elle est fonction du degré de maturité de l'entreprise. Sur la voie de la sainteté, on ne peut brûler les étapes : seul le palier immédiatement supérieur nous est accessible, sinon c'est la chute.

 

Ad augusta per angusta!

 


Notes

  1. Bénard, C. : Les 9 points clés de la conduite d'un projet informatique, Les Éditions d'Organisation, Paris, 1992. Retour au texte.

  2. Humphrey, W.S. : Managing the Software Process, Addison Wesley, Reading Mass, 1989. Retour au texte.

Creative Commons License Cette création est mise à disposition sous un contrat Creative Commons. Dernières mises à jour : 10/04/2015