Learning Moments

Seperti proses software engineering lainnya, extreme programming berusaha untuk meningkatkan kualitas, produktivitas, dan performance software. Proses extreme programming harus dapat diukur agar dapat mengetahui kondisi sekompleks apakah yang bisa diselesaikan oleh proses tersebut.

Tulisan ini akan membahas setiap langkah di model proses pada extreme programming. Pertanyaan utama dalam study ini adalah “kompleksitas model seperti apa yang sesuai dengan extreme programming”. Study ini akan menghasilkan beberapa argumentasi dasar mengenai kompleksitas model yang sesuai dengan extreme programming.

1. Kompleksitas Software

Kompleksitas software adalah pendekatan untuk mendefinisikan bagaimana program software menjadi komplex. Kompleksitas software diukur oleh konsep yang disebut pengukuran software. Pengukuran produk difokuskan pada pengukuran dan prediksi karakteristik produk seperti kompleksitas komputasi dan reabilitas model, sebaik model evaluasinya. Proses pengukuran pada umumnya akan berfokus pada estimasi biaya, produktivitas model, pengukuran design, dan kualitas palayanan model.

1. 1 Pengukuran Software

Banyak sekali model pengukuran software yang dapat diadopsi untuk mengukur kompleksitas software. Basili [1983] mendefinisikan kompleksitas sebagai pengukuran dari sumber daya yang diekspansi oleh sistem pada saat berinteraksi dengan software pada saat melakukan suatu pekerjaan. Apabila sistem yang berinteraksi tersebut adalah pengembang, kompleksitas akan didefinisikan dengan tingkat kesulitan dalam melakukan pekerjaan, seperti coding, debugging, dan testing. Oleh karena itu kompleksitas software sering diaplikasikan pada interaksi antara software dengan pengembangnya.

Interaksi software dengan pengembangnya akan dilakukan menggunakan bahasa pemrograman khusus. Pada pendekatan Halstead [1973], pengukuran software dilakukan dengan sum LOC (Line of Codes), jumlah operan, dan operator. Metode ini dikembangkan oleh McCabe [1976] melalui pengukuran yang mendalam mengenai tipe data, tipe pengulangan, cabang, dan pernyataan kondisional.

Pengukuran lebih awal dapat dilakukan dengan mempertimbangkan kebutuhan dan rancangan. Pengukuran kebutuhan dapat dilihat dari spesifikasi yang diminta. Pengukuran rancangan didapatkan dari struktur diagram, derajat hubungan, dan alur informasi [shepperd, 1988].

Pendekatan lain untuk mengukur kompleksitas adalah dengan menggunakan notasi standard diagram seperti UML. Hal lain yang tak kalah penting dalam model rancangan software adalah arsitektur.

Arsitektur pada suatu sistem dinyatakan sebagai komposisi dari beberapa komponen yang saling berhubungan dalam menyelesaikan suatu pekerjaan.

Aktivitas pusat dari arsitektur rancangan adalah dekomposisi dari system menjadi sub system. Dekomposisi tersebut bertujuan untuk mengurangi kompleksitas konstruksi. Alsharif, et al [2004] menggunakan metode fungsi point secara penuh untuk menghitung kompleksitas dari software dalam komponen dan antar komponen satu dengan komponen lainnya.

1.2 Ukuran Software & Jenis Software yang Dikembangkan

Prinsip pengukuran membawa kita kepada pengetahuan yang lebih baik mengenai kompleksitas software. Software yang kompleks berarti ukuran dari project juga besar. Project size merupakan pendefinisi yang signifikan mengenai upaya, biaya, dan penjadwalan. Ukuran project dapat dihubungkan dengan jenis software yang dikembangkan seiring dengan berjalannya waktu, dan factor-faktor personal seperti keahlian, pengetahuan, dan komunikasi [McConnell, 2006].

