Preparare il piano di consegna del codice sorgente [chiuso]

Innanzitutto buona fortuna.

Ecco alcune delle cose che probabilmente dovresti chiedere / essere fornite.

• Elenco dei difetti noti.
• Elenco dei record di anomalie e problemi.
• Dettagli sulle ultime due versioni come; quanto tempo ci sono voluti per implementare, c'è stato un periodo di aumenti di incidenti successivi al rilascio, ecc.
• Chi sono i principali esperti in materia.
• Quali sono gli orari di apertura e il supporto principale.
• Per quanto tempo è esistito il prodotto e quanto è stabile il codice base.
• Qual è la roadmap del prodotto.
• Cos'è lo stack tecnologico.
• Quali sono i punti di integrazione e chi supporta i sistemi integrati.
• C'è qualche componente DR
• Chi è responsabile per invocare DR
• Quali sono gli SLA delle applicazioni o i target di servizio.
• Qual è la crescita prevista del file system / database / code di messaggi.
• Quando vengono eseguiti i backup del sistema, chi è responsabile e qual è la strategia di ripristino.
• Chi è responsabile della gestione del backlog del prodotto.
• Quali SLA e dettagli di contatto del fornitore sono disponibili.
• Ci sono delle pianificazioni batch o dei processi a esecuzione prolungata.
• Il sistema è completamente transazionale e come viene gestito la concorrenza.
• Qual è il principale processo di gestione degli incidenti per l'applicazione.
• Cosa, quando, chi e come vengono informati gli stakeholder delle modifiche e interruzioni.
• Quali sono i periodi / periodi di interruzione concordati.
• Dove viene mantenuto il codice sorgente
• Come viene eseguito il backup del codice sorgente, ripristinato e modificato il registro.
• Dove, cosa e chi possiede l'architettura della soluzione.
• Qual è la destinazione di distribuzione (DEV, ST, UAT, Pre PROD, PROD, DR).
• Quando vengono rinnovate le licenze di terze parti.
• Esiste un grafico RACI
• Quanti utenti ci sono e dove si trovano.
• Quali sono i problemi o i reclami più comuni relativi alla risoluzione dei problemi.
• Chi è responsabile per la concessione dell'accesso al sistema.
• Quando vengono eseguiti i pent test / i controlli di sicurezza.
• Dove si trova l'elemento della configurazione e il processo di generazione automatica.
• Chi è responsabile della gestione del controllo del codice sorgente e del server di creazione.
• Dove sono le guide di installazione.
• Esiste documentazione per l'infrastruttura di destinazione e la rete.
• Quali sono i tipi di gravità e impatto degli incidenti recenti.
• Ci sono istruzioni per la configurazione della workstation dello sviluppatore.
  • Quali strumenti e supporti di sviluppo vengono utilizzati e sono concessi in licenza per il tuo team.

Questo è tutto ciò che riesco a pensare al momento.

What are thing to take into consideration when the handover starts, to make sure we have everything and be capable to maintain that product in the future?

Le cose che dovresti accertarti sono:

• vedi che creano il codice con successo
• li vedi creare test unitari e fare tutto il passaggio
• li vedi eseguire altri test con successo, e tutti passano (accettazione, integrazione, ecc.)
• ottieni il database dei problemi aperti (facile da ottenere se usano bugzilla, o simili)
• il prodotto viene eseguito (istruzioni di installazione).

Tutto il resto spetta al manutentore attuale da consegnare.

Devi assicurarti che il team fornisca il codice fornirà supporto per un periodo di tempo. Fatti un contratto firmato!

Avrai domande più tardi sul fatto che non sapevi che dovevi chiedere in anticipo, quindi hanno bisogno di "aggirarsi" per spiegare cose a te non solo dare il codice, i documenti e tutto ciò che hanno sul progetto.

Quando hai un passaggio di progetto perdi una cosa importante: l'esperienza di squadra originale.

A volte ottieni anche qualcosa che non ti aspetti: la loro ostilità.

L'azienda che effettua il passaggio di consegne sta ottenendo un buon affare con il passaggio di consegne? Se perdono affari perché ti rivolgono il progetto, gli (orgogliosi) sviluppatori che hanno creato il codice potrebbero risentirsi del fatto che il loro "bambino" viene dato via. Potresti ricevere risposte come: "È nella documentazione che hai" ... anche se non lo è.

Gli aspetti tecnici sono buoni da trattare, ma tengono anche in considerazione il lato umano di esso.

YMMV!

Il codice viene fornito con una suite di test? Passa tutti i test nella suite di test? Quanta copertura ha la suite?

Vorrei raccomandare che, mancando una suite di test, rendi la costruzione della suite di test e del framework correlato la tua prima priorità.