Dans nos précédents articles concernant la performance d’une équipe de développement, nous avons abordé l’alignement, la qualité et la productivité.

Aujourd’hui, parlons de l’évolutivité. Derrière le terme d’évolutivité, nous trouvons en particulier la capacité à minimiser la dette embarquée dans vos applications. Effectivement, plus vous minimiserez celle-ci, plus vous pourrez évoluer rapidement et avec des contraintes minimales.

La dette applicative est une notion qui devient de plus en plus populaire auprès des analystes. Celle que l’institut Gartner a ainsi désignée puis évaluée à près de à 1,000 milliards de $ est une notion bien présente sur le terrain et visible de quiconque dans le monde applicatif.

Pendant longtemps, les départements informatiques ont présenté à leur management le coût des applications développées sans réellement mesurer les coûts induits pour le futur.

Et pourtant, dès que vous développez et déployez une application, vous générez des coûts de maintenance qui dureront aussi longtemps que l’application elle-même. Ces coûts ne disparaitront qu’au remplacement de l’application.

L’expérience montre que les applications durent toujours plus longtemps que prévu. Même quand vous pensez qu’il s’agit d’une solution temporaire, un changement d’orientation ou des restrictions budgétaires peuvent impacter le timing de la nouvelle version. Des problèmes apparaissent aussi souvent dans tout projet logiciel et les retards de livraison sont la règle dans ce domaine, sans parler d’échec de certains projets en particulier dans le cas de rupture technologique.

Dans tout projet logiciel, des problèmes apparaissent au fil du temps et les retards de livraison sont la règle dans ce domaine, sans parler des échecs complets de certains projets, en particulier dans le cas d’une rupture technologique.

Par conséquent, livrer une application qui fonctionnera avec un effort de maintenance minimal est, en fait, l’un des éléments les plus importants pour mesurer la performance d’une équipe de développement logiciel.

La dette applicative est généralement difficile à mesurer dans la mesure où la majorité des coûts cachés ne sont pas dans la maintenance corrective pure. Bien sûr, quand une application est vraiment boguée les gens prennent conscience du problème et réagissent.

Mais dans la plupart des cas une partie non négligeable de la dette réelle se cache dans une mauvaise conception qui se traduit par une évolution démesurée des coûts de maintenance, le problème grandissant au fil du temps jusqu’à devenir démesuré.

Si votre évolution des coûts ressemble à la courbe ‘non industrielle’ ci-après, il est temps de penser à une réelle modernisation de votre application :

De notre point de vue, il y a 2 types de systèmes :

1. Ceux qui sont très stables fonctionnellement. Dans ces scénarios, même si une évolution individuelle s’avère couteuse, c’est probablement une bonne chose de les maintenir sur le long terme, bien que la technologie soit très ancienne. On lance souvent des projets au prétexte que la technologie n’est plus supportée par l’éditeur, mais ce n’est pas un argument si important lorsque votre système a fonctionné pendant des décennies. Le risque est minime avec un tel historique.
2. Ceux qui évoluent beaucoup parce que l’entreprise exige des ajustements de l’application relativement souvent. Dans ces situations, si vous avez basculé dans un scénario de dette lourde, il est toujours temps de parier sur une nouvelle conception pour résoudre le problème. Le plus délicat est que vous devrez probablement le faire par ‘morceaux’ pour sécuriser le succès du projet car les projets ‘big bang’ mènent souvent à des échecs majeurs. Rajeunir le code, réduire la taille de la base et l’aligner avec une technologie plus récente vous fera économiser de l’argent relativement rapidement. Encore faut-il le faire correctement, avec l’approche appropriée, les bonnes personnes et un outillage efficace.

L’effet de levier de la dette applicative

Dans la mesure où votre application évolue, l’héritage que vous avez développé grossit en maintenance et une sur-complexité impacterait l’évolution des coûts.

Prenons un scénario typique d’une application qui a un cycle de vie de 10 ans. Le tableau suivant décrit un ‘scénario nominal’ avec un développement initial de 100 et des évolutions au cours des années suivantes. La maintenance est calculée sur la base de 15% du temps passé cumulé.

Maintenant, imaginons une équipe qui n’est pas complètement optimale mais qui ajoute un peu de sur-complexité avec un facteur de 20% par an, ce qui n’est pas outrageux. Là encore, nous estimons que la complexité se démultiplie au fil des années et accroît le coût des évolutions par une approche cumulative. Nous calculons là encore la maintenance avec 15 % du temps passé.

Le coût cumulé du projet a doublé à la fin et, fait notable, le coût de l’évolution de l’année 10 est 6 fois supérieur à ce qu’il serait sans le fardeau de cet héritage trop complexe !

Une autre observation qui peut être intéressante est de comprendre ce qui se passe quand le projet démarre mal. Avec un facteur de dérive de complexité de 30% au début, même si vous réagissez et que vous baissez progressivement le facteur de 1,3 à 1 au fil des années, vous n’allez jamais réduire votre coût de maintenance suffisamment pour être aligné avec les équipes ci-dessus.

C’est pourquoi, comme nous l’avons expliqué dans l’article sur la productivité, il est également très important d’être capable d’estimer la taille réelle et la complexité de votre projet. C’est une façon de s’assurer de ne développer que le minimum nécessaire dans la mesure où chaque ligne de code superflue sera très couteuse tout au long du cycle de vie de l’application.

De nos observations sur le terrain, nous sommes toujours très surpris quand les gens ne connaissent pas les métriques simples comme :

• Nombre d’entités du métier ou tables,
• Nombre d’écrans ou de pages,
• Nombre de rapports,
• Nombre de lignes de code.

Une chose est sûre, il faut être en mesure d’évaluer le coût sur la base de ces éléments factuels (ou encore mieux, avec des détails comme les règles métier, les propriétés des données, les champs de l’interface utilisateur… ) à la fois pour la production du logiciel mais aussi pour évaluer la maintenance et la mise en œuvre des évolutions.

Si le seul critère que vous avez pour connaitre l’impact d’une demande de fonctionnalité est le temps estimé par vos développeurs, il se peut que vous soyez en difficulté dans la mesure où vous n’avez aucun moyen de contester. Et l’expérience montre un degré très élevé de variabilité entre les compétences des développeurs.

Comme toujours, n’hésitez pas à commenter et à partager vos propres expériences.

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