Angka pada table ini valid hanya untuk bentangan tujuan dari perbandingan antar bentangan ukuran. Nominal cocomo menunjukkan semakin tinggi produktivitas, semakin tinggi pencapaian.

Setelah ukuran, jenis project yang dikembangkan juga dapat menimbulkan kompleksitas. Product based software atau tailor based software adalah kategori dasar yang dapat memberikan perbedaan level kompleksitas. Contohnya pada prodect based, tim pengembang dapat dengan mudah mendefinisikan kebutuhan dan mengacu pada fitur yang ingin dicapai. Hal ini berbeda dengan tailore based yang harus memperhatikan kepentingan dan keinginan stakeholders yang disepakati dalam kontrak pengembangan software.

Contoh lain dari pengembangan software adalah seperti riset yang dilakukan Putnam & Mayers (1992). Putnam & Mayers menyajikan berbagai hasil dari tipe project yang umum beserta tingkat produktivitasnya, yang dapat dilihat pada table berikut :

Tabel tersebut menunjukkan pahwa pengembangan 10 KLOC project untuk system bisnis 5 kali lebih produktif daripada creative driver. Hasil ini dapat dikombinasikan dengan kategori utama yang telah dinyatakan sebelumnya (product based atau tailor based)

2. Faktor Personel dan Bahasa Pemrograman

Personel atau orang juga merupakan factor penting dalam hasil suatu project. Martin [2007] menyatakan bahwa prinsip, pola, dan pelatihan adalah hal yang penting, namun oranglah yang membuat elemen-elemen tersebut bekerja. Fakta ini dapat dengan mudah diketahui dengan mengamati developer baru yang akan membangun intranet system, dibandingkan dengan developer yang sudah 30 tahun berpengalaman, untuk membangun system sejenis. Implikasi dari hasil ini adalah bahwa pemilik project tidak dapat memperkirakan secara akurat mengenai kompleksitas suatu project apabila mereka tida mengetahui dengan tepat siapa yang akan mengerjakan project mereka.

Orang-orang yang akan bergabung dalam pengembangan project harus memiliki dasar pendidikan atau pengalaman yang sesuai. Secara teknis, kasus spesifik seperti bahasa pemrograman dapat mempengaruhi estimasi dari kompleksitas software di 4 bagian : pengalaman personel, fungsionalitas dari bahasa pemrograman, kekayaan dari piranti, dan tipe bahasa pemrograman. Riset Prechelt [2000] menunjukkan bahwa menggunakan bahasa yang diinterpretasikan dapat lebih produktif daripada bahasa tersusun. Riset lain yang dilakukan Jones [1998] menunjukkan bahwa perbandingan dari pernyataan bahasa pemrograman tingkat tinggi sepadan dengan kode C, seperti yang ditunjukkan pada table di bawah ini :

3. Kompleksitas Software Pada Extreme Programming

Extreme programming adalah disiplin dari pengembangan software berdasarkan pada nilai simplicity, komunikasi, feedback, dan keberanian [Jeffries, 2006]. Semua nilai direfleksikan pada kunci dari aktivitas XP yang disimpulkan dengan menggunakan gambar sbb :

Berdasar Pressman [2005] kunci dari aktivitas yang diilustrasikan pada gambar di atas mengarah pada poin-poin sebagai berikut :

1. Aktivitas perencanaan (planning) yang membentuk suatu rangkaian cerita user.

2. Aktivitas perancangan designing) yang menekankan pada kesederhanaan, mengikuti aturan KIS (keep it simple).

3. Aktivitas pengkodean (coding). Dalam melakukan pengkodean, developer harus mengikuti coding standard, sehingga code pada system tetap konsisten, mudah dibaca, dan mudah di-refactor.

4. Testing. Testing pada XP dilakukan melalui unit test, yaitu uji coba pada setiap unit yang ada pada system. Sekali unit test tersebut dilakukan, pengembang akan berfokus pada apa yang harus diimplementasikan untuk melewati unit tersebut.

