Préparer le plan de transfert de code source
Notre société est sur le point d'acquérir un code source d'un énorme produit.
Qu'est-ce que la chose à prendre en compte lorsque le transfert commence, pour que nous ayons tout et être capable de maintenir ce produit à l'avenir?
Premièrement bonne chance.
Voici certaines des choses que vous devriez probablement demander/être fournie.
- Liste des défauts connus.
- Liste des enregistrements d'incident et de problèmes.
- Détails sur les deux dernières versions comme; Combien de temps ont-ils pris pour mettre en œuvre, existe-t-il une période d'augmentation des incidents après la libération, etc.
- Qui sont les experts de la matière clé.
- Quelles sont les heures d'exploitation et le support primaire.
- Depuis combien de temps le produit existe-t-il et la stable est la base de code?.
- Quelle est la feuille de route du produit.
- Quelle est la pile technologique?.
- Quels sont les points d'intégration et qui soutient les systèmes intégrés.
- Y a-t-il des composants DR
- Qui est responsable d'invoquer le dr dr
- Quelles sont les SLA d'application ou les objectifs de service.
- Quelle est la croissance attendue des files d'attente du système de fichiers/de la base de données/des messages.
- Quand les sauvegardes système sont-elles effectuées, qui est responsable et quelle est la stratégie de restauration.
- Qui est responsable de la gestion de l'arriéré du produit.
- Quel vendeur SLA et les coordonnées sont en place.
- Existe-t-il des horaires de lots ou des processus longs en cours d'exécution.
- Le système est-il complètement transactionnel et comment la concurrence est-elle gérée?.
- Quel est le processus de gestion des incidents majeurs pour l'application.
- Quoi, quand, qui et comment les parties prenantes sont notifiées des changements et des pannes.
- Quelles sont les périodes de panne contestées/fois.
- Où est conservé le code source.
- Comment le code source est sauvegardé, restauré et modifier le journal géré.
- Où, quoi et qui possède 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.
- Y a-t-il un graphique RACI
- Combien d'utilisateurs y a-t-il et où sont-ils situés?.
- Quels sont les problèmes de dépannage courants ou les plaintes.
- Qui est responsable de l'octroi d'un accès système.
- Quand sont des tests de pent/des audits de sécurité entrepris?.
- Où est le processus de construction CI et automatisé.
- Qui est responsable de l'administration du contrôle source et de la construction du serveur.
- Où sont les guides d'installation.
- Existe-t-il une documentation pour l'infrastructure et le réseau cible.
- Quels sont les types de gravité et d'impact des incidents récents.
- Existe-t-il des instructions de configuration de la station de travail de développeur.
- Quels sont les aides et les cadres de développement utilisés et sont-ils autorisés à votre équipe.
C'est à peu près tout ce que je peux penser pour le moment.
Qu'est-ce que la chose à prendre en compte lorsque le transfert commence, pour que nous ayons tout et être capable de maintenir ce produit à l'avenir?
Les choses que vous devriez vous assurer sont:
- vous les voyez construire le code avec succès
- vous les voyez construire des tests de l'unité et faire tout passe
- vous les voyez exécuter d'autres tests avec succès et tous réussir (acceptation, intégration, etc.)
- vous obtenez la base de données des problèmes ouverts (facile à obtenir s'ils utilisent Bugzilla ou similaire)
- le produit fonctionne (instructions d'installation).
Tout le reste est à la hauteur du responsable actuel.
Vous devez vous assurer que l'équipe maintient le code fournira un soutien pendant une période de temps. Faites-en un contrat signé!
Vous aurez des questions plus tard que vous ne saviez pas que vous avez dû demander à l'avance, alors ils ont besoin de "rester autour" pour vous expliquer que vous ne vous expliquez pas seulement le code, les docs et tout ce qu'ils ont sur le projet.
Lorsque vous avez un transfert de projet, vous perdez une chose importante: l'expérience de l'équipe d'origine.
Vous avez parfois aussi quelque chose que vous ne vous attendiez pas: leur hostilité.
L'entreprise fait-elle le transfert du transfert d'avoir une bonne affaire avec le transfert? S'ils perdent des affaires parce qu'ils tournent le projet à vous, les développeurs (fiers) qui ont créé le code pourraient ressentir le fait que leur "bébé" est donné. Vous pourriez avoir des réponses comme: "C'est dans les docs que tu as" ... même si ce n'est pas le cas.
Les aspects techniques sont bons pour couvrir, mais également prendre en considération le côté humain de celui-ci.
Ymmv!
Le code vient-il avec une suite de test? Est-ce que tous les tests de la Suite Test-Suite? Combien de couverture la suite a-t-elle?
Je recommanderais que, à la suite d'une suite de tests, vous feriez construire la suite de tests et le cadre connexe Votre première priorité.