Agile Software Development
Pengembangan PL menggunakan
Metode Agile
Topik
Pengembangan PL dengan Cepat (rapid)
Metode Agile
Prinsip-prinsip Metode Agile
Penerapan Metode Agile
Kelemahan Metode Agile
Pengembangan PL dengan cepat (rapid)
Pengembangan PL cepat adalah salah satu kebutuhan penting untuk sistem PL.
Bisnis beroperasi dengan cepat, perubahan
kebutuhan yang cepat menjadikan sulit sekali untuk membuat kebutuhan PL yang stabil.
PL harus berevolusi dengan cepat untuk memenuhi
kebutuhan bisnis yang cepat berganti.
Pengembangan PL dengan cepat (rapid)
Spesifikasi, desain, dan implementasi dilakukan secara berselang seling.
Sistem dibangun dalam urutan versi, dimana
pemangku kepentingan terlibat dalam evaluasi tiap versi.
Antarmuka (GUI) dibangun menggunakan IDE
(integrated development environment) atau kakas
grafis.
Metode Agile
Ketidakpuasan akan metode desain tahun 1980-an dan 1990-an menyebabkan lahirnya metode Agile.
Metode Agile memiliki karakteristik:
Fokus kepada kode daripada desain.
Berbasis kepada pendekatan iteratif.
Menyelesaikan PL dengan cepat dan berevolusi
dengan cepat untuk memenuhi perubahan kebutuhan pengguna PL.
Menghilangkan biaya ekstra (overhead) pada proses PL dan merespon dengan cepat perubahan
kebutuhan tanpa kerja ulang yang terlalu banyak.
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
Prinsip-prinsip Metode Agile
Prinsip Deskripsi
Keterlibatan pengguna Pengguna harus ikut terlibat dalam proses pengembangan.
Peran mereka adalah untuk menyediakan dan memberi prioritas terhadap kebutuhan sistem baru, dan mengevaluasi iterasi pada sistem.
Penyelesaian bertahap PL dibangun secara bertahap dengan pengguna ikut
menentukan kebutuhan yang termasuk dalam setiap tahapan.
Fokus pada orang bukan proses
Keahlian dan kemampuan tim pengembang harus
dimanfaatkan. Anggota tim harus diberi kebebasan untuk menentukan cara bekerja mereka sendiri.
Mengakomodasi Perubahan
Mengantisipasi kebutuhan sistem akan berubah sehingga membuat desain sistem yang dapat mengakomodasi perubahan.
Menjaga Fokus kepada kesederhanaan PL yang sedang dibangun.
Penerapan Metode Agile
Pengembangan PL dimana produk yang dibangun berskala kecil atau menengah.
Pengembangan sistem dimana ada komitmen jelas dari pengguna untuk ikut terlibat didalam proses pengembangan PL dan tidak ada banyak aturan luar dan regulasi yang mempengaruhi PL.
Dikarenakan fokus kepada sistem yang kecil, maka
penerapan metode Agile pada sistem besar akan
menemukan masalah.
Kelemahan Metode Agile
Akan sulit menjaga minat pengguna PL untuk tetap terlibat dalam proses pengembangan.
Anggota tim mungkin tidak sesuai dengan karakteristik metode Agile.
Memberi prioritas pada perubahan akan sulit jika ada banyak pemangku kepentingan.
Menjaga kesederhanaan sistem memerlukan kerja ekstra.
Kontrak bisa menjadi masalah sama halnya dengan
pendekatan pengembangan iteratif.
Metode Agile dan Perawatan PL
Banyak organisasi lebih banyak menghabiskan
waktu merawat PL dibandingkan membangun PL.
Sehingga agar metode Agile sukses maka perawatan PL harus didukung penuh sama halnya dengan
pengembangan PL.
Masalah bisa muncul jika tim pengembang asli
tidak dapat dipertahankan.
Plan-driven dan Pengembangan Agile
Pengembangan dengan Plan-driven
Terbagi atas tahapan-tahapan yang keluarannya telah direncanakan diawal.
Pengembangan dengan Agile
Spesifikasi, desain, implementasi, dan uji coba
dilakukan secara berselang. Keluaran dari proses
pengembangan ditentukan melalui proses negosiasi
selama proses pengembangan PL.
Plan-driven dan Pengembangan Agile
Isu Teknis, SDM, dan Organisasi
Kebanyakan proyek melibatkan elemen-elemen dari plan-driven dan proses Agile. Keseimbangan antara keduanya tergantung dari:
Apakah sangat penting untuk memiliki spesifikasi dan desain yang sangat detil sebelum berpindah ke
implementasi? Jika benar maka kemungkinan pendekatan plan-driven lebih cocok.
Apakah melibatkan pengguna PL untuk mendapatkan
umpan balik dengan cepat sangat realistis? Jika benar
gunakan metode Agile.
Isu Teknis, SDM, dan Organisasi
Seberapa besar sistem yang akan dibangun?
Metode agile cocok dengan sistem yang dibangun oleh tim kecil. Jika membutuhkan tim besar maka pendekatan plan-driven lebih cocok.
Apakah tipe dari sistem yang akan dibangun?
Pendekatan plan-driven dibutuhkan untuk
membangun sistem yang membutuhkan banyak analisis sebelum implementasi.
Berapa lama umur hidup sistem? Sistem dengan
umur hidup lama membutuhkan dokumentasi
Isu Teknis, SDM, dan Organisasi
Teknologi apa yang tersedia untuk mendukung pengembangan sistem? Metode agile tergantung pada kakas berkualitas untuk mengakomodasi desain yang berevolusi.
Bagaimana organisasi tim pengembang? Jika time pengembang tersebar, maka sebuah dokumen
desain perlu dibuat untuk berkomunikasi.
Seberapa bagus kualitas desainer dan programer di tim pengembang? Metode agile membutuhkan
kualitas individu yang lebih tinggi.
Extreme Programming (XP)
Topik
Extreme Programming
Refactoring
Uji coba (Testing)
Pair Programming
Extreme Programming
Metode agile yang paling terkenal dan banyak digunakan.
Pendekatan “ekstrim” terhadap pengembangan iteratif.
Versi-versi baru dibangun beberapa kali dalam satu hari.
Tahapan-tahapan diselesaikan setiap 2 minggu.
Semua uji coba harus dijalankan untuk setiap build,
dan sebuah build diterima jika uji coba berjalan
XP dan Prinsip Agile
Pengembangan bertahap didukung melalui rilis sistem kecil namun sering.
Keterlibatan pengguna berarti keterlibatan penuh pengguna di dalam tim.
Fokus pada orang melalui pair programming, kepemilikan bersama, dan proses yang
menghindari waktu kerja yang panjang.
Perubahan diakomodir melalui rilis sistem yang teratur.
Menjaga kesederhanaan sistem dengan melakukan
refactoring kode.
Putaran Rilis XP
Praktek-praktek XP
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6.
Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements and no more.
Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as
Praktek-praktek XP
Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity
On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an
Skenario Kebutuhan
Dalam XP, pengguna adalah bagian dari tim XP, dan
bertanggung jawab untuk mengambil keputusan dalam spesifikasi kebutuhan.
Kebutuhan pengguna dituangkan dalam bentuk skenario atau “user stories.”
Skenario tertulis diatas kertas dan tim pengembang membagi menjadi tugas-tugas implementasi
(implementation tasks). Tugas tersebut menjadi basis penjadwalan dan perhitungan biaya.
Pengguna menentukan skenario yang akan diikutkan
pada rilis selanjutnya berdasarkan skala prioritas.
Contoh: skenario “prescribing
medication”
Contoh “task cards” untuk prescribing
medication
Refactoring
Tim programmer mencari kemungkinan untuk meningkatkan kualitas PL meskipun tidak ada
kebutuhan mendesak untuk peningkatan kualitas PL.
Membuat kode PL mudah dipahami sehingga mengurangi kebutuhan akan dokumentasi PL.
Perubahan lebih mudah dilakukan karena kode yang terstruktur dan jelas.
Akan tetapi, beberapa perubahan membutuhkan
refactoring pada arsitektur dan membutuhkan
Contoh Refactoring
Organisasi ulang hirarki kelas untuk menghilangkan duplikasi kode.
Membersihkan dan mengganti nama-nama atribut dan method agar mudah dipahami.
Mengganti kode dengan method-method yang
sudah tersedia didalam pustaka.
Uji coba dalam XP
Uji coba memegang peranan penting dalam XP.
Program diuji coba setiap ada perubahan.
Fitur-fitur uji coba dalam XP:
Pengembangan berbasis uji coba (test first driven development)
Pengembangan uji coba bertahap dari skenario (incremental test development)
Keterlibatan pengguna dalam pembuatan uji coba dan
validasi
Test-first development
Menulis kode uji coba sebelum kode implementasi untuk mengklarifikasi spesifikasi kebutuhan yang akan diimplementasikan.
Uji coba ditulis sebagai program sehingga dapat dijalankan secara otomatis.
