Dans nos derniers articles concernant la performance d’une équipe de développement, nous avons développé l’alignement et la qualité.

Aujourd’hui nous abordons la dimension de la productivité.

Pourtant, et bien que le développement logiciel ne soit pas une nouvelle discipline, il n’existe pas de méthodologie universellement reconnue pour mesurer la productivité d’une équipe de développement. La première question à se poser est la suivante : “Pourquoi en est-il ainsi ?”

Premièrement, par définition, chaque développement logiciel est unique. Vous n’avez pas besoin de réaliser deux fois le même logiciel dans la mesure où vous pouvez le reproduire indéfiniment en la copiant. Cela rend réellement impossible la comparaison formelle et rigoureuse entre deux logiciels.

Deuxièmement, le rythme de l’évolution technologique est particulièrement rapide. Par conséquent, chaque fois qu’une méthodologie relative à une certaine vague technologique est suffisamment éprouvée, elle s’avère généralement déjà obsolète.

Troisièmement, la part de créativité dans la recherche de solutions à un problème unique est assez importante. Il est donc difficile d’avoir un repère unique. Certaines approches, comme la mesure du résultat en termes de “lignes de code” par exemple, permettent de mesurer la taille de la solution, mais finalement pas la taille du problème. Et parmi les solutions à un problème, la solution la plus légère est en général la plus précieuse, pas seulement, parce qu’il est vraisemblable qu’elle soit moins chère à produire (encore que parfois, il se peut qu’il soit plus long d’écrire un texte synthétique qu’un texte plus long), mais surtout parce qu’elle coûte moins à maintenir (en principe car à l’inverse, une solution trop dense ou trop abstraite peut être non maintenable).

Ces dernières parenthèses illustrent bien la difficulté du problème. Pour autant, devons-nous abandonner l’idée de mesurer la productivité du développement logiciel ?

Ce n’est pas notre opinion chez SoftFluent. Commençons par observer différentes approches pratiquées pour relever ce défi.

Méthodologies agiles

C’est sans aucun doute la tendance majeure du moment dans les méthodes de développement logiciel et c’est une méthode à laquelle nous croyons. La mise en avant des méthodologies agiles est souvent liée à la sécurisation d’un processus collaboratif entre la gestion du produit et des développeurs. En ce sens, cette approche relève assez bien le défi d’alignement dont nous avons parlé dans notre précédent billet. Mais comment traitent t’elles de la productivité ?

Sur ce sujet, la pratique courante est d’évaluer la tâche de développement en utilisant des niveaux de complexité et des “ points ”. En fonction du niveau de complexité, une formule non-linéaire donne le temps de développement.

Dans de nombreuses méthodologies agiles, l’évaluation utilise les suites de Fibonacci pour déterminer le temps de développement en fonction de la complexité. La suite de Fibonacci présente la propriété que chaque nombre des séries est la somme des 2 nombres précédents ce qui donne par exemple le tableau suivant :

 

Lorsque l’on gère la liste des fonctionnalités à réaliser, elles sont évaluées en complexité et traduites en points. La mesure classique utilisée en méthodologies agiles met en avant la vitesse représentée par le nombre de points par itération, selon le schéma ci-dessous.

Cette approche fonctionne assez bien pour évaluer la relative efficacité d’une équipe donnée au fil du temps. Mais la principale faiblesse est qu’elle ne donne qu’une mesure relative. Les points sont définis par l’équipe de développement et ne peuvent être comparés à d’autres développements sur le marché. Elle ne vous permet pas de positionner votre équipe de développement relativement à l’état de l’art du marché.

Analyse des points de fonction

L’analyse des points de fonction est une méthode d’évaluation qui relève le défi en définissant de manière “absolue” ce qui doit être produit en termes de complexité

En utilisant des catégories telles que :

• Requêtes externes
• Interfaces externes
• Fichiers logiques internes
• Entrées externes
• Sorties externes

Il convient de décrire de manière détaillée les fonctionnalités les différentes fonctionnalités du logiciel dans chaque domaine.

En utilisant ensuite des matrices de complexité, sur lesquelles on peut positionner les différentes fonctionnalités, la méthode propose des barèmes pour calculer les points de fonction pour chaque fonctionnalité et pour le projet.

