Extreme Programming (XP): Nilai dan Amalan

Extreme Programming (XP) adalah metodologi Agile yang menyatakan bahawa tabiat kejuruteraan yang baik perlu dibawa kepada hadnya yang logik. Di mana rangka kerja lain memberitahu anda cara menguruskan kerja, XP memberitahu anda dengan tepat cara menulis, menguji, dan mengintegrasikannya.

Kent Beck memperkenalkan XP pada lewat 1990-an semasa bekerja dalam projek Chrysler Comprehensive Compensation. Beliau mendapati bahawa amalan yang kadang-kadang digunakan oleh pasukan perisian apabila keadaan semakin serius, seperti menulis ujian dahulu atau menyemak kod bersama rakan, paling berkesan apabila diterapkan secara berterusan. XP memformalkan pandangan itu ke dalam satu set nilai dan amalan yang boleh diguna pakai oleh mana-mana pasukan.

Apakah Extreme Programming?

Extreme Programming adalah metodologi Agile yang dibina sekitar pengeluaran yang kerap, maklum balas berterusan, dan disiplin kejuruteraan yang ketat. Ia mengemas tabiat kraf perisian yang terbukti ke dalam rangka kerja padu supaya pasukan boleh menghantar perisian bersedia untuk pengeluaran dalam lelaran mingguan atau dua minggu sekali.

Tidak seperti Scrum yang memberi tumpuan terutamanya kepada proses dan upacara, XP menentukan amalan teknikal yang spesifik. Ia memberitahu anda untuk menulis ujian sebelum kod, mengintegrasikan kerja anda beberapa kali sehari, dan memastikan reka bentuk cukup mudah untuk diubah pada bila-bila masa.

Fakta Penting

• Pasukan yang mengamalkan integrasi berterusan melihat kitaran integrasi kod sehingga 65% lebih pantas (DORA State of DevOps Report, 2023).
• Pembangunan berpandukan ujian (TDD) mengurangkan kadar kecacatan sebanyak 40 hingga 80% dalam kajian terkawal (Microsoft Research / IBM Research, 2008).
• Sehingga 2024, amalan XP tertanam dalam tabiat kerja kira-kira 14% pasukan perisian profesional, selalunya digabungkan dengan Scrum (State of Agile Report, 2024).

XP berkongsi akar falsafahnya dengan Agile Manifesto, yang mengkodkan gerakan yang Beck bantu mulakan. Tetapi XP mendahului Manifesto dua tahun dan pergi lebih jauh dalam menentukan tingkah laku kejuruteraan.

5 nilai XP

XP sangat jelas tentang minda di sebalik amalannya. Lima nilai ini membentuk setiap keputusan dalam pasukan XP.

Komunikasi. Masalah berterusan apabila orang berhenti bercakap. XP memerlukan perbualan bersemuka yang berterusan antara pembangun, penguji, dan wakil pelanggan yang ditempatkan bersama pasukan.

Kesederhanaan. Bina hanya apa yang anda perlukan hari ini. Pasukan XP menolak reka bentuk spekulatif dan memilih penyelesaian paling mudah yang menyelesaikan masalah semasa. Ini menjadikan kod lebih mudah diubah esok hari.

Maklum Balas. Kitaran pendek wujud untuk menjana maklum balas dengan cepat. Maklum balas datang daripada ujian unit yang berjalan dalam beberapa saat, daripada binaan integrasi yang berjalan setiap jam, dan daripada pelanggan yang menyemak features sebenar setiap minggu.

Keberanian. Keputusan kejuruteraan yang baik kadang-kadang tidak selesa. XP meminta pasukan untuk memadamkan kod yang tidak aktif, membuat semula kod tanpa segan silu, dan memberitahu pelanggan apabila tarikh akhir tidak realistik. Itu memerlukan keberanian.

Hormat. Sumbangan setiap ahli pasukan penting. Hormat bermaksud tiada seorang pun menghantar kod yang sengaja merosakkan kerja orang lain, dan tiada seorang pun menolak kebimbangan tanpa mendengarnya.

12 amalan teras XP

XP mengatur amalannya kepada empat kumpulan. Pengelompokan di bawah mencerminkan cara Kent Beck menggambarkannya dalam formulasi asalnya.

Maklum balas berskala halus

Proses berterusan

Pemahaman bersama

Kebajikan pengaturcara

Manfaat XP

Kecacatan muncul serta-merta. TDD dan CI menangkap kemunduran pada saat ia muncul, bukan tiga Sprint kemudian apabila sumbernya sukar dijejaki.

