Comment gérez-vous les projets laissés par les autres employés? [fermé]

Il arrive que quelqu'un quitte soudainement l'entreprise. Maintenant, son travail doit être terminé et on vous le confie. N'ayant aucune idée de ce qu'il faisait (90% ou 9%), comment gérez-vous les restes?

1. Dois-je repartir de zéro? Et si c'était fait à 90%?
2. Dois-je essayer de comprendre ce qu'il a fait? Et si c'était juste un non-sens?

Pour savoir quoi faire, vous devez savoir ce que vous avez et comment il est en forme.

Alors, commencez par avoir un aperçu rapide de toutes les sources et voyez ce que vous avez. S'il est clair, il est plus facile de terminer ce qui manque. Faites des tests unitaires pour découvrir ce qui fonctionne et ce qui ne fonctionne pas.

Si ce n'est pas vraiment clair, commencez à comprendre ce qui fonctionne avec les nouveaux tests unitaires. Si cela est impossible, dites à votre chef d'équipe que vous avez un problème et que vous ne pourrez peut-être pas le résoudre. Il peut alors décider si le travail à gauche doit être récupéré de toute façon ou s'il est tout simplement trop mauvais et vous devez le refaire.

En plus de ce que les autres ont écrit, je vous suggère de parler à toute personne qui a eu un contact direct avec le gars. Je comprends de votre description qu'il travaillait seul, il devait quand même faire rapport à quelqu'un? Et il peut y avoir du personnel QA ayant testé ce qu'il avait produit ... Ces personnes devraient (normalement) avoir au moins une idée approximative de la distance que le gars a parcourue avec son projet avant de partir. À moins bien sûr que les informations / produits fournis par lui se soient avérés être totalement non fiables, contribuant à sa mise à pied.

Discutez-en avec votre responsable et allouez un laps de temps pour l'exploration / test initial du code restant et la compréhension des spécifications et des exigences. Cela pourrait être à peu près une journée pour un projet sur une échelle de temps de quelques mois-personne, au plus une semaine pour un projet d'une ou plusieurs années-personnes, etc.

Après cette exploration initiale, vous devriez avoir une estimation approximative de

• ce que le produit est censé faire,
• que peut-il faire actuellement et dans quelle mesure,
• combien de temps et de risques il faudrait pour réécrire à partir de zéro,
• combien de temps et de risque il faudrait pour terminer ce qui a déjà été fait.

Ensuite, vous pouvez vous asseoir à nouveau avec votre manager pour prendre une décision.

D'après mon expérience, ce n'est pas une situation rare. Malheureusement, vous avez vraiment deux problèmes ici :

1) Les restes de ce projet 2) Les raisons pour lesquelles vous êtes entré dans ce pétrin en premier lieu

Pour (1), vous devez tenir compte de la taille / complexité du projet. S'il s'agit d'une semaine de travail, vous devrez probablement tout recommencer. S'il s'agit d'une année de travail, vous devrez peut-être voir ce que vous pouvez récupérer du code existant.

Dans tous les cas, vous devez suivre ces étapes immédiatement:

a) Dites à vos managers que vous avez un gros problème

b) Obtenez les spécifications du projet et obtenez une compréhension approfondie de ce que vous devez réaliser - ou parlez aux sponsors du projet s'il n'y a pas de spécifications.

c) Parlez aux gestionnaires / clients, etc. et découvrez si quelqu'un a / pense avoir une idée de l'état du projet.

Une fois que vous avez fait cela, vous serez en mesure de commencer à examiner le code / à élaborer une stratégie.

(Je ne pense pas que les tests unitaires vous aideront beaucoup - ils pourraient vous dire si les fonctions qui ont été écrites fonctionnent réellement, mais ils ne vous disent pas quelles fonctions devraient être là.)

Ce que je n'aurais pas ensuite, c'est obtenir un aperçu de l'architecture du code qui existe, et comment cela correspond au problème défini dans la spécification. Ensuite, déterminez quels sont les sous-composants de chacun de ces composants principaux et voyez comment ils s'intègrent à la vue d'ensemble. Faire cela vous dira (grossièrement) quels composants manquent.

Une fois que vous savez ce qui existe, vous devez commencer à examiner le code existant pour voir s'il fait ce qu'il est censé faire.

Une fois que vous avez fait tout cela, vous serez en mesure d'estimer combien de travail il reste à faire.

En ce qui concerne la partie (2), votre entreprise devra peut-être examiner les politiques d'embauche / politiques de rétention du personnel, trouver des moyens de tenir les programmeurs responsables des progrès.

Enfin, vous devez également réfléchir à la manière dont vous pourriez éviter que cela ne se produise dans l'entreprise si vous partez à la hâte.

Vous devez absolument essayer et exécuter le logiciel pour voir ce qui fonctionne et ce qui ne fonctionne pas.

