Adaptive software development: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k Mimihitam memindahkan halaman Adaptive Software Development ke Adaptive software development |
k Bot: Perubahan kosmetika |
||
Baris 1:
'''''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
== Siklus hidup ASD ==
Baris 8:
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" />.
Baris 16:
=== ''Learn: Quality Review'' ===
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
== Referensi ==
| |||