5. Release. Dalam merilis software, XP menggunakan suatu metode pengurutan. Hal ini berarti bahwa proses pada XP tidak berjalan sekali pada satu baris. Proses pada XP berjalan pada model incremental dan berututan.

Berbagai langkah pada extreme programming menghasilkan mindset bahwa XP sangat simple dan sesuai untuk pengembangan software berukuran kecil hingga medium.

4. Pengukuran Model Pada Extreme Programming

Kesederhanaan pada model proses extreme programming dapat menumbuhkan kesimpulan yang menunjukkan bahwa hasil dari proses model akan memberikan model kompleksitas yang kecil-menengah.

Kecenderungan ini berdasar pada teori Krebs [2009] yang dapat diselidiki dengan melihat tiga elemen kunci daei project cerdas, yaitu kemajuan, kualitas, dan moral dari tim. Pengukuran kemajuan berarti membandingkan rencana awal dengan dengan nilai actual. Pada extreme programming, kebutuhan dapat dirumuskan secara cerdas sehingga perencanaan (untuk perkiraan usaha yang diperlukan software) dan nilai actual (untuk perkiraan usaha yang dibutuhkan untuk mengkonversi kebutuhan) dapat didefinisikan secara berbeda. Dalam hal ini pengukuran progress/kemajuan dapat berubah-ubah selama siklus extreme programming berjalan. Bagaimanapun terdapat dua metode yang umum digunakan, yaitu metode story point & use case points.

Karena metode story point relative dekat dengan cerita/penjelasan user, maka metode story point dapat digunakan secara linear. Metode story point berubah-ubah namun konsisten karena ada angka-angka yang digunakan oleh tim untuk mengukur cerita/penjelasan user. Cerita/penjelasan user merefleksikan kebutuhan dari project. Cerita/penjelasan yang panjang lebar menunjukkan bahwa project tersebut cukup compleks dan sebaliknya. Metode story point lebih berfokus pada ukuran dibandingkan durasi, sehingga metode ini dapat diadopsi dengan memberikan nilai numeric pada setiap cerita. Contohnya ukuran cerita dapat diberi nilai small (kecil) = 5, medium (menengah) = 10, large (besar) = 20. Story point dapat dikelompokkan dengan index seperti gambar berikut :

Kompleksitas dari software dapat dihitung dengan menambahkan semua story point dalam urutan. Apabila tim project dapat membuat definisi yang baik mengenai skala ukuran cerita (low, medium, high), tim tersebut dapat dengan cepat membangun kategori yang tepat.

Model pengukuran lain pada extreme programming berasal ari arsitektur dari software. Pada sudut pandang yang sederhana, arsitekur merupakan pambagian pemahaman mengenai rancangan system [Fowler, 2002]. Arsitektur berfokus pada bagaimana komponen dan interface menunjukkan metamorfosis pada extreme programming. Metamorfosis tersebut membentuk system dengan mengidentifikasi object kunci dan memberi masukan mengenai aspek-aspek pada system. Kartu CRC adalah salah satu model rancangan yang menunjukkan hubungan antar kelas (class), dimana rancangan ini dapat menjadi framework untuk menghitung kompleksitas arsitektur berdasarkan metode function point secara penuh [Al Sharif et al, 2004]. Gambar di bawah ini menunjujjan software arsitektur yang dideskripsikan dengan kartu CRC.

Berdasar kartu CRC, function point secara penuh dihitung dengan seberapa banyak kelas (class) pada kartu CRC yang menangani input/masukan dan ouput/hasil keluaran dari komunikasi. Panah-panah tersebut menunjukkan setiap kelas berkolaborasi dengan kelas lain. Function point secara penuh dapat dihitung sesuai deskripsi pada table berikut

Hasil dari table tersebut menyediakan informasi untuk tim extreme programming mengenai kompleksitas dari software melalui arsitekturnya. Hasil dari table tersebut dikombinasikan dengan story point akan menghasilkan model kompleksitas yang lebih jelas untuk tim sebelum memulai sesi pengkodean (coding).

