Agile Development

 Assalamualaikum wr wb, semoga kalian sehat selalu pembaca, kali ini saya akan membagikan sebuah materi tentang Agile development guna memberitahu kalian cara dalam melakukan manajemen proyek  dengan metodologi tertentu salah satunya adalah Agile Development, jadi gak usah banyak basa basi berikut materi nya:

PENGANTAR AGILE VS WATERFALL 

Dalam menerapkan manajemen proyek diperlukan sebuah metodologi atau pendekatan. Metodologi atau pendekatan merupakan suatu ilmu mengenai metode. Dua contoh metodologi yang sudah sangat besar dan dipakai oleh banyak orang di seluruh dunia: Waterfall dan Agile. 

Apa yang dimaksud dengan pendekatan Waterfall? 

Waterfall merupakan salah satu pendekatan manajemen proyek yang terbagi menjadi beberapa fase sekuensial. Sekuensial artinya bertahap, satu demi satu. Pendekatan ini diambil dari istilah ‘air terjun’ karena alur fase satu dengan lainnya berurutan seperti air terjun. Batas antara satu fase dengan fase lainnya disebut dengan gate. Pada ilustrasi berikut ini, diperlihatkan bagaimana fase dan gate saling terhubung. Fase dua dapat dilakukan setelah fase satu selesai, kemudian perpindahan fase dilakukan dengan melewati gate. Setelah melewati gate antara fase satu dan dua, proses pelaksanaan proyek pada dasarnya tidak bisa mengulangi pengerjaan fase satu.

  

Pendekatan ini diawali dengan menjabarkan kebutuhan atau requirements secara detil. Kebutuhan merupakan ekspektasi dan keinginan dari pemilik proyek mengenai tujuan dan hasil yang ingin dicapai oleh proyek. Setelah kebutuhan dijabarkan di awal, pendekatan ini akan mengimplementasikan change control sekali setelah requirement disetujui. Ini dilakukan untuk mendapatkan kontrol dan prediksi atas proyek dari sisi biaya dan jadwal. Mari kita ingat kembali skema Iron Triangle pada materi sebelumnya. Ilustrasi dari pelaksanaan Waterfall adalah untuk ‘mengunci’ sebuah aspek dari Iron Triangle: Lingkup. Jadi, proyek yang menerapkan pendekatan ini, berusaha memprediksi waktu dan biaya dari proyek dengan mempertimbangkan lingkup yang fixed di awal. Perhatikan ilustrasi berikut! 

Pendekatan ini setidaknya memiliki tiga fase, pengembangannya dalam berbagai bidang proyek dapat menjadi 5 hingga 6 fase. Tiga fase tersebut adalah: mendefinisikan requirements, mendesain dan membangun solusi, kemudian mengetes dan mengimplementasikan solusi. Solusi yang dimaksud adalah keluaran dari proyek. Satu fase dengan fase lainnya dibatasi oleh gate (terjemah: gerbang). Setelah melewati gate, pada dasarnya proses pengerjaan proyek tidak bisa mengulangi fase sebelumnya. Pada praktiknya, beberapa proses dibuat supaya dapat berulang meskipun sangat terbatas. Perhatikan skema berikut ini.  

Pendekatan ini populer pada tahun 1970-1990-an. Alur yang sederhana dan disiplin membuat orang-orang menyukai pendekatan ini. Sayangnya pendekatan ini lebih cocok digunakan untuk melaksanakan proyek dalam kategori keilmuan yang cenderung statis. Misalnya proyek pembangunan infrsatruktur jalan, dimana keilmuan teknik sipil dan material sangat dominan. Dua keilmuan tersebut cenderung statis dan prediktif. Sedangkan dalam dunia sistem informasi, kompleksitas dan teknologi pengembangannya sangat cepat berubah dan berkembang. Karenanya, muncul beberapa kelemahan dari pendekatan ini dalam pelaksanaan proyek IT (Information Technology). 

Tiga masalah utama pendekatan ini dalam IT adalah:  

• Bug pada program atau ketidaksesuaian ekspektasi pemilik proyek akan diketahui pada fase akhir,         setelah proses desain dan implementasi yang memakan waktu dan biaya. 

• Masukan dari end user dari produk sangat terbatas dan diberikan di akhir proses pelaksanaan                 proyek. 

• Tidak banyak change request yang diajukan pemilik proyek dan end user, hal ini akan berdampak         pada penurunan kualitas produk. 

Seiring berjalan waktu, muncul pendekatan lain yang lain: pendekatan iteratif. Pendekatan ini mencoba menjawab masalah yang tidak bisa ditangani oleh Waterfall. Ini juga menjadi cikal bakal kelahiran metodologi Agile dan turunannya. 

Agile hakikatnya bukanlah sebuah metodologi diskrit, ia merupakan cara pandang yang dibangun atas nilai dan prinsip Agile. Agile juga didefinisikan sebagai pendekatan (approach) dalam manajemen proyek dengan karakter fleksibel dan adaptif. Sebagian orang salah dalam mengartikan Agile ke dalam bentuk-bentuk baku, padahal aslinya Agile adalah cara pandang atau pendekatan. Karenanya, untuk menerapkan Agile dalam proyek kita perlu memanfaatkan alat bantu atau kerangka kerja turunan Agile. Namun itu akan kita bahas untuk materi selanjutnya. Sekarang, kita kembali dulu pada Agile Manifesto. Berikut ini adalah poin-poin dari Agile Manifesto:

• Individuals and interaction over processes and tools 

