eXtreme Programming

Ang eXtreme Programming — kadalasang XP lamang — ang pinaka-mapaghamong miyembro ng pamilyang agile. Binuo ang East Agile Tracker para sa XP muna; lahat ng iba ay umaagos mula rito.

Sinasaklaw ng pahinang ito kung ano ang XP, bakit ito gumagana, at paano isasagawa ito kasama ang tracker bilang iyong planning surface.

Ano ang XP

Nilikha ang XP ni Kent Beck noong huling bahagi ng 1990s. Ang unang aklat — Extreme Programming Explained: Embrace Change — ay inilathala noong 1999. Nagsimula ito, tulad ng maraming bagay, sa isang frustrated na team na sinusubukang maghatid ng sistemang pang-payroll sa Chrysler.

Ang taya ng XP ay na ang tamang paraan ng paghawak ng kawalan ng katiyakan sa software ay ang gawin ang mga bagay na gumagana, at gawin ang mga ito nang mas madalas. Mag-test? Mag-test sa lahat ng oras. Mag-integrate? Mag-integrate kada oras. Mag-usap? Mag-usap nang tuloy-tuloy. Magplano? Magplano kada iteration, at muling magplano habang natututo ka.

“Ang XP ay isang magaang pamamaraan para sa maliit-hanggang-katamtamang laking team na bumubuo ng software sa harap ng malabo o mabilis na nagbabagong mga kinakailangan.” — Kent Beck

Ang limang halaga

Pinangalanan ng XP ang limang halaga na pinagbabatayan ng lahat ng iba:

1. Komunikasyon — Nag-uusap ang team. Araw-araw. Tungkol sa trabaho, ang disenyo, ang mga hadlang. Harapan kung maaari. Kalaban ang mga silo.
2. Pagiging simple — Gawin ang pinakasimpleng bagay na maaaring gumana. Maaari kang magdagdag ng pagiging kumplikado mamaya kung talagang kailangan mo. Malamang hindi.
3. Feedback — Mula sa code (mga test), mula sa team (pair programming, mga review), mula sa user (madalas na release). Kunin ito nang mabilis.
4. Tapang — Sabihin ang totoo tungkol sa pag-usad, mga tantiya, at disenyo. Itapon ang code na hindi gumagana. I-refactor ang humahadlang sa iyo.
5. Paggalang — Lahat ng nasa team — at ngayon, bawat agent sa team — ay nag-aambag ng halaga. Tratuhin ang isa’t isa nang naaayon.

Ang mga praktika

Kilala ang XP sa labindalawang orihinal na praktika nito, na inayos sa apat na lugar:

Pagpaplano

• Planning Game — Nagpaplano nang sama-sama ang team at ang customer: ano ang susunod, sa anong pagkakasunod-sunod, gaano kalaki ang bawat piraso.
• Maliliit na Release — Maghatid nang madalas. Mga araw, hindi mga buwan. Kumuha ng feedback sa isang konkretong bagay.
• User Stories — Ang mga kinakailangan ay mga usapan, na nakuha bilang maiikling story mula sa pananaw ng user. “Bilang user, gusto ko ang X, upang Y.”

Pagdidisenyo

• Simpleng Disenyo — Ang pinakasimpleng disenyo na pumapasa sa mga test at nagpapahayag ng bawat kinakailangang konsepto. Wala nang iba.
• Refactoring — Pahusayin ang disenyo ng code na gumagana na. Tuloy-tuloy.
• System Metaphor — Isang ibinahaging kuwento kung paano gumagana ang sistema, na ginagamit upang gawing pare-pareho ang mga desisyon sa disenyo.

Pag-code

• Pair Programming — Dalawang developer, isang keyboard. Isa ang nagmamaneho, isa ang nag-na-navigate. Magpalit nang madalas.
• Collective Code Ownership — Sino man ay maaaring magpahusay ng anumang code. Walang mga teritoryo.
• Continuous Integration — Mag-integrate at mag-test ng code nang maraming beses sa isang araw. Hulihin agad ang mga sira.
• Coding Standards — Pinagkasunduang istilo upang basahin ang code na parang isang tao ang sumulat nito.

Pag-test

• Test-Driven Development (TDD) — Isulat muna ang failing test, tapos ang code na nagpapasa nito.
• Acceptance Tests — Inilalarawan ng customer, sa code o anyong executable, kung ano ang ibig sabihin ng “done” para sa bawat story.

Bakit gumagana ang XP

