Comment mesurer la valeur potentielle de la refactorisation

Sur un vieux projet volumineux avec une dette technique, comment pouvez-vous estimer ou mesurer de manière fiable les avantages du code de refactoring?

Par exemple, supposons que certains composants d'une solution de pile logicielle soient écrits dans un langage ancien et que certains composants ultérieurs soient écrits dans un langage plus récent. De nouvelles fonctionnalités et corrections de bugs sont constamment ajoutées à cette solution par une équipe de développement.

Les développeurs suggèrent que le remplacement des anciens composants de langage existants par la nouvelle version serait «une bonne chose». Toutefois, aucune fonction supplémentaire ne serait ajoutée par ce travail et cela coûterait x jours de développement.

Un représentant des ventes suggère d’ajouter «une excellente nouvelle fonctionnalité». la société mesure la valeur de sa suggestion en utilisant une formule. c'est à dire. Il rapportera à la société un million de livres sterling, sur t années, pour un coût de x jours de développement

Comment l'entreprise peut-elle chiffrer la proposition de refactoring de manière significative? et dans quelles circonstances est-il susceptible d'être l'option la plus rentable pour l'entreprise?

Il rapportera à la société un million de livres sterling, sur t années, pour un coût de x jours de développement

Ce qui ne tient pas compte des coûts de maintenance, des coûts de support, du coût des ventes / du marketing et repose sur de nombreuses hypothèses quant à la manière dont la fonctionnalité sera utilisée sur le marché.

Mais peu importe; votre question est assez claire sur ce que vous recherchez:

Comment puis-je faire une analyse de rentabilité pour la refactorisation?

La principale chose à réaliser est que le temps est égal à l'argent. Vous pouvez aller directement à "5 développeurs 2 semaines = 80 heures * 5 développeurs * 50 $ / heure -> 20 000 $" et cela a du sens pour les gens d'affaires. Les hommes d’affaires avisés noteront que ces 5 développeurs sont rémunérés dans un sens ou l’autre, ce qui signifie qu’ils ne dépensent pas et n’économisent pas les 20 000 dollars - ils utilisent les 20 000 dollars de la manière la plus rentable. Quoi qu'il en soit, avec la liste.

• Efficacité - Vous pouvez sans doute faire plus de choses avec C # qu'avec VB6. Un meilleur outillage, de meilleures bibliothèques, peu importe. Les nouvelles technologies ont tendance à être plus efficaces que les anciennes. Si vous pouvez faire des choses en moins de temps, cela signifie que vous économisez de l'argent.
• Frais généraux - Le codage n'est pas le seul coût du logiciel. Considérez ce qui se passe lorsque Windows 2020 est disponible. Combien de temps et d'efforts allez-vous consacrer à l'application de l'application VB6? Combien de temps et d'efforts cela représente-t-il par rapport à une application C #? C'est économiser votre argent d'entreprise.
• Qualité - Vraisemblablement, vous pouvez réaliser des tâches avec une meilleure qualité en C # que VB6 (ou avec une architecture plus propre, ou tout ce que votre cible de refactoring est). Une qualité supérieure signifie moins de bugs. Moins de bogues signifie moins de coûts pour réparer ces bogues, moins de coûts de support client pour résoudre ces problèmes, moins de pertes de clients dues à des problèmes de qualité, une augmentation des ventes due à une réputation de qualité ... autant en dollars pour votre entreprise.
• Économies de personnel - Voyons les choses en face: personne ne veut travailler avec cette application VB6 de merde. Cela signifie que plus de personnes quitteront l'entreprise, ce qui nécessitera du temps et de l'argent pour les remplacer. Cela signifie qu'il faut plus de temps et d'argent pour embaucher de nouveaux employés. Pire encore, cela signifie que les développeurs qui se suicideront en carrière travailleront parfaitement avec cette application VB6. Ces développeurs à leur tour précipitent la spirale de la mort des problèmes de qualité. Réduire le chiffre d'affaires et les délais d'embauche permet à votre entreprise d'économiser de l'argent. Garder les développeurs complaisants et misérables à l’écart sauve votre entreprise.
• Moral - De même, les programmeurs déjà présents détestent travailler dans VB6. Ils le feront, et ils pourraient même le faire bien. Mais ça craint. Peut-être pas pour tout le monde, mais certainement pour certains. Cela signifie plus de temps consacré à la navigation sur le Web pour retrouver sa motivation. Cela signifie des repas plus longs. Cela signifie moins de choses à faire pendant que vos programmeurs mettent plus de temps à récupérer du travail fastidieux.
• Capacité - Ceci est moins applicable avec les refacteurs basés sur la technologie, mais s'applique au type de refacteurs d'architecture. Certains problèmes de code vous empêchent activement de fournir la fonctionnalité X intéressante pour gagner beaucoup d'argent. Peut-être que vous ne pouvez pas évoluer. Peut-être que vous ne pouvez pas obtenir les données pour faire de l'informatique cool. Peut-être que le code est un tel nid de rat qu'il est extrêmement difficile de faire le travail. Peu importe. Parfois, vous êtes à ce point, parfois vous conduisez directement vers ce point. Il est difficile de traduire en termes commerciaux, mais si vous le pouvez, "ce problème nous empêche de tirer parti des opportunités X, Y et Z" peut être puissant.