Poin pertama menggambarkan pentingnya interaksi antar manusia dalam tim. Tim pengembang dalam metodologi agile harus lebih mencurahkan pikiran dan tenaga untuk mengelola ritme kerja mandiri (individual) sekaligus mengoptimasi kominikasi antar anggotanya, alih-alih memulai dengan prosedur dan standardisasi alat-alat penunjang. 
Keanggotaan dalam tim tidak dirancang secara hirarki, dimana satu pihak perlu menerbitkan perintah sesuai birokrasi untuk menggerakkan pihak lain di ‘bawahnya’. Keanggotaan dibuat secara sirkular dimana pusatnya adalah perangkat lunak. Model ini akan memungkinkan setiap orang dalam tim memiliki rasa tanggungjawab dan posisi tersendiri dalam proses pengembangan perangkat lunak. Model ini juga mendorong interaksi satu sama lain dalam anggota tim dengan setara. Tanpa menghilangkan peran (roles) spesifik setiap orang. 

Poin agile manifesto pertama ini tidak menunjukkan bahwa proses dan tools tidak berguna, melainkan untuk menjelaskan bahwa proses dan alat pada dasarnya tidak akan responsif terhadap pengubahan akan kebutuhan dan keinginan customer. 

 

• Working software over comprehensive documentation 

Agile hadir bukan untuk mengeliminasi dokumentasi proyek pengembangan perangkat lunak, melainkan untuk mempersingkatnya. Pada metodologi tradisional, pengembangan perangkat lunak bersifat documentation driven. Kendala-kendala yang muncul dari sfiat inilah yang coba ditanggulangi untuk menghasilkan proses pengembangan yang lebih fleskibel dan adaptif. Agile tetap menerima proses modelling dan dokumentasi hanya apabila keuntungan dari proses tersebut sangat jelas dan tuntas. 

 

• Customer collaboration over contract negotiation 

Dalam dunia drama pengembangan perangkat lunak, customer sering digambarkan sebagai pihak yang tidak mau tahu akan proses pengembangan. Yang diinginkan adalah supaya perangkat lunak selesai tepat waktu, dana tidak bocor, dan fitur lengkap. Lalu pengembang akan banting tulang siang malam hingga begadang untuk merampungkan aplikasi ‘seadanya’. Saat customer mencoba aplikasi, rupanya tidak sesuai espektasi. Meminta perbaikan pun akan sulit karena menambah waktu dan biaya. Akhirnya produk tidak pernah muncul di halaman unduhan aplikasi. Ini adalah mimpi buruk bagi customer dan developer.  

Membangun perangkat lunak tidak pernah sama dengan membangun gedung bertingkat. Membuat kontrak di awal untuk membatasi waktu dan biaya malah jadi bumerang bagi semua pihak. Maka terminologi kolaborasi dijadikan jembatan untuk mempertemukan kenyataan dengan kebutuhan. Menjembatani idealisme pelanggan dengan kompleksitas teknis yang dihadapi pengembang. Setelah dijembatani, timbullah empati yang menjadi kunci dari kualitas perangkat lunak yang dikembangkan. 

 

• Responding to change over following a plan 

Merespon terhadap pengubahan dalam pengembangan perangkat lunak awalnya tabu dan sulit dilakukan. Atau setidaknya disimpan untuk dikerjakan entah kapan. Padahal seringkali customer baru menyadari kebutuhannya setelah keinginannya diimplementasikan dalam bentuk aplikasi. Fenomena ini yang membuat metode manajemen proyek yang berjalan sekuensial tidak lagi relevan. Dibutuhkan proses yang memfasilitasi pengubahan yang sifatnya iteratif. 

  

 

Apa keuntungan menggunakan Agile? Dalam Agile, kepuasan pelanggan atas kualitas produk lebih terjamin dibanding Waterfall. Mengapa begitu? Ini karena, Agile memberikan kelonggaran untuk menerima masukan akan pengubahan dari klien, walaupun itu harus memakan waktu lebih. Kualitas akan menjadi variabel yang bisa terus dikembangkan, sedangkan waktu dan biaya akan difiksasi berdasarkan iterasi yang dibutuhkan. Tapi ini sekaligus membuat Agile lebih hemat secara waktu dan biaya. Bagaimana bisa? Karena pada praktiknya, Agile memungkinkan untuk menyelesaikan produk lebih cepat meski dengan fitur bertahap. Akibatnya, klien dapat memperjelas ekspektasinya secara bertahap atau iteratif. Tidak menutup kemungkinan, ekspektasi klien terjawab lebih cepat karena proses iterasi yang dilakukan. Agile dapat menjawab masalah yang timbul akibat kompleksitas proyek yang tinggi, masalah yang tidak dapat ditangani oleh Waterfall. Dengan kompleksitas yang tinggi, pengubahan perlu dilakukan lebih banyak sekaligus rapi. Hal inilah yang dapat dijawab oleh Agile. 

Namun apakah Agile cocok digunakan pada semua proyek? Apakah Agile selalu lebih unggul dibanding Waterfall? 

Kita coba ingat kembali bagaimana karakter dari masing-masing pendekatan. Waterfall adalah pendekatan manajemen proyek yang bersifat sekuensial. Kelebihannya adalah pada kesederhanaan dan menggambarkan kebutuhan sedetil mungkin di awal proyek. Kelemahan pendekatan ini adalah tidak bisa menangani proyek yang kompleks, dimana biasanya terdapat banyak change request di tengah-tengah keberjalanan proyek.  

 

Nah itu tadi yang bisa saya bagikan , harap para pembaca bisa memahami tulisan saya pada postingan kali ini, Akhir kata saya ucapkan terimakasih dan jumpa lagi wassalamualaikum wr wb.

Source : (Shofiyah A.I . MODUL AGILE DEVELOPMENT)