Extreme Programming adalah salah satu dari pendekatan agile software development yang paling sering digunakan.^[1] Meskipun pekerjaan awal pada ide-ide dan metode yang terkait dengan XP terjadi pada akhir 1980-an, pekerjaan seminal pada subjek ini telah ditulis oleh Kent Beck.^[2] Extreme Programming diciptakan oleh Kent Beck selama pekerjaannya di proyek Chrysler Comprehensive Compensation System (C3).^[3] Beck menjadi pemimpin proyek C3 pada bulan Maret 1996 dan mulai memperbaiki metodologi pengembangan yang digunakan dalam proyek dan menulis buku tentang metodologi (pada bulan Oktober 1999, Extreme Programming Explained diterbitkan).^[3] Chrysler membatalkan proyek C3 pada Februari 2000, setelah tujuh tahun, ketika perusahaan diakuisisi oleh Daimler-Benz ^[4].

Beck ^[2] mendefinisikan seperangkat nilai yang membentuk fondasi untuk semua pekerjaan yang dilakukan sebagai bagian dari XP — komunikasi (communication), kesederhanaan (simplicity), umpan balik (feedback), keberanian (courage), dan rasa hormat (respect). Masing-masing nilai ini digunakan sebagai penggerak untuk aktivitas, tindakan, dan tugas XP tertentu.^[1]

Untuk mencapai komunikasi yang efektif antara praktisi perangkat lunak dan pemangku kepentingan lain (misalnya, untuk membangun fitur dan fungsi yang diperlukan untuk perangkat lunak), XP menekankan kolaborasi yang erat, tetapi informal (verbal) antara pelanggan dan pengembang, pembentukan metafora yang efektif untuk mengkomunikasikan konsep-konsep penting, memberikan umpan balik yang berkelanjutan, dan menghindari dokumentasi yang banyak sebagai media komunikasi.^[1]

Untuk mencapai kesederhanaan , XP membatasi pengembang untuk merancang hanya kebutuhan mendesak, daripada mempertimbangkan kebutuhan masa depan. Tujuannya adalah untuk membuat desain sederhana yang dapat dengan mudah diimplementasikan dalam kode. Jika desain harus diperbaiki, itu dapat di-refactored di lain waktu.^[1]

Umpan balik berasal dari tiga sumber: perangkat lunak yang diimplementasikan itu sendiri, pelanggan, dan anggota tim perangkat lunak lainnya. Dengan merancang dan menerapkan strategi pengujian yang efektif, perangkat lunak (melalui hasil tes) memberikan umpan balik bagi agile team. XP menggunakan pengujian unit sebagai taktik pengujian utamanya. Ketika setiap kelas dikembangkan, tim mengembangkan pengujian unit untuk melaksanakan setiap operasi sesuai dengan fungsionalitas yang ditentukan. Ketika sebuah increment disampaikan ke pelanggan, user stories atau use case yang diterapkan oleh increment tersebut digunakan sebagai dasar untuk acceptance testing. Sejauh mana perangkat lunak mengimplementasikan luaran, fungsi, dan perilaku use case adalah bentuk umpan balik. Akhirnya, ketika kebutuhan baru diturunkan sebagai bagian dari perencanaan berulang, tim memberikan pelanggan umpan balik cepat mengenai dampak biaya dan jadwal.^[1]

Beck berpendapat bahwa kepatuhan yang ketat terhadap praktik XP tertentu menuntut keberanian. Kata yang lebih baik mungkin disiplin. Sebagai contoh, sering ada tekanan yang signifikan untuk merancang kebutuhan pada masa depan. Sebagian besar tim perangkat lunak menyerah, dengan alasan bahwa "merancang untuk besok" akan menghemat waktu dan upaya dalam jangka panjang. Tim agile XP harus memiliki disiplin (keberanian) mendesain untuk hari ini, mengakui bahwa kebutuhan pada masa depan dapat berubah secara dramatis, sehingga menuntut pengerjaan ulang yang substansial dari desain dan kode yang diimplementasikan.^[1]

Dengan mengikuti masing-masing nilai-nilai ini, tim agile menanamkan rasa hormat (respect) di antara anggotanya, antara pemangku kepentingan lain dan anggota tim, dan secara tidak langsung, untuk perangkat lunak itu sendiri. Ketika mereka berhasil mencapai pengiriman increment perangkat lunak, tim mengembangkan rasa hormat yang semakin besar terhadap proses XP.^[1]

Extreme Programming menggunakan pendekatan berorientasi objek sebagai paradigma pengembangan yang disyaratkan dan mencakup seperangkat aturan dan praktik yang terjadi dalam konteks empat kegiatan kerangka kerja: perencanaan (planning), desain (design), pengkodean (coding), dan pengujian (testing).^[1]

