Comment gérer la gestion en poussant les systèmes hérités?

Je suis actuellement en stage rémunéré et j'ai été chargé de maintenir un système obsolète qui a été développé par plusieurs développeurs (à des moments différents) au cours des 5 dernières années. La direction convient que le "système est sous assistance vitale" et je reçois régulièrement des rapports de bogues des utilisateurs finaux qui utilisent actuellement le système.

La direction souhaite désormais prolonger le projet d'une année supplémentaire et, ce faisant, tripler presque la base d'utilisateurs.

En tant que stagiaire (ou n'importe quel poste de niveau d'entrée), comment "repousser"? J'ai déjà rédigé un rapport exprimant mes préoccupations, mais dans un document ouvert. Existe-t-il un protocole ou un type de document pour suggérer des modifications? Suis-je en mesure de faire des suggestions ou dois-je simplement continuer à soutenir l'ancien système?

• Pour clarifier, le développement de logiciels n'est pas l'activité principale de mon entreprise. En tant que tel, aucun protocole interne n'existe. De plus, le projet n'a aucune documentation officielle et aucun document sur les exigences. Le développement est très ponctuel.

Je suis actuellement en stage rémunéré et j'ai été chargé de maintenir un système obsolète qui a été développé par plusieurs développeurs (à des moments différents) au cours des 5 dernières années. La direction convient que le "système est sous assistance vitale" et je reçois régulièrement des rapports de bogues des utilisateurs finaux qui utilisent actuellement le système.

Le système n'est pas obsolète si les gens l'utilisent toujours et qu'il soutient les activités commerciales. Puisqu'il est toujours utilisé, l'entreprise ne peut pas simplement le jeter - il doit être pris en charge jusqu'à ce que le besoin du système n'existe plus. Cela pourrait être un changement dans les objectifs commerciaux ou un nouveau système a été développé, testé et déployé avec succès auprès des utilisateurs finaux.

Vraiment, 5 ans, ce n'est pas si long. J'ai travaillé avec du code qui avait 10 ans auparavant. S'il répond toujours aux besoins de l'utilisateur, pourquoi le jeter? Cela jette beaucoup d'argent dépensé pour le développer. Jusqu'à ce qu'il devienne impossible à maintenir en raison de l'augmentation des coûts ou que les exigences changent radicalement, il n'y a aucune raison commerciale de le jeter.

La direction souhaite désormais prolonger le projet d'une année supplémentaire et, ce faisant, tripler presque la base d'utilisateurs.

Si la direction dit que ce système est «de survie», pourquoi essaient-ils de le déployer davantage? Il est courant que les activités de maintenance se poursuivent sur un système hérité jusqu'à ce qu'il soit remplacé, mais si un système est en fin de vie, il n'est généralement pas déployé auprès d'un plus grand nombre de personnes. L'extension de la maintenance est une chose, mais l'ajout d'utilisateurs qui dépendent du système est une situation tout à fait différente.

Pour moi, il semble que ce ne soit pas réellement une fin de vie, mais plutôt une phase de maintenance et qu'il continuera d'être là jusqu'à ce que le système ne réponde plus aux besoins des utilisateurs.

En tant que stagiaire (ou n'importe quel poste de niveau d'entrée), comment "repousser"? J'ai déjà rédigé un rapport exprimant mes préoccupations, mais dans un document ouvert. Existe-t-il un protocole ou un type de document pour suggérer des modifications? Suis-je en mesure de faire des suggestions ou dois-je simplement continuer à soutenir l'ancien système?

Vous devez continuer à prendre en charge l'ancien système. Plus tard, vous mentionnez que le logiciel n'est pas l'activité principale de votre entreprise. Dans un tel environnement, le travail des équipes logicielles est de soutenir l'activité principale de l'entreprise. Cependant, les équipes logicielles doivent également garder à l'esprit les objectifs de l'entreprise.

