eXtreme Programming

eXtreme Programming — biasanya cukup disebut XP — adalah anggota paling menuntut dari keluarga agile. East Agile Tracker dibangun untuk XP lebih dulu; segala sesuatu yang lain mengalir darinya.

Halaman ini membahas apa itu XP, mengapa ia bekerja, dan bagaimana mempraktikkannya dengan tracker sebagai permukaan perencanaan Anda.

Apa itu XP

XP diciptakan oleh Kent Beck pada akhir 1990-an. Buku pertamanya — Extreme Programming Explained: Embrace Change — diterbitkan pada 1999. Ia dimulai, seperti banyak hal, dengan sebuah tim yang frustrasi mencoba merilis sistem penggajian di Chrysler.

Taruhan XP adalah bahwa cara yang benar untuk menangani ketidakpastian dalam perangkat lunak adalah melakukan hal-hal yang berhasil, dan melakukannya lebih sering. Uji? Uji sepanjang waktu. Integrasikan? Integrasikan setiap jam. Bicara? Bicara terus-menerus. Rencanakan? Rencanakan setiap iterasi, dan rencanakan ulang saat Anda belajar.

“XP adalah metodologi ringan untuk tim kecil-hingga-menengah yang mengembangkan perangkat lunak menghadapi kebutuhan yang kabur atau berubah cepat.” — Kent Beck

Lima nilai

XP menyebutkan lima nilai yang menjadi gantungan segala sesuatu yang lain:

Komunikasi — Tim berbicara. Setiap hari. Tentang pekerjaan, desain, hambatan. Tatap muka bila memungkinkan. Silo adalah musuh.
Kesederhanaan — Lakukan hal paling sederhana yang mungkin berhasil. Anda bisa menambahkan kompleksitas nanti jika Anda benar-benar membutuhkannya. Anda mungkin tidak akan.
Umpan balik — Dari kode (uji), dari tim (pair programming, review), dari pengguna (release sering). Dapatkan dengan cepat.
Keberanian — Katakan kebenaran tentang kemajuan, estimasi, dan desain. Buang kode yang tidak berfungsi. Refactor apa yang menahan Anda.
Rasa hormat — Setiap orang dalam tim — dan kini, setiap agen dalam tim — berkontribusi nilai. Perlakukan satu sama lain sesuai dengan itu.

Praktiknya

XP terkenal dengan dua belas praktik aslinya, diorganisasikan dalam empat area:

Perencanaan

Planning Game — Tim dan pelanggan merencanakan bersama: apa yang datang berikutnya, dalam urutan apa, seberapa besar setiap bagiannya.
Small Releases — Kirim sering. Hitungan hari, bukan bulan. Dapatkan umpan balik atas sesuatu yang konkret.
User Stories — Kebutuhan adalah percakapan, ditangkap sebagai story singkat dari sudut pandang pengguna. “Sebagai pengguna, saya ingin X, agar Y.”

Perancangan

Simple Design — Desain paling sederhana yang lolos uji dan mengungkapkan setiap konsep yang dibutuhkan. Tidak lebih.
Refactoring — Tingkatkan desain kode yang sudah berfungsi. Terus-menerus.
System Metaphor — Sebuah kisah bersama tentang bagaimana sistem bekerja, digunakan untuk membuat keputusan desain yang konsisten.

Pengkodean

Pair Programming — Dua pengembang, satu keyboard. Satu menyetir, satu menavigasi. Bergantian sering.
Collective Code Ownership — Siapa pun dapat memperbaiki kode mana pun. Tanpa wilayah kekuasaan.
Continuous Integration — Integrasikan dan uji kode berkali-kali sehari. Tangkap kerusakan seketika.
Coding Standards — Gaya yang disepakati sehingga kode terbaca seolah ditulis satu orang.

Pengujian

Test-Driven Development (TDD) — Tulis uji yang gagal lebih dulu, lalu kode yang membuatnya lolos.
Acceptance Tests — Pelanggan mendefinisikan, dalam bentuk kode atau eksekutabel, apa arti “selesai” untuk setiap story.