Perubahan tidak mahal. Reka bentuk mudah ditambah pembuatan semula kod berterusan bermakna pangkalan kod tidak pernah mengeras kepada bentuk yang mahal untuk diubah suai. Apabila keperluan berubah, yang pasti berlaku, pasukan XP menyesuaikan diri tanpa perlu menulis semula.

Kepercayaan pelanggan meningkat. Kerana wakil pelanggan melihat perisian berfungsi setiap minggu, tiada kejutan tidak menyenangkan semasa pelancaran. Pihak berkepentingan boleh mengubah hala pasukan berdasarkan kemajuan yang nyata dan ditunjukkan.

Pengetahuan pasukan tersebar. Pengaturcaraan berpasangan dan pemilikan kolektif bermakna tiada individu yang menjadi satu titik kegagalan. Apabila seseorang pergi, pengetahuan pangkalan kod kekal bersama pasukan.

Kualiti tanpa fasa QA yang berasingan. Pengujian dibina ke dalam setiap jam pembangunan. Kualiti bukan gerbang di penghujung; ia adalah sifat berterusan kerja.

Batasan dan bila tidak menggunakan XP

XP bukan pilihan yang sesuai di mana-mana. Berikut adalah situasi di mana ia sukar digunakan.

Pasukan yang diedarkan secara geografi. Pengaturcaraan berpasangan paling berkesan secara bersemuka. Alat pasangan jarak jauh membantu, tetapi amalan itu kehilangan sebahagian maklum balas spontannya apabila pembangun berada di zon masa yang berbeza.

Pasukan yang besar atau stabil. XP direka bentuk untuk pasukan kecil, biasanya lima hingga dua belas pembangun. Dalam program yang lebih besar, beban penyelarasan pemilikan kolektif dan integrasi berterusan boleh menjadi ketara tanpa alatan tambahan.

Konteks kawal selia atau kritikal dari segi keselamatan. Industri seperti aeroangkasa, peranti perubatan, atau pematuhan kewangan sering memerlukan dokumentasi awal yang terperinci dan kelulusan yang bercanggah dengan pilihan dokumentasi minimum XP. Amalan XP masih boleh wujud bersama aliran kerja pematuhan, tetapi anda perlu menyesuaikannya dengan teliti.

Pasukan yang baharu dalam pengujian automatik. TDD memerlukan perubahan budaya. Pasukan yang tidak pernah menulis ujian dahulu mungkin mendapati kadar XP terlalu pantas. Pengenalan secara beransur-ansur, bermula dengan CI dan standard pengekodan, cenderung lebih berkesan daripada mengamalkan semua dua belas amalan sekaligus.

Apabila keperluan tetap dan tidak berubah. Nilai XP datang daripada kemampuan menyesuaikan diri. Jika kontrak mentakrifkan setiap keperluan terlebih dahulu dan perubahan dikenakan penalti, fleksibiliti XP terbuang sia-sia dan pendekatan berpandukan rancangan mungkin lebih sesuai untuk projek itu.

Cara mengamalkan XP dalam pasukan

XP paling baik diperkenalkan secara berperingkat. Membuang dua belas amalan baharu kepada pasukan dalam semalaman jarang melekat.

Langkah 1: Bersetuju dengan standard pengekodan

Sebelum apa-apa pun, pasukan menyelaraskan satu gaya pengekodan bersama dan menguatkuasakannya melalui alat linting atau pemformatan. Ini tidak mempunyai geseran yang tinggi dan mewujudkan pemahaman bersama yang menjadi asas XP yang lain.

Langkah 2: Perkenalkan integrasi berterusan

Sediakan saluran paip CI yang menjalankan ujian automatik pada setiap komit. Walaupun sut ujian masih kecil pada mulanya, tabiat mengintegrasikan dengan kerap dan memperbaiki kegagalan dengan serta-merta mengubah cara pasukan berfikir tentang kerja mereka.

Langkah 3: Mulakan pengaturcaraan berpasangan untuk kerja yang kompleks

Jangan wajibkan pasangan untuk setiap tugas dari hari pertama. Mulakan dengan kerja yang paling kompleks atau berisiko. Pasukan sering mendapati mereka ingin berpasangan lebih banyak setelah melihat betapa cepatnya masalah dikesan.

Langkah 4: Amalkan pembangunan berpandukan ujian secara beransur-ansur

Pilih satu feature baharu dan bina menggunakan TDD dari awal. Bandingkan kadar kecacatan dan keyakinan pembuatan semula berbanding features yang dibina dengan cara lama. Bukti itu biasanya meyakinkan skeptik lebih pantas daripada mana-mana hujah.

Langkah 5: Bawa wakil pelanggan ke dalam kitaran perancangan