En attendant, capturez vos suggestions d'une manière qui n'est pas dominatrice. Indiquez d'autres technologies ou techniques qui pourraient être intégrées au système ou utilisées si / quand un nouveau système est créé et leurs avantages / inconvénients. La façon dont vous procédez dépend de l'entreprise, mais compte tenu de certains points ultérieurs, il serait peut-être utile d'établir un wiki ou un autre site collaboratif.

Dans une entreprise non logicielle, les logiciels sont un coût et les équipes logicielles (en particulier les gestionnaires de projets / programmes logiciels) devraient s'efforcer de minimiser autant que possible les coûts de construction et de maintenance des systèmes logiciels, tout en répondant aux besoins des utilisateurs finaux. . Jeter un logiciel qui (pour autant que je sache, de votre message, de toute façon) répond aux besoins des utilisateurs va à l'encontre de ce qui est dans le meilleur intérêt de l'équipe du logiciel.

* Pour clarifier, le développement de logiciels n'est pas l'activité principale de mon entreprise. En tant que tel, aucun protocole interne n'existe. De plus, le projet n'a aucune documentation officielle, aucun document sur les exigences. Le développement est très ponctuel.

Pour moi, c'est le problème. Ne pas produire de documentation, ne pas développer selon une spécification et un manque de cohérence a tendance à augmenter le coût de développement de logiciels. Travailler à résoudre ce problème serait ma plus haute priorité, et je le ferais en travaillant sur des choses comme une norme de codage, le contrôle de version, la production de code auto-documenté et de documents de conception, le suivi des défauts et les spécifications des exigences.

J'ai déjà rédigé un rapport exprimant mes préoccupations

Bien. C'est à peu près l'étendue de ce que vous pouvez faire en tant que stagiaire. Pour référence future lors de la rédaction de tels rapports, j'insiste sur la présentation de faits concrets d'une manière impartiale et professionnelle, sans préjugés émotionnels. Vous ne savez pas qui lira le rapport, peut-être quelqu'un qui peut ou non avoir causé certains des problèmes que vous décrivez ou qui a pris des décisions qui ont conduit à ces problèmes. Tout autre chose que des faits froids pourrait être considéré par ces personnes comme un affront ou une infraction et les amènera à ne pas vous aimer et à ne pas prendre tout cela au sérieux.

La direction veut maintenant prolonger le projet pour une autre année et, ce faisant, presque tripler la base d'utilisateurs

Gardez à l'esprit que des décisions commerciales comme celle-ci sont prises parce qu'elles essaient de prendre leurs décisions avec les ressources dont elles disposent. Je suis certain que la direction est probablement au courant des problèmes avec les logiciels hérités et est probablement au courant des plaintes des utilisateurs, mais a-t-elle les ressources de développement logiciel disponibles pour gérer la refactorisation ou une réécriture?

La plupart du temps, ce n'est pas le cas, surtout si le logiciel n'est pas le pain de la société et que la qualité et la satisfaction des utilisateurs avec le logiciel n'affecteront pas directement le résultat net. Prendre ce genre de décisions est parfois la raison pour laquelle être un manager est nul parce que vous êtes souvent dans une situation perdante, peu importe ce que vous faites.

maintenir un système obsolète qui a été développé par plusieurs développeurs (à des moments différents) au cours des 5 dernières années

Des erreurs ont été commises tout au long du projet qui l'ont conduit à ce point. Le manque d'entrées ou d'exigences solides des utilisateurs, le manque de bonne gestion des produits et de contrôle des changements pour gérer les exigences et les besoins changeants et le manque de ressources techniques adéquates à mettre en œuvre ont causé les problèmes tels qu'ils existent aujourd'hui. Je ne sais pas si obsolète est le bon mot. La technologie sous-jacente repose-t-elle sur des cadres et des technologies non pris en charge, ou n'est-ce tout simplement pas la technologie de pointe ou idéale?

En tant que stagiaire (ou n'importe quel poste de niveau d'entrée), comment "repousser"?