En résumé, cela revient à "cela nous aidera à mieux faire notre travail; si nous le faisons mieux, nous pourrons vous faire / économiser plus d’argent".

La question que vous devriez vous poser est la suivante: comment le vendeur sait-il que la fonctionnalité coûtera x jours-développeur de travail? Etant donné que même les bons chefs de projet avec des années d'expérience professionnelle ne peuvent pas souvent le dire, de telles données provenant d'un vendeur semblent extrêmement ... spéculatives .

Selon mon expérience, les vendeurs ne font généralement pas d’estimations, mais se demandent si c’est trop, tant pour la direction que pour le client: si la direction est prête à payer 50 hommes-semaines de travail, mais qu’elle rejettera absolument 75 hommes-semaines, disons que la fonctionnalité prenne 70 jours-homme tout en étant prête à renégocier (chose qui est hors de question pour une estimation réelle) jusqu'à 55 jours-homme.

• D'une part, vous avez des estimations faites par des experts en informatique qui disent quelque chose comme:

  Selon cet audit spécifique, nous gaspillons 8 000 dollars par jour en utilisant une technologie obsolète par rapport à des projets similaires de taille similaire qui utilisent des technologies plus récentes. Il semble également qu'il faudra entre 50 et 80 semaines-homme pour migrer l'ensemble de la base de code; pendant ce temps, il n'y aurait pas de nouvelles fonctionnalités publiées. Il existe également un risque de 10% que la migration d'un composant spécifique entraîne 20 à 30 semaines de travail supplémentaires.

• D'autre part, vous avez des suppositions faites par des vendeurs, en fonction de leur influence lors de la négociation avec la personne dont ils ont besoin pour convaincre.

Tout dépend de votre influence sur votre entreprise. La communication est essentielle, et c’est là que les vendeurs séduisent généralement les professionnels de l’informatique quand il s’agit d’expliquer les avantages d’une fonctionnalité à la direction (ou à un client).

Notez que si par le passé, vos estimations étaient assez précises, vous gagnez en réputation et en influence. Si vos estimations étaient toujours fausses, la direction ignorerait probablement vos propositions.

En ce qui concerne les estimations, il est extrêmement difficile d’en faire une analyse utile car il existe un grand nombre de paramètres à prendre en compte. Entre autres:

• Savez-vous réellement à quel point votre équipe en C # est compétente par rapport à VB6? Est-ce basé sur des mesures réelles ou juste des suppositions?

• Cette équipe a-t-elle développé de grands projets en C #? Connaissent-ils les outils à utiliser (IDE, débogueurs, profileurs, etc.)? Avez-vous besoin de licences supplémentaires (ce qui, dans le monde de Microsoft, représente des milliers de dollars par ordinateur)?

• Le projet actuel est-il totalement clair et vous pouvez garantir qu'il n'y aura pas de surprises lors de la migration? Est-il simple de réécrire tout , chaque fonctionnalité, ou y aurait-il des surprises?

• Avez-vous l'infrastructure qui prend en charge C #? Qu'en est-il de l'intégration continue? Qu'en est-il de votre serveur de construction? Guides de style? Dames statiques?

