Dasar-dasar Extreme Programming (XP)
XP adalah sebuah proses perangkat lunak yang membantu pengembang membuat kode berkualitas dengan cepat. Di sini, kita mendefinisikan kualitas sebagai sebuah basis kode yang sesuai dengan desain spesifikasi dan ekspektasi pelanggan.
XP fokus pada:
- Implementasi desain sederhana
- Komunikasi antara pengembang dan pelanggan
- Secara terus menerus menguji basis kode
- Refaktorisasi untuk mengakomodasi perubahan spesifikasi
- Mencari timbal balik pelanggan
XP cenderung bekerja dengan baik untuk usaha pengembangan dengan ukuran kecil sampai sedang dalam lingkungan yang memiliki perubahan spesifikasi yang sering, dan di mana komunikasi yang mendekati secara mudah.
XP berbeda dengan proses pengembangan tradisional dalam beberapa hal. Pertama, hal ini menghindari sindrom proyek skala besar yang mana pelanggan dan tim pemrograman bertemu untuk mendesain setiap rincian dari aplikasi sebelum koding dimulai. Project manager mengetahui pendekatan ini memiliki kelemahan tersendiri, tidak sedikit yang mana spesifikasi pelanggan dan kebutuhan berubah terus menerus untuk merefleksikan aturan bisnis yang baru atau kondisi pasar. Contohnya, departemen keuangan mungkin menginginkan laporan pembayaran diurutkan dengan proses tanggal dibandingkan dengan nomor cek. Atau departemen pemasaran mungkin menjelaskan bahwa pelanggan tidak akan membeli produk XYZ jika tidak dikiriman sebuah e-mail setelah registrasi pada website. Sebaliknya, sesi perencanaan XP fokus pada pengumpulan kebutuhan umum aplikasi, tidak mempersempit pada setiap rincian.
Perbedaan lain pada metodologi XP adalah menghindari koding yang tidak diperlukan fungsionalitasnya. Jika pelanggan Anda berpikir bahwa fitur itu dibutuhkan tetapi tidak wajib ada, hal ini secara umum akan ditinggalkan dari rilisan. Oleh sebab itu, Anda akan fokus pada tugas yang ada, menambahkan nilai ke sebuah produk software. Konsentrasi hanya pada fungsi yang diwajibkan ada membantu Anda memproduksi perangkat lunak yang berkualitas dalam jangka waktu yang singkat.
Tetapi perbedaan utama XP dibanding dengan metodologi tradisional adalah pendekatannya pada pengujian. Setelah sebuah fase desain yang inklusif, model pengembangan perangkat lunak tradisional menyarankan Anda membuat kode terlebih dahulu dan membuat antarmuka pengujian kemudian. Pada XP, Anda harus membuat pengujian unit terlebih dahulu, lalu menulis kode untuk lolos dari pengujian. Anda mendesain pngujian unit dalam sebuah lingkungan XP dengan mengikuti konsep yang telah didiskusikan pada Bab 5.
Model Pengembangan XP memiliki 12 praktik inti yang mengarahkan proses, dirangkum pada tabel 1. Singkatnya, Anda dapat mengelompokkan 12 praktik inti XP ke dalam 4 konsep:
- Mendengarkan pelanggan dan pemrogram lain
- Kolaborasi dengan pelanggan untuk mengembangkan spesifikasi aplikasi dan kasus pengujian
- Koding dengan seorang rekan pemrograman
- Pengujian dan pengujian kembali basis kode
Sebagian besar komentar dari setiap praktik yang terdaftar pada table 1 bisa menjelaskan beberapa hal dari prinsip dasar yang penting. Selain itu, seperti perencanaan dan pengujian, diperlukan diskusi yang lebih jauh lagi.
Perencanaan XP
Fase perencanaan yang sukses bergantung pada dasar dari proses XP. Fase perencanan dalam XP berbeda dari model pengembangan tradisional, yang seringkali mengombinasikan pengumpulan kebutuhan dan desain aplikasi. Perencanaan pada XP fokus pada identifikasi kebutuhan aplikasi pelanggan dan mendesain cerita pengguna (atau cerita kasus) yang sesuai. Anda memperoleh wawasan tambahan dalam tujuan aplikasi dan kebutuhan dengan membuat cerita pengguna. Untuk tambahan, pelanggan menggunakan cerita pengguna ketika menjalankan pengujian penerimaan di akhir dari suatu siklus perilisan. Akhirnya, sebuah keuntungan yang nyata dari fase perencanaan adalah pelanggan memperoleh kepemilikan dan kepercayaan dalam aplikasi dengan berpartisipasi di dalamnya.
Tabel 1. 12 Praktik Extreme Programming
Praktik | Komentar |
1. Perencanaan dan kebutuhan |
Personil pemasaran dan pengembangan bisnis bekerja bersama untuk mengidentifikasi nilai bisnis yang maksimal dari setiap fitur perangkat lunak. Setiap fitur utama perangkat lunak ditulis sebagai cerita pengguna. Pemrogram menyediakan estimasi waktu untuk penyelesaian setiap cerita pengguna. Pengguna memilih fitur perangkat lunak berdasarkan estimasi waktu dan nilai bisnis. |
2. Perilisan penambahan kecil |
Berusaha untuk menambahkan fitur kecil yang nyata dan memberi nilai lebih serta merilis basis kode sesering mungkin. |
3. Metafora system | Tim pemrograman Anda mengidentifikasi suatu metafora pengaturan untuk membantu konvensi penamaan dan alur program. |
4. Desain sederhana |
Implementasi desain yang paling sederhana yang memungkinkan kode Anda untuk lolos pengujian unit. Asumsikan akan ada perubahan, sehingga jangan membuang banyak waktu untuk mendesain, langsung implementasikan. |
5. Pengujian berkelanjutan |
Tulis pengujian unit sebelum menulis modul kode. Setiap unit belum lengkap sampai bisa lolos pengujian unit. Lebih jauh, program belum lengkap sampai telah melewati semua pengujian unit dan pengujian penerimaan. |
6. Refaktorisasi |
Membersihkan dan menyederhanakan basis kode Anda. Pengujian unit membantu memastikan bahwa Anda tidak menghancurkan fungsionalitas dalam prosesnya. Anda harus mengulang semua pengujian unit setelah ada refaktorisasi. |
7. Pemrograman sepasang |
Anda dan pemrogram lain bekerja bersama, dengan mesin yang sama, untuk membuat basis kode. Hal ini memungkinkan ulasan kode secara langsung, yang mana secara dramatis memfasilitasi deteksi gangguan dan resolusi. |
8. Kepemilikan kolektif atas kode |
Semua kode adalah hak milik semua pemrogram. Tidak ada satu pun pemrogram yang didedikasikan untuk basis kode spesifik. |
9. Integrasi berkelanjutan |
Setiap hari, integrasikan semua perubahan, setelah kode melewati pengujian unit, kembalikan ke dalam basis kode. |
10. Kerja 40 jam per minggu |
Tidak diizinkan adanya lembur, jika Anda bekerja dengan dedikasi selama 40 jam per minggu, jam lembur tidak dibutuhkan. Pengecualian hanya untuk minggu sebelum perilisan. |
11. Kehadiran pelanggan di tempat |
Anda dan tim pemrograman memiliki akses tidak terbatas ke pelanggan, untuk memungkinkan Anda untuk menyelesaikan pertanyaan secara cepat dan meyakinkan, yang mana menjaga penguluran proses pengembangan. |
12. Standar Pemrograman |
Semua kode seharusnya terlihat sama. Pengembangan sebuah metafora system membantu mencapai prinsip ini. |
Referensi :
Glenford, J. M., Sandler, C., & Badgett, T. (2012). The Art of Software Testing. New Jersey: John Wiley & Sons, Inc.