Mengapa XP bekerja

XP itu tidak nyaman. Pair programming memaksa Anda berpikir dengan suara keras. TDD memaksa Anda tahu seperti apa keberhasilan sebelum Anda menulis kode. Continuous integration membunuh branch berumur-panjang favorit Anda. Release kecil berarti Anda tidak bisa bersembunyi di balik peta jalan enam bulan.

Ia bekerja karena semua hal ini memperpendek loop umpan balik. Semakin cepat Anda mengetahui bahwa Anda salah, semakin murah koreksinya. XP, secara mendasar, adalah tentang membuat loop umpan balik seketat mungkin.

Ia juga tentang keberanian dan rasa hormat. Anda hanya bisa melakukan XP pada tim yang cukup saling percaya untuk salah dengan terbuka.

Model story yang disiplin

East Agile Tracker mengkodekan teori perencanaan tertentu. Perlakukan bagian ini sebagai manual operasi untuk mengapa model datanya terlihat seperti itu — dan sebagai panduan lapangan tentang apa yang harus dilakukan (dan tidak dilakukan) dalam praktik.

Mengapa keempat tipe story penting

Segala sesuatu adalah story, tetapi ada empat jenis, dan perbedaannya adalah inti keseluruhannya:

Feature membawa poin dan satu-satunya hal yang “dihitung” ke velocity. Ini memaksa Anda mengiris pekerjaan menjadi nilai yang dapat diamati pengguna.
Bug tanpa poin (nol). Cacat tidak menghasilkan kredit, yang membuat biaya pengerjaan ulang terlihat alih-alih diberi imbalan.
Chore juga tanpa poin — pekerjaan yang perlu tanpa nilai pengguna langsung (infra, refactor, penyiapan). Menjaganya di nol menekan tim untuk menggabungkannya ke dalam feature di mana pun memungkinkan agar pembingkaian nilai tetap jujur.
Release adalah penanda nol-poin yang digunakan untuk menambatkan tonggak dan membiarkan alat memproyeksikan tanggal.

Efek perilakulah yang penting: ketika bug dan chore tidak mencetak skor, tim secara alami terdorong untuk mengungkapkan pekerjaan sebagai fungsionalitas berorientasi-pengguna, dan menjadi sangat sadar akan biaya cacat. Itu adalah disiplin perencanaan yang dikodekan ke dalam model data.

Backlog tunggal berurutan

Tiga zona, satu aturan.

Icebox adalah kolam ide yang belum diprioritaskan.
Backlog adalah daftar berurutan ketat, prioritas tunggal — tanpa seri, tanpa “P1/P1/P1.”
Zona Current menampung iterasi aktif.

Product owner memiliki urutan dari atas ke bawah, dan invariannya adalah bagian atas backlog selalu yang paling penting dan paling baik dispesifikasikan, dengan kejelasan secara sah menurun saat Anda turun ke bawah. Sebuah story di dekat bagian atas dengan kriteria penerimaan yang kabur adalah bug perencanaan. Icebox boleh menjadi kuburan; Backlog tidak boleh.

Perencanaan otomatis yang digerakkan velocity

Inilah bagian yang kebanyakan tim implementasikan ulang dengan buruk di tempat lain. Perencanaan ala-tracker menghitung rata-rata velocity bergulir dari poin yang baru diterima dan secara otomatis menarik sebanyak itu poin story ke iterasi berikutnya — Anda tidak “berkomitmen” pada sprint secara manual, data empiris yang melakukannya untuk Anda. Dua konsekuensi yang layak dipertahankan:

Anda mengestimasi hanya feature, menggunakan poin relatif (Fibonacci 1/2/3/5/8 atau skala kami yang lebih ketat 0/1/2/3), bukan jam. Estimasi adalah percakapan tentang ukuran, bukan janji.
Anda tidak mengakali velocity. Membengkakkan poin agar “terlihat cepat,” atau memberi poin pada chore, memecah proyeksi yang membuat seluruh sistem jujur. Velocity adalah instrumen pengukuran, dan Anda tidak mengutak-atik instrumen Anda sendiri.

