Mempersiapkan rencana penyerahan kode sumber [ditutup]

12

Perusahaan kami akan memperoleh kode sumber produk besar.

Apa hal yang perlu dipertimbangkan ketika serah terima dimulai, untuk memastikan kami memiliki segalanya dan mampu mempertahankan produk itu di masa depan?

documentation  maintenance  knowledge-transfer 
— Ahmed Aswani
sumber
1
Jika memungkinkan, mintalah akuisisi untuk beberapa insinyur yang mengerjakan proyek. Ini akan membantu masalah kontinuitas sumber daya.
— tehnyit
kita tidak cukup beruntung. kami tidak dapat melakukan itu maksimal yang dapat kami lakukan adalah menyediakan beberapa insinyur selama 3-4 minggu.
— Ahmed Aswani
Saya telah menemukan jawaban terkait yang menurut saya melengkapi sebagian besar jawaban di sini.
— Ahmed Aswani

Jawaban:

8

Semoga berhasil.

Berikut adalah beberapa hal yang mungkin harus Anda minta / sediakan.

  • Daftar cacat yang diketahui.
  • Daftar catatan insiden dan masalah.
  • Detail pada dua rilis terakhir seperti; berapa lama waktu yang mereka butuhkan untuk mengimplementasikan, apakah ada periode peningkatan insiden setelah rilis, dll.
  • Siapa ahli materi pelajaran utama.
  • Berapa jam operasi dan dukungan utama?
  • Berapa lama produk tersebut ada dan seberapa stabil basis kode.
  • Apa itu peta jalan produk.
  • Apa tumpukan teknologi.
  • Apa saja poin integrasi, dan siapa yang mendukung sistem terintegrasi.
  • Apakah ada komponen DR
  • Siapa yang bertanggung jawab untuk memohon DR
  • Apa aplikasi SLA atau target layanan.
  • Apa yang diharapkan dari antrian sistem file / basis data / pesan.
  • Kapan cadangan sistem dilakukan, siapa yang bertanggung jawab, dan apa strategi pemulihannya.
  • Siapa yang bertanggung jawab untuk mengelola simpanan produk.
  • Apa rincian vendor SLA dan kontak yang ada.
  • Apakah ada jadwal batch atau proses yang berjalan lama.
  • Apakah sistem sepenuhnya transaksional dan bagaimana konkurensi dikelola.
  • Apa proses manajemen insiden utama untuk aplikasi.
  • Apa, kapan, siapa, dan bagaimana para pemangku kepentingan diberitahu tentang perubahan dan pemadaman.
  • Apa periode / waktu pemadaman yang disepakati.
  • Di mana kode sumber disimpan.
  • Bagaimana kode sumber dicadangkan, dipulihkan, dan ubah log dikelola.
  • Di mana, apa dan siapa yang memiliki arsitektur solusi.
  • Apa target penyebaran (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Kapan lisensi pihak ketiga diperbarui.
  • Apakah ada grafik RACI
  • Berapa banyak pengguna di sana dan di mana mereka berada.
  • Apa masalah atau keluhan pemecahan masalah yang umum.
  • Siapa yang bertanggung jawab untuk memberikan akses sistem.
  • Kapan tes pent / audit keamanan dilakukan.
  • Di mana CI dan proses pembangunan otomatis.
  • Siapa yang bertanggung jawab untuk mengelola kontrol sumber dan membangun server.
  • Di mana panduan instalasi.
  • Apakah ada dokumentasi untuk infrastruktur dan jaringan target.
  • Apa saja jenis keparahan dan dampak dari insiden baru-baru ini.
  • Apakah ada instruksi pengaturan workstation pengembang.
    • Alat bantu dan kerangka kerja apa yang digunakan dan apakah mereka dilisensikan untuk tim Anda.

Hanya itu yang bisa saya pikirkan saat ini.

— Kane
sumber
8
Silakan tentukan "DR", "DEV, ST, UAT, Pre PROD, PROD, DR", dan "RACI". Perhatikan bahwa beberapa di antaranya tidak relevan untuk kode sumber (yaitu, bagan RACI bersifat organisasional, tidak terkait kode sama sekali.)
— S.Lott
Saya ingin sekali akses ke repositori kode sumber whoel tidak hanya versi kode sumber saat ini. Komentar dalam hal ini akan sering tellyou mengapa kode diubah dengan cara tertentu. Itu penting untuk iknwo untuk mempertahankannya.
— HLGEM
@HLGEM maaf pernyataan saya tentang versi saat ini dari kode sumber tersirat (baik bagi saya toh) kode sumber lengkap untuk semua komponen.
— Kane
@ S.Lott DR digunakan untuk menggambarkan "pemulihan bencana". Dev adalah istilah umum untuk "Lingkungan Pengembangan", apa pun yang terdiri dari untuk lingkungan Anda. ST adalah singkatan untuk Lingkungan Pengujian Sistem. Saya tidak setuju bahwa RACI adalah alat organisasi karena digunakan untuk menggambarkan siapa yang bertanggung jawab, akuntabel, terinformasi dan berkonsultasi. Jadi, ketika kode berkomitmen siapa yang bertanggung jawab untuk itu? Siapa yang dikonsultasikan sebagai bagian dari peer review? Siapa yang diberi tahu bahwa bangunan berhasil / gagal? Dan seterusnya
— Kane
@ame: Harap perbarui jawabannya dengan definisi. Tolong jangan menambahkan komentar lagi untuk jawabannya. Harap perbarui jawabannya.
— S.Lott
6

Apa hal yang perlu dipertimbangkan ketika serah terima dimulai, untuk memastikan kami memiliki segalanya dan mampu mempertahankan produk itu di masa depan?

Hal-hal yang harus Anda pastikan adalah:

  • Anda melihat mereka membangun kode dengan sukses
  • Anda melihat mereka membangun unit test dan berhasil
  • Anda melihat mereka menjalankan tes lain dengan sukses, dan semua lulus (penerimaan, integrasi, dll)
  • Anda mendapatkan basis data masalah terbuka (mudah didapat jika mereka menggunakan bugzilla, atau serupa)
  • produk berjalan (instruksi instalasi).

Segala sesuatu yang lain tergantung pada pengelola saat ini untuk menyerahkan.

— BЈовић
sumber
2
Saya akan menyarankan agar ini dimodifikasi untuk memiliki kata-kata "Anda harus melihatnya ..." misalnya, "Anda harus melihat mereka membuat kode" dan "Anda harus melihatnya menjalankan tes unit", dll. Bukti penting di sini.
— S.Lott
@ S.Lott Apakah mereka menunjukkan, atau menulis dalam dokumen, itu tidak masalah. Ahmed Aswani dan timnya akan mempertahankan aplikasi, dan harus dapat melakukan semua langkah di atas sendiri. Saya memodifikasi jawabannya sedikit, tetapi saya tidak yakin apakah itu yang Anda sarankan.
— BЈовић
1
Klaim bahwa kode dibuat tidak sama dengan benar-benar melihat kode dibuat. Pernah ke sana. Selesai itu. Dokumentasinya bisa kabur, membingungkan atau tidak lengkap. Ini adalah prinsip "Percaya tapi Verifikasi" yang lama. Sampai Anda melihatnya, jangan percaya.
— S.Lott
1
@ S.Lott Ok masuk akal. Sekarang saya memikirkannya, saya berada dalam situasi yang sama sebelumnya, di mana mereka membuat kami menerapkan sesuatu pada papan HW yang rusak. Kami menghabiskan 4 bulan yang baik sebelum mencari tahu apa yang sebenarnya salah.
— BЈовић
5

Anda perlu memastikan bahwa tim menyerahkan kode akan memberikan dukungan untuk jangka waktu tertentu. Buat kontrak yang ditandatangani!

Anda akan memiliki pertanyaan di kemudian hari bahwa Anda tidak tahu Anda harus bertanya di muka, jadi mereka perlu "bertahan" untuk menjelaskan hal-hal kepada Anda tidak hanya memberikan kode, dokumen, dan apa pun yang mereka miliki di proyek.

Ketika Anda memiliki penyerahan proyek, Anda kehilangan satu hal penting: pengalaman tim asli.

Terkadang Anda juga mendapatkan sesuatu yang tidak Anda harapkan: permusuhan mereka.

Apakah perusahaan melakukan serah terima yang baik dengan serah terima itu? Jika mereka kehilangan bisnis karena mereka menyerahkan proyek kepada Anda, pengembang (bangga) yang menciptakan kode mungkin membenci fakta bahwa "bayi" mereka diberikan. Anda mungkin mendapatkan respons seperti: "Ada di dokumen yang Anda dapatkan" ... bahkan jika tidak.

Aspek teknis baik untuk dibahas, tetapi juga mempertimbangkan sisi manusiawi dari itu.

YMMV!

— JohnDoDo
sumber
0

Apakah kode dilengkapi dengan suite uji? Apakah semua tes dalam test-suite lulus? Berapa cakupan yang dimiliki suite?

Saya akan merekomendasikan itu, melewatkan test-suite, Anda menjadikan membangun test-suite dan kerangka kerja terkait sebagai prioritas utama Anda.

— blueberryfields
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.