• En production, les serveurs (s’il s’agit d’une application Web) ou les ordinateurs clients (s’il s’agit d’une application de bureau) peuvent-ils exécuter la version du .NET Framework que vous prévoyez d’utiliser?

Mais le plus important est de savoir pourquoi vous voulez tout réécrire. Quel est le problème que vous essayez de résoudre par une réécriture? Une perte de productivité? Comment le mesurez-vous? Comment montrez-vous cette perte de productivité à la direction?

Une fois que vous avez montré que vous perdiez, disons, 8 000 USD par jour à cause de VB6 (ce qui signifie que vous économiserez 8 000 USD par jour une fois que vous aurez migré vers C #), comment expliquez-vous les avantages de la détention de chaque développement de nouvelles fonctionnalités et en se concentrant sur une réécriture complète? Quel est l'avantage par rapport à la réécriture progressive dans laquelle vous migrez vos composants par petits morceaux, un par un, tout en proposant de nouvelles fonctionnalités?

Tout d'abord, vous devez estimer le coût de développement pour la reconfiguration comme pour la demande de fonctionnalité liée aux ventes.

Cela peut être difficile à définir avec précision si le travail est volumineux, mais si vous avez suffisamment de personnel expérimenté dans les deux technologies, cela devrait être faisable.

Deuxièmement, vous avez besoin d’une estimation du coût de la non-refactorisation. Si vous faisiez les estimations pour moi, je m'attendrais à un certain niveau de mesures. Par exemple, la différence entre le coût de développement moyen du code VB et du code C # sur un trimestre. Ou certains tels. Cela dépendra évidemment de votre précision.

Avec ces deux chiffres, vous pouvez estimer la période de retour sur investissement que la refactorisation vous donnera, c'est-à-dire à quel moment la restofactorisation passera d'un coût net à un gain net.

Je ne peux que deviner à quel point un résultat donné serait convaincant. Cependant, si c'est moins d'un an, ce sera probablement assez fort, beaucoup plus que 2 ans, alors vous risquez de vous battre.

En outre, il est probablement utile d’ajouter d’autres dimensions pour vous aider à construire votre cause. L’une des méthodes que j’ai utilisées par le passé consiste à vérifier si des entretiens de fin d’entreprise ont cité la technologie comme moteur. Si tel est le cas, vous pouvez affirmer que la reconfiguration conservera du personnel (embauche et formation coûteuses).

Évidemment, vous pouvez argumenter ces choses sans preuves à l'appui, mais j'estime que cela peut avoir un impact considérable sur l'impact de l'affaire.

La valeur de la refactorisation apparaît de plusieurs manières différentes.

Cela vous aide à apporter d'autres modifications ultérieurement, de sorte que les X jours de cette fonctionnalité prendraient maintenant 2 / 3X jours. Pour utiliser la terminologie agile, il augmente la vitesse.

La modification explicite indiquée au fil du temps vous aiderait dans la mesure où vous n’auriez plus besoin de conserver les développeurs ayant une expérience VB6, mais uniquement ceux ayant une expérience C #.

Cela contribue également à d'autres moyens moins concrets, tels que la fidélisation du personnel et le recrutement. Est-ce qu'un travail en C # et VB6 serait plus ou moins attrayant qu'un travail en C #? Seriez-vous plus ou moins susceptible de décrocher un emploi ou de conserver un emploi en travaillant sur une base de code agréable ou moche?

Je pense que l’autre question qui manque est que vous devez mesurer le coût de la refactorisation par rapport aux pertes de revenus générées par la non-refactorisation.

Refactoriser pour changer de code est une perte de temps. Il doit apporter de la valeur à la table. Dans ce contexte, je ne parle pas de passer une heure à refactoriser une classe de problèmes, mais à procéder à une refactorisation majeure, telle que le passage à un langage CLR différent de celui que vous avez utilisé dans votre exemple.

• Si nous continuons à faire ce que nous faisons, manquons-nous quelque chose? Existe-t-il une vieille conception cruelle qui nous empêche de réaliser de la valeur? Par exemple, si nous souhaitons ajouter une fonctionnalité, est-il si difficile que sa mise en oeuvre prenne par exemple 100 heures, contre 50 heures pour le refactorisation et 25 heures pour la nouvelle conception?

• Le code existant porte-t-il une dette technique qui nous coûte de l’argent? Ce vieux code merdique est-il la source de bugs? Est-ce que nous finissons par travailler gratuitement pour résoudre les problèmes à cause de cela? Personne n'aime donner gratuitement des heures facturables lucratives.

• Le coût de la refactorisation est-il égal ou inférieur au coût de la non-refactorisation?

• Est-il possible d’amortir les coûts en confiant à une petite équipe de rockstars le code qui cause le plus de problèmes? Pouvons-nous répartir le refactor à travers les versions? Il y a des petites inefficacités partout: pouvons-nous "combler les lacunes" pour ainsi dire avec ce travail supplémentaire?

Avantages d'avoir un système refactorisé

Vous effectuez une analyse de rentabilisation en faveur de la refactorisation en comparant les avantages nets de l’activité commerciale entre le fait de ne pas le faire. Cela signifie soit une réduction des coûts réels actuels, soit une augmentation des entrées de fonds réelles futures.

Les principaux postes budgétaires affectés par la refactorisation sont les suivants:

• Coûts de maintenance: si le système actuel est une pile de spaghettis fragile et qu’il est observable dans la pratique que la réparation de petites anomalies (tant dans le développement que dans les opérations) prend une grande quantité d’heures-personnes, on peut s’attendre à ce que les coûts d’une telle la maintenance sera plus petite pour un système "correctement reconçu". Examinez quels sont vos coûts annuels de maintenance pure et comment ils pourraient changer de manière réaliste après la réécriture.

• Coût de l'ajout de nouvelles fonctionnalités - là encore, si la conception et la structure du système actuel rendent l'écriture de nouvelles fonctionnalités trop longue, une réécriture pourrait permettre de réaliser des économies. Examinez votre budget prévu pour les nouvelles fonctionnalités, mais soyez réaliste: si vous déclarez que vous constaterez une amélioration de 50%, attendez-vous à développer réellement des fonctionnalités dans x mois-hommes qui nécessitaient auparavant 2 * x hommes-mois à réaliser; de telles promesses peuvent être difficiles à tenir.

• Impact de la qualité logicielle sur les ventes - si le système actuel cause souvent des problèmes visibles au client, tels que des pannes ou des temps d'arrêt malgré des efforts de maintenance suffisants, la réécriture peut constituer une solution. S'il s'agit d'un problème majeur, les mêmes vendeurs peuvent quantifier la valeur d'une "fonctionnalité" appelée "produit plus stable".

Si les trois points ci-dessus n'atteignent pas le coût escompté de la réécriture (et plus; le coût d'opportunité de x jours de développement consacrés aux non-fonctionnalités est égal à la valeur de ces fonctionnalités, qui est supérieure au coût pur de x dev -days) alors j'ai bien peur que ce soit ça - les économies attendues ne justifient pas la réécriture.

De plus, si votre feuille de route ne montre pas la nécessité de fournir autant de nouvelles fonctionnalités que vous le souhaitez, les économies devraient être sous la forme habituelle. Il fallait auparavant 10 personnes pour faire tout le nécessaire, mais après la réécriture, 'Sera capable de faire la même chose avec seulement 6 personnes' . Si vous pouvez "vendre" plus de projets de développement que de développeurs, l'amélioration de l'efficacité vous permet de développer davantage d'éléments, mais si l'entreprise disposant des ressources actuelles est déjà en mesure de développer tout ce qui apporte de la valeur ajoutée, le seul avantage financier peut venir de payer moins de personnes ou d'avoir des personnes moins chères.

La valeur de la refactorisation peut être mesurée comme suit: la nouvelle fonctionnalité actuelle x coûtera 5 développeurs sur 2 semaines. Si nous restructurons votre ancien composant, le coût des nouvelles fonctionnalités sera réduit d'environ 20%. Donc, la nouvelle fonctionnalité x ne coûtera que 4 développeurs sur 2 semaines.

La refactorisation est un investissement dans la réduction du coût des développements futurs. Si vous ne pouvez pas présenter cet argument pour votre refactoring, il n’ya probablement aucune analyse de rentabilisation à cet égard.