Menetapkan perulangan dan merilis rencana

Agile dan metodologi berulang lainnya dibangun di atas konsep iterasi dan rilis. Artikel ini menguraikan penugasan iterasi dan rilis selama perencanaan. Tugas tersebut mendorong visibilitas garis waktu untuk mempermudah percakapan di antara anggota tim strategi cloud. Tugas juga menyelaraskan tugas teknis dengan cara yang dapat dikelola oleh tim adopsi cloud selama implementasi.

Menetapkan iterasi

Dalam pendekatan iterasi untuk implementasi teknis, Anda merencanakan upaya teknis di sekitar blok waktu berulang. Iterasi cenderung menjadi blok waktu selama satu minggu hingga enam minggu. Konsensus menunjukkan bahwa dua minggu adalah durasi iterasi rata-rata untuk sebagian besar tim adopsi cloud. Tetapi pilihan durasi iterasi bergantung pada jenis upaya teknis, overhead administratif, dan preferensi tim.

Untuk mulai menyelaraskan upaya dengan garis waktu, sebaiknya Anda menentukan serangkaian iterasi yang berlangsung 6 hingga 12 bulan.

Memahami velositas

Menyelaraskan upaya untuk iterasi dan rilis memerlukan pemahaman tentang velositas. Velositas adalah jumlah pekerjaan yang dapat diselesaikan dalam iterasi tertentu. Selama perencanaan awal, velositas berupa perkiraan. Setelah beberapa iterasi, velositas menjadi indikator komitmen yang sangat berharga yang dapat dibuat oleh tim dengan penuh keyakinan.

Anda dapat mengukur velositas dalam istilah abstrak seperti titik kisah. Anda juga dapat mengukurnya dalam istilah yang lebih nyata seperti jam. Untuk sebagian besar kerangka kerja iterasi, sebaiknya gunakan pengukuran abstrak untuk menghindari tantangan dalam presisi dan persepsi. Contoh dalam artikel ini mewakili velostias dalam jam per sprint. Representasi ini membuat topik bisa lebih dipahami secara universal.

Contoh: Tim adopsi cloud teridir dari lima orang telah berkomitmen pada sprint selama dua minggu. Mengingat adanya kewajiban saat ini seperti rapat dan dukungan proses lainnya, setiap anggota tim dapat secara konsisten berkontribusi 20 jam per minggu untuk upaya adopsi. Untuk tim ini, perkiraan velositas awal adalah 100 jam per sprint.

Perencanaan iterasi

Awalnya, Anda merencanakan iterasi dengan mengevaluasi tugas teknis berdasarkan backlog prioritas. Tim adopsi cloud memperkirakan upaya yang diperlukan untuk menyelesaikan berbagai tugas. Tugas-tugas tersebut kemudian ditetapkan ke iterasi pertama yang tersedia.

Selama perencanaan iterasi, tim adopsi cloud memvalidasi dan memperbaiki perkiraan. Itu dilakukan sampai mereka menyelaraskan semua velositas yang tersedia untuk tugas-tugas tertentu. Proses ini berlanjut untuk setiap beban kerja prioritas hingga semua upaya selaras dengan perkiraan iterasi.

Dalam proses ini, tim memvalidasi tugas yang ditetapkan untuk sprint berikutnya. Tim memperbarui perkiraannya berdasarkan percakapan tim tentang setiap tugas. Tim kemudian menambahkan setiap perkiraan tugas ke sprint berikutnya sampai velositas yang tersedia terpenuhi. Akhirnya, tim memperkirakan tugas tambahan dan menambahkannya ke iterasi berikutnya. Tim melakukan langkah-langkah ini sampai velostias iterasi tersebut juga habis.

Proses sebelumnya berlanjut sampai semua tugas ditetapkan ke iterasi.

Contoh: Mari kita mem-build contoh sebelumnya. Asumsikan setiap migrasi beban kerja memerlukan 40 tugas. Asumsikan juga Anda memperkirakan setiap tugas untuk mengambil rata-rata selama satu jam. Estimasi gabungannya adalah sekitar 40 jam per migrasi beban kerja. Jika perkiraan ini tetap konsisten untuk kesepuluh beban kerja prioritas, beban kerja tersebut akan memakan waktu 400 jam.

Velositas yang ditentukan dalam contoh sebelumnya menunjukkan bahwa migrasi dari 10 beban kerja pertama akan memakan waktu empat iterasi, yaitu dua bulan waktu kalender. Iterasi pertama akan terdiri dari 100 tugas yang menghasilkan migrasi dua beban kerja. Dalam iterasi berikutnya, kumpulan serupa dari 100 tugas akan menghasilkan migrasi tiga beban kerja.

Peringatan

Jumlah tugas dan perkiraan sebelumnya secara ketat digunakan sebagai contoh. Tugas teknis seringnya tidak konsisten. Anda tidak akan melihat contoh ini sebagai refleksi dari jumlah waktu yang diperlukan untuk memigrasikan beban kerja.

Perencanaan rilis

Dalam adopsi cloud, suatu rilis didefinisikan sebagai kumpulan kiriman yang menghasilkan cukup nilai bisnis untuk memberi alasan risiko gangguan pada proses bisnis.

Melepaskan perubahan terkait beban kerja ke dalam lingkungan produksi akan menciptakan beberapa perubahan pada proses bisnis. Idealnya, perubahan ini berjalan mulus, dan bisnis melihat nilai perubahan tanpa gangguan yang signifikan terhadap layanan. Tetapi risiko gangguan bisnis hadir dengan perubahan apa pun dan tidak boleh dianggap remeh.

Untuk memastikan perubahan dibenarkan oleh potensi hasilnya, tim strategi cloud harus berpartisipasi dalam perencanaan rilis. Setelah tugas diselaraskan dengan sprint, tim dapat menentukan garis waktu secara kasar kapan setiap beban kerja akan siap untuk rilis produksi. Tim strategi cloud akan meninjau waktu setiap rilis. Tim kemudian akan mengidentifikasi titik perubahan antara risiko dan nilai bisnis.

Contoh: Dengan melanjutkan contoh sebelumnya, tim strategi cloud telah meninjau rencana iterasi. Tinjauan tersebut mengidentifikasi dua titik rilis. Selama iterasi kedua, total lima beban kerja akan siap untuk migrasi. Kelima beban kerja tersebut akan memberikan nilai bisnis yang signifikan serta akan memicu rilis pertama. Rilis berikutnya akan datang pada dua iterasi berikutnya, ketika lima beban kerja berikutnya siap untuk rilis.

Menetapkan jalur dan tag iterasi

Bagi pelanggan yang mengelola rencana adopsi cloud di Azure DevOps, proses sebelumnya tecermin dengan menetapkan jalur iterasi untuk setiap tugas dan kisah pengguna. Sebaiknya Anda menandai setiap beban kerja dengan rilis tertentu. Penandaan dan penugasan tersebut memberi umpan pada populasi laporan garis waktu otomatis.

Langkah berikutnya

Perkirakan garis waktu untuk mengomunikasikan ekspektasi dengan benar.

Memperkirakan garis waktu