Aspek Dasar Extreme Programming

Tujuan Extreme Programming

Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan.P

Penggunaan Extreme Programming

XP tepat digunakan saat

• Keperluan berubah dengan cepat

• Resiko tinggi dan ada proyek dengan tantangan yang baru

• Tim programmer sedikit, yaitu antara 2-10 orang

• Mampu mengotomatiskan tes

• Ada peran serta pelanggan secara langsung

Variabel Extreme Programming

Terdapat 4 variabel XP, yaitu antara lain :

1. Cost (biaya) Dengan meningkatkan biaya, kita bisa menciptakan program yang lebih baik. Sebaliknya mengurangi biaya untuk proyek tidak akan menyelesaikan masalah customer. Tetapi, biaya yang tiak terbatas juga akan menimbulkan kerusakan.
2. Time (waktu) Dengan meningkatkan waktu makan kita akan mampu menciptakan program yang berkualitas dan dengan feature-feature yang lebih banyak.Akan tetapi waktu yang berlebihan tidak baik, karena dapat merusak terhadap diri sendiri. Waktu yang sedikit juga tidak baik karena kualitas yang dihasilkan akan jauh dari yang diharapkan.
3. Quality (mutu) Mutu merupakan suatu variabel pengendali yang sangat “mengerikan” karena merupakan suatu hal yang sangat diperhatikan oleh konsumen.
4. Scope (feature) Scope merupakan varibel primer. Jika kita mengurangi Scope,maka kita bisa mengurangi biaya dan meningkatkan kualitas.

Kunci utama Extreme Programming(Extreme Programming Value)

Menurut penggagas dari metode XP, Kent Beck mendefinisikan lima kunci utama dari XP, yaitu :

1. Communication XP memfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programmer yang biasanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programmer lain dalam menuliskan kode program.
2. Courege Para anggota tim dan penanggungjawab pengembangan perangkat lunakharus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar. Untuk dapat melakukan sesuatu dengan penuh integritas, terlebih dahulu para anggota tim memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan metode yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan.Dengarkan selalu pendapat rekan yang lain. Dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work Semua nilai di atas berujung pada sebuah kondisi dimana kita melakukan pekerjaan dengan berkualitas. Denagn proses yang berkualitas maka akan muncul pula implikasi perangkat lunak yang berkualitas sebagai hasil akhir.

Prinsip utama Extreme Programming

Dalam penerapannya, Extreme Programming memiliki lima prinsip utama, yaitu:

1. Rapid Feedback Menurut ilmu psikologi, waktu antara sebuah aksi dengan feedbacknya sangat penting untuk dipelajari. Dalam sebuah proyek XP, developer memperoleh feedback sesegera mungkin, menginterpretasikannya, lalu mengambil inti sarinya dan meletakkannya ke dalam system. Feedback dari pelanggan terhitung harian, bukan bulanan, dan feedback dari developer terhitung menitan, bukan mingguan!
2. Assume Simplicity Hanya mendesain untuk masalah saat ini dan menghemat waktu 98% dari masalah tersebut dan hanya menekuni sekitar 2% untuk bagian yang sulit. XP berencana untuk masa depan sehingga desainnya bias di-reuse, lakukan pekerjaan yang penting, dan percayalah bahwa untuk kekompleksitasan bias ditambahkan kemudian.
3. Incremental Change Pemecahan problem yaitu dengan bagian-bagian kecil perubahan saja. Jadi perubahan-perubahan yang terjadi pada XP melalui tahap-tahap kecil dan waktu yang singkat.
4. Embracing Change Mencari dan menyediakan terlebih dahulu sebanyak mungkin pilihan ketika menyelesaikan masalah yang begitu menekan.
5. Quality Work Setiap orang suka mengerjakan pekerjaan yang bagus dan layak dan kualitas yang dimaksud di sini adalah kualitas yang sempurna dan kualitas yang sempurna secara ekstrim. Karena tanpa kualitas kita tidak akan suka melakukan pekerjaan tersebut, hasilnya tidak akan sempurna dan proyeknya akan jatuh berantakan.

Aspek Dasar Extreme Programming

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:

1. The Planning Game

Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.

2. Small Releases

Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.

3. Metaphor

Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.

4. Simple Design

Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.

5. Refactoring

Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.

6. Testing

XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.

7. Pair Programming

Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.

8. Collective Ownership

Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.

9. Coding Standards

Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.

10. Continous Integration

Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.

11. 40-hours Week

Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.

12. On-Site Customer

      Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada   
      proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan 
      turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan 
      diharapkan klien dapat segera memberikan masukan untuk koreksinya.