Vous êtes dans une position de moindre puissance et vous êtes temporaire. Ce n'est pas grave si vous avez raison, je ne m'attendrais pas à ce qu'un stagiaire me "repousse" jamais. Je m'attends à ce qu'ils apprennent, discutent des problèmes tels qu'ils les voient et suivent les ordres. C'est à peu près ça. Une fois qu'un ordre est donné, je m'attends à ce qu'il soit exécuté au mieux de leurs capacités, car le temps de la discussion est terminé à ce stade.

Tu es stagiaire. Je doute beaucoup que vous soyez même à distance des impératifs commerciaux quotidiens dans leur ensemble et comme d'autres personnes l'ont remarqué, une base de code vieille de 5 ans n'est pas vraiment aussi ancienne.

Les décisions concernant le remplacement des anciens systèmes ne sont pas toujours motivées par des considérations techniques; ils sont motivés par l'évolution des besoins de l'entreprise. La contribution à ceux-ci peut être difficile à maintenir; mais à la fin de la journée, vous devez reconnaître que votre position ne signifie pas nécessairement que vous avez toutes les connaissances disponibles et requises. J'irais jusqu'à dire que vous avez en fait très peu de connaissances nécessaires pour faire le choix de la meilleure décision à l'heure actuelle.

Mon conseil est le suivant: apprenez de l'expérience et arrêtez de supposer que vos connaissances l'emportent sur celles des personnes qui doivent gérer l'entreprise au jour le jour.

Votre travail consiste à maintenir le système en marche et non à suggérer un nouveau remplacement brillant.

Il me semble que beaucoup de jeunes programmeurs ne réalisent pas que la maintenance des anciens systèmes est une partie plus importante du travail de programmation que la conception de nouveaux systèmes brillants /

Ne repoussez pas. La seule chose que vous devez faire est d'exprimer vos préoccupations de manière claire et concise. Le fait est que la plupart des entreprises dans lesquelles vous travaillerez à l'avenir auront des systèmes hérités. Ces anciens systèmes doivent être maintenus car, dans de nombreux cas, ils sont trop chers à remplacer.

Dans de nombreux cas, vous pouvez même avoir les meilleures intentions de remplacer le système actuel par un meilleur système, cependant, vous pouvez simplement introduire de nouveaux et différents bugs ... lorsque vous quittez le système, il se transformera rapidement en un système hérité et la société être au même endroit qu'avant. Rien n'est obsolète jusqu'à ce qu'il ne serve plus son objectif ou qu'il soit complètement incompatible avec les systèmes modernes. Mon entreprise possède un système vieux de plus de 20 ans que nous sommes en train de convertir en ASP.NET. Le système fonctionne toujours mais la prise en charge de l'ancienne technologie diminue et le faire fonctionner avec les navigateurs Web modernes prend de plus en plus de temps.

Ce que tu peux faire:

Laisser les choses plus propres

Lorsque vous entretenez quelque chose, laissez-le plus propre qu'au début. faites votre correction, mais nettoyez aussi les choses afin que la prochaine fois que quelqu'un doit apporter une modification, il soit plus facile à comprendre.

Créer de la documentation

Si le manque de documentation est un problème, créez de la documentation. Lorsque vous travaillez sur une partie particulière du système, documentez-la.

Rendez-le moins douloureux

Comme je l'ai dit, vous pouvez exprimer vos préoccupations, mais votre mieux est de travailler avec diligence sur le système et de mieux travailler pour ceux qui vous suivent. Corrigez correctement les bogues. Document. Le code dispersé sent. Fais le mieux. Et quand vous faites ces choses, informez vos supérieurs. Dites-leur que vous faites X, Y et Z pour améliorer le processus de développement. Cela renforce la crédibilité et à long terme, cela vous aidera, vous et votre entreprise, plus que toute autre chose.

VOUS NE FAITES PAS !!! Ceci est une grande opportunité!

Vous êtes un stage à apprendre! Ce projet est un monde réel tel qu'il se présente.

