Adaptive software development: Perbedaan antara revisi

'''''Adaptive Software Development''''' adalah pendekatan ''[[Extreme programming|Extreme Programming]]'' yang dimodifikasi, yang merupakan ''agile model'' yang paling banyak digunakan.<ref>{{Cite journal|last=Qureshi|first=Muhammad|year=2007|title=An adaptive software development process model|url=|journal=Advances in Engineering Software|volume=|issue=|pages=|doi=}}</ref>. ''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)''<ref>{{Cite book|title=Software engineering : a practitioner's approach|url=http://worldcat.org/oclc/949696534|publisher=McGraw-Hill Education|date=2015|isbn=9781259253157|oclc=949696534|last=Pressman, Roger S.}}</ref>''.''

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.<ref name=":0">{{Cite book|title=The one minute methodology|url=http://worldcat.org/oclc/26725304|publisher=Dorset House|date=1990|isbn=093263317X|oclc=26725304|last=Orr, Ken.}}</ref>.

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.<ref name=":0" />.

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.<ref name=":0" />.

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.<ref name=":0" />.

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.<ref name=":0" />.

Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar pertama kali" mendominasi dan perkembangan berlangsung secara linear ''([[Model Waterfall|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 pelangga, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik dimanfaatkan, dan status proyek.<ref name=":0" />.