eXtreme Programming

eXtreme Programming — biasanya hanya XP — ialah ahli yang paling menuntut dalam keluarga agile. East Agile Tracker dibina untuk XP dahulu; segala yang lain terhasil daripadanya.

Halaman ini meliputi apa itu XP, mengapa ia berfungsi, dan cara mengamalkannya dengan tracker sebagai permukaan perancangan anda.

Apa itu XP

XP dicipta oleh Kent Beck pada akhir 1990-an. Buku pertama — Extreme Programming Explained: Embrace Change — diterbitkan pada 1999. Ia bermula, seperti banyak perkara, dengan pasukan yang kecewa cuba menghantar sistem gaji di Chrysler.

Pertaruhan XP ialah cara yang betul untuk menangani ketidakpastian dalam perisian ialah melakukan perkara yang berfungsi, dan melakukannya lebih kerap. Uji? Uji sepanjang masa. Integrasi? Integrasi setiap jam. Bercakap? Bercakap berterusan. Rancang? Rancang setiap iterasi, dan rancang semula apabila anda belajar.

“XP ialah metodologi ringan untuk pasukan bersaiz kecil-ke-sederhana yang membangunkan perisian dalam menghadapi keperluan yang kabur atau berubah dengan pantas.” — Kent Beck

Lima nilai

XP menamakan lima nilai yang segala yang lain bergantung padanya:

1. Komunikasi — Pasukan bercakap. Setiap hari. Tentang kerja, reka bentuk, halangan. Bersemuka apabila boleh. Silo ialah musuh.
2. Kesederhanaan — Lakukan perkara paling mudah yang mungkin boleh berfungsi. Anda boleh menambah kerumitan kemudian jika anda benar-benar memerlukannya. Anda mungkin tidak akan.
3. Maklum balas — Daripada kod (ujian), daripada pasukan (pengaturcaraan berpasangan, semakan), daripada pengguna (release kerap). Dapatkannya dengan pantas.
4. Keberanian — Beritahu kebenaran tentang kemajuan, anggaran, dan reka bentuk. Buang kod yang tidak berfungsi. Refactor apa yang menahan anda.
5. Hormat — Semua orang dalam pasukan — dan kini, setiap ejen dalam pasukan — menyumbang nilai. Layan satu sama lain sewajarnya.

Amalan

XP terkenal dengan dua belas amalan asalnya, disusun dalam empat bidang:

Perancangan

• Planning Game — Pasukan dan pelanggan merancang bersama: apa yang akan datang seterusnya, dalam susunan apa, sebesar mana setiap bahagian.
• Small Releases — Hantar kerap. Hari, bukan bulan. Dapatkan maklum balas pada sesuatu yang konkrit.
• User Stories — Keperluan ialah perbualan, ditangkap sebagai story ringkas daripada sudut pandangan pengguna. “Sebagai pengguna, saya mahu X, supaya Y.”

Mereka bentuk

• Simple Design — Reka bentuk paling mudah yang lulus ujian dan menyatakan setiap konsep yang diperlukan. Tidak lebih.
• Refactoring — Tingkatkan reka bentuk kod yang sudah berfungsi. Secara berterusan.
• System Metaphor — Kisah bersama tentang cara sistem berfungsi, digunakan untuk membuat keputusan reka bentuk konsisten.

Pengekodan

• Pair Programming — Dua pembangun, satu papan kekunci. Seorang memandu, seorang menavigasi. Tukar kerap.
• Collective Code Ownership — Sesiapa boleh memperbaik mana-mana kod. Tiada wilayah peribadi.
• Continuous Integration — Integrasi dan uji kod berkali-kali sehari. Tangkap kerosakan serta-merta.
• Coding Standards — Gaya yang dipersetujui supaya kod dibaca seolah-olah seorang menulisnya.

Pengujian

• Test-Driven Development (TDD) — Tulis ujian yang gagal dahulu, kemudian kod yang menjadikannya lulus.
• Acceptance Tests — Pelanggan mentakrif, dalam kod atau bentuk boleh laksana, apa “selesai” bermaksud untuk setiap story.

Mengapa XP berfungsi

