Comment convaincre la direction de faire face à la dette technique?
C'est une question que je me pose souvent lorsque je travaille avec des développeurs. J'ai travaillé dans quatre entreprises jusqu'à présent et j'ai pris conscience d'un manque d'attention à garder le code propre et à gérer la dette technique qui entrave les progrès futurs dans une application logicielle. Par exemple, la première entreprise pour laquelle j'ai travaillé avait écrit une base de données à partir de zéro plutôt que d'utiliser quelque chose comme MySQL et cela a créé un enfer pour l'équipe lors de la refactorisation ou de l'extension de l'application. J'ai toujours essayé d'être honnête et clair avec mon manager quand il discute des projections, mais la direction ne semble pas intéressée à réparer ce qui est déjà là et c'est horrible de voir l'impact que cela a sur le moral de l'équipe.
Que pensez-vous de la meilleure façon de résoudre ce problème? Ce que j'ai vu, ce sont des gens qui font leurs bagages et partent. La société devient alors une porte tournante avec des développeurs qui entrent et sortent et aggravent le code. Comment communiquez-vous cela à la direction pour qu'elle s'intéresse au tri dette technique ?
Lorsque j'ai rencontré mon patron pour en discuter, il a dit que je devrais inclure le refactoring dans toutes mes estimations. Il a dit que ce n'était pas un problème auquel il voulait penser. Au lieu de cela, je devrais le gérer.
Ce n'est pas un problème auquel la direction en général veut penser. Ce ne sont pas les ingénieurs, vous l'êtes. Faites-en simplement une partie tacite de toutes vos estimations et vous constaterez que la dette technique diminue.
Mais ce ne sera jamais parfait. La dette technique, comme la dette de carte de crédit, est un investissement pour accélérer les clients et gagner plus rapidement des parts de marché sur vos concurrents. Comme le crédit, s'il est géré correctement, il peut vous permettre de réussir.
C'est comme Gandhi a dit lorsqu'on lui a demandé si sa tactique fonctionnerait avec quelqu'un comme Hitler. Il a dit: "Ce serait difficile." Mais je pense qu'il y a un argument valable que la réponse est vraiment "Non". Malheureusement, je ne pense pas que ce que vous essayez de faire puisse être fait. Ce n'est pas que j'essaie d'être pessimiste, mais j'essaie plutôt d'être honnête.
Le problème pour moi n'est pas que les managers doivent être convaincants. Les meilleurs comprennent déjà que la dette peut être un tueur si elle n'est pas gérée. Mais qu'ils le comprennent ou non, qu'ils soient bons ou mauvais gestionnaires, ils sont tous confrontés à la pression de livrer, et cette livraison est jugée par leurs patrons en fonction d'une date. La qualité n'a d'importance que si elle est extrêmement mauvaise, auquel cas c'est la faute des développeurs, ou extrêmement bonne, auquel cas c'est le génie de la gestion qui l'a fait se produire. La qualité doit juste être "assez bonne".
Je pense que j'aime ce que Renesis a dit dans sa réponse, car c'est l'un des rares à comprendre que la direction pense très différemment de l'ingénierie. Et je pense que nous avons tous vu la progression des entreprises devenir axées sur les dates et davantage gérées par des projets plutôt que centrées sur le client et la qualité. Par cela, je veux dire les entreprises typiques, pas les entreprises vraiment solides qui ont le courage de dire "Cela sera fait quand c'est fait" (comme Apple Computer ou id Software - et oui, je comprendre que parfois les gens ne sont pas libres d’adopter cette approche).
Mais voici la chose: les entreprises qui adoptent l'approche de la qualité d'abord ... que remarquez-vous à leur sujet? C'est vrai, ils sont dirigés par des ingénieurs, pas des vendeurs, des spécialistes du marketing, des chefs de projet ou des comptables. Pensez à HP, Apple, id, Google, Microsoft et IBM. Tout a commencé et a été couronné de succès par des ingénieurs, pas par des vendeurs, bien que les vendeurs aient certainement joué un rôle, et je suis sûr que beaucoup douteraient de l'association de Microsoft à la qualité :) Et parmi ceux-là, ceux qui sont descendus se sont éloignés du leadership axé sur l'ingénierie. Cependant, il y a toute une série d'arguments dans cette déclaration, car il y a beaucoup d'entreprises techniques qui ont finalement échoué en raison d'une incapacité à s'adapter aux temps changeants et à gérer leur propre croissance. Je ne vois pas le leadership basé sur l'ingénierie comme la cause de ces échecs, pour moi, c'est une question de compétences et de sens des affaires qui sont indépendants de quelqu'un qui est développeur ou comptable. Cependant, je pense que, d'une manière générale, l'ingénierie se consacre aux rigueurs de la responsabilité et de la discipline qui profitent aux entreprises où l'ingénierie fait partie.
Sérieusement, regardez autour de vous. Le leadership informatique fait cruellement défaut. L'accent est toujours mis sur le coût et le temps, et rarement sur la qualité tant qu'il est suffisant. Les responsables informatiques relèvent rarement du PDG, c'est désormais toujours le directeur financier. L'informatique est coincée à faire du soutien à la production et est de plus en plus redevable aux chefs de projet qui se concentrent sur des morceaux plus petits, plus digestes et mesurables, pas sur des changements significatifs de valeur révolutionnaire (pas que ce soit nécessairement faux; diviser pour mieux régner est une bonne chose, mais la vision doit être là pour la vue d'ensemble).
Désolé de prendre autant de temps sur ce poste, mais à la fin, je pense que votre question, sur la façon de prendre soin de la gestion de la dette technique, est souvent mieux résolue en trouvant le bon leader, plutôt que de changer celui qui existe. Expliquer la dette technique aux penseurs standard signifie changer l'orientation vers l'argent et le coût, comme l'a dit Renesis, et je pense que cela perd beaucoup en traduction; même si vous réussissiez, cela n'aurait d'importance que si le leader de l'entreprise l'achetait. Convaincre votre manager intermédiaire de faire la bonne chose ne fera probablement que le renvoyer.
La première chose à faire est de changer le libellé. L'appeler "dette technique" donne à la direction l'idée que l'autoriser est un investissement quelconque - quand c'est vraiment plus comme un virus. (Je suis comme le Dave Ramsey de la dette technique.)
Le laisser impayé a un coût énorme qui ne peut être vu ou facilement quantifié.
Énumérez les problèmes tels que les suivants pour la gestion:
- Les estimations des nouvelles fonctionnalités sont bien plus élevées qu'elles ne devraient l'être. Ou, tout à fait impossible.
- Un mauvais code génère plus de mauvais code
- La liste des bogues s'allonge même si les développeurs les corrigent toujours
- Les membres de l'équipe partent (cela peut en soi montrer qu'il y a un problème comme expliqué dans cette excellente réponse )
Ma direction a en fait commencé à faire un effort sérieux pour régler la dette technique, ce qui est l'une des raisons pour lesquelles j'aime travailler là-bas, mais c'est un effort à long terme et cela ne fait jamais de mal de leur rappeler pourquoi l'effort en vaut la peine.
Une façon de maintenir la pression est à chaque fois qu'on me demande un devis, et du temps aurait pu être gagné si je n'avais pas eu à régler des problèmes techniques spécifiques de dette, j'inclus cela dans mon devis. Par exemple, " Ce bogue me prendra 2-3 jours à retrouver, mais si nous avions déjà corrigé ces 2 autres bogues de" faible priorité "qui ont été dans la file d'attente pour toujours, il prendre probablement moins d'un. "Souvent, la réponse sera d'aller de l'avant et de réparer les autres pendant que vous y êtes.
Je suis également d'accord avec d'autres réponses sur la simple prise en compte des améliorations dans votre travail et les faire au fur et à mesure si ce n'est pas trop perturbateur. Ma tâche actuelle consiste à faire des ajouts à du code très mal conçu. Plutôt que d'ajouter au gâchis en écrivant mon nouveau code pour correspondre, je passe un peu de temps à consolider les fonctionnalités communes, donc l'envoi d'un paquet devient un appel de fonction d'une ligne au lieu de répéter constamment 15 lignes de copie et- coller le passe-partout.
Je sais pertinemment que cela va sauver la santé mentale de certains mainteneurs plus loin sur la route. Je le sais parce que je suis ce mainteneur aujourd'hui. Cependant, je pense également que cela va accélérer ma propre tâche actuelle consistant à intégrer cette fonctionnalité et à la déboguer maintenant.
Une autre technique que j'ai utilisée dans le passé et que je devrais recommencer est de garder une branche DVCS de refactoring dans une arborescence de travail séparée pour ce temps d'arrêt lorsque vous compilez, attendez un long test, ou juste besoin d'un changement de rythme un peu lorsque vous êtes épuisé par un bug. Tant que vous fusionnez occasionnellement de l'amont afin de ne pas trop diverger, vous pouvez prendre aussi longtemps que vous le souhaitez sur la refactorisation des changements avec très peu d'effort marginal. 15 minutes ici et là par jour peuvent vraiment s'accumuler au fil du temps.
Vous pouvez essayer l'analogie avec la carte de crédit. Demandez-leur "vous sentez-vous à l'aise de laisser vos relevés de carte de crédit impayés pendant une longue période?"
Les gestionnaires comprennent les coûts et les avantages, mais (généralement) pas les termes techniques utilisés par nos développeurs. Le terme "dette technique" a déjà été inventé pour aider à surmonter cette barrière de communication, mais vous devrez peut-être l'articuler plus clairement. La plupart des gestionnaires savent très bien (souvent par expérience) que les paiements par carte de crédit en souffrance augmentent avec un taux d'intérêt horrible, donc ça fait mal de les laisser impayés. Cela peut les aider à comprendre la gravité du problème concernant l'entropie logicielle.
Mais si cela ne les convainc pas, essayez de rassembler des preuves factuelles et de faire des calculs. Par exemple. combien cela coûte-t-il à l'entreprise - à la fois en espèces et en temps perdu - de remplacer un employé qui quitte?.
Personne ne donnera d'argent pour remplacer quelque chose qui fonctionne par autre chose qui (avec un peu de chance) fonctionne également.
Ce que vous pouvez faire est de proposer de le remplacer par quelque chose qui en fait plus, c'est-à-dire de regrouper le service de la dette technologique dans une mise à niveau qui apporte des avantages commerciaux instantanés et tangibles.
Bien sûr, vous devriez être ouvert à ce sujet, nous ne parlons pas ici de "le glisser" dans un nouveau projet.
Je trouve l'autre côté, celui des développeurs plus difficile à gérer. Fondamentalement, cela se résume à ceci: pour certains développeurs, s'assurer que votre code est le meilleur code possible que vous pouvez trouver est une question de fierté professionnelle. Pour d'autres, ce n'est qu'un autre travail et l'objectif est de le faire rapidement et de rentrer à la maison.
Aucune quantité convaincante ne changera cette situation, et si vous introduisez une norme de qualité de code obligatoire, vos neuf à cinq développeurs trouveront un moyen de faire fonctionner le système, tandis que vos développeurs dédiés seront inévitablement ennuyés par l'ensemble de la procédure (qui n'est pas ne les vise pas, mais vous ne pouvez pas dire que le développeur X doit obéir aux règles, tandis que Y peut faire ce qu'il veut).
Ce qui fonctionne, mais peut être très frustrant, c'est que vos développeurs les plus dévoués et compétents supervisent la base de code, probablement un bon compromis entre aller de l'avant et ranger ce qui ne va pas.
Le fait est que dans de nombreuses entreprises, compte tenu notamment de la situation économique actuelle, chaque heure doit être facturée à quelqu'un.
Ou ils descendent, rapide.
À moins que les clients existants ne soient prêts à payer pour la refactorisation, ce qui est profondément improbable à moins qu'il ne s'accompagne de performances ou de fonctionnalités considérablement améliorées. Cela ne se produira alors pas sur les anciennes bases de code. Vous pourrez peut-être l'introduire dans le budget des nouveaux projets, si les clients ont des poches profondes, mais à moins que vous n'ayez pas besoin de changer les API dans le refactoring, cela ne sera d'aucune utilité pour les projets plus anciens et pourrait bien introduire un situation où l'entreprise prend en charge deux bases de code, ce qui entraîne des maux de tête et des coûts supplémentaires.
En tant qu'ingénieur, j'aimerais refactoriser l'ancien code, qui n'est plus vraiment adapté à l'usage, chaque fois que quelque chose devient obsolète ou obsolète. Mais comme mes médecins dans toutes les entreprises dans lesquelles j'ai déjà travaillé m'ont dit: "Qui paiera?"
J'essaie toujours de nettoyer au fur et à mesure. Je n'ai pas fini tant que le code n'est pas propre. Le problème de la dette technique est que la plupart des gens ne la comprennent pas. La meilleure façon de l'aborder est de ne pas en accumuler. Si vos responsables font confiance à vos développeurs pour décider comment résoudre un problème, vous pouvez intégrer l'hygiène du code à chaque tâche de programmation. Si vous n'arrivez jamais à enregistrer un mauvais code, vous n'accumulez pas de dettes. Si vous suivez également la Boy Scout Rule (laissez toujours le code plus propre que vous ne l'avez trouvé), votre dette existante disparaîtra lentement.
Je ne vois pas le refactoring comme une tâche distincte de l'implémentation de fonctionnalités. Il en fait partie intégrante.
Si vous avez affaire à des gestionnaires non techniques, il serait utile que vous puissiez formuler votre discussion en termes qu'ils comprennent. Si vous pouvez construire un cas réaliste pour un retour sur investissement positif sur le travail dépensé pour rembourser la dette technique, vous pourriez arriver quelque part. Cet exercice dépendra de votre situation, mais un exemple pourrait être quelque chose comme ceci:
Analysez le temps que les développeurs sont obligés de passer à aider le support pour les problèmes de production, puis démontrez que la correction d'un ancien code cruel A. réduirait le nombre de problèmes de support, B. faciliterait la résolution des problèmes par le support sans escalader vers le développement, et C. réduire le temps que le développement consacre aux problèmes de production lorsqu'ils surviennent. Mettez-le en termes d'économies en évitant que les développeurs ne soient bloqués pour faire du travail de support. Soulignez également que chaque heure qu'un développeur consacre à l'assistance est un "double coup dur" car non seulement vous payez un développeur pour l'assistance, mais vous brûlez le coût d'opportunité de ce que ce développeur pourrait faire (ajout de nouvelles fonctionnalités, etc. .)
Ouais, certains des numéros seront vaudou/fumée-et-miroirs ... c'est OK, le sale secret de la direction est qu'ils savent que la majorité des numéros qu'ils échappent sont des B.S. totaux. Tant que vous leur donnez quelque chose d'apparemment concret pour travailler, afin qu'ils puissent le saisir, vous avez une chance de vous battre.
Après cette explication de l'endettement technique, votre management devrait être convaincu de le rembourser:
Imaginez que vous ayez une cuisine très sale pleine de merde. Avant de préparer un repas, vous devez d'abord passer une heure à nettoyer. Et c'est comme ça à chaque fois que tu veux manger. De plus, lors de la préparation d'un repas, vous devez être extrêmement prudent pour vous assurer que la merde ne tombe pas dans votre repas.
La cuisine est votre code, le repas est votre produit et manger, c'est vendre votre produit.
S'ils peuvent se permettre d'attendre plus longtemps qu'un changement soit mis en œuvre, sans filet de sécurité des tests unitaires, alors il y a quelque chose qui ne va pas dans votre entreprise.
Il doit être un argument très convaincant, en termes de produit d'origine et d'analyse de rentabilisation, que je ne pouvais pas utiliser cet argent maintenant pour faire quelque chose de plus important pour moi. Que cela vous plaise ou non, votre direction ou vos clients paient pour cela et vous devez pouvoir vendre pour les convaincre.
Reformulons ceci pour vous positionner en tant que client. Bon vieux jeu de rôle.
Supposons que vous achetiez un réfrigérateur. Et vous pourriez acheter un réfrigérateur pour 1000 $ qui fonctionnait bien auprès d'Acme Corp. Ou un réfrigérateur pour 2000 $ d'Acme Deluxe Fridges qui avait la même apparence à l'extérieur et avait les mêmes spécifications techniques, mais avait des coûts de maintenance inférieurs en raison d'une architecture interne plus propre.
En tant que client, lequel achèteriez-vous vous-même?
Et quelle est la meilleure réponse selon les ingénieurs d'Acme Deluxe?
" Dette technique " peut être un sujet délicat à présenter à la direction car ils n'en voient peut-être pas la nécessité. La question pourrait être formulée comme s'il y a ou non un champion dans l'entreprise pour déclarer: "Écoutez, nous prenons X% de temps pour travailler sur la dette technique ici. Donnez-nous 3 mois pour vous montrer que cela fonctionne bien", ou quelque chose similaire. Il y a une prétention à l'autonomie mais aussi un délai car sinon la direction peut se demander combien de temps jusqu'à ce qu'ils voient des résultats ce qui est un territoire plutôt dangereux.
Cependant, le premier point est de savoir s’ils y voient ou non un problème. Si la personne malvoyante ne sait rien des lunettes et quels types de changements elles peuvent apporter, comment comprendre pourquoi un examen de la vue pourrait être utile? Même idée ici où le sujet est assez technique et difficilement quantifiable malheureusement.
Vous devriez juste arrêter de vous en plaindre.
Voici pourquoi:
- Ils ne prévoient jamais d'utiliser le logiciel plus d'un an
- c'est juste une perte de temps pour le peaufiner si leur plan est de le vider après
- il y a de vrais problèmes qui doivent être résolus maintenant
- les programmeurs ont juste besoin d'apprendre à gérer la maintenance, même si ce n'est pas toujours amusant
- se plaindre que vous savez mieux ce qui doit être fait est arrogant - quelqu'un d'autre prend la décision, et vous devriez en être heureux
- Ils vous font de toute façon confiance pour écrire du bon code
La meilleure façon de progresser est donc:
- Lorsqu'ils vous confient une nouvelle tâche, essayez de la mettre en œuvre le mieux possible dans le temps imparti
- Écrivez-le parfaitement la première fois. Si vous devez le changer par la suite, vous avez fait une erreur la première fois et tout changement va toujours dans la mauvaise direction - et c'est une opportunité d'apprentissage pour les programmeurs lorsque vous faites des erreurs.
- Ne demandez pas de temps supplémentaire pour cela, vous ne l'obtiendrez pas, il y a des délais que vous connaissez.
Je suppose que vous n'avez jamais été impliqué dans un projet de réécriture/remplacement ou même de mise à niveau du système existant.
Ce sont certains des projets les plus difficiles à mener à bien. Certains des problèmes que vous rencontrerez sont les suivants:
- Les règles métier se perdent dans le temps.
- La documentation et la mise en œuvre sont totalement désynchronisées.
- Ce que vous voyez comme un bug, les utilisateurs le voient comme une fonctionnalité.
- Inversement, de nombreuses "fonctionnalités" seront considérées comme des défauts par les utilisateurs.
- Vous n'obtiendrez pas l'adhésion des utilisateurs - ils considéreront votre "recherche de faits" comme des "nerds posant des questions stupides", ils considéreront l'effort de test comme une perte de temps, ils insisteront pour ajouter de nouvelles fonctionnalités, ainsi l'allongement d'un projet sera déjà en retard.
- Il y a de fortes chances que le code source ne corresponde pas à 100% à l'exécutable en cours d'exécution.
- Pendant que votre service s'embête à refactoriser le développement, l'entreprise ne souhaite pas le faire.
- Il est probable que votre refacturation impliquera des "interfaces améliorées plus propres", entraînant ainsi d'autres projets dans votre bourbier de retards de livraison et d'échecs de tests.
- Une fois le projet en conserve (bien plus de 50% de ces efforts échouent complètement), vous aurez perdu toute crédibilité - vous devrez déménager dans une autre entreprise dans une autre ville pour trouver quelqu'un prêt à vous écouter aussi.
- Si le projet "réussit", tout le monde se souviendra de quel cauchemar ce fut - vous le ferez .......
Je vous exhorte à éviter tout projet de réécriture/refactorisation comme la peste, ils peuvent être parmi les expériences les plus décourageantes de toute carrière professionnelle.
Il y a beaucoup de sagesse dans la phrase "Si ce n'est pas cassé, ne le répare pas".
Ayant déjà été impliqué dans une réécriture majeure (et pas seulement dans la refonte), je peux convenir qu'amener les responsables financiers à accepter le projet était l'un des principaux obstacles. Surmonter cet obstacle m'a obligé à rédiger, présenter et défendre un rapport qui mettait en évidence un certain nombre de problèmes qui signifiaient que l'activité de l'entreprise allait être morte dans l'eau à court ou moyen terme.
Facteurs clés pour faire avancer l'accord:
- Le code existant se trouvait dans une chaîne d'outils non prise en charge (MicroPower Pascal), qui ne fonctionnait que sur une plate-forme de développement presque non compatible (PDP11-23).
- Trouver des développeurs capables de travailler sur des outils et des cibles devenait presque impossible.
- Le matériel cible n'était plus disponible si des pièces de rechange étaient nécessaires et le et le fabricant étaient de plus en plus réticents à fournir un service de réparation.
- Des problèmes dans le code entraînaient une insatisfaction des clients facilement identifiable et des coûts de service directs.
- L'ajout de nouvelles fonctionnalités ou même de corrections de bogues devenait presque impossible en raison des limitations du matériel cible, ce qui nécessitait de refactoriser d'autres zones afin de fournir de l'espace lors de la résolution des problèmes.
- Avec un temps de construction de 8 heures, le développement et le test de toutes les modifications étaient coûteux.
Le rapport détaille les problèmes, avec des estimations des coûts permanents, et propose 3 options:
- Geler où nous étions avec peut-être même pas de corrections de bugs dans un avenir proche.
- Optimiser le code pour l'espace uniquement, sans égard à la maintenabilité, soulignant que quiconque tente de maintenir le code optimisé devrait être plus intelligent que celui qui a fait l'optimisation.
- Réimplémenter, avec la testabilité et la maintenabilité comme facteurs élevés, dans un langage standard, largement enseigné, (ANSI C), sur du nouveau matériel COTS à faible coût (PC-104), avec plusieurs fournisseurs disponibles avec un en interne carte d'interface conçue pour lui permettre de fonctionner avec le matériel existant restant. Ajout d'un ensemble limité de nouvelles fonctionnalités dans le cadre du développement, telles que le stockage non volatile, une minuterie de surveillance pour fournir un redémarrage automatique en cas de panne certaines unités se bloquaient plusieurs fois par jour et nécessitaient un appel de service de 40 £ out to reset, de meilleurs diagnostics dans le processus.
Ayant obtenu le feu vert pour la 3ème option, mon contrat de 3 mois s'est transformé en 3 ans de travail très dur, à la fois en développant le nouveau logiciel et le matériel, mais avec un très bon résultat.
Pour les cas avec une dette technique moins extrême, j'ai tendance à adopter ce que j'appelle le refactoring de guérilla:
En cas de problème avec un module spécifique:
- Écrivez un ensemble de tests qui démontrent le problème qui sont également susceptibles d'échouer sans refactoring
- Refactor dans le cadre du développement soulignant que les tests échouent toujours.
Pour ma vie, je ne peux pas comprendre pourquoi certaines personnes ont si aveuglément peur du changement - cela sent le manque de confiance en vos propres capacités.
J'ai regardé un spectacle hier soir dans le parc national de Yosemite et il a été remarqué que de 1940 à la fin des années 1990, pas un seul nouvel arbre Sequoia n'a germé. On a découvert que la raison en était qu'il y avait une politique stricte contre les incendies de forêt et que les pommes de pin Sequoia avaient besoin de la chaleur du feu pour s'ouvrir et libérer leurs graines.
Vous voyez, un feu tous les dix ans environ était sain. Il a éliminé tout le bois mort et les ronces accumulés pour garder en bonne santé les arbres existants (processus) et faire de la place pour de nouveaux (caractéristiques).
Je suis actuellement sur un projet qui a un argument clair pour la reconstruction: le logiciel hérité a été entièrement écrit à l'aide de formulaires Web .NET. Presque toute la logique métier est mélangée à la logique d'affichage des balises HTML/serveur et ne peut pas être étendue à d'autres applications maintenant que l'entreprise a pris de l'expansion.
La direction est derrière la tâche car ils ont une confiance appropriée dans leurs développeurs, ce qui, je le réalise, est un luxe rare.
Oui, demandez-vous si une reconstruction est vraiment nécessaire. Faites de votre mieux pour réutiliser le code existant qui fonctionne là où vous le pouvez. Intégrez ce code dans la reconstruction si nécessaire. Ne laissez personne vous convaincre qu'avoir peur de faire des changements audacieux est le seul moyen d'exister en tant que développeur de logiciels.
Bonne chance!
Vous devez donner à votre direction une raison financière pour faire face à la dette technique et un cadre pour gérer la réduction de cette dette technique.
Le maintien d'une feuille de route technologique est l'un de ces cadres. Commencer avec une feuille de route vous aidera à vous empêcher de vous accumuler sur la dette technique, et peut également vous aider à réduire la dette existante.
De nombreux projets à long terme réussis ont associé des comités directeurs et des feuilles de route pour guider le développement. Ceux-ci sont particulièrement utiles lorsque plusieurs équipes de développement et parties prenantes sont impliquées.
Ma suggestion est que vous discutiez de cette stratégie avec vos managers (et si possible ceux qui décident où l'argent est dépensé).
L'approche générale de la création et de la gestion d'une feuille de route est simple, mais elle nécessite le soutien de votre équipe de direction. Définissez d'abord un objectif. Définissez les éléments de la dette technique et développez une architecture de système cible qui réduit les éléments de votre dette technique. Rappelez-vous, il ne doit pas être parfait, juste réalisable et meilleur que ce que vous êtes actuellement. Tenez compte des logiciels, des outils de développement, des plates-formes matérielles, des nouvelles fonctionnalités majeures qui peuvent être ajoutées au système. Faites une analyse des coûts. Si vous avez l'architecture souhaitée, quels sont les avantages tangibles de la refactorisation? (Les avantages incluraient une durée de test réduite, des produits logiciels plus fiables, des cycles de développement plus prévisibles, etc.) Si vous pouvez montrer suffisamment d'avantages pour effectuer une refactorisation, vous pouvez obtenir un support de gestion.
Une fois que vous avez une feuille de route et un support de gestion, développez une série d'étapes (également appelées plan) que vous devez suivre pour atteindre cet état souhaité. Ce peut être une bonne idée de mettre sur pied un comité directeur qui maintient la feuille de route, forme et éduque les équipes de développement sur la feuille de route et examine périodiquement les changements pour l'intégrité architecturale.
Les feuilles de route sont vraiment utiles, et peut-être que la 13ème question sur le test Joel devrait être "Avez-vous une feuille de route?"
Voici une vidéo de la première heure d'une récente session de la feuille de route Red Hat Linux .