Apa yang dimaksud dengan Agile?

Agile adalah istilah yang menjelaskan pendekatan untuk pengembangan perangkat lunak yang menekankan pengiriman bertahap, kolaborasi tim, perencanaan berkelanjutan, dan pembelajaran berkelanjutan. Istilah Agile ditemukan pada tahun 2001 di Agile Manifesto. Manifesto ini menetapkan prinsip-prinsip untuk memandu pendekatan yang lebih baik untuk pengembangan perangkat lunak. Pada intinya, manifesto menyatakan empat pernyataan nilai yang mewakili fondasi gerakan Agile. Seperti yang ditulis, manifesto menyatakan:

Kami telah mencapai nilai:

• Individu dan interaksi melalui proses dan alat.
• Perangkat lunak yang berfungsi melalui dokumentasi yang komprehensif.
• Kolaborasi pelanggan melalui negosiasi kontrak.
• Menanggapi perubahan mengikuti rencana.

Manifesto tidak menyiratkan bahwa item di sisi kanan pernyataan ini tidak penting atau diperlukan. Sebaliknya, item di sebelah kiri hanya lebih dihargai.

Metode dan praktik agile

Penting untuk dipahami bahwa Agile bukanlah suatu hal. Anda tidak melakukan Agile. Sebaliknya, Agile adalah pola pikir yang mendorong pendekatan untuk pengembangan perangkat lunak. Karena tidak ada pendekatan tunggal yang berfungsi untuk semua situasi, istilah Agile telah mewakili berbagai metode dan praktik yang selaras dengan pernyataan nilai dalam manifesto.

Metode agile, yang sering disebut kerangka kerja, adalah pendekatan komprehensif untuk fase siklus hidup DevOps: perencanaan, pengembangan, pengiriman, dan operasi. Mereka meresepkan metode untuk menyelesaikan pekerjaan, dengan panduan dan prinsip yang jelas.

Scrum adalah kerangka kerja Agile yang paling umum, dan kerangka kerja yang dimulai oleh sebagian besar orang. Praktik tangkas, di sisi lain, adalah teknik yang diterapkan selama fase siklus hidup pengembangan perangkat lunak.

• Merencanakan Poker adalah praktik estimasi kolaboratif yang dirancang untuk mendorong anggota tim berbagi pemahaman mereka tentang apa yang dilakukan berarti. Banyak orang menemukan proses yang menyenangkan, dan telah terbukti membantu menumbuhkan kerja tim dan perkiraan yang lebih baik.
• Integrasi berkelanjutan (CI) adalah praktik teknik Agile umum yang melibatkan integrasi perubahan kode ke cabang utama secara sering. Build otomatis memverifikasi perubahan. Akibatnya, ada pengurangan utang integrasi dan cabang utama yang terus dikirim.

Praktik ini, seperti semua praktik Agile, membawa label Agile , karena konsisten dengan prinsip-prinsip dalam manifesto Agile.

Yang bukan Agile

Karena Agile telah mendapatkan popularitas, banyak stereotip dan salah tafsir telah melemparkan bayangan negatif pada efektivitasnya. Sangat mudah mengatakan "Ya, kami melakukan Agile," tanpa akuntabilitas apa pun. Mengingat hal ini, pertimbangkan beberapa hal yang Agile tidak.

• Agile bukan koboi pengkodean. Agile tidak boleh bingung dengan pendekatan "kami akan mencari tahu saat kami pergi" untuk pengembangan perangkat lunak. Ide seperti itu tidak bisa lebih jauh dari kebenaran. Agile memerlukan definisi nilai yang dilakukan dan eksplisit yang dikirimkan kepada pelanggan di setiap sprint. Sementara Otonomi nilai Agile untuk individu dan tim, itu menekankan otonomi yang selaras untuk memastikan bahwa peningkatan otonomi menghasilkan nilai yang meningkat.
• Tangkas bukan tanpa kekakuan dan perencanaan. Sebaliknya, metodologi dan praktik Agile biasanya menekankan disiplin dalam perencanaan. Kuncinya adalah perencanaan berkelanjutan di seluruh proyek, bukan hanya merencanakan di depan. Perencanaan berkelanjutan memastikan bahwa tim dapat belajar dari pekerjaan yang mereka jalankan. Melalui pendekatan ini, mereka memaksimalkan return on investment (ROI) perencanaan.

"Rencana tidak berharga, tetapi perencanaan adalah segalanya." — Dwight D. Eisenhower

