Comment mesurer la valeur potentielle du refactoring
Sur un projet ancien et volumineux avec une dette technique, comment pouvez-vous estimer ou mesurer de manière fiable l'avantage du refactoring de code?
Par exemple, supposons que certains composants d'une solution de pile logicielle soient écrits dans une langue plus ancienne et que certains composants ultérieurs soient écrits dans une langue plus récente. 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". Cependant, aucune fonctionnalité supplémentaire ne serait ajoutée par ce travail et cela coûtera x jours de développement.
Un vendeur suggère d'ajouter "une nouvelle fonctionnalité intéressante". l'entreprise mesure la valeur de sa suggestion en utilisant une formule. c'est à dire. Il gagnera à la société F millions de livres, sur t années, au coût de x jours de travail
Comment l'entreprise peut-elle chiffrer la proposition de refactorisation de manière significative? et dans quelles circonstances est-elle susceptible d'être l'option la plus rentable pour l'entreprise?
Il gagnera à la société F millions de livres, sur t années, au coût de x jours de travail
Ce qui ignore les coûts de maintenance, les coûts de support, le coût des ventes/marketing et fait beaucoup d'hypothèses sur la façon dont la fonctionnalité sera prise sur le marché.
Mais peu importe; votre question est suffisamment claire sur ce que vous recherchez:
Comment puis-je faire une analyse de rentabilisation 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 $/h -> 20 000 $" et cela a du sens pour les gens d'affaires. Les gens d'affaires intelligents noteront que ces 5 développeurs sont payés de toute façon, ce qui vous permet de ne pas dépenser/économiser les 20 000 $ - il utilise les 20 000 $ de la manière la plus rentable. Quoi qu'il en soit, avec la liste.
- Efficacité - Vraisemblablement, vous pouvez faire plus de choses avec C # qu'avec VB6. Un meilleur outillage, de meilleures bibliothèques, peu importe. Les nouvelles technologies ont tendance à être meilleures que les anciennes. Si vous pouvez faire des choses en moins de temps, cela signifie que vous économisez de l'argent à l'entreprise.
- Overhead - Le codage n'est pas le seul coût du logiciel. Considérez ce qui se passe lorsque Windows 2020 sort. Combien de temps et d'efforts allez-vous consacrer à l'application de cette application VB6? Combien de temps et d'efforts cela représente-t-il plus qu'une application C #? C'est économiser de l'argent pour votre entreprise.
- Qualité - Vraisemblablement, vous pouvez faire des choses avec une meilleure qualité en C # que VB6 (ou avec une architecture plus propre, ou quoi que ce soit votre objectif de refactoring). Une qualité supérieure signifie moins de bugs. Moins de bogues signifie moins de coûts pour corriger ces bogues, moins de coûts de support client pour résoudre ces problèmes, moins de pertes de clients en raison de problèmes de qualité, une augmentation des ventes en raison d'une réputation de qualité ... tous les dollars pour votre entreprise.
- HR Savings - Avouons-le: personne ne veut travailler avec cette application VB6 merdique. Cela signifie que plus de personnes quitteront l'entreprise, ce qui entraînera du temps et de l'argent dépensés pour les remplacer. Cela signifie qu'il faut plus de temps et d'argent pour embaucher de nouveaux employés. Le pire de tout, cela signifie que vous aurez des développeurs qui commettent très bien un suicide professionnel en travaillant avec cette application VB6. Ces développeurs accélèrent à leur tour la spirale mortelle des problèmes de qualité. La réduction du chiffre d'affaires et des temps d'embauche permet à votre entreprise d'économiser de l'argent. Garder les développeurs complaisants et merdiques à l'écart sauve votre entreprise.
- Moral - De même, les programmeurs qui sont déjà là détestent travailler en VB6. Ils le feront, et ils pourraient même bien le faire. Mais ça craint. Peut-être pas pour tout le monde, mais certainement pour certains. Cela signifie plus de temps passé à naviguer sur le Web pour récupérer la motivation. Cela signifie des déjeuners plus longs. Cela signifie moins de choses à faire pendant que vos programmeurs mettent plus de temps à se remettre du travail.
- Capacité - Ceci est moins applicable avec les refacteurs axés sur la technologie, mais s'applique au type d'architecture des refactors. Certains problèmes de code vous empêchent activement de fournir une fonctionnalité intéressante X pour gagner des tonnes d'argent. Peut-être que vous ne pouvez pas évoluer. Peut-être que vous ne pouvez pas accéder aux 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 tout droit vers ce point. C'est difficile à traduire en termes commerciaux, mais si vous le pouvez, "ce problème nous empêche de profiter des opportunités X, Y et Z" peut être puissant.
Dans l'ensemble, cela revient à "ces choses nous aideront à mieux faire notre travail; si nous faisons mieux notre travail, nous pouvons vous faire/économiser plus d'argent".
La question que vous devez vous poser est de savoir comment le vendeur sait que la fonctionnalité coûtera x développeur-jours de travail. Étant donné que même de 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 suppose que c'est trop pour la direction ou client: si la direction est prête à payer 50 semaines-homme de travail, mais rejettera absolument 75 semaines-homme, disons que la fonctionnalité prendra 70 semaines-homme tout en étant prêt à renégocier (ce qui est hors de question pour une estimation réelle ) jusqu'à 55 semaines-homme.
D'une part, vous avez des estimations faites par des experts informatiques qui disent quelque chose comme:
Selon cet audit spécifique, nous gaspillons 8 000 $ 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, aucune nouvelle fonctionnalité ne sera disponible. Il existe également un risque de 10% que la migration d'un composant spécifique puisse entraîner 20 à 30 semaines de travail supplémentaires.
D'autre part, vous avez suppositions faites par les 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 ici, et c'est là que les vendeurs gagnent généralement les professionnels de l'informatique lorsqu'il s'agit d'expliquer les avantages d'une fonctionnalité à la direction (ou à un client).
Notez que si dans le passé, vos estimations étaient assez précises, vous gagnez en notoriété et en influence. Si vos estimations étaient toujours erronées, la direction ignorerait probablement vos propositions.
Quant aux estimations, il est extrêmement difficile d'en faire une précieuse ici, car il y a un grand nombre de paramètres à prendre en compte. Entre autres:
Savez-vous réellement à quel point votre équipe est compétente en C # par rapport à VB6? Est-ce basé sur des mesures réelles ou sur 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, signifie des milliers de dollars par machine)?
Le projet actuel est-il totalement clair et vous pouvez garantir qu'il n'y aura pas de surprise 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 #? Et l'intégration continue? Et votre serveur de build? Guides de style? Contrôleurs statiques?
En production, les serveurs (s'il s'agit d'une application Web) ou les PC 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 voulez-vous 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 perdez, disons, 8 000 $ par jour à cause de VB6 (ce qui signifie que vous économiserez 8 000 $ par jour une fois que vous aurez migré vers C #), comment expliquez-vous les avantages de chaque développement de nouvelles fonctionnalités et en se concentrant sur une réécriture complète? Quel est l'avantage par rapport à réécriture progressive où vous migrez vos composants en 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 refacturation comme vous le feriez pour la demande de fonctionnalité axée sur les ventes.
Cela peut être difficile à obtenir si c'est un gros travail, mais, en supposant que vous avez suffisamment de personnes expérimentées dans les 2 technologies, cela devrait être faisable.
Deuxièmement, vous avez besoin d'une estimation du coût de la non-refacturation. Si vous faisiez les estimations pour moi, je m'attendrais à un certain niveau de métriques. Par exemple, la différence entre le coût moyen de développement pour VB et pour le code C # sur un quart. Ou certains autres. Cela dépendra évidemment de la précision avec laquelle vous effectuez le suivi.
Avec ces 2 chiffres, vous pouvez estimer la période de récupération que la refacturation vous donnera, c'est-à-dire à quel moment la refacturation 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 pourriez bien avoir du mal.
De plus, cela vaut probablement la peine d'ajouter d'autres dimensions pour vous aider à construire votre coque. L'une que j'ai utilisée dans le passé est de voir si des entretiens de sortie ont cité la technologie comme un moteur. Dans l'affirmative, vous pouvez faire valoir que la refacturation conservera le personnel (l'embauche et la formation étant très coûteuses).
De toute évidence, vous pouvez discuter de ces choses sans preuves à l'appui, mais je trouve que cela peut faire une énorme différence dans l'impact de l'affaire.
Je pense que le point que les autres réponses manquent est que vous devez mesurer le coût de la refactorisation par rapport aux pertes de revenus liées à la non-refactorisation.
La refactorisation pour changer le 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 à problème, mais au refactoring majeur tel que le passage à un autre langage CLR comme vous l'avez utilisé dans votre exemple.
Si nous continuons à faire ce que nous faisons, manquons-nous quelque chose? Existe-t-il un vieux design cruel qui nous empêche de réaliser de la valeur? Par exemple, si nous voulons ajouter une fonctionnalité, est-ce si difficile que cela pourrait prendre par exemple 100 heures pour mettre en œuvre, contre 50 heures pour refactoriser et 25 heures pour mettre en œuvre contre la nouvelle conception?
Le code existant comporte-t-il une dette technique cela nous coûte-t-il de l'argent? Cet ancien code merdique est-il la source de bogues? Finissons-nous 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 le coût en ayant une petite équipe de rockstars refactoriser le code causant le plus de problèmes? Pouvons-nous répartir le refactoriseur entre les versions? Il y a de petites inefficacités partout: peut-on "combler les lacunes" pour ainsi dire avec ce travail supplémentaire?
La valeur du refactoring se présente de plusieurs manières différentes.
Il vous aide à apporter d'autres modifications plus tard, de sorte que les X jours que cette fonctionnalité aurait pris prendraient désormais 2/3X jours. Pour utiliser la terminologie agile, cela augmente la vitesse.
La modification explicite répertoriée aiderait au fil du temps car vous n'auriez plus besoin de maintenir les développeurs avec une expérience VB6, seulement ceux avec une expérience C #.
Cela aide également d'autres façons moins tangibles, comme la rétention du personnel et le recrutement. Un travail en C # et VB6 serait-il plus ou moins attrayant qu'un travail en C #? Seriez-vous plus ou moins susceptible de prendre un emploi ou de rester à un emploi travaillant sur une base de code de Nice ou moche?
Avantages d'avoir un système refactorisé
Vous faites une analyse de rentabilisation pour la refactorisation en comparant les avantages commerciaux de base entre le faire et ne pas le faire. Cela signifie soit une réduction des coûts réels actuels, soit une augmentation des entrées de trésorerie réelles futures.
Les éléments budgétaires clés affectés par le refactoring sont les suivants:
- Coûts de maintenance - si le système actuel est une pile fragile de spaghettis, et il est observable dans la pratique que la correction de petits bugs (à la fois en cours de développement et d'exploitation) prend une grande quantité d'heures-homme, alors on pourrait s'attendre à ce que les coûts de tels la maintenance sera moindre pour un système "correctement repensé". Jetez un œil à vos coûts annuels de maintenance pure et comment ils pourraient changer de façon réaliste après la réécriture.
Coût de l'ajout de nouvelles fonctionnalités - encore une fois, si la conception et la structure actuelles du système nécessitent trop de temps pour écrire de nouvelles fonctionnalités, une réécriture peut permettre des économies. Jetez un coup d'œil à votre budget prévu pour les nouvelles fonctionnalités, mais soyez réaliste - si vous prétendez que vous verrez une amélioration de 50%, alors attendez-vous à développer réellement des fonctionnalités en x mois-homme qui auparavant ont pris 2 * x mois-homme pour se réaliser; ces promesses peuvent être difficiles à tenir.
Impact sur la qualité des logiciels sur les ventes - si le système actuel cause fréquemment des problèmes visibles par le client, par exemple plantages ou temps d'arrêt malgré un effort de maintenance adéquat, une réécriture peut être une solution. SI 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 encore; le coût d'opportunité de passer x jours-dev sur des non-fonctionnalités est égal à la valeur de ces fonctionnalités, qui est supérieure au coût pur du x dev -days) alors je crains que ce soit tout - les économies attendues ne justifient pas la réécriture.
De plus, si votre feuille de route ne montre pas le besoin de "autant que vous pouvez fournir" de nouvelles fonctionnalités, alors les économies devraient être sous une forme "il fallait 10 personnes pour faire tout le nécessaire, mais après la réécriture, nous pourrons faire de même avec seulement 6 personnes '. Si vous pouvez "vendre" plus de projets de développement que vous n'en avez de développeurs, alors l'amélioration de l'efficacité vous permet de développer plus de choses, mais si l'entreprise avec les ressources actuelles est déjà en mesure de développer toutes les choses qui apportent une valeur supplémentaire, alors le seul avantage financier peut venir de payer moins de personnes ou d'avoir des gens moins chers.
La valeur du refactoring peut être mesurée comme suit: actuellement, la nouvelle fonctionnalité x coûtera 5 devs 2 semaines. Si nous remanions l'ancien composant, le coût des nouvelles fonctionnalités sera réduit d'environ 20%. Ainsi, la nouvelle fonctionnalité x ne coûtera que 4 devs sur 2 semaines.
Le refactoring est un investissement pour réduire le coût des développements futurs. Si vous ne pouvez pas faire valoir cet argument pour votre refactoring, il n'y a probablement pas d'argument commercial pour cela.