Pelatihan Tertulis DevOps

Bagaimana Cara Memperlancar Alur Kerja DevOps Anda?

Dalam DevOps, aliran kerja berarti seluruh rangkaian pembuatan perangkat lunak dari ide hingga baris kode yang berjalan di produksi. Anda dan tim DevOps bertanggung jawab membangun serta menjaga aliran yang andal, konsisten, dan cepat untuk memenuhi dan melampaui sasaran organisasi serta mengungguli produk dan layanan lain di pasar Anda.

Tetapkan Misi untuk Transformasi DevOps Anda

Setelah tim DevOps terbentuk, tetapkan misi. Tim membutuhkan misi bersama agar dapat bekerja dengan baik. Tanpanya, tim tidak akan mampu memprioritaskan pekerjaan penting dan membedakan hambatan serius dari tugas kecil. Misi harus menantang dan ambisius, tetapi tetap bisa dicapai dalam jangka waktu tertentu.

Sesuaikan misi dengan tim DevOps Anda. Dasarkan misi pada karakteristik, tantangan, dan tujuan organisasi dalam melayani klien internal dan eksternal yang berinteraksi dengan tim.

Berikut beberapa contoh pernyataan misi untuk memulai transformasi DevOps:

• Mengurangi rata-rata waktu dari commit kode hingga beroperasi di produksi sebesar 75% dalam 3 bulan.
• Mengurangi rata-rata waktu dari permintaan hingga beroperasi di produksi sebesar 33% dalam 6 bulan.
• Mengurangi jumlah insiden produksi sebesar 50% dalam 12 bulan.

Apa Itu Aliran Nilai dan Siapa yang Terlibat?

Untuk memperbaiki pekerjaan, Anda perlu memahami aliran nilai. Dalam sistem TI, aliran nilai adalah urutan kegiatan untuk merancang, membangun, dan mengoperasikan produk serta layanan perangkat lunak tertentu. Aliran ini juga mencakup tenaga kerja, pengetahuan, sarana, dan bahan yang memungkinkan pekerjaan terus berjalan.

Dalam organisasi yang kompleks, tidak ada orang yang dapat mengenali keseluruhan aliran nilai sendiri. Libatkan semua anggota tim DevOps, pemangku kepentingan, penyedia, perwakilan klien, dan jika memungkinkan, klien itu sendiri.

Buat Peta Aliran Nilai untuk Menemukan Peluang Perbaikan

Peta aliran nilai membantu Anda dan tim DevOps melihat cara kerja sehari-hari dalam organisasi pengembangan dan pengiriman perangkat lunak. Tujuannya bukan mendokumentasikan setiap langkah secara lengkap. Pahami alur kerja sehari-hari secukupnya untuk menemukan inefisiensi, kendala, masalah, dan pemborosan waktu serta sumber daya yang utama.

Saat teknisi pengembangan dan operasi pertama kali membuat peta aliran nilai bersama, teknisi operasi biasanya baru memahami dampak konfigurasi server basis data yang keliru dan ketiadaan tablespace terhadap pengembangan. Teknisi pengembangan pun biasanya baru melihat akibat mengirim perangkat lunak tanpa fitur pemantauan, ketersediaan, kemudahan pengujian, dan konfigurasi yang tertanam.

Hilangkan Sebanyak Mungkin Serah Terima, Kendala, dan Pemborosan

Serah terima, pemborosan, dan kendala sangat memengaruhi efisiensi tetapi sering diabaikan. Saat kegiatan diserahkan ke tim lain, orang perlu memberi tahu, mengajukan permintaan, menjadwalkan, menetapkan atau menurunkan prioritas, dan menyelesaikan konflik.

Setiap serah terima pekerjaan ke tim lain dapat menghilangkan informasi dan memperpanjang waktu tunggu keseluruhan dalam aliran nilai.

Untuk mengatasi masalah ini:

• Pertanyakan waktu yang dibutuhkan untuk setiap serah terima. Pada contoh peta aliran nilai di atas, tim penerapan baru mengambil kode yang lulus pengujian setelah 80 jam. Mengapa demikian? Bisakah proses ini diotomatisasi? Tentu saja.
• Hilangkan pemborosan akibat serah terima berulang. Pada peta di atas, tim pengujian mengembalikan 65% fitur ke pengembangan. Perbaikan cacat tertentu perlu dikirim sampai 3 kali sebelum disetujui penguji. Bisakah iterasi ini dipercepat dengan mengintegrasikan kedua tim dengan lebih baik? Banyaknya cacat juga menunjukkan bahwa ada yang belum berjalan optimal pada tim pengembangan. Temukan dan atasi penyebab masalah mutu tersebut.
• Pertanyakan dan hilangkan sebanyak mungkin serah terima. Pada peta di atas, permintaan yang telah diperjelas baru diproses pihak pemberi persetujuan setelah 320 jam. Mengapa pihak ini dibutuhkan? Nilai apa yang ditambahkannya pada aliran nilai? Apakah mereka memiliki informasi dan wawasan yang cukup untuk memutuskan? Jika menjadi bagian dari tim yang memperjelas permintaan, mereka akan lebih memahami apa yang disetujui dan satu serah terima yang memakan waktu 320 jam dapat dihilangkan. Sulit mengharapkan hasil besar dari DevOps jika kendala dan hambatan yang memperlambat aliran tetap ada.

DevOps mendorong Anda mengajukan pertanyaan seperti ini untuk mengubah cara kerja yang sudah ada. Tidak semua orang senang mendengarnya. Anda sudah siap menghadapinya.

Tampilkan Aliran Kerja kepada Semua Orang

Agar pekerjaan bergerak dari kiri ke kanan dan organisasi DevOps mencapai sasaran, gunakan alat dan mekanisme yang memperlihatkan alirannya. Di bidang TI, hanya perlu satu klik untuk menyerahkan pekerjaan ke tim lain. Namun, pekerjaan yang belum lengkap, dependensi yang tidak konsisten, dan kesalahpahaman sering membuat pekerjaan bolak-balik antartim, “selangkah maju, dua langkah mundur”, sehingga berjalan lambat atau terhenti.

Pastikan aliran kerja terlihat oleh semua orang, bukan hanya tim sendiri. DevOps menggunakan Product Backlog, backlog perencanaan sprint, dan papan Kanban. Papan ini harus memperlihatkan tugas tim sekaligus seluruh aliran, dari ide awal produk dan layanan hingga pemeliharaan operasional dan akhir masa pakai. Dengan demikian, semua orang cepat melihat pekerjaan yang terhambat dan bertanggung jawab bersama untuk menyingkirkan hambatan agar pekerjaan kembali mengalir.

Batasi Ukuran Batch dan Pekerjaan yang Sedang Berlangsung

Penelitian di Stanford University menemukan bahwa mengerjakan beberapa hal sekaligus kurang produktif daripada mengerjakan satu hal setiap kali. Peneliti juga menemukan bahwa orang yang rutin menerima berbagai arus informasi elektronik sekaligus lebih sulit berkonsentrasi, mengingat informasi, atau beralih tugas daripada orang yang menyelesaikan satu tugas setiap kali.

Bagi tim DevOps, ini berarti mengurangi pekerjaan yang sedang berlangsung dan membatasi ukuran batch pengiriman kode. Misalnya, batasi pengembangan hingga 6 tugas aktif untuk menghindari pergantian konteks dan menjaga fokus. Anda juga dapat memperkirakan setiap tugas menggunakan poin cerita dengan bobot bilangan Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, ..). Tim menangani hingga jumlah poin tertentu (kecepatan tim) dalam periode tertentu (sprint).

Selain meningkatkan mutu dan produktivitas, membatasi ukuran batch membantu tim menemukan akar penyebab dan menyelesaikan masalah lebih cepat. Setelah tugas selesai, masukkan kode ke repositori bersama, validasi dengan platform integrasi berkelanjutan, lalu terapkan ke produksi. Batch kecil memudahkan identifikasi masalah produksi dan pembatalan perubahan jika diperlukan. Dengan terus mengirimkan ke produksi, tim juga bangga berkontribusi pada misi organisasi. Bandingkan cara kerja ini dengan semangat, motivasi, dan tantangan teknis tim yang menulis kode selama 8 bulan tanpa mengirim satu baris pun ke produksi.

Gunakan 20% Waktu untuk Mengurangi Utang Teknis

Jika organisasi tidak menyisihkan waktu untuk mengurangi utang teknis dan terus menumpuk solusi sementara, semua teknisi akhirnya akan menghabiskan seluruh waktunya memperbaiki masalah. Dalam istilah keuangan, organisasi hanya membayar bunga utangnya.

KESIMPULAN

Bab ini membahas apa itu aliran nilai dan aliran kerja dalam DevOps, mengapa keduanya penting, dan bagaimana memperlancar pekerjaan di sepanjang aliran nilai.