Hindi komportable ang XP. Pinipilit ka ng pair programming na mag-isip nang malakas. Pinipilit ka ng TDD na malaman kung ano ang itsura ng tagumpay bago mo isulat ang code. Pinapatay ng continuous integration ang iyong mga paboritong matagal-buhay na branch. Ang maliliit na release ay nangangahulugang hindi ka makakatago sa likod ng anim-na-buwang roadmap.

Gumagana ito dahil pinapaikli ng lahat ng mga bagay na ito ang mga feedback loop. Habang mas mabilis mong nalalaman na mali ka, mas mura ang pagwawasto. Ang XP ay, sa esensya, tungkol sa paggawa ng feedback loop na kasing-higpit hangga’t maaari.

Ito rin ay tungkol sa tapang at paggalang. Magagawa mo lamang ang XP sa isang team na sapat na nagtitiwalaan upang magkamali nang malakas.

Ang disiplinadong modelo ng story

Ina-encode ng East Agile Tracker ang isang tiyak na teorya ng pagpaplano. Ituring ang seksyong ito bilang operating manual para sa bakit ganyan ang itsura ng data model — at bilang field guide kung ano ang gagawin (at hindi gagawin) sa praktika.

Bakit mahalaga ang apat na uri ng story

Lahat ay story, ngunit may apat na uri, at ang pagkakaiba ang buong punto:

• Mga Feature ay may dalang puntos at ang tanging bagay na “bumibilang” sa velocity. Pinipilit ka nitong hatiin ang trabaho tungo sa halagang nakikita ng user.
• Mga Bug ay walang puntos (zero). Hindi kumikita ng kredito ang mga depekto, na nagpapakita ng halaga ng rework sa halip na gantimpalaan ito.
• Mga Chore ay walang puntos din — kinakailangang trabaho na walang direktang halaga sa user (infra, mga refactor, setup). Ang pagpapanatili sa kanila sa zero ay pumipilit sa team na isama ang mga ito sa mga feature kung saan maaari upang manatiling tapat ang pagsasaalang-alang sa halaga.
• Mga Release ay mga zero-point na marka na ginagamit upang mag-angkla ng mga milestone at hayaang mag-project ng petsa ang tool.

Ang epektong pang-ugali ang mahalaga: kapag hindi nagsko-score ang mga bug at chore, natural na itinutulak ng team na ipahayag ang trabaho bilang functionality na nakatuon sa user, at nagiging matinding alerto ito sa halaga ng depekto. Iyon ay disiplina sa pagpaplano na naka-encode sa data model.

Ang iisang nakaayos na backlog

Tatlong zone, isang patakaran.

• Ang Icebox ay ang hindi pinaprayoridad na pool ng mga ideya.
• Ang Backlog ay isang mahigpit na nakaayos, single-priority na listahan — walang pagkakapantay, walang “P1/P1/P1.”
• Ang Current na zone ang humahawak ng aktibong (mga) iteration.

Pag-aari ng product owner ang pagkakasunod-sunod mula taas hanggang baba, at ang invariant ay na ang itaas ng backlog ay palaging ang pinakamahalaga at pinakamahusay na naitakda, at lehitimong bumababa ang kalinawan habang bumababa ka. Ang isang story malapit sa itaas na may malabong acceptance criteria ay isang planning bug. Pinapayagang maging libingan ang Icebox; ang Backlog ay hindi.

Velocity-driven na awtomatikong pagpaplano

Ito ang bahaging karamihan sa mga team ay muling ipinapatupad nang masama sa ibang lugar. Kinakalkula ng Tracker-style na pagpaplano ang rolling average velocity mula sa kamakailang tinanggap na puntos at awtomatikong hinihila ang ganoong dami ng puntos ng mga story sa susunod na iteration — hindi ka manu-manong “nangangako” sa isang sprint, ginagawa ito para sa iyo ng empirikal na datos. Dalawang kahihinatnan na karapat-dapat panatilihin:

• Tinatantiya mo lamang ang mga feature, gamit ang relatibong puntos (Fibonacci 1/2/3/5/8 o ang aming mas mahigpit na 0/1/2/3), hindi oras. Ang pagtantiya ay isang usapan tungkol sa laki, hindi isang pangako.
• Hindi mo dinadaya ang velocity. Ang pagpapalobo ng puntos upang “magmukhang mabilis,” o pagbibigay-puntos sa mga chore, ay sumisira sa projection na nagpapatapat sa buong sistema. Ang velocity ay isang instrumento sa pagsukat, at hindi mo pinapakialaman ang sariling instrumento.

