Préparer le plan de transfert du code source [fermé]


12

Notre entreprise est sur le point d'acquérir le code source d'un énorme produit.

Quelles sont les choses à prendre en considération lorsque le transfert commence, pour nous assurer que nous avons tout et être en mesure de maintenir ce produit à l'avenir?


1
Si possible, demandez l'acquisition pour certains des ingénieurs travaillant sur le projet. Cela contribuera à résoudre le problème de continuité des ressources.
tehnyit

nous n'avons pas la chance. nous ne pouvons pas faire cela le maximum que nous pouvons faire est de mettre un ingénieur à disposition pendant 3-4 semaines.
Ahmed Aswani

J'ai trouvé une réponse connexe, je pense qu'elle complète la plupart des réponses ici.
Ahmed Aswani

Réponses:


8

Tout d'abord bonne chance.

Voici certaines des choses que vous devriez probablement demander / recevoir.

  • Liste des défauts connus.
  • Liste des enregistrements d'incidents et de problèmes.
  • Détails sur les deux dernières versions comme; combien de temps ont-ils mis à mettre en œuvre, y a-t-il eu une période d'incidents accrus après la libération, etc.
  • Qui sont les principaux experts en la matière.
  • Quelles sont les heures d'ouverture et le support principal.
  • Depuis combien de temps le produit existe-t-il et à quel point la base de code est-elle stable?
  • Quelle est la feuille de route du produit.
  • Quelle est la pile technologique.
  • Quels sont les points d'intégration et qui prend en charge les systèmes intégrés.
  • Y a-t-il des composants DR
  • Qui est responsable de l'invocation de DR
  • Quels sont les SLA d'application ou les cibles de service.
  • Quelle est la croissance attendue du système de fichiers / base de données / files d'attente de messages.
  • Quand les sauvegardes du système sont-elles effectuées, qui est responsable et quelle est la stratégie de restauration.
  • Qui est responsable de la gestion du backlog produit.
  • Quels SLA du fournisseur et coordonnées sont en place.
  • Existe-t-il des planifications par lots ou des processus de longue durée?
  • Le système est-il complètement transactionnel et comment est géré la concurrence.
  • Quel est le processus de gestion des incidents majeurs pour l'application.
  • Quoi, quand, qui et comment les parties prenantes sont-elles informées des changements et des pannes.
  • Quelles sont les périodes / heures d'interruption convenues.
  • Où est conservé le code source.
  • Comment le code source est-il sauvegardé, restauré et le journal des modifications est-il géré?
  • Où, quoi et à qui appartient l'architecture de la solution.
  • Quelle est la cible de déploiement (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Quand les licences tierces sont-elles renouvelées?
  • Existe-t-il un graphique RACI
  • Combien d'utilisateurs sont là et où se trouvent-ils.
  • Quels sont les problèmes de dépannage ou les plaintes les plus courants.
  • Qui est responsable d'accorder l'accès au système.
  • Quand les pent-tests / audits de sécurité sont-ils entrepris?
  • Où est le CI et le processus de construction automatisé.
  • Qui est responsable de l'administration du contrôle de code source et du serveur de génération.
  • Où sont les guides d'installation.
  • Existe-t-il une documentation pour l'infrastructure et le réseau cibles?
  • Quels sont les types de gravité et d'impact des incidents récents.
  • Existe-t-il des instructions de configuration du poste de travail développeur.
    • Quels outils de développement et frameworks sont utilisés et sont-ils sous licence pour votre équipe?

C'est à peu près tout ce à quoi je peux penser en ce moment.


8
Veuillez définir "DR", "DEV, ST, UAT, Pre PROD, PROD, DR" et "RACI". Notez que certains de ces éléments ne sont pas pertinents pour le code source (c.-à-d. Que les graphiques RACI sont organisationnels et ne sont pas liés au code du tout.)
S.Lott

Je ne voudrais pas avoir accès au dépôt de code source whoel et pas seulement aux versions actuelles du code source. Les commentaires dans ce document vous diront souvent pourquoi le code a été modifié d'une manière particulière. C'est important pour iknwo de le maintenir.
HLGEM

@HLGEM désolé ma déclaration sur les versions actuelles du code source impliquait (enfin pour moi de toute façon) le code source complet pour tous les composants.
Kane

@ S.Lott DR est utilisé pour décrire la "reprise après sinistre". Dev est un terme commun pour «environnement de développement», quel qu'il soit pour votre environnement. ST est l'abréviation de System Testing Environment. Je ne suis pas d'accord que le RACI est un outil organisationnel car il est utilisé pour décrire qui est responsable, responsable, informé et consulté. Alors, quand le code est engagé, qui en est responsable? Qui est consulté dans le cadre d'un examen par les pairs? Qui est informé qu'une construction a réussi / échoué? Et ainsi de suite
Kane

@kame: Veuillez mettre à jour la réponse avec les définitions. Veuillez ne pas ajouter d'autres commentaires à la réponse. Veuillez mettre à jour la réponse.
S.Lott

6

Quelles sont les choses à prendre en considération lorsque le transfert commence, pour nous assurer que nous avons tout et être en mesure de maintenir ce produit à l'avenir?

Les choses que vous devez vous assurer sont:

  • vous les voyez construire le code avec succès
  • vous les voyez construire des tests unitaires et réussir
  • vous les voyez exécuter d'autres tests avec succès et tous réussissent (acceptation, intégration, etc.)
  • vous obtenez la base de données des problèmes ouverts (faciles à obtenir s'ils utilisent bugzilla, ou similaire)
  • le produit fonctionne (instructions d'installation).

Tout le reste est à la charge du mainteneur actuel.


2
Je suggérerais que ceux-ci soient modifiés pour avoir les mots "Vous devez les voir ..." par exemple, "Vous devez les voir construire le code" et "Vous devez les voir exécuter les tests unitaires", etc. Les preuves sont importantes ici.
S.Lott

@ S.Lott Qu'ils affichent ou écrivent dans un document, cela n'a pas d'importance. Ahmed Aswani et son équipe vont maintenir l'application, et devraient pouvoir faire toutes les étapes ci-dessus par eux-mêmes. J'ai un peu modifié la réponse, mais je ne sais pas si c'est ce que vous avez suggéré.
BЈовић

1
Une affirmation selon laquelle le code est construit n'est pas la même chose que de voir le code être construit. Été là. C'est fait. La documentation peut être vague, confuse ou incomplète. C'est l'ancien principe "Faire confiance mais vérifier". Jusqu'à ce que vous le voyiez, ne le croyez pas.
S.Lott

1
@ S.Lott Ok est logique. Maintenant que j'y pense, j'étais dans une situation similaire auparavant, où ils nous ont fait implémenter quelque chose sur des cartes HW cassées. Nous avons passé 4 bons mois avant de découvrir ce qui ne va vraiment pas.
BЈовић

5

Vous devez vous assurer que l'équipe remet le code pour vous aider pendant un certain temps. Faites-en un contrat signé!

Plus tard, vous aurez des questions que vous ne saviez pas que vous deviez poser à l'avance, donc ils doivent "rester" pour vous expliquer des choses, pas seulement donner le code, les documents et tout ce qu'ils ont sur le projet.

Lorsque vous avez un transfert de projet, vous perdez une chose importante: l'expérience originale de l'équipe.

Parfois, vous obtenez également quelque chose à quoi vous ne vous attendiez pas: leur hostilité.

L'entreprise effectuant le transfert obtient-elle une bonne affaire avec le transfert? S'ils perdent des affaires parce qu'ils vous tournent le projet, les (fiers) développeurs qui ont créé le code pourraient ne pas aimer que leur "bébé" soit donné. Vous pourriez obtenir des réponses du type: "C'est dans les documents que vous avez" ... même si ce n'est pas le cas.

Les aspects techniques sont bons à couvrir, mais prennent également en compte le côté humain de celui-ci.

YMMV!


0

Le code est-il fourni avec une suite de tests? Tous les tests de la suite de tests réussissent-ils? Quelle est la couverture de la suite?

Je recommanderais que, en l'absence d'une suite de tests, vous fassiez de la construction de la suite de tests et du cadre connexe votre première priorité.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.