XP tidak selesa. Pengaturcaraan berpasangan memaksa anda berfikir secara lantang. TDD memaksa anda mengetahui rupa kejayaan sebelum anda menulis kod. Integrasi berterusan membunuh cabang panjang kegemaran anda. Release kecil bermaksud anda tidak boleh bersembunyi di sebalik peta jalan enam bulan.

Ia berfungsi kerana semua perkara ini memendekkan gelung maklum balas. Lebih pantas anda mengetahui anda salah, lebih murah pembetulannya. XP, pada asasnya, adalah tentang menjadikan gelung maklum balas seketat mungkin.

Ia juga tentang keberanian dan hormat. Anda hanya boleh melakukan XP pada pasukan yang cukup mempercayai satu sama lain untuk salah secara lantang.

Model story berdisiplin

East Agile Tracker mengkodkan teori perancangan tertentu. Anggap bahagian ini sebagai manual pengendalian untuk mengapa model data kelihatan seperti yang ada — dan sebagai panduan lapangan untuk apa yang perlu dilakukan (dan tidak dilakukan) dalam amalan.

Mengapa empat jenis story penting

Segala-galanya ialah story, tetapi terdapat empat jenis, dan perbezaannya adalah seluruh maksudnya:

• Feature membawa mata dan merupakan satu-satunya perkara yang “dikira” ke arah velocity. Ini memaksa anda menghiris kerja kepada nilai yang boleh diperhatikan pengguna.
• Bug tidak bermata (sifar). Kecacatan tidak mendapat kredit, yang menjadikan kos kerja semula kelihatan dan bukannya diberi ganjaran.
• Chore juga tidak bermata — kerja perlu tanpa nilai pengguna langsung (infra, refactor, persediaan). Mengekalkannya pada sifar menekan pasukan untuk menggabungkannya ke dalam feature di mana mungkin supaya pembingkaian nilai kekal jujur.
• Release ialah penanda sifar mata digunakan untuk mengikat pencapaian dan membenarkan alat mengunjurkan tarikh.

Kesan tingkah laku itulah yang penting: apabila bug dan chore tidak mendapat skor, pasukan secara semula jadi mendesak untuk menyatakan kerja sebagai fungsi berorientasikan pengguna, dan ia menjadi amat sedar tentang kos kecacatan. Itu ialah disiplin perancangan yang dikodkan dalam model data.

Backlog tunggal yang tersusun

Tiga zon, satu peraturan.

• Icebox ialah kolam idea tidak diprioritikan.
• Backlog ialah senarai keutamaan-tunggal yang disusun ketat — tiada seri, tiada “P1/P1/P1.”
• Zon Current memegang iterasi aktif.

Pemilik produk memiliki susunan dari atas ke bawah, dan invariannya ialah bahagian atas backlog sentiasa yang paling penting dan paling baik dispesifikasikan, dengan kejelasan menurun secara sah apabila anda turun ke bawah. Story berhampiran bahagian atas dengan kriteria penerimaan yang kabur ialah pepijat perancangan. Icebox dibenarkan menjadi kubur; Backlog tidak.

Perancangan automatik dipacu-velocity

Ini ialah bahagian yang kebanyakan pasukan laksana semula dengan buruk di tempat lain. Perancangan gaya-tracker mengira purata velocity berputar daripada mata yang baru-baru ini diterima dan secara automatik menarik mata story sebanyak itu ke dalam iterasi seterusnya — anda tidak “berkomitmen” secara manual kepada sprint, data empirikal melakukannya untuk anda. Dua akibat yang patut dikekalkan:

• Anda menganggar feature sahaja, menggunakan mata relatif (Fibonacci 1/2/3/5/8 atau 0/1/2/3 kami yang lebih ketat), bukan jam. Anggaran ialah perbualan saiz, bukan janji.
• Anda tidak menipu velocity. Mengembungkan mata untuk “kelihatan pantas,” atau memberi mata kepada chore, memecahkan unjuran yang menjadikan keseluruhan sistem jujur. Velocity ialah alat pengukuran, dan anda tidak mengusik alat anda sendiri.