Kegiatan perencanaan dimulai dengan mendengarkan — kegiatan pengumpulan kebutuhan yang memungkinkan anggota teknis tim XP untuk memahami konteks bisnis perangkat lunak dan untuk mendapatkan perkiraan yang luas untuk luaran yang dibutuhkan dan fitur serta fungsionalitas utama. Mendengarkan mengarah pada penciptaan serangkaian "stories" yang menggambarkan luaran, fitur, dan fungsionalitas yang diperlukan untuk perangkat lunak yang akan dibangun. Setiap stories ditulis oleh pelanggan dan ditempatkan pada kartu indeks (index card). Pelanggan memberikan nilai (yaitu prioritas) ke stories berdasarkan nilai bisnis keseluruhan dari fitur atau fungsi. Anggota tim XP kemudian menilai setiap stories dan menetapkan biaya (cost) — diukur dalam minggu pengembangan — untuk stories tersebut. Jika stories diperkirakan membutuhkan lebih dari tiga minggu pengembangan, pelanggan diminta untuk membagi stories menjadi stories yang lebih kecil dan penugasan nilai dan biaya terjadi lagi. Penting untuk dicatat bahwa stories baru dapat ditulis kapan saja.^[1]

Pelanggan dan pengembang bekerja sama untuk memutuskan bagaimana mengelompokkan stories ke dalam rilis berikutnya (software increment berikutnya) untuk dikembangkan oleh tim XP. Setelah komitmen dasar (kesepakatan tentang stories untuk dimasukkan, tanggal pengiriman, dan masalah proyek lainnya) dibuat untuk rilis, tim XP mengurutkan stories yang akan dikembangkan dalam salah satu dari tiga cara: (1) semua stories akan segera diimplementasikan (dalam beberapa minggu), (2) stories dengan nilai tertinggi akan dipindahkan ke jadwal paling atas dan diterapkan terlebih dahulu, atau (3) stories paling berisiko akan dipindahkan ke jadwal paling atas dan diimplementasikan terlebih dahulu.^[1]

Setelah rilis proyek pertama (juga disebut software increment) telah disampaikan, tim XP menghitung project velocity. Secara sederhana, project velocity adalah sejumlah stories pelanggan yang diimplementasikan selama rilis pertama. Project velocity kemudian dapat digunakan untuk membantu memperkirakan tanggal pengiriman dan jadwal untuk rilis berikutnya dan menentukan apakah overcommitment telah dibuat untuk semua stories di seluruh proyek pengembangan. Jika terjadi overcommitment , konten rilis diubah atau tanggal pengiriman akhir diubah.^[1]

Ketika pekerjaan pengembangan berlangsung, pelanggan dapat menambahkan stories, mengubah nilai stories yang ada, membagi stories, atau menghilangkannya. Tim XP kemudian mempertimbangkan kembali semua rilis yang tersisa dan memodifikasi rencananya.^[1]

Desain XP dengan ketat mengikuti prinsip KIS (Keep It Simple). Desain yang sederhana selalu lebih disukai daripada representasi yang lebih kompleks. Selain itu, desain tersebut memberikan panduan implementasi untuk sebuah stories seperti yang ditulis — tidak kurang, tidak lebih. Desain fungsi tambahan (karena pengembang menganggapnya akan diperlukan nanti) tidak disarankan. XP mendorong penggunaan kartu CRC sebagai mekanisme yang efektif untuk berpikir tentang perangkat lunak dalam konteks orientasi objek. Kartu CRC (class-responsibility-collaborator) mengidentifikasi dan mengatur kelas berorientasi objek yang relevan dengan software increment saat ini. Kartu CRC adalah satu-satunya work product desain yang diproduksi sebagai bagian dari proses XP. Jika masalah desain yang sulit ditemui sebagai bagian dari desain sebuah stories, XP merekomendasikan pembuatan prototipe operasional dari bagian desain tersebut. Disebut spike solution, prototipe desain diimplementasikan dan dievaluasi. Tujuannya adalah untuk menurunkan risiko ketika implementasi yang sebenarnya dimulai dan untuk memvalidasi perkiraan awal untuk stories yang berisi masalah desain.^[1]

Pada bagian sebelumnya, kami mencatat bahwa XP mendorong refactoring — teknik konstruksi yang juga merupakan metode untuk optimasi desain. Fowler^[5] menjelaskan refactoring adalah proses mengubah sistem perangkat lunak sedemikian rupa sehingga tidak mengubah perilaku eksternal kode namun meningkatkan struktur internal. Ini adalah cara yang terdisiplin untuk membersihkan kode [dan memodifikasi / menyederhanakan desain internal] yang meminimalkan kemungkinan bug. Karena desain XP hampir tidak menggunakan notasi dan menghasilkan sedikit, jika ada, work product selain dari kartu CRC dan spike solution, desain dipandang sebagai fakta sementara yang dapat dan harus terus dimodifikasi ketika konstruksi berlanjut. Maksud refactoring adalah untuk mengontrol modifikasi ini dengan menyarankan perubahan desain kecil bahwa "secara radikal dapat meningkatkan desain".^[5] Perlu dicatat, bahwa upaya yang diperlukan untuk refactoring dapat tumbuh secara dramatis seiring dengan meningkatnya ukuran aplikasi. Gagasan sentral dalam XP adalah bahwa desain muncul sebelum dan sesudah koding. Refactoring berarti bahwa desain terjadi terus-menerus ketika sistem dibangun. Bahkan, kegiatan konstruksi itu sendiri akan memberikan tim XP panduan tentang cara meningkatkan desain.^[1]

