Adaptive software development
Adaptive Software Development adalah pendekatan Extreme Programming yang dimodifikasi, yang merupakan agile model yang paling banyak digunakan.[1] Adaptive Software Development (ASD) telah diusulkan oleh Jim Highsmith [Hig00] sebagai teknik untuk membangun perangkat lunak dan sistem yang kompleks. Dasar-dasar filosofis ASD fokus pada kolaborasi manusia dan pengaturan diri tim. Highsmith berpendapat bahwa pendekatan pengembangan yang agile dan adaptif berdasarkan kolaborasi adalah "sebanyak-banyaknya sumber order dalam interaksi kompleks sebagai disiplin dan rekayasa." Highsmith mendefinisikan siklus hidup ASD yang terdiri dari tiga fase, spekulasi (speculation), kolaborasi (collaboration) , dan pembelajaran (learning)[2].
Siklus hidup ASD
[sunting | sunting sumber]Speculate: Initiation and Planning
[sunting | sunting sumber]Ada lima langkah umum dalam "berspekulasi" meskipun kata "langkah" agak keliru, karena setiap langkah dapat direvisi beberapa kali selama fase inisiasi (initiation) dan perencanaan (planning). Pertama, inisiasi proyek melibatkan pengaturan misi dan tujuan proyek, memahami kendala, menetapkan organisasi proyek, mengidentifikasi dan menguraikan kebutuhan, membuat perkiraan ukuran dan ruang lingkup awal, dan mengidentifikasi risiko proyek utama. Karena kecepatan biasanya menjadi pertimbangan utama dalam menggunakan ASD, banyak data inisiasi proyek harus dikumpulkan dalam sesi awal JAD. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk proyek berukuran kecil hingga menengah atau memakan waktu dua atau tiga minggu untuk proyek yang lebih besar. Selama sesi JAD, kebutuhan dikumpulkan secara cukup rinci untuk mengidentifikasi fitur dan menetapkan kerangka objek, data, atau model arsitektur lainnya.[3]
Selanjutnya, kotak waktu (time-box) untuk seluruh proyek ditetapkan berdasarkan ruang lingkup, kebutuhan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan dari pekerjaan inisiasi proyek. Berspekulasi tidak mengabaikan estimasi, itu hanya berarti menerima bahwa estimasi itu lemah. Langkah ketiga adalah memutuskan jumlah iterasi dan menetapkan kotak waktu untuk masing-masing. Untuk aplikasi kecil hingga menengah, iterasi biasanya bervariasi dari empat hingga delapan minggu. Beberapa proyek bekerja paling baik dengan iterasi dua minggu, sementara yang lain mungkin membutuhkan lebih dari delapan minggu (walaupun ini jarang terjadi). Ukuran proyek keseluruhan dan tingkat ketidakpastian adalah dua faktor yang menentukan panjang iterasi individu.[3]
Setelah menetapkan jumlah iterasi dan jadwal untuk masing-masing, anggota tim mengembangkan tema atau tujuan untuk masing-masing iterasi. Seperti sama pentingnya untuk menetapkan tujuan proyek secara keseluruhan, setiap iterasi harus memiliki tema sendiri (ini mirip dengan Sprint Goal in Scrum). Setiap iterasi memberikan serangkaian fitur yang dapat dibuktikan ke proses tinjauan pelanggan, membuat produk terlihat oleh pelanggan. Di dalam iterasi, "builds" menghadirkan fitur-fitur kerja ke proses integrasi harian (atau lebih sering), menjadikan produk terlihat oleh tim pengembangan. Pengujian merupakan bagian integral dan berkelanjutan dari pengembangan fitur — bukan aktivitas yang dilakukan pada tahap akhir.[3]
Pengembang dan pelanggan menetapkan fitur untuk setiap iterasi. Kriteria paling penting untuk penugasan fitur adalah bahwa setiap iterasi harus memberikan serangkaian fitur yang visible dan tangible kepada pelanggan. Dalam proses penugasan, pelanggan memutuskan prioritas fitur, menggunakan perkiraan fitur, risiko, dan informasi ketergantungan yang disediakan oleh tim pengembangan. Spreadsheet adalah alat yang efektif untuk perencanaan iterasi berbasis fitur. Pengalaman menunjukkan bahwa jenis perencanaan ini — dilakukan sebagai tim dan bukan oleh manajer proyek — memberikan pemahaman yang lebih baik tentang proyek daripada pendekatan berbasis tugas tradisional. Perencanaan berbasis fitur mencerminkan keunikan masing-masing proyek.[3]
Collaborate: Concurrent Feature Develompent
[sunting | sunting sumber]Sementara tim teknis menyediakan perangkat lunak yang berfungsi, manajer proyek memfasilitasi kolaborasi dan kegiatan pengembangan bersamaan. Untuk proyek yang melibatkan tim terdistribusi, berbagai mitra aliansi, dan pengetahuan yang luas, bagaimana orang berinteraksi dan bagaimana mereka mengelola ketergantungan adalah masalah penting. Untuk proyek yang lebih kecil di mana anggota tim bekerja dalam kedekatan fisik, kolaborasi dapat terdiri dari obrolan informal dan papan tulis. Namun, proyek yang lebih besar membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek. Kolaborasi, suatu tindakan penciptaan bersama, dipupuk oleh kepercayaan dan rasa hormat. Penciptaan bersama mencakup tim pengembangan, pelanggan, konsultan luar, dan vendor. Tim harus berkolaborasi dalam masalah teknis, kebutuhan bisnis, dan pengambilan keputusan yang cepat.[3]
Learn: Quality Review
[sunting | sunting sumber]Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar pertama kali" mendominasi dan perkembangan berlangsung secara linear (waterfall). Jika orang terus dipaksa untuk melakukannya dengan benar, mereka tidak akan bereksperimen dan belajar. Dalam pengembangan waterfall, setiap penyelesaian fase menghambat mundur karena tidak boleh ada kesalahan. Belajar dari kesalahan dan eksperimen mengharuskan anggota tim membagikan kode dan artefak yang diselesaikan sebagian lebih awal, untuk menemukan kesalahan, belajar dari mereka, dan mengurangi jumlah total pengerjaan ulang dengan menemukan masalah kecil sebelum menjadi masalah besar. Tim harus belajar membedakan antara pekerjaan jelek dan pekerjaan setengah jadi. Terdapat 4 kategori umum untuk hal yang harus dipelajari pada setiap iterasi pengembangan, yaitu kualitas hasil dari perspektif pelanggan, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik dimanfaatkan, dan status proyek.[3]
Referensi
[sunting | sunting sumber]
- ^ Qureshi, Muhammad (2007). "An adaptive software development process model". Advances in Engineering Software.
- ^ Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ a b c d e f Orr, Ken. (1990). The one minute methodology. Dorset House. ISBN 093263317X. OCLC 26725304.