Permainan perancangan hanya berfungsi jika seseorang dengan kuasa produk sebenar turut serta. Jika pelanggan di tapak sepenuh masa tidak praktikal, wujudkan irama yang tetap (mingguan atau dua minggu sekali) di mana pihak berkepentingan perniagaan menyemak kisah, menjawab soalan, dan menerima kisah pengguna yang selesai. Padukan ini dengan kriteria penerimaan yang jelas dan Definition of Done bersama.

XP vs Scrum

XP dan Scrum kedua-duanya Agile, tetapi beroperasi di peringkat yang berbeza. Ramai pasukan menjalankan kedua-duanya serentak.

Pasukan yang menjalankan Scrum sering mengamalkan amalan XP seperti TDD dan CI dalam Sprint mereka. Scrum menyediakan pembungkus pengurusan; XP menyediakan disiplin kejuruteraan. Gabungan ini kadang-kadang dipanggil "Scrum/XP" dan merupakan salah satu konfigurasi Agile yang paling biasa dalam praktik.

Pasukan yang memerlukan lebih fleksibiliti dalam menggabungkan pendekatan Agile kadang-kadang menggunakan Scrumban, yang menarik pengurusan aliran gaya Kanban ke dalam irama Scrum. Untuk organisasi yang berkembang melepasi satu pasukan, Scaled Agile Framework (SAFe) boleh menampung amalan XP di peringkat pasukan sambil menambah lapisan penyelarasan di atasnya.

Soalan lazim

Adakah Extreme Programming masih digunakan hari ini?

Ya. Amalan XP masih hidup, sering tertanam dalam pasukan Scrum yang tidak semestinya menamakan mereka sebagai "XP." Integrasi berterusan, TDD, dan pengaturcaraan berpasangan kini merupakan amalan standard dalam pembangunan perisian moden, sebahagiannya kerana XP membuktikan nilainya pada awal 2000-an.

Bolehkah anda menggabungkan XP dan Scrum?

Sudah tentu, dan ramai pasukan berbuat demikian. Scrum mengendalikan struktur Sprint, upacara, dan pengurusan Backlog. XP mengendalikan cara kod sebenarnya ditulis dan diuji dalam Sprint tersebut. Kedua-dua rangka kerja saling melengkapi dan bukannya bersaing.

Apakah permainan perancangan dalam XP?

Permainan perancangan adalah pendekatan XP kepada perancangan lelaran. Pelanggan menulis kisah yang menerangkan apa yang mereka perlukan; pembangun menganggar usaha. Bersama-sama mereka memutuskan apa yang muat ke dalam lelaran seterusnya. Ia serupa dengan sesi perancangan Sprint dalam Scrum tetapi dengan pelanggan memainkan peranan yang lebih aktif dan masa nyata dalam menentukan skop.

Adakah XP memerlukan pengaturcaraan berpasangan sepenuh masa?

Tidak semestinya. XP mengesyorkan pengaturcaraan berpasangan untuk kebanyakan kod pengeluaran, tetapi ramai pasukan menggunakannya secara terpilih, terutamanya untuk kerja yang kompleks, berisiko tinggi, atau asing. Matlamatnya ialah lebih banyak pandangan pada lebih banyak masalah, bukan kepatuhan tegar kepada peraturan.

Apakah perbezaan antara TDD dan ujian unit?

Ujian unit bermaksud menulis ujian untuk mengesahkan kod yang sudah wujud. TDD membalikkan urutan itu: anda menulis ujian dahulu (yang gagal), kemudian menulis kod minimum untuk meluluskannya, kemudian membersihkan reka bentuk. Urutannya penting kerana ia memaksa anda berfikir tentang apa yang perlu dilakukan oleh kod sebelum menulisnya.

Pemikiran penutup

XP kekal sebagai salah satu metodologi Agile yang paling teliti dari sudut teknikal. Amalannya masih relevan kerana ia menangani punca utama masalah kualiti perisian: integrasi lambat, ujian yang tiada, reka bentuk yang terlalu kompleks, dan komunikasi yang lemah. Pasukan yang mengambil XP dengan serius cenderung menghasilkan kod yang lebih mudah diubah, lebih mudah diuji, dan lebih mudah diserahkan.

Mulakan dengan satu atau dua amalan, ukur kesannya, dan bina dari situ. Set penuh dua belas amalan adalah destinasi, bukan titik permulaan.

Bacaan berkaitan

• Apakah Metodologi Agile
• Agile Manifesto: Nilai dan Prinsip Dijelaskan
• Apakah Scrum
• Kisah Pengguna: Cara Menulisnya dengan Baik
• Perancangan Sprint: Panduan Praktikal
• Kriteria Penerimaan: Cara Menulisnya
• Definition of Done
• Scrumban: Pendekatan Hibrid
• Scaled Agile Framework (SAFe)