Imbalannya adalah proyeksi tanggal release menjadi kalkulasi alih-alih negosiasi, dan percakapan dengan pemangku kepentingan bergeser dari “bisakah kamu komitmen X pada hari Jumat” menjadi “pada velocity saat ini, release ini mendarat sekitar tanggal Y — ini trade-off cakupan/tanggalnya.”

Daur hidup story dan loop penerimaan

Mesin statusnya adalah Start → Finish → Deliver → Accept / Reject. Status kritisnya adalah Deliver: seorang engineer menandai story sebagai delivered, tetapi ia belum selesai sampai product owner secara eksplisit menerimanya terhadap kriteria penerimaannya — atau menolaknya, mengembalikannya. Ini menanamkan loop umpan balik pelanggan ke dalam setiap story alih-alih menunda penerimaan ke demo akhir-sprint.

Kriteria penerimaan harus ada pada story sebelum dimulai, idealnya dalam bentuk Given/When/Then sehingga memetakan langsung ke acceptance test. INVEST adalah pengecekan kewarasan apakah suatu story terbentuk dengan baik:

Independent — dapat dirilis tanpa story lain.
Negotiable — menangkap niat, bukan spesifikasi beku.
Valuable — bagi pengguna atau pemangku kepentingan.
Estimable — tim dapat mengukurnya.
Small — muat nyaman dalam satu iterasi.
Testable — memiliki kriteria penerimaan yang dapat dijalankan.

Irama

Upacara perencanaan ringan dan teratur:

Iteration Planning Meeting mingguan untuk memberi poin pada story baru dan memastikan kriteria penerimaan di bagian atas backlog.
Standup harian singkat yang berfokus pada aliran dan blocker.
Retrospektif per iterasi untuk menyesuaikan proses.

Iterasi biasanya satu atau dua minggu — cukup pendek sehingga estimasi yang buruk murah untuk ditemukan.

Praktik rekayasa yang membuat perencanaan bekerja

Perencanaan ala-tracker adalah separuh terlihat dari XP; ia runtuh tanpa separuh rekayasa.

Test-first / TDD dan suite acceptance-test yang nyata adalah yang membuat “delivered” berarti sesuatu.
Continuous integration dan release kecil yang sering menjaga cycle time tetap pendek sehingga velocity stabil alih-alih bergumpal.
Pair programming (atau review yang kuat) menjaga work-in-progress tetap rendah — selesaikan sebelum Anda mulai — yang merupakan tuas tunggal terbesar pada cycle time.
Product owner yang tersedia adalah yang menjaga loop accept/reject dari kemacetan.

Anti-pola yang perlu diwaspadai

Kegagalan yang berulang:

Memperlakukan Backlog sebagai tempat parkir alih-alih urutan prioritas yang sebenarnya.
Mengestimasi bug dan chore agar velocity terlihat lebih baik.
Membawa story raksasa yang tidak dapat selesai dalam satu iterasi. Pecah sampai masing-masing dapat di-deliver secara independen.
Membiarkan story menumpuk di Delivered karena tidak ada yang menerima.

Salah satu dari ini diam-diam mengubah sistem empiris kembali menjadi perencanaan angan-angan. Tracker tidak dapat menghentikan Anda melakukannya; ia hanya dapat membuatnya terlihat. Lihat kolom Delivered Anda di akhir setiap iterasi — jika bertambah, itu sinyal Anda.

XP dengan East Agile Tracker

Tracker adalah permukaan perencanaan yang diinginkan tim XP sejak masa Pivotal Tracker. Setiap konsep memetakan langsung:

User Stories → Story

User story XP adalah story East Agile Tracker. Tulis mereka dalam tipe Feature. Gunakan deskripsi untuk percakapan; gunakan komentar untuk diskusi berkelanjutan. Kriteria penerimaan ada di deskripsi.

Planning Game → Papan

Planning Game dalam XP adalah percakapan antara bisnis dan tim tentang prioritas dan ukuran. Di East Agile Tracker:

Orang produk menulis story di Backlog dan mengurutkannya berdasarkan prioritas.
Tim mengestimasi feature dalam poin (skala Fibonacci atau East Agile).
Sistem merencanakan otomatis iterasi dari velocity.
Tim memulai story dari bagian atas kolom Current.

Itu saja. “Permainan” hidup dalam percakapan; tracker hanya menjaga skornya.

Small Releases → Release (tipe story)

XP mengatakan release sering. Release adalah salah satu dari empat tipe story di East Agile Tracker. Buat release untuk setiap tonggak pengiriman; seret ke iterasi tempat ia dirilis. Release melewati Started/Finished/Delivered dan langsung ke Accepted ketika Anda merilis.

Continuous Integration → Mesin status story

Mesin status bukan CI itu sendiri — itu sistem build Anda — tetapi jalur Finished → Delivered → Accepted mencerminkan loop penerimaan-pelanggan yang dijelaskan XP. Selesaikan pekerjaan, deliver ke pelanggan, terima ketika dikonfirmasi berfungsi.

Velocity → “Cuaca kemarin”

XP menyebutnya yesterday’s weather: seberapa banyak yang Anda selesaikan iterasi lalu adalah prediksi terbaik seberapa banyak yang akan Anda selesaikan kali ini. East Agile Tracker menghitung velocity secara otomatis — rata-rata iterasi terkini, strategi yang dapat dikonfigurasi — dan menggunakannya untuk merencanakan otomatis kapasitas iterasi berikutnya.

Acceptance Tests → Review

Review story di tracker memetakan ke penerimaan. Tugaskan reviewer (pelanggan, product owner, atau bahkan agen yang bertindak sebagai salah satunya). Mereka approve atau reject. Rejected mengirim story kembali ke Started.

Pair Programming → Ko-kepemilikan

Tim XP berpasangan pada kode. Di tracker, ini muncul sebagai pemilik ganda pada story. Tugaskan kedua pasangan ke story; kedua nama muncul di kartu.

XP dengan agen — praktik baru

XP ditulis sebelum agen AI dapat berkontribusi secara berarti pada perangkat lunak. Kami pikir ini adalah pembaruan paling penting bagi XP dalam dua puluh lima tahun.

Dalam praktik kami — dan untuk apa tracker ini dibangun — sebuah agen adalah anggota tim XP yang bernama. Ia memiliki perannya sendiri, mitra pasangannya sendiri (manusia atau agen), dan jejak auditnya sendiri. Ia dapat melakukan apa pun yang dapat dilakukan anggota tim manusia di permukaan perencanaan: estimasi, memiliki story, berkomentar, bertransisi, menerima review.

Nilai-nilai XP masih berlaku. Komunikasi: agen berkomunikasi dengan membaca aliran event dan memposting komentar. Kesederhanaan: agen dibatasi pada peran yang Anda berikan. Umpan balik: setiap aksi agen ada di log audit, dapat segera di-review. Keberanian: jujurlah tentang apa yang dilakukan agen Anda dengan benar dan apa yang tidak. Rasa hormat: rekan setim agen berkontribusi nilai — akui itu.

Kami tidak menempatkan agen di dalam tracker melakukan pengkodean. Kami memberikan permukaan perencanaan kepada manusia dan agen yang bekerja bersama. Anda yang membawa coding agent — Claude Code, Codex, milik Anda sendiri — dan menghubungkannya ke tracker via API. Agen mengambil story, melakukan pekerjaan, berkomentar, bertransisi. Anda me-review jejaknya dan menerima.

Inilah Inclusive Agile Planning. Ini adalah XP, dengan tim yang benar-benar dimilikinya.

Bacaan lebih lanjut

Extreme Programming Explained — Buku fondasi Kent Beck, 1999.
Manifesto Agile — Tempat keluarga ini dimulai.
Pengembangan Agile — Gambaran yang lebih luas.
Petunjuk Pengoperasian — Panduan praktis untuk tracker.
Panduan API — Menyambungkan coding agent Anda.