Hasilnya ialah unjuran tarikh release menjadi pengiraan dan bukannya rundingan, dan perbualan dengan pihak berkepentingan beralih daripada “boleh anda berkomitmen kepada X menjelang Jumaat” kepada “pada velocity semasa, release ini mendarat sekitar tarikh Y — inilah pertukaran skop/tarikh.”

Kitaran hayat story dan gelung penerimaan

Mesin keadaan ialah Start → Finish → Deliver → Accept / Reject. Keadaan kritikal ialah Deliver: seorang jurutera menandakan story sebagai delivered, tetapi ia belum selesai sehingga pemilik produk secara eksplisit menerimanya berdasarkan kriteria penerimaannya — atau menolaknya, menghantarnya kembali. Ini menanam gelung maklum balas pelanggan ke dalam setiap satu story dan bukannya menangguhkan penerimaan ke demo akhir sprint.

Kriteria penerimaan tergolong pada story sebelum ia dimulakan, sebaik-baiknya dalam bentuk Given/When/Then supaya ia memetakan terus kepada ujian penerimaan. INVEST ialah semakan kewarasan tentang sama ada story terbentuk dengan baik:

• Independent — boleh dihantar tanpa story lain.
• Negotiable — menangkap niat, bukan spesifikasi beku.
• Valuable — kepada pengguna atau pihak berkepentingan.
• Estimable — pasukan boleh menyaiznya.
• Small — muat selesa dalam satu iterasi.
• Testable — mempunyai kriteria penerimaan yang boleh dilaksanakan.

Irama

Upacara perancangan adalah ringan dan tetap:

• Mesyuarat Perancangan Iterasi mingguan untuk memberi mata kepada story baharu dan menetapkan kriteria penerimaan di bahagian atas backlog.
• Standup harian yang ringkas berfokus pada aliran dan blocker.
• Retrospektif setiap iterasi untuk menyesuaikan proses.

Iterasi biasanya satu atau dua minggu — cukup pendek sehingga anggaran yang buruk adalah murah untuk ditemui.

Amalan kejuruteraan yang menjadikan perancangan berfungsi

Perancangan gaya-tracker ialah separuh kelihatan XP; ia runtuh tanpa separuh kejuruteraan.

• Test-first / TDD dan suite ujian penerimaan sebenar ialah apa yang membenarkan “delivered” bermaksud sesuatu.
• Integrasi berterusan dan release kecil yang kerap mengekalkan masa kitaran pendek supaya velocity stabil dan bukannya bonggol.
• Pengaturcaraan berpasangan (atau semakan kuat) mengekalkan kerja-dalam-proses rendah — selesai sebelum anda mula — yang merupakan tuas terbesar pada masa kitaran.
• Pemilik produk yang tersedia ialah apa yang mengekalkan gelung terima/tolak daripada terhenti.

Anti-pola untuk diawasi

Kegagalan yang berulang:

• Melayan Backlog sebagai tempat letak kereta dan bukannya susunan keutamaan sebenar.
• Menganggar bug dan chore untuk menjadikan velocity kelihatan lebih baik.
• Membawa story besar yang tidak boleh selesai dalam satu iterasi. Bahagikan sehingga setiap satu boleh dihantar secara bebas.
• Membenarkan story bertimbun dalam Delivered kerana tiada siapa yang menerima.

Mana-mana ini dengan senyap menukar sistem empirikal kembali kepada perancangan angan-angan. Tracker tidak boleh menghentikan anda daripada melakukannya; ia hanya boleh menjadikannya kelihatan. Lihat lajur Delivered anda pada akhir setiap iterasi — jika ia bertambah, itu isyarat anda.

XP dengan East Agile Tracker

Tracker ialah permukaan perancangan yang pasukan XP inginkan sejak zaman Pivotal Tracker. Setiap konsep memetakan terus:

User Stories → Story

User story XP ialah story East Agile Tracker. Tulis ia dalam jenis Feature. Gunakan penerangan untuk perbualan; gunakan ulasan untuk perbincangan berterusan. Kriteria penerimaan tergolong dalam penerangan.

Planning Game → Papan

Planning Game dalam XP ialah perbualan antara perniagaan dan pasukan tentang keutamaan dan saiz. Dalam East Agile Tracker:

1. Orang produk menulis story dalam Backlog dan menyusunnya mengikut keutamaan.
2. Pasukan menganggar feature dalam mata (skala Fibonacci atau East Agile).
3. Sistem merancang iterasi secara automatik daripada velocity.
4. Pasukan memulakan story dari bahagian atas lajur Current.

Itu sahaja. “Permainan” tinggal dalam perbualan; tracker hanya menyimpan markah.

Small Releases → Release (jenis story)

XP mengatakan release kerap. Release ialah salah satu daripada empat jenis story dalam East Agile Tracker. Cipta release untuk setiap pencapaian penghantaran; seret ia ke iterasi di mana ia dihantar. Release melangkau Started/Finished/Delivered dan pergi terus ke Accepted apabila anda menghantar.

Continuous Integration → Mesin keadaan story

Mesin keadaan bukan CI itu sendiri — itu sistem binaan anda — tetapi laluan Finished → Delivered → Accepted mencerminkan gelung penerimaan-pelanggan yang XP terangkan. Selesaikan kerja, hantar ia kepada pelanggan, terima apabila ia disahkan berfungsi.

Velocity → “Cuaca semalam”

XP memanggilnya cuaca semalam: berapa banyak yang anda selesaikan iterasi lepas ialah ramalan terbaik berapa banyak yang anda akan selesaikan iterasi ini. East Agile Tracker mengira velocity secara automatik — purata iterasi terkini, strategi boleh dikonfigurasi — dan menggunakannya untuk merancang kapasiti iterasi seterusnya secara automatik.

Acceptance Tests → Semakan

Semakan story dalam tracker memetakan kepada penerimaan. Tugaskan penyemak (pelanggan, pemilik produk, atau bahkan ejen yang bertindak sebagai satu). Mereka meluluskan atau menolak. Ditolak menghantar story kembali ke Started.

Pair Programming → Pemilikan bersama

Pasukan XP berpasangan pada kod. Dalam tracker, ini muncul sebagai pelbagai pemilik pada story. Tugaskan kedua-dua pasangan kepada story; kedua-dua nama muncul pada kad.

XP dengan ejen — amalan baharu

XP ditulis sebelum ejen AI boleh menyumbang dengan bermakna kepada perisian. Kami berfikir ini ialah kemas kini paling penting kepada XP dalam dua puluh lima tahun.

Dalam amalan kami — dan apa yang tracker dibina untuk — seorang ejen ialah ahli pasukan XP bernama. Ia mempunyai peranannya sendiri, rakan berpasangannya sendiri (manusia atau ejen), dan jejak auditnya sendiri. Ia boleh melakukan apa-apa yang ahli pasukan manusia boleh lakukan dalam permukaan perancangan: anggar, miliki story, ulas, ubah, terima semakan.

Nilai XP masih berpegang. Komunikasi: ejen berkomunikasi dengan membaca aliran peristiwa dan menyiarkan ulasan. Kesederhanaan: ejen dikekang kepada peranan yang anda berikan kepada mereka. Maklum balas: setiap tindakan ejen berada dalam log audit, boleh disemak serta-merta. Keberanian: jujur tentang apa yang ejen anda betulkan dan apa yang tidak. Hormat: rakan sepasukan ejen menyumbang nilai — kenalinya.

Kami tidak meletakkan ejen di dalam tracker melakukan pengekodan. Kami memberikan permukaan perancangan kepada manusia dan ejen yang bekerja bersama. Anda bawa ejen pengekodan — Claude Code, Codex, milik anda sendiri — dan sambungkannya ke tracker melalui API. Ejen mengambil story, melakukan kerja, mengulas, mengubah. Anda menyemak jejak dan menerima.

Inilah Perancangan Agile Inklusif. Ia adalah XP, dengan pasukan yang ia sebenarnya ada.

Bacaan lanjut

• Extreme Programming Explained — Buku asas Kent Beck, 1999.
• Manifesto Agile — Di mana keluarga bermula.
• Pembangunan Agile — Gambaran yang lebih luas.
• Arahan Pengendalian — Panduan praktikal kepada tracker.
• Panduan API — Memasang ejen pengekodan anda.