Setelah stories dikembangkan dan pekerjaan desain awal dilakukan, tim tidak pindah ke kode, melainkan mengembangkan serangkaian pengujian unit yang akan melatih setiap stories yang akan dimasukkan dalam rilis saat ini (software increment) .Sekali pengujian unit telah dibuat, pengembang lebih mampu fokus pada apa yang harus diterapkan untuk lulus pengujian. Tidak ada hal ekstra yang ditambahkan (KIS). Setelah kode selesai, kode dapat segera diuji, dengan demikian memberikan umpan balik instan kepada pengembang.^[1]

Konsep kunci selama aktivitas pengkodean (dan salah satu aspek XP yang paling banyak dibicarakan) adalah pemrograman berpasangan (pair programming). XP merekomendasikan agar dua orang bekerja bersama di satu komputer untuk membuat kode sebuah stories. Ini memberikan mekanisme untuk pemecahan masalah waktu-nyata (dua kepala seringnya lebih baik dari satu) dan jaminan kualitas waktu nyata (kode ditinjau saat dibuat). Itu juga membuat pengembang fokus pada masalah yang dihadapi. Dalam praktiknya, setiap orang mengambil peran yang sedikit berbeda. Sebagai contoh, satu orang mungkin berpikir tentang detail pengkodean dari bagian tertentu dari desain sementara yang lain memastikan bahwa standar pengkodean (bagian yang diperlukan dari XP) sedang diikuti atau bahwa kode untuk stories akan memenuhi pengujian unit yang telah dikembangkan untuk memvalidasi kode terhadap stories.^[1]

Ketika pemrogram berpasangan menyelesaikan pekerjaan mereka, kode yang mereka kembangkan terintegrasi dengan pekerjaan orang lain. Dalam beberapa kasus ini dilakukan setiap hari oleh tim integrasi. Dalam kasus lain, programmer berpasangan memiliki tanggung jawab integrasi. Strategi "integrasi berkesinambungan" ini membantu menghindari masalah kompatibilitas dan antarmuka dan menyediakan lingkungan "smoke testing" yang membantu mengungkap kesalahan lebih awal.^[1]

Pembuatan pengujian unit sebelum pengkodean adalah elemen kunci dari pendekatan XP. Pengujian unit yang dibuat harus diimplementasikan menggunakan kerangka kerja yang memungkinkan mereka untuk diotomatisasi (karenanya, mereka dapat dieksekusi dengan mudah dan berulang kali). Ini mendorong strategi pengujian regresi setiap kali kode diubah. Ketika pengujian unit individual diorganisasikan ke dalam "universal testing suite",^[6] pengujian integrasi dan validasi sistem dapat terjadi setiap hari. Ini memberikan tim XP indikasi kemajuan yang berkesinambungan dan juga dapat menaikkan bendera peringatan lebih awal jika semuanya serba salah. Wells menyatakan: "Memperbaiki masalah kecil setiap beberapa jam membutuhkan waktu lebih sedikit daripada memperbaiki masalah besar sebelum batas waktu." Acceptance test , juga disebut customer test, ditentukan oleh pelanggan dan fokus pada keseluruhan fitur sistem dan fungsionalitas yang dapat dilihat dan ditinjau oleh pelanggan. Acceptance test berasal dari user stories yang telah diterapkan sebagai bagian dari rilis perangkat lunak.^[1]

1. ^ ^{a b c d e f g h i j k l m n o p q r} Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534. Diarsipkan dari versi asli tanggal 2023-07-16. Diakses tanggal 2019-07-30. 
2. ^ ^{a b} Beck, Kent, 1961- Verfasser. Extreme programming explained : Second edition, embrace change. ISBN 0321278658. OCLC 953805139. Pemeliharaan CS1: Banyak nama: authors list (link)
3. ^ ^{a b} "Extreme Programming". Diarsipkan dari versi asli tanggal 2019-07-30. 
4. ^ Stephens, Matt, 1971- (2003). Extreme programming refactored : the case against XP. Berkeley, Calif.: Apress. ISBN 1590590961. OCLC 52359427. Pemeliharaan CS1: Banyak nama: authors list (link)
5. ^ ^{a b} Fowler, Martin Beck, Kent (2002). Refactoring improving the design of existing code. Addison-Wesley. OCLC 935190387. Diarsipkan dari versi asli tanggal 2023-07-16. Diakses tanggal 2019-07-30. Pemeliharaan CS1: Banyak nama: authors list (link)
6. ^ Wells, D., “XP—Unit Tests,” 1999, available at www.extremeprogramming.org/ rules/unittests.html.