Pada sesi pengkodean, beberapa aktivitas seperti tes untuk setiap unit dan pemfaktoran adalah aktivitas utama yang dilakukan tim pengembang. Pada sesi ini pengukuran model seperti LOC atau Cocomo akan menyediakan hasil yang lebih tajam untuk tim mengenai kompleksitas model. Bagaimanapun, karena nilai dari extreme programming adalah kesederhanaan, maka berbagai metode oengukuran sebaiknya tidak membatasi produktivitas dari tim. Orang-orang dalam tim dapat memilih model pengukuran software yang mereka butuhkan, sejak pra pengkodean hingga sesi pengkodean.

5. Menyesuaikan Kompleksitas Model Dengan Extreme Programming

Sebagai salah satu metode cerdas yang cukup terkenal, extreme programming mengalami banyak perubahan definisi kebutuhan sebagai bagian dari style cerdas [Beck, 2000]. Hal ini berarti bahwa setiap permintaan dari client akan didiskusikan dalam team meeting. Ketika perubahan definisi kebutuhan dapat diterima sesuai dengan waktu, sumber daya, dan perencanaan anggaran, tim akan mengkonfirmasi rencana rilis selanjutnya. Sebaliknya, apabila tidak dapat diterima, tim akan melakukan negosiasi ulang dengan client. Pendekatan ini mungkin dilakukan pada skala software yang kecil hingga menengah atau software yang dibangun sebagai produk. Bagaimanapun, pendekatan ini tidak mungkin dilakukan untuk software dengan skala besar (untuk kebutuhan enterprise). Pada skala enterprise, esensi dari bisnis dapat menjadi pemicu utama untuk segala sesuatu termasuk pengembangan software. Situasi ini sering disebut sebagi “kematian yang tiba-tiba (sudden death situation)“, ketika stakeholder memiliki keinginan agar tim pengembang dapat menemukan cara untuk memenuhi berbagai kebutuhan proses bisnis. Apabila situasi ini terjadi, banyak pengembang yang melakukan berbagai macam tindakan, seperti memperpanjang waktu project atau menambahkan anggota tim. Tindakan kedua dapat menyebabkan tim berkembang menjadi besar dan hal ini tidak disarankan pada extreme programming. Extreme programming menyarankan untuk membuat komposisi tim yang kecil atau tidak lebih dari 12 orang [Wake, 2000]. Argumen Wake tersebut berkaitan dengan teori McConnell [2006] mengenai ukuran project. Teori tersebut menyatakan bahwa project dengan skala kecil dimulai dengan individu hingga 5 orang dan project dengan skala menengah terdiri dari 5-25 orang.

Tabel berikut ini mengilustrasikan hubungan antara banyaknya member dalam suatu tim dengan ukuran project.

Rancangan yang sederhana adalah kunci dari model rancangan pada extreme programming. Nilai ini diadopsi dengan sedikit sekali diagram pada extreme programming. Extreme programming dimulai dengan pemodelan menggunakan prototype yang disebut ‘spike solution’. Cerita/penjelasan user dapat dituliskan pada dua sisi kartu yang mendeskribsikan apa yang dapat dilakukan user. Cerita/penjelasan user menyediakan informasi mengenai software behavior dan struktur software. Pada extreme programming penggunaan UML sebagai model rancangan cukup baik, namun software yang dapat bekerja dengan baik adalah yang paling utama. UML yang terlalu banyak akan mengakibatkan kondisi yang disebut paralys atau biasa disebut “hanya rancangan, tidak ada software yang dapat digunakan“. Bagaimanapun peneliti menyimpulkan bahwa model rancangan tidak cukup untuk mendefinisikan degala kebutuhan informasi yang akan dimunculkan pada pengembangan software. Extreme programming memiliki kelemahan pada blueprint yang detail.

