La perception de la performance en développement logiciel selon le style de gestion

Voir la version AMP

La perception de la performance en développement logiciel varie selon le style de gestion; il faut le souligner, la mesure de la performance est vraiment une question de perception. L’évaluation de la performance d’une équipe de développement est en fait étroitement liée au style de gestion et aux priorités que celui-ci dicte; en développement logiciel comme dans toute autre activité d’ailleurs.

Tout gestionnaire souhaiterait avoir une évaluation objective de son équipe de développement et de son département TI dans le cadre d’un projet de développement logiciel. Le terme « objectif » est la clé de l’énigme ici. Existe-t-il une méthode objective d’évaluation de la performance d’un développeur, d’une équipe de développement, d’une entreprise de développement logiciel ? Existe-t-il un indicateur clé de performance en développement logiciel, qui dit la vérité ?

En fait, on ne compte plus les systèmes, méthodes et nomenclatures qui ont été développées depuis le début de l’ère industrielle afin d’évaluer la performance en développement logiciel comme ailleurs.

Ainsi, beaucoup d’entreprises se demandent si leur équipe de développement logiciel ou celle de leur consultant TI est performante. Étonnamment, il existe une méthode objective et universelle développée dans le cadre du système CMMI (Capability Maturity Model Integration) permettant d’évaluer la performance d’une équipe de développement logiciel.

Cette méthode d’évaluation, FFP (Full Functional Point), permet d’évaluer, de façon constante et indépendante de la technologie, l’effort nécessaire pour générer un livrable défini.  Cette évaluation, associée à la vélocité, permettra de mesurer la performance d’une équipe de développement logiciel. Cependant, dans les faits, cette méthode est elle aussi assujettie au style de gestion.

Nous développerons en détail les notions de FFP (point de fonction) et de vélocité dans nos prochains billets; nous expliquerons dans ce billet-ci les deux principaux styles de gestion de projet en développement logiciel et comment ils influencent l’évaluation de la performance d’une équipe de développement.

En résumé, tout est question de gestion et de métriques.

Êtes-vous plus Agile ou Waterfall ?

Quel type de gestionnaire êtes-vous ?  Agile ou Waterfall ?

En d’autres mots, dans le projet de développement logiciel (d’application) que vous lancez; qu’est-ce qui a le plus d’importance ?  La valeur ou le plan ?

Considérant la représentation ci-dessous des deux styles de gestion, il n’y a pas de bonne ou mauvaise réponse à cette question !

gestion par valeur vs gestion par plan

La réalité est que dans les grandes entreprises, certains projets de grande envergure impliquent plusieurs départements et plusieurs intervenants. Dans ce cas de figure, nul doute que le plan est non seulement utile mais il est nécessaire.

Typiquement, dans un projet de développement logiciel de grande envergure tel que « la refonte d’une application de back-office critique », tous les départements bénéficiaires et / ou contributeurs présentent leurs requêtes et leurs contraintes. Et ils s’attendent à voir leurs requêtes comblées et réalisées puisque toutes les fonctionnalités demandées, petites ou grandes, sont considérées nécessaires par chaque requérant. Ainsi, toutes les fonctions requises et nécessaires dans le cadre du projet seront toutes intégrées au plan final.

Un projet de développement logiciel (d’application) est lancé avec l’objectif qu’il aura un impact positif sur l’ensemble des parties impliquées. Il sollicite la coordination de plusieurs départements et mobilise de nombreuses ressources à différentes périodes.  Sa réalisation demandera un effort collectif de collaboration. Incidemment, le plan engendre un effet mobilisateur et agit comme un outil de coordination auprès des différents intervenants.

Pour toutes ces raisons, il est primordial de réaliser le projet de développement logiciel dans sa totalité et ce, malgré les imprévus et leur impact sur les coûts et l’échéancier. Dans le style de gestion par « Plan », les coûts et le temps peuvent être variables alors que la finalité du projet est immuable.

L’évaluation de la performance en développement logiciel

En gestion par « Plan », l’évaluation de la performance de l’équipe de développement logiciel se fera sur la base de l’atteinte des objectifs de coûts, de temps et d’échéancier, la portée (le livrable) quant à elle étant fixe. Oui, les coûts et le temps sont variables mais combien près des estimations initiales l’équipe a-t-elle été en mesure de livrer ? Telle est la question. Bien sûr, on dira que l’estimation initiale était fausse mais cela sera le sujet d’un prochain billet…

Quant à l’évaluation du projet, elle se fera sur la base de l’impact de l’application (les bénéfices) sur les différents départements impliqués, une fois le projet complété.

Dans le cadre d’un projet de moindre envergure ou encore au sein d’une PME, il serait plus avisé, considérant les restrictions imposées en termes de ressources et de coûts, d’opter pour une gestion selon la méthodologie Agile et de considérer comme priorité la valeur apportée par le projet, les retombées en termes de bénéfices pour l’entreprise.

Typiquement, dans le cadre d’un projet de développement Agile, toutes les fonctionnalités de l’application à développer sont évaluées en termes de valeur (bénéfice) apportée à l’entreprise selon différentes hiérarchies; par exemple, fonctionnalité critique, importante, utile, souhaitée, optionnelle, etc.

Ainsi, le projet auquel on attribue une enveloppe budgétaire fixe et un échéancier de production déterminée s’entame avec le développement des fonctions jugées critiques et importantes en priorité. Le projet de développement Agile est piloté par la Valeur et non le Plan.

En gestion par « Valeur », l’évaluation de la performance de l’équipe de développement logiciel se fera sur la base du nombre de fonctionnalités livrées dans le temps et le budget alloués qui sont fixes.  Quant à l’évaluation du projet de développement, elle se fera sur la base des bénéfices obtenus (augmentation de la productivité, accès à l’intelligence d’affaires, réduction des coûts, etc.) grâce aux fonctionnalités livrées. À titre de référence, soulignons que les deux types de gestion appellent des outils de gestion de projet différents.

Par exemple, dans l’environnement Microsoft, le gestionnaire de projet par Plan s’appuiera sur un outil tel que Microsoft Project qui met l’emphase sur les tâches restantes à accomplir alors que le gestionnaire de projet par Valeur utilisera un outil tel que TFS (Team Foundation Server) qui met l’emphase sur les heures restantes à accomplir.

Conclusion

La perception de la performance d’une équipe de développement logiciel est vraiment tributaire du style de gestion du Directeur de Projet, du Directeur de Département ou encore de la Direction; le fait est que le style de gestion dicte des priorités différentes, ce qui orientera l’évaluation de la performance et donc, le choix des indicateurs de performance.

Au final, allez-vous évaluer les coûts et le temps requis pour livrer le projet informatique dans sa totalité, l’impact du projet final une fois complété ou encore la qualité de la valeur (les bénéfices) apportée à l’entreprise dans le temps alloué ?

Peut-être l’idéal serait de toujours être agile localement (dans l’exécution) sans jamais perdre de vue le plan, quel que soit le type d’entreprise ou l’envergure du projet de développement logiciel !

 

Bon projet de développement,

 

Michel et Denis Paul

Laisser un commentaire

Votre adresse de courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *