Tentang mengelola migrasi besar

Untuk mengelola dan secara efektif mengatur proyek migrasi besar, manajer proyek perlu memiliki pemahaman tingkat tinggi tentang portofolio, fase migrasi besar, dan tanggung jawab setiap alur kerja.

Workstream dalam migrasi besar

Pada fase migrasi, pada waktu tertentu, minimal empat alur kerja beroperasi secara bersamaan: yayasan, tata kelola proyek, portofolio, dan alur kerja migrasi. Ini adalah alur kerja inti dari setiap proyek migrasi besar, dan proyek Anda mungkin memiliki tambahan, alur kerja pendukung. Untuk informasi selengkapnya, lihat Workstream dalam migrasi besar di playbook Foundation untuk migrasiAWS besar.

Memberi makan pipa migrasi

Di pabrik migrasi, perencanaan gelombang dan migrasi terjadi pada saat yang sama dan beroperasi terus menerus. Tim portofolio memberi makan pipeline migrasi dengan merencanakan gelombang, dan tim migrasi menyelesaikan pipeline dengan melakukan migrasi dan memotong beban kerja. Tim portofolio menyiapkan lima gelombang di akhir tahap inisialisasi, dan tahap implementasi dimulai ketika tim migrasi mulai memigrasi satu atau lebih gelombang yang disiapkan.

Untuk setiap gelombang, alur kerja portofolio berjalan 1-2 minggu, dan alur kerja migrasi biasanya berjalan 3-4 minggu. Portofolio workstream adalah lima gelombang di depan alur kerja migrasi, sehingga selalu ada buffer lima gelombang antara portofolio dan alur kerja migrasi. Sepanjang tahap implementasi, tim portofolio dan tim migrasi terus memproses gelombang, dan buffer mencegah alur kerja migrasi kehabisan server untuk bermigrasi. Untuk contoh jadwal gelombang, lihat Tahap 2: Menerapkan migrasi besar di Panduan untuk migrasiAWS besar.

Tim portofolio memprioritaskan aplikasi dan kemudian menugaskannya ke gelombang dalam kelompok bergerak logis. Saat merencanakan gelombang, tim portofolio mempertimbangkan kompleksitas migrasi, kesamaan aplikasi, dan dependensi aplikasi dan infrastruktur. Ini membantu memastikan bahwa aplikasi dan dependensinya dimigrasi secara keseluruhan. Untuk informasi selengkapnya tentang perencanaan gelombang, lihat playbook Portofolio untuk migrasiAWS besar. Untuk tata kelola proyek, Anda mengelola dan melacak informasi tentang wave dan sprint, termasuk aplikasi, server, dan pemilik aplikasi. Anda dapat menggunakan dasbor di situs Confluence, daftar di Microsoft Excel, atau kombinasi alat.

Periode hida da da digunakan

Setelah Anda menyelesaikan cutover, aplikasi dan server yang dimigrasi memasuki periode hypercare. Pada periode hypercare, tim migrasi mengelola dan memantau aplikasi yang dimigrasi di cloud untuk mengatasi masalah apa pun. Biasanya, periode ini panjangnya 1—4 hari. Pada akhir periode hypercare, tim migrasi mentransfer tanggung jawab untuk aplikasi ke tim cloud operations (Cloud Ops). Pada saat ini, gelombang dianggap lengkap.

Membangun pendekatan tangkas

Dengan membangun pendekatan yang gesit, tim proyek dapat tetap fleksibel dan cepat beradaptasi dengan perubahan selama migrasi. Kami merekomendasikan mengadopsi kerangka kerja Scrum untuk migrasi besar. Di buku pedoman Migrasi untuk migrasiAWS besar, Anda menetapkan gelombang ke sprint, yang merupakan periode waktu tetap di mana tim migrasi bekerja pada semua gelombang dalam sprint itu. Jika setiap sprint berdurasi 2 minggu, setiap gelombang mencakup setidaknya dua sprint. Sprint terdiri dari acara standar, seperti merencanakan sprint dan melakukan pertemuan stand-up harian, tinjauan, dan retrospektif.

Anda menggunakan backlog sprint, yang terdiri dari tugas saat ini dan tertunda dalam sprint, untuk mengelola aktivitas. Dalam playbook ini, Anda memilih alat manajemen proyek untuk melacak kemajuan. Anda dapat memilih proyek atau aplikasi pelacakan masalah, seperti Jira atau Confluence, dan Anda juga dapat memilih pendekatan visual untuk mewakili tugas, seperti papan Kanban atau bagan Gantt. Dengan melacak backlog sprint di satu atau beberapa alat ini, Anda memberikan transparansi proyek, menetapkan pemilik untuk setiap tugas, dan menetapkan tenggat waktu yang jelas.