Vous devrez ensuite considérer quelle documentation a été laissée. Y a-t-il des exigences écrites? Y a-t-il des tâches spécifiques - les tâches sont-elles suivies d'une manière ou d'une autre? Quelqu'un l'a-t-il testé? Dans l'affirmative, ils sauront ce qui a été fait et ce qui ne l'a pas été.

Je pense qu'un plan d'action serait:

1. Cochez les exigences qui ont été remplies (par une analyse rapide du système comme le ferait un testeur)

2. Regardez le code - pouvez-vous le comprendre? Est-ce bien écrit?

De toute évidence, si c'est fait à 90% et que le code est bien écrit, il suffit de le terminer.

Pas encore mentionné.

Essayez de contacter le gars qui est parti. Ce n'est pas possible dans tous les cas. Mais s'il est en bonne santé et qu'il aime au moins un peu son travail, il vous aidera et vous donnera une réponse honnête des progrès et des parties manquantes. Et il pourrait vous expliquer la situation dans son ensemble.

Félicitations, c'est votre chance de briller et de faire une impression vraiment positive sur vos patrons. Ce que vous avez ici est une opportunité inestimable. Alors, que devez-vous faire et comment?

Tout d'abord, récupérez le code. Il n'a peut-être pas tout vérifié (le gars qui nous a fait ça ne l'a pas fait) et donc quelqu'un avec des droits d'administrateur le retire de son ordinateur et le vérifie pour vous.

Ensuite, triez le problème. Prenez les exigences et notez quelles parties semblent avoir du code écrit et lesquelles ne le font pas. Ceci est la liste approximative de ce qui n'est pas terminé. Il grandira à mesure que vous ferez la prochaine étape. Parcourez ensuite le code et évaluez-le, exécutez-le et voyez ce qui fonctionne actuellement et ce qui semble ne pas fonctionner même s'il y a du code écrit. Ajoutez les pièces non fonctionnelles à la liste. Recherchez les tests unitaires (je serais surpris si vous les trouviez, les gens qui renflouent juste avant une date limite parce qu'ils savent qu'ils échouent ont tendance à ne pas les écrire). Maintenant, au moins, vous avez une bonne idée de sa gravité. Consultez également les exigences et voyez à quelles questions vous avez besoin de répondre. Souvent, les échecs du projet sont dus à de mauvaises exigences et à un développeur qui ne veut pas (pour une multitude de raisons) de poser d'autres questions.

Maintenant, vous faites votre plan de projet. Commencez par une liste des questions que vous vous posez sur les exigences (écrivez-les officiellement dans un document), puis énumérez les choses que vous devez faire pour terminer le travail. Faites une estimation du temps que cela prendra. Déterminez si ce qui existe actuellement est récupérable (et sinon, soyez prêt à justifier pourquoi pas).

Maintenant, rencontrez le chef de projet (et votre patron s'il s'agit de deux personnes différentes) et dites-lui les mauvaises nouvelles. (C'est presque toujours une mauvaise nouvelle quand quelqu'un part soudainement et que vous devez reprendre là où il s'est arrêté, les bons développeurs ne laissent pas les gens dans l'embarras - ils partent au moins avec une liste de ce qu'ils ont fait et de ce qu'il reste à faire L'exception peut être si quelqu'un est parti en raison de problèmes de santé.) Dans votre discussion, vous pouvez obtenir certaines des réponses dont vous avez besoin et vous et le PM pouvez retravailler un peu le plan du projet.

Faites le suivi de la réunion en envoyant le PM et d'autres parties prenantes essentielles (le PM identifiera qui), une copie de vos questions auxquelles il faut répondre et le plan de projet que vous avez élaboré.

Maintenant, vous avez ce dont vous avez besoin pour commencer le codage réel, alors mettez-vous au travail.

En attendant, vous avez probablement été retiré de quelque chose d'autre pour sauver ce projet. Assurez-vous que votre travail est en forme pour que quelqu'un d'autre le récupère ou pour que vous le récupériez une fois le projet terminé. Cela signifie les mêmes types de choses, un document où vous dites ce qui est fait et ce qui ne l'est pas et un archivage de tout le code source (pas nécessairement au coffre si ce n'est pas fait, mais quelque part où quelqu'un d'autre peut y accéder .

Si vous n'avez pas été retiré de votre travail actuel, vous devez déterminer avec votre patron combien de temps vous consacrerez à la journée de travail. C'est l'un de ces moments où des heures supplémentaires peuvent être nécessaires et seront appréciées. Plus il est proche de l'échéance réelle, plus la gestion est désespérée, vous pourrez peut-être calculer la rémunération des heures supplémentaires ou un gros bonus si l'échéance est proche. Si ce travail va retarder considérablement l'autre travail, vous devez vous assurer que les parties prenantes de ce projet en sont conscientes.

Une fois que vous avez réussi à sauver le projet, assurez-vous de vous en vanter lors de votre prochaine évaluation des performances.