• Agile bukan alasan untuk kurangnya peta jalan. Kesalahpahaman ini mungkin telah melakukan yang paling membahayakan gerakan Agile secara keseluruhan. Organisasi dan tim yang mengikuti pendekatan Agile benar-benar tahu ke mana mereka pergi dan hasil yang ingin mereka capai. Mengenali perubahan sebagai bagian dari proses berbeda dari pivot ke arah baru setiap minggu, sprint, atau bulan.
• Agile bukan pengembangan tanpa spesifikasi. Diperlukan dalam proyek apa pun untuk menjaga tim Anda selaras tentang mengapa dan bagaimana pekerjaan terjadi. Pendekatan Agile untuk spesifikasi termasuk memastikan bahwa spesifikasi berukuran tepat, dan bahwa spesifikasi tersebut mencerminkan dengan tepat bagaimana tim mengurutkan dan memberikan pekerjaan.
• Agile tidak mampu mengakomodasi pekerjaan yang tidak dienkripsi dan gangguan lainnya. Penting untuk menyelesaikan sprint sesuai jadwal. Tetapi hanya karena masalah muncul bahwa pengembangan sidetracks tidak berarti bahwa sprint harus gagal. Teams dapat merencanakan gangguan dengan menunjuk sumber daya sebelumnya untuk masalah dan masalah yang tidak terduga. Kemudian mereka dapat mengatasi masalah tersebut tetapi tetap berada di jalur pengembangan.
• Agile tidak pantas untuk organisasi besar. Keluhan umum adalah bahwa kolaborasi, komponen utama metodologi Agile, sulit dalam tim besar. Keluhan lain adalah pendekatan yang dapat diskalakan untuk Agile memperkenalkan struktur dan metode yang membahayakan fleksibilitas. Terlepas dari kesalahpahaman ini, dimungkinkan untuk menskalakan prinsip Agile dengan sukses. Untuk informasi tentang mengatasi kesulitan ini, lihat Menskalakan Agile ke tim besar.
• Tangkas tidak efisien. Untuk beradaptasi dengan perubahan kebutuhan pelanggan, pengembang menginvestasikan waktu setiap iterasi untuk menunjukkan produk yang berfungsi dan mengumpulkan umpan balik. Memang benar bahwa upaya ini mengurangi waktu yang mereka habiskan untuk pengembangan. Tetapi menggabungkan permintaan pelanggan lebih awal menghemat waktu yang signifikan nanti. Ketika fitur tetap selaras dengan visi pelanggan, pengembang menghindari perombakan besar-besaran di garis bawah.
• Agile tidak cocok untuk aplikasi saat ini, yang sering berpusat pada streaming data. Proyek tersebut biasanya melibatkan lebih banyak pemodelan data dan beban kerja extract-transform-load (ETL) daripada antarmuka pengguna. Fakta ini menyulitkan untuk menunjukkan perangkat lunak yang dapat digunakan pada jadwal yang konsisten dan ketat. Tetapi dengan menyesuaikan tujuan, pengembang masih dapat menggunakan pendekatan Agile. Alih-alih bekerja untuk menyelesaikan tugas setiap perulangan, pengembang dapat fokus menjalankan eksperimen data. Alih-alih menyajikan produk yang berfungsi setiap beberapa minggu, mereka dapat bertujuan untuk lebih memahami data.

Mengapa Agile?

Jadi mengapa ada yang mempertimbangkan pendekatan Agile? Jelas bahwa aturan keterlibatan di sekitar membangun perangkat lunak pada dasarnya telah berubah dalam 10-15 tahun terakhir. Banyak aktivitas terlihat mirip, tetapi lanskap dan lingkungan tempat kami menerapkannya terlihat berbeda.

• Bandingkan seperti apa rasanya membeli perangkat lunak hari ini dengan awal 2000-an. Seberapa sering orang mengemudi ke toko untuk membeli perangkat lunak bisnis?
• Pertimbangkan bagaimana umpan balik dikumpulkan dari pelanggan tentang produk. Bagaimana tim memahami apa yang orang pikirkan tentang perangkat lunak mereka sebelum media sosial?
• Pertimbangkan seberapa sering tim ingin memperbarui dan meningkatkan perangkat lunak yang mereka berikan. Pembaruan tahunan tidak lagi layak terhadap kompetisi modern.

Diego Lo Guidice forrester mengatakan yang terbaik dalam blognya, Mengubah Pengiriman Aplikasi (Oktober, 2020).

"Semuanya telah berubah secara dramatis. Keberlanjutan, selain hijau dan bersih, berarti bahwa apa yang kita bangun saat ini harus mudah dan cepat diubah besok. Rencana strategis bersifat jangka pendek, dan perencanaan dan perubahan berkelanjutan." — Diego Lo Guidice, Forrester

Aturan telah berubah, dan organisasi di seluruh dunia sekarang menyesuaikan pendekatan mereka dengan pengembangan perangkat lunak yang sesuai. Metode dan praktik Agile tidak menjanjikan untuk menyelesaikan setiap masalah. Tetapi mereka berjanji untuk membangun budaya dan lingkungan di mana solusi muncul melalui kolaborasi, perencanaan dan pembelajaran berkelanjutan, dan keinginan untuk mengirim perangkat lunak berkualitas tinggi lebih sering.

Langkah berikutnya

Memutuskan untuk mengambil rute Agile ke pengembangan perangkat lunak dapat memperkenalkan beberapa peluang menarik untuk meningkatkan proses DevOps Anda. Satu set pertimbangan utama berfokus pada pembandingan pengembangan Agile dan kontras dengan pendekatan organisasi saat ini.