Pour en savoir plus, nous recommandons ce document Analyse des points de fonction de Software Metrics, une société spécialisée dans ce domaine.

Cette approche fonctionne relativement bien dans un contexte de méthodologie traditionnelle en cascade avec une phase de conception significative et permet ainsi de mesurer la complexité d’un développement et faire de réelles comparaisons d’un projet à un autre.

Les principales faiblesses de cette méthode sont les suivantes :

• Elle requiert un investissement significatif en compétences pour vraiment maîtriser l’approche et obtenir les résultats et mesures escomptés,
• Elle requiert un processus rigoureux et complet dans la description du logiciel, un effort que nous voyons de moins en moins sur le terrain dans la mesure où les gens se sont tournés vers les méthodologies agiles avec des projets souvent inscrits dans des calendriers contraints.

Notre approche pour les logiciels d’entreprise

De notre point de vue, obtenir une mesure ‘absolue’ du logiciel produit par votre équipe pour un budget donné demeure un sujet important.

Et comme nous comprenons les défis mentionnés ci-dessus, nous avons ajusté notre méthodologie simplifiée pour mesurer la taille d’un projet de développement logiciel, en particulier dans le domaine des ‘applications métier’.

Lorsque nous parlons d’applications métier, nous considérons tout type d’applications qui manipulent des données structurées, qu’il s’agisse d’applications internes centrées sur un axe ou un secteur vertical, de logiciels de gestion de la relation client, de sites web e-commerce complexes ou extranet, etc…

De par notre expérience, il nous apparait que la taille et la complexité des projets est fonction d’un nombre relativement réduit de paramètres, comparables d’un projet à un autre, indépendamment du secteur ou du domaine.

Chaque application possède certes des spécificités qui lui sont propres (complexité de workflow, connexions externes spécifiques, interfaces utilisateur dynamiques, calculs personnalisés avancés ou multi-tenant pour les applications SaaS) mais nous observons que l’impact en termes de coût de développement est relativement constant d’un projet à l’autre.

Et si vous combinez plusieurs facteurs de complexité, vous pouvez également trouver des ratios qui vous aident à faire face à cette complexité et vous devriez dans tous les cas être en mesure d’évaluer un projet sur la base des éléments suivants :

• Nombre d’entités métier,
• Nombre de règles métier simples (au sein d’une entité),
• Nombre de règles métier avancées (combinant plusieurs entités par exemple),
• Nombre d’éléments pour l’interface utilisateur (écrans, pages web),
• Nombre de rapports (ou états),
• Nombre d’interfaces externes,
• Nombre de calculs ou processus de traitements par lots,
• Nombre de variations technologiques de chaque composant (client -riche, page web, version mobile, technologies de base de données, utilisation d’un stockage “cloud&rdquo ;).

Dans les projets qui utilisent notre fabrique logicielle CodeModeler, nous avons constaté sur le terrain qu’un projet ne devrait jamais coûter plus que :

• 4 000 Euros par entité si c’est une application d’entreprise,
• 6 000 Euros par entité si c’est un produit packagé sous forme de produit multi-clients paramétrable (type progiciel)

Cela donne un moyen très simple de détecter d’éventuels problèmes de productivité lors d’audit de projets en condition réelle avec un peu d’historique et d’héritage. Nous comparons également cette information avec le nombre total de lignes de code pour l’application. Notre expérience nous donne des ratios relativement constants corrélant le nombre d’entités avec le nombre de lignes de code dans des langages tels C# ou VB, si l’application est correctement écrite.

Nous avons également constaté que CodeFluent Entities réduisait le nombre de lignes de code écrites manuellement par un facteur de 2 avec un lien direct sur l’effort de maintenance.

Et bien sûr, la bonne nouvelle quand vous utilisez l’outil est que vous obtenez des métriques sur tous les paramètres mentionnés ci-dessus alors que nous voyons encore beaucoup de clients ‘aveugles’ sur le terrain, incapables de maitriser ces paramètres clés pour connaitre sa productivité.

Qu’en est-il de votre propre expérience ?

Nous sommes très à l’écoute de vos propres expériences, dans la mesure où c’est un sujet très chaud qui manque cruellement d’une solution reconnue.

Lire la suite : Mesurer la performance d’une équipe de développement – Partie 4