Tabel di bawah ini akan mengilustrasikan model rancangan dibandingkan dengan kejelasan dari UML model proses yang disebut ICONIX [Rosenberg, 2000].

Kualitas pengkodean yang tinggu dan software yang dapat bekerja dengan baik adalah hal yang sangat penting pada extreme programming. Konsep yang disebut oemfaktoran dan uji coba (testing) akan memberikan jaminan kualitas dan performansi kode. Kode yang telah diuji coba adalah kode yang baik. Metode pengujian pada extreme programming disebut pengujian unit (unit testing). Unit testing dimulai dengan kerangka kode yang menunjukkan scenario ujicoba. Unit testing dan pengkodean yang ideal pada extreme programming akan memakan banyak waktu dan menghadapi kompleksitas software yang memiliki sangat banyak ketergantungan dan komponen-komponen yang sangat kompleks.

KESIMPULAN

• Pengukutan software dapat diterapkan pada metodologi cerdas seperti extreme programming
• Pengukuran proses yang sudah ada dapat diadopsi untuk mengumpulkan informasi mengenai model kompleksitas software untuk extreme programming. Study mengenai madalah ini menunjukkan dua macam pengukuran, yaitu pada arsitektor dan code metric.
• Kompleksitas yang dapat ditangani pada extreme programming sangat bergantung pada tim sebagai fackor personal. Karena tim pada extreme programming relative kecil, maka ukuran tim akan menjadi tolak ukr dari ukuran dan jenis software yang akan dikembangkan. Hal ini berarti pada kasus normal, ukuran software dan kompleksitas dari software yang dikembangkan dengan extreme programming akan memiliki skala kompleksitas kecil-menengah.
• Penyesuaian model kompleksitas dengan extreme programming melalui kebutuhan, rancangan, dan pengkodean memberikan pemahaman yang lebih baik bahwa model roses pada extreme programming paling sesuai untuk model kompleksitas dengan ukuran kecil sampai menengah.

• Kompleksitas model pada extreme programming dapat ditingkatkan dengan memperluas dan mengadopsi metode framework terstruktur yang tidak sesuai dengan software untuk skala enterprise.

Permasalahan utama yang sering muncul dalam sebuah proyek pengembangan perangkat lunak adalah perubahan requirement yang begitu cepat. Hal ini terjadi sebagai akibat perubahan-perubahan yang muncul baik pada aspek bisnis maupun teknologi yang berlangsung lebih cepat daripada proses pengembangan perangkat lunak itu sendiri. Extreme Programming (XP) adalah sebuah pendekatan pengembangan perangkat lunak yang mencoba meningkatkan efisiensi dan fleksibilitas dari sebuah proyek pengembangan perangkat lunak dengan mengkombinasikan berbagai ide sederhana.

Bayangkan diri anda seorang project leader pada sebuah proyek pengembangan perangkat lunak. Setelah berbulan-bulan mengembangkan perangkat lunak dan proyek hampir selesai tiba-tiba saja di perusahaan klien anda terjadi perubahan kebijakan yang berimplikasi pada perangkat lunak anda. Betapa frustrasinya anda dan tim karena anda tidak bisa menolak perubahan-perubahan yang diajukan klien tersebut karena kontrak anda mengakomodasi adanya perubahan-perubahan tersebut. Hal tersebut seringkali terjadi disebabkan lamanya proses pengembangan perangkat lunak. Proses pengembangan perangkat lunak yang kompleks dapat menghabiskan waktu berbulan-bulan bahkan bertahun-tahun sebelum perangkat lunak dapat digunakan. Padahal seringkali dalam waktu tersebut terjadi perubahan besar pada situasi bisnis maupun teknologi yang bisa membuat perangkat lunak menjadi tidak relevan lagi.

Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.

Tujuan XP

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 XP

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 XP

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 XP (XP 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 XP

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 XP

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.