Vous êtes très chanceux de l'avoir. Le fait que vous ne soyez pas qualifié n'est pas votre préoccupation. (Si \ lorsque la direction l'a réalisé, vous aurez beaucoup gagné)

VOUS serez qualifié une fois que vous aurez terminé ce stage, et c'est une excellente nouvelle.

PS: Faites des sauvegardes religieusement, assurez-vous que TOUT ce que vous faites peut être annulé. Commencez par les problèmes qui sont des "solutions faciles" mais qui posent de gros problèmes aux utilisateurs. Faites de petits pas.

Je suppose, dans un sens très théorique - il n'y a rien de tel que le système Legacy . J'ai un très vieux téléphone (un système hérité), et de nos jours il y a de bons téléphones Android (plates-formes modernes), mais mon téléphone fonctionne et fait ce dont j'ai besoin. Pourquoi devrais-je jeter ça?

Tous les systèmes que vous appelez aujourd'hui «hérités» étaient un jour à la pointe de la technologie. Ce n'est que le temps dont nous avons besoin. De plus, quand il y a un travail important en place, ce n'est pas que refaire tout le reste dans les plates-formes modernes, cela signifie qu'il sera automatiquement sans bug (ou sans douleur).

Voici ce que je vous recommande de faire:

1. Oubliez d'abord votre aversion pour le "système hérité". Cela vous rendra très contre-productif.

2. Commencez à documenter ce que vous faites maintenant et ce que vous pensez. Quoique pas à pas. Il n'y a tout simplement pas de meilleur moment pour faire de la documentation que celui où vous réalisez que vous en avez besoin.

3. Au lieu d'essayer de repousser la poursuite du «système hérité» - essayez de définir le chemin pour sa sortie en douceur. Essayez de voir que vous pouvez convaincre la direction qu'un développement plus récent, qui peut être isolé, peut se faire pas à pas dans les nouvelles plates-formes sans interrompre l'interopérabilité avec les anciens systèmes. Lentement (et ce sera très lentement) à mesure que les choses évoluent, la nécessité de conserver l'ancien système disparaîtrait. C'est la seule façon de dire au revoir à n'importe quel ancien système.

Dipan.

La vérité, c'est que personne ne donne aux stagiaires le travail qu'ils veulent faire. Lorsque vous êtes la personne la plus jeune, vous obtenez le travail le moins excitant. La façon dont vous gérez personnellement cela en dit long sur l'organisation quant à savoir si elle peut vous faire confiance pour faire plus de travail passionnant.

Voici donc une occasion inestimable de montrer que vous pouvez livrer en faisant les corrections de bugs, que vous pouvez refactoriser en faisant un peu mieux chaque partie du code que vous touchez, que vous pouvez créer des tests unitaires, en commençant à les créer pour ce système et que vous pouvez documenter en créant de la documentation pour la prochaine pauvre âme qui est coincée avec ce système. Cela vous donne également l'opportunité de montrer que vous pouvez traiter efficacement avec les utilisateurs (pour obtenir plus de détails sur les bogues signalés) et répondre à leurs besoins. Si le projet n'est pas maintenant dans le contrôle de code source, placez-le là et si les bogues ne sont pas suivis dans un traqueur de bogues, alors démarrez-en un. Ces types d'actions vous montreront comment travailler professionnellement.

Ou vous pouvez prendre le chemin opposé et vous contenter de dire à quel point le projet est mauvais et à quel point il serait cool de le remplacer. Dans ce cas, vous ne serez presque certainement pas offert un emploi dans cette entreprise après votre stage.

Vous n'avez probablement pas suffisamment d'informations pour déterminer s'il est rentable de partir une autre année ou non. Il serait intéressant de comprendre l'entreprise et pourquoi elle ajoute des utilisateurs. Il semble qu'il y ait une certaine croissance et ils ne peuvent tout simplement pas se permettre de prendre du recul financièrement ou sous certaines contraintes de temps pour créer une autre application. La construction d'une nouvelle application est rarement le meilleur choix de toute façon. 5 ans n'est pas si vieux à moins qu'ils ne l'aient construit sur une ancienne technologie.