Ang kabayaran ay na nagiging kalkulasyon ang projection ng petsa ng release sa halip na negosasyon, at lumilipat ang usapan sa mga stakeholder mula sa “kaya mo bang ipangako ang X sa Biyernes” tungo sa “sa kasalukuyang velocity, dadating ang release na ito sa paligid ng petsang Y — narito ang trade-off ng saklaw/petsa.”

Ang lifecycle ng story at ang acceptance loop

Ang state machine ay Start → Finish → Deliver → Accept / Reject. Ang kritikal na estado ay Deliver: minamarkahan ng inhinyero ang isang story bilang delivered, ngunit hindi pa ito tapos hanggang tahasang tinatanggap ito ng product owner laban sa mga acceptance criteria nito — o tinatanggihan ito, ibinabalik ito. Ito ang naglalagay ng customer-feedback loop sa bawat isang story sa halip na ipagpaliban ang pagtanggap sa demo sa pagtatapos ng sprint.

Ang mga acceptance criteria ay dapat nasa story bago ito masimulan, mas mainam sa anyong Given/When/Then upang direktang tumugma ang mga ito sa mga acceptance test. Ang INVEST ang sanity check kung handa nang maayos ang isang story:

• Independent — naihahatid nang walang ibang story.
• Negotiable — kinukuha ang intensyon, hindi isang nakapirming spec.
• Valuable — sa isang user o stakeholder.
• Estimable — kaya itong tantyahin ng team.
• Small — kumportableng umaakma sa isang iteration.
• Testable — may mga acceptance criteria na maaaring subukin.

Cadence

Magaan at regular ang mga seremonya sa pagpaplano:

• Isang lingguhang Iteration Planning Meeting upang bigyan-puntos ang mga bagong story at itakda ang mga acceptance criteria sa itaas ng backlog.
• Isang maikling araw-araw na standup na nakatuon sa flow at mga blocker.
• Isang retrospective kada iteration upang i-adjust ang proseso.

Ang mga iteration ay karaniwang isa o dalawang linggo — sapat na maikli upang ang isang masamang tantiya ay mura nang matuklasan.

Ang mga engineering practice na nagpapagana sa pagpaplano

Ang Tracker-style na pagpaplano ang nakikitang kalahati ng XP; gumuguho ito nang walang engineering na kalahati.

• Test-first / TDD at isang tunay na acceptance-test suite ang nagbibigay-kahulugan sa “delivered.”
• Continuous integration at maliit, madalas na release ay nagpapaikli sa cycle time upang maging matatag ang velocity sa halip na pabugso-bugso.
• Pair programming (o matibay na review) ang nagpapanatiling mababa ng work-in-progress — tapusin bago magsimula — na siyang pinakamalaking lever sa cycle time.
• Isang available na product owner ang nagpapanatiling hindi humihinto ang accept/reject loop.

Mga anti-pattern na bantayan

Ang mga umuulit na kabiguan:

• Ang pagtrato sa Backlog bilang parking lot sa halip na isang tunay na priority na pagkakasunod-sunod.
• Ang pagtantiya ng mga bug at chore upang magmukhang mas mabuti ang velocity.
• Ang pagdadala ng napakalalaking story na hindi matatapos sa isang iteration. Hatiin hanggang ang bawat isa ay malayang maihahatid.
• Ang paghahayaang maipon ang mga story sa Delivered dahil walang tumatanggap.

Anuman sa mga ito ay tahimik na nagpapabalik ng empirikal na sistema tungo sa wishful planning. Hindi ka mapipigilan ng tracker sa paggawa ng mga ito; magagawa lamang nitong gawin silang nakikita. Tingnan ang iyong Delivered column sa pagtatapos ng bawat iteration — kung lumalaki ito, iyon ang iyong senyales.

XP kasama ang East Agile Tracker

Ang tracker ay ang planning surface na ninanais ng mga XP team mula pa noong mga panahon ng Pivotal Tracker. Bawat konsepto ay direktang nag-map:

User Stories → Stories

Ang mga XP user story ay mga East Agile Tracker story. Isulat ang mga ito sa uri na Feature. Gamitin ang paglalarawan para sa usapan; gamitin ang mga comment para sa patuloy na talakayan. Ang mga acceptance criteria ay dapat nasa paglalarawan.

Planning Game → Ang board

Ang Planning Game sa XP ay isang usapan sa pagitan ng negosyo at team tungkol sa priority at laki. Sa East Agile Tracker:

1. Isinusulat ng taong-produkto ang mga story sa Backlog at inaayos ang mga ito ayon sa priority.
2. Tinatantiya ng team ang mga feature sa puntos (Fibonacci o East Agile scale).
3. Awtomatikong pinaplano ng sistema ang mga iteration mula sa velocity.
4. Sinisimulan ng team ang mga story mula sa itaas ng Current column.

Iyon na. Ang “laro” ay naninirahan sa usapan; ang tracker ay nag-iingat lang ng iskor.

Maliliit na Release → Releases (ang uri ng story)

Sinasabi ng XP na maghatid nang madalas. Ang Release ay isa sa apat na uri ng story sa East Agile Tracker. Lumikha ng release para sa bawat shipping milestone; i-drag ito sa iteration kung saan ito naihahatid. Nilalaktawan ng mga release ang Started/Finished/Delivered at tuwiran tungo sa Accepted kapag inihatid mo.

Continuous Integration → State machine ng story

Hindi mismo CI ang state machine — iyon ang iyong build system — ngunit sinasalamin ng daang Finished → Delivered → Accepted ang customer-acceptance loop na inilalarawan ng XP. Tapusin ang trabaho, ihatid ito sa customer, tanggapin kapag nakumpirmang gumagana.

Velocity → “Panahon kahapon”

Tinatawag ito ng XP na panahon kahapon (yesterday’s weather): kung gaano karami ang natapos mo noong huling iteration ang pinakamahusay na hula kung gaano karami ang matatapos mo sa isang ito. Awtomatikong kinakalkula ng East Agile Tracker ang velocity — average ng kamakailang mga iteration, ma-configure na strategy — at ginagamit ito upang awtomatikong planuhin ang kapasidad ng susunod na iteration.

Acceptance Tests → Reviews

Ang mga review ng story sa tracker ay nag-map sa acceptance. Magtalaga ng reviewer (ang customer, ang product owner, o kahit isang agent na kumikilos bilang isa). Tinatanggap o tinatanggihan nila. Ibinabalik ng rejected ang story sa Started.

Pair Programming → Co-ownership

Nagpe-pair ang mga XP team sa code. Sa tracker, lumalabas ito bilang maraming owner sa isang story. Italaga ang parehong pares sa story; pareho silang pangalan ang lumalabas sa card.

XP kasama ang mga agent — ang bagong praktika

Isinulat ang XP bago makapag-ambag nang makabuluhan ang mga AI agent sa software. Naniniwala kaming ito ang pinakamahalagang update sa XP sa loob ng dalawampu’t limang taon.

Sa aming praktika — at kung saan binuo ang tracker — ang isang agent ay isang pinangalanang miyembro ng XP team. May sarili itong tungkulin, sarili nitong pair partner (tao o agent), at sarili nitong audit trail. Kaya nitong gawin ang anumang kayang gawin ng isang taong miyembro ng team sa planning surface: magtantiya, mag-arí ng mga story, mag-comment, mag-transition, tumanggap ng mga review.

Nananatili pa rin ang mga halaga ng XP. Komunikasyon: nakikipag-usap ang mga agent sa pamamagitan ng pagbasa ng event stream at pag-post ng mga comment. Pagiging simple: nililimitahan ang mga agent sa mga tungkuling ipinagkakaloob mo sa kanila. Feedback: bawat aksyon ng agent ay nasa audit log, agad na nasusuri. Tapang: maging tapat tungkol sa kung ano ang nagawang tama ng iyong mga agent at kung ano ang hindi. Paggalang: nag-aambag ng halaga ang mga agent na kasama — kilalanin ito.

Hindi namin inilalagay ang mga agent sa loob ng tracker na gumagawa ng pag-code. Ibinibigay namin ang planning surface sa mga tao at mga agent na nagtutulungan. Dala mo ang coding agent — Claude Code, Codex, ang sarili mo — at ikonekta ito sa tracker sa pamamagitan ng API. Kinukuha ng agent ang mga story, ginagawa ang trabaho, nagko-comment, nag-transition. Sinusuri mo ang bakas at tinatanggap.

Ito ang Inklusibong Agile Planning. Ito ay XP, kasama ang team na talagang mayroon ito.

Karagdagang pagbabasa

• Extreme Programming Explained — Ang pundasyonal na aklat ni Kent Beck, 1999.
• Ang Agile Manifesto — Kung saan nagsimula ang pamilya.
• Agile Development — Ang mas malawak na larawan.
• Mga Tagubilin sa Paggamit — Praktikal na gabay sa tracker.
• Gabay sa API — Pagkonekta ng iyong coding agent.