eXtreme Programming

eXtreme Programming — பொதுவாக வெறுமனே XP — அஜைல் குடும்பத்தின் மிகவும் கோரும் உறுப்பினர். East Agile Tracker முதலில் XP-க்காகக் கட்டமைக்கப்பட்டது; மற்ற அனைத்தும் அதிலிருந்து வெளிப்படுகின்றன.

இந்தப் பக்கம் XP என்ன, ஏன் வேலை செய்கிறது, மற்றும் tracker-ஐ உங்கள் திட்டமிடல் மேற்பரப்பாகக் கொண்டு அதை எவ்வாறு பயிற்சி செய்வது என்பதை உள்ளடக்குகிறது.

XP என்ன

XP 1990-களின் பிற்பகுதியில் Kent Beck ஆல் உருவாக்கப்பட்டது. முதல் புத்தகம் — Extreme Programming Explained: Embrace Change — 1999-இல் வெளியிடப்பட்டது. பல விஷயங்களைப் போலவே, இது Chrysler-இல் ஒரு payroll அமைப்பை வழங்க முயற்சிக்கும் ஒரு விரக்தியடைந்த அணியுடன் தொடங்கியது.

XP-இன் பந்தயம் என்னவென்றால், மென்பொருளில் நிச்சயமற்ற தன்மையைக் கையாள்வதற்கான சரியான வழி வேலை செய்யும் விஷயங்களைச் செய்வது, மேலும் அடிக்கடி செய்வது. Test? எல்லா நேரத்திலும் test செய்யுங்கள். Integrate? ஒவ்வொரு மணிநேரமும் integrate செய்யுங்கள். பேசுங்கள்? தொடர்ந்து பேசுங்கள். Plan? ஒவ்வொரு மறுசுழற்சியையும் plan செய்யுங்கள், மற்றும் கற்றுக்கொள்ளும்போது மறு-plan செய்யுங்கள்.

“XP என்பது தெளிவற்ற அல்லது வேகமாக மாறிவரும் தேவைகளை எதிர்கொண்டு மென்பொருளை மேம்படுத்தும் சிறிய-முதல்-நடுத்தர அளவிலான அணிகளுக்கான ஒரு இலகுரக முறையியல்.” — Kent Beck

ஐந்து மதிப்புகள்

XP மற்ற அனைத்தும் தொங்கும் ஐந்து மதிப்புகளைப் பெயரிடுகிறது:

1. Communication — அணி பேசுகிறது. தினமும். வேலை, வடிவமைப்பு, தடைகள் பற்றி. முடிந்தபோது நேருக்கு நேர். Silos எதிரி.
2. Simplicity — வேலை செய்யக்கூடிய எளிமையான விஷயத்தைச் செய்யுங்கள். உண்மையில் தேவைப்பட்டால் பின்னர் சிக்கலைச் சேர்க்கலாம். நீங்கள் அநேகமாக சேர்க்க மாட்டீர்கள்.
3. Feedback — குறியீட்டிலிருந்து (tests), அணியிலிருந்து (pair programming, reviews), பயனரிடமிருந்து (அடிக்கடி releases). அதை வேகமாகப் பெறுங்கள்.
4. Courage — முன்னேற்றம், மதிப்பீடுகள், மற்றும் வடிவமைப்பு பற்றி உண்மையைச் சொல்லுங்கள். வேலை செய்யாத குறியீட்டை வீசுங்கள். உங்களைத் தடுப்பதை refactor செய்யுங்கள்.
5. Respect — அணியில் உள்ள ஒவ்வொருவரும் — மற்றும் இப்போது, அணியில் உள்ள ஒவ்வொரு ஏஜெண்டும் — மதிப்பு பங்களிக்கிறார்கள். அதற்கேற்ப ஒருவரையொருவர் நடத்துங்கள்.

நடைமுறைகள்

XP அதன் பன்னிரண்டு அசல் நடைமுறைகளுக்கு பிரபலமானது, நான்கு பகுதிகளில் ஒழுங்கமைக்கப்பட்டுள்ளது:

திட்டமிடல்

• Planning Game — அணியும் வாடிக்கையாளரும் ஒன்றாகத் திட்டமிடுகிறார்கள்: அடுத்து என்ன வருகிறது, எந்த வரிசையில், ஒவ்வொரு பகுதியும் எவ்வளவு பெரியது.
• Small Releases — அடிக்கடி வழங்குங்கள். மாதங்கள் அல்ல, நாட்கள். ஏதாவது உறுதியான ஒன்றில் feedback பெறுங்கள்.
• User Stories — தேவைகள் உரையாடல்கள், பயனரின் பார்வையில் இருந்து சிறிய ஸ்டோரிகளாகப் பிடிக்கப்படுகின்றன. “ஒரு பயனராக, நான் X-ஐ விரும்புகிறேன், அதனால் Y.”

வடிவமைத்தல்

• Simple Design — tests-இல் தேர்ச்சி பெறும் மற்றும் ஒவ்வொரு தேவையான கருத்தையும் வெளிப்படுத்தும் எளிமையான வடிவமைப்பு. மேலும் இல்லை.
• Refactoring — ஏற்கனவே வேலை செய்யும் குறியீட்டின் வடிவமைப்பை மேம்படுத்துங்கள். தொடர்ந்து.
• System Metaphor — வடிவமைப்பு முடிவுகளை சீரானதாக ஆக்க பயன்படுத்தப்படும், அமைப்பு எவ்வாறு வேலை செய்கிறது என்பது பற்றிய பகிரப்பட்ட கதை.

குறியீட்டாக்கம்

• Pair Programming — இரண்டு டெவலப்பர்கள், ஒரு விசைப்பலகை. ஒருவர் ஓட்டுகிறார், ஒருவர் வழிநடத்துகிறார். அடிக்கடி மாறுங்கள்.
• Collective Code Ownership — யாரும் எந்த குறியீட்டையும் மேம்படுத்தலாம். சிற்றரசுகள் இல்லை.
• Continuous Integration — ஒரு நாளில் பல முறை குறியீட்டை integrate செய்து test செய்யுங்கள். உடைவுகளை உடனடியாகப் பிடியுங்கள்.
• Coding Standards — ஒரே நபர் எழுதியதைப் போல குறியீடு படிக்கும்படி, ஒப்புக்கொள்ளப்பட்ட பாணி.

சோதனை

• Test-Driven Development (TDD) — தோல்வியடையும் test-ஐ முதலில் எழுதுங்கள், பின்னர் அதை வெற்றியடையச் செய்யும் குறியீடு.
• Acceptance Tests — ஒவ்வொரு ஸ்டோரிக்கும் “done” என்றால் என்ன என்பதை வாடிக்கையாளர் குறியீடு அல்லது செயல்படுத்தக்கூடிய வடிவத்தில் வரையறுக்கிறார்.

XP ஏன் வேலை செய்கிறது

XP சங்கடமானது. Pair programming உங்களை சத்தமாக யோசிக்க கட்டாயப்படுத்துகிறது. TDD நீங்கள் குறியீட்டை எழுதுவதற்கு முன் வெற்றி எப்படி இருக்கும் என்பதை அறிய கட்டாயப்படுத்துகிறது. Continuous integration உங்களுக்குப் பிடித்த நீண்ட-கால branches-ஐ கொல்கிறது. Small releases என்றால் ஆறு மாத roadmap-க்குப் பின்னால் நீங்கள் மறைய முடியாது.

இவை அனைத்தும் feedback loops-ஐ குறைக்கின்றன என்பதால் இது வேலை செய்கிறது. நீங்கள் தவறு செய்தீர்கள் என்பதை எவ்வளவு வேகமாக கண்டுபிடிக்கிறீர்களோ, திருத்தம் அவ்வளவு மலிவானது. XP, அடிப்படையில், feedback loop-ஐ முடிந்தவரை இறுக்கமாக ஆக்குவது பற்றியது.

இது courage மற்றும் respect பற்றியதும் கூட. சத்தமாகத் தவறு செய்யும் அளவு ஒருவரையொருவர் நம்பும் ஒரு அணியில் மட்டுமே நீங்கள் XP செய்ய முடியும்.

ஒழுங்குபடுத்தப்பட்ட ஸ்டோரி மாதிரி

East Agile Tracker திட்டமிடலின் ஒரு குறிப்பிட்ட கோட்பாட்டைக் குறியீடாக்குகிறது. தரவு மாதிரி ஏன் இப்படி இருக்கிறது என்பதற்கான இயக்க கையேடாக இந்தப் பகுதியைக் கருதுங்கள் — மற்றும் நடைமுறையில் என்ன செய்வது (மற்றும் செய்யாதது) என்பதற்கான கள வழிகாட்டியாக.

நான்கு ஸ்டோரி வகைகள் ஏன் முக்கியம்

எல்லாம் ஒரு ஸ்டோரி, ஆனால் நான்கு வகைகள் உள்ளன, மேலும் அந்த வேறுபாடே முழுக் கருத்து:

• Features புள்ளிகளைச் சுமக்கின்றன, மற்றும் வேகத்திற்கு “கணக்கிடப்படும்” ஒரே விஷயம். வேலையை பயனர்-காணக்கூடிய மதிப்பாக நறுக்க இது உங்களைக் கட்டாயப்படுத்துகிறது.
• Bugs புள்ளியிடப்படாதவை (பூஜ்ஜியம்). குறைபாடுகள் கடன் சம்பாதிப்பதில்லை, இது மறுவேலையின் செலவை வெகுமதியாகக் காட்டாமல் தெரியும்படி வைக்கிறது.
• Chores உம் புள்ளியிடப்படாதவை — நேரடி பயனர் மதிப்பு இல்லாத அவசிய வேலை (infra, refactors, setup). அவற்றைப் பூஜ்ஜியத்தில் வைத்திருப்பது, மதிப்பு வடிவமைப்பு நேர்மையாக இருக்க முடிந்தவரை அவற்றை features-ஆக தொகுக்க அணியை அழுத்துகிறது.
• Releases மைல்கற்களை நங்கூரமிடவும், கருவி ஒரு தேதியைக் கணிக்கவும் பயன்படுத்தப்படும் பூஜ்ஜிய-புள்ளி குறிப்பான்கள்.

நடத்தைசார் விளைவே முக்கியம்: bugs மற்றும் chores மதிப்பெண் பெறாதபோது, ஒரு அணி இயற்கையாகவே வேலையை பயனர்-நோக்கு செயல்பாடாக வெளிப்படுத்தத் தள்ளுகிறது, மேலும் அது குறைபாட்டுச் செலவை கூர்மையாக உணரத் தொடங்குகிறது. அது தரவு மாதிரியில் குறியீடாக்கப்பட்ட ஒரு திட்டமிடல் ஒழுக்கம்.

ஒற்றை வரிசைப்படுத்தப்பட்ட backlog

மூன்று மண்டலங்கள், ஒரு விதி.

• Icebox முன்னுரிமை இல்லாத யோசனைக் குளம்.
• Backlog கறாராக வரிசைப்படுத்தப்பட்ட, ஒற்றை-முன்னுரிமை பட்டியல் — சம இணைப்புகள் இல்லை, “P1/P1/P1” இல்லை.
• Current மண்டலம் செயலில் உள்ள மறுசுழற்சி(களை) வைத்திருக்கிறது.

product owner மேலிருந்து கீழ் வரிசையை வைத்திருக்கிறார், மேலும் மாறிலி என்னவென்றால் backlog-இன் உச்சி எப்போதும் மிக முக்கியமானதாகவும் சிறந்தபடி குறிப்பிடப்பட்டதாகவும் இருக்கும், கீழே செல்லச்செல்ல தெளிவு நியாயமாகக் குறையும். தெளிவற்ற ஏற்றுக்கொள்ளும் அளவுகோல்களுடன் உச்சிக்கு அருகில் உள்ள ஒரு ஸ்டோரி ஒரு திட்டமிடல் bug. Icebox ஒரு கல்லறையாக இருக்க அனுமதிக்கப்படுகிறது; Backlog அல்ல.

வேக-இயக்கப்பட்ட தானியங்கி திட்டமிடல்

பெரும்பாலான அணிகள் வேறு இடங்களில் மோசமாக மறுசெயலாக்கும் பகுதி இதுவே. Tracker-பாணி திட்டமிடல் சமீபத்தில் ஏற்றுக்கொள்ளப்பட்ட புள்ளிகளிலிருந்து ஒரு உருளும் சராசரி வேகத்தைக் கணக்கிட்டு, அந்த அளவு புள்ளி ஸ்டோரிகளை அடுத்த மறுசுழற்சியில் தானாக இழுக்கிறது — நீங்கள் ஒரு sprint-க்கு கைமுறையாக “commit” செய்வதில்லை, அனுபவ தரவு அதை உங்களுக்காகச் செய்கிறது. பாதுகாக்கத் தகுந்த இரண்டு விளைவுகள்:

• நீங்கள் features-ஐ மட்டுமே மதிப்பிடுகிறீர்கள், தொடர்புடைய புள்ளிகளைப் பயன்படுத்தி (Fibonacci 1/2/3/5/8 அல்லது எங்கள் இறுக்கமான 0/1/2/3), மணிநேரங்கள் அல்ல. மதிப்பிடுதல் என்பது ஒரு அளவு உரையாடல், ஒரு வாக்குறுதி அல்ல.
• நீங்கள் வேகத்தை விளையாடுவதில்லை. “வேகமாகத் தோன்ற” புள்ளிகளை ஊதிப்பெருக்குவது, அல்லது chores-க்கு புள்ளியிடுவது, முழு அமைப்பையும் நேர்மையாக்கும் கணிப்பை உடைக்கிறது. வேகம் என்பது ஒரு அளவீட்டுக் கருவி, மேலும் உங்கள் சொந்தக் கருவியை நீங்கள் சேதப்படுத்துவதில்லை.

பயன் என்னவென்றால், release தேதி கணிப்பு ஒரு பேச்சுவார்த்தைக்குப் பதிலாக ஒரு கணக்கீடாக மாறுகிறது, மேலும் பங்குதாரர்களுடனான உரையாடல் “வெள்ளிக்கிழமைக்குள் X-ஐ உறுதியளிக்க முடியுமா” என்பதிலிருந்து “தற்போதைய வேகத்தில், இந்த release Y தேதியைச் சுற்றி இறங்கும் — இங்கே நோக்கம்/தேதி பரிமாற்றம்” என்பதற்கு மாறுகிறது.

ஸ்டோரி வாழ்க்கைச் சுழற்சியும் ஏற்றுக்கொள்ளும் சுழற்சியும்

நிலை இயந்திரம் Start → Finish → Deliver → Accept / Reject. முக்கியமான நிலை Deliver: ஒரு பொறியாளர் ஒரு ஸ்டோரியை delivered என குறிக்கிறார், ஆனால் product owner அதன் ஏற்றுக்கொள்ளும் அளவுகோல்களுக்கு எதிராக வெளிப்படையாக அதை ஏற்றுக்கொள்ளும் வரை — அல்லது அதை நிராகரித்துத் திருப்பி அனுப்பும் வரை — அது முடிந்ததல்ல. இது ஒவ்வொரு ஸ்டோரியிலும் ஒரு வாடிக்கையாளர்-கருத்துப் பின்னூட்ட சுழற்சியை ஏற்றுக்கொள்ளலை sprint-முடிவு டெமோவுக்கு ஒத்திவைப்பதற்குப் பதிலாக இணைக்கிறது.

ஏற்றுக்கொள்ளும் அளவுகோல்கள் ஸ்டோரி தொடங்கும் முன்பே அதில் இருக்க வேண்டும், சிறந்தபடி Given/When/Then வடிவில், இதனால் அவை ஏற்றுக்கொள்ளும் சோதனைகளுக்கு நேரடியாக வரைபடமாகும். ஒரு ஸ்டோரி நன்கு உருவாக்கப்பட்டதா என்பதற்கான விவேகச் சோதனை INVEST:

• Independent — மற்ற ஸ்டோரிகள் இல்லாமல் வெளியிட முடியும்.
• Negotiable — நோக்கத்தைப் பிடிக்கிறது, உறைந்த spec அல்ல.
• Valuable — ஒரு பயனருக்கு அல்லது பங்குதாரருக்கு.
• Estimable — அணி அதை அளவிட முடியும்.
• Small — ஒரு மறுசுழற்சியில் வசதியாகப் பொருந்துகிறது.
• Testable — செயல்படுத்தக்கூடிய ஏற்றுக்கொள்ளும் அளவுகோல்கள் உள்ளன.

தாளம்

திட்டமிடல் சடங்குகள் இலகுவாகவும் வழக்கமாகவும் இருக்கின்றன:

• backlog-இன் உச்சியில் புதிய ஸ்டோரிகளுக்கு புள்ளியிடவும் ஏற்றுக்கொள்ளும் அளவுகோல்களை நிர்ணயிக்கவும் ஒரு வாராந்திர Iteration Planning Meeting.
• பாய்வு மற்றும் blockers-இல் கவனம் செலுத்தும் ஒரு குறுகிய daily standup.
• செயல்முறையைச் சரிசெய்ய ஒவ்வொரு மறுசுழற்சிக்கும் ஒரு retrospective.

மறுசுழற்சிகள் பொதுவாக ஒன்று அல்லது இரண்டு வாரங்கள் — ஒரு மோசமான மதிப்பீடு கண்டுபிடிக்க மலிவாக இருக்கும் அளவு குறுகியது.

திட்டமிடலை வேலை செய்ய வைக்கும் பொறியியல் நடைமுறைகள்

Tracker-பாணி திட்டமிடல் XP-இன் காணக்கூடிய பாதி; பொறியியல் பாதி இல்லாமல் அது சரிந்துவிடும்.

• Test-first / TDD மற்றும் ஒரு உண்மையான acceptance-test தொகுப்பே “delivered” என்பதற்கு அர்த்தம் கொள்ள வைக்கின்றன.
• Continuous integration மற்றும் சிறிய, அடிக்கடி releases சுழற்சி நேரத்தைக் குறுகியதாக வைத்திருக்கின்றன, இதனால் வேகம் கட்டையாக இருப்பதற்குப் பதிலாக நிலையாக இருக்கிறது.
• Pair programming (அல்லது வலுவான review) நடப்பில் உள்ள வேலையைக் குறைவாக வைத்திருக்கிறது — தொடங்கும் முன் முடியுங்கள் — இது சுழற்சி நேரத்தில் ஒற்றை மிகப்பெரிய காரணி.
• ஒரு கிடைக்கக்கூடிய product owner என்பது accept/reject சுழற்சி தேங்குவதைத் தடுக்கிறது.

கவனிக்க வேண்டிய எதிர்-வடிவங்கள்

மீண்டும் மீண்டும் வரும் தோல்விகள்:

• Backlog-ஐ ஒரு பார்க்கிங் lot-ஆக உண்மையான முன்னுரிமை வரிசைக்குப் பதிலாக நடத்துவது.
• வேகத்தை சிறப்பாகக் காட்ட bugs மற்றும் chores-ஐ மதிப்பிடுவது.
• ஒரு மறுசுழற்சியில் முடிக்க முடியாத பெரிய ஸ்டோரிகளைச் சுமப்பது. ஒவ்வொன்றும் சுயாதீனமாக வழங்கக்கூடியதாகும் வரை பிரிக்கவும்.
• யாரும் ஏற்றுக்கொள்ளாததால் Delivered-இல் ஸ்டோரிகள் குவிய அனுமதிப்பது.

இவற்றில் எதுவும் ஒரு அனுபவ அமைப்பை அமைதியாக மீண்டும் விருப்பத் திட்டமிடலாக மாற்றுகிறது. அவற்றைச் செய்வதிலிருந்து tracker உங்களைத் தடுக்க முடியாது; அதை காணக்கூடியதாக மட்டுமே ஆக்க முடியும். ஒவ்வொரு மறுசுழற்சியின் முடிவிலும் உங்கள் Delivered நெடுவரிசையைப் பாருங்கள் — அது வளர்ந்துகொண்டிருந்தால், அது உங்கள் சமிக்ஞை.

East Agile Tracker உடன் XP

XP அணிகள் Pivotal Tracker நாட்களிலிருந்து விரும்பிக்கொண்டிருந்த திட்டமிடல் மேற்பரப்பு tracker. ஒவ்வொரு கருத்தும் நேரடியாக வரைபடமாகிறது:

User Stories → Stories

XP user stories என்பது East Agile Tracker ஸ்டோரிகள். அவற்றை Feature வகையில் எழுதுங்கள். உரையாடலுக்கு விளக்கத்தைப் பயன்படுத்துங்கள்; தொடர்ந்த விவாதத்திற்கு கருத்துகளைப் பயன்படுத்துங்கள். ஏற்றுக்கொள்ளும் அளவுகோல்கள் விளக்கத்தில் சேர்கின்றன.

Planning Game → போர்டு

XP-இல் Planning Game என்பது முன்னுரிமை மற்றும் அளவு பற்றி வணிகத்திற்கும் அணிக்கும் இடையேயான ஒரு உரையாடல். East Agile Tracker-இல்:

1. வணிக நபர் Backlog-இல் ஸ்டோரிகளை எழுதி அவற்றை முன்னுரிமைப்படி வரிசைப்படுத்துகிறார்.
2. அணி features-ஐ புள்ளிகளில் மதிப்பிடுகிறது (Fibonacci அல்லது East Agile அளவீடு).
3. வேகத்திலிருந்து அமைப்பு மறுசுழற்சிகளைத் தானாகத் திட்டமிடுகிறது.
4. அணி Current நெடுவரிசையின் உச்சியிலிருந்து ஸ்டோரிகளைத் தொடங்குகிறது.

அவ்வளவுதான். “game” உரையாடலில் வாழ்கிறது; tracker வெறுமனே மதிப்பெண்ணை வைத்திருக்கிறது.

Small Releases → Releases (ஸ்டோரி வகை)

அடிக்கடி release செய்யுங்கள் என்று XP சொல்கிறது. Release என்பது East Agile Tracker-இல் உள்ள நான்கு ஸ்டோரி வகைகளில் ஒன்று. ஒவ்வொரு வழங்கும் மைல்கல்லுக்கும் ஒரு release-ஐ உருவாக்குங்கள்; அது வழங்கப்படும் மறுசுழற்சிக்கு அதை இழுக்கவும். Releases Started/Finished/Delivered-ஐத் தவிர்த்து, நீங்கள் வழங்கும்போது நேராக Accepted-க்குச் செல்கின்றன.

Continuous Integration → ஸ்டோரி நிலை இயந்திரம்

நிலை இயந்திரம் CI அல்ல — அது உங்கள் build அமைப்பு — ஆனால் Finished → Delivered → Accepted பாதை XP விவரிக்கும் வாடிக்கையாளர்-ஏற்றுக்கொள்ளும் சுழற்சியைப் பிரதிபலிக்கிறது. வேலையை முடியுங்கள், அதை வாடிக்கையாளருக்கு வழங்குங்கள், அது செயல்படுவதை உறுதிப்படுத்தும்போது ஏற்றுக்கொள்ளுங்கள்.

Velocity → “Yesterday’s weather”

XP அதை yesterday’s weather என்று அழைக்கிறது: கடைசி மறுசுழற்சியில் நீங்கள் எவ்வளவு முடித்தீர்களோ அதுவே இந்த ஒன்றில் நீங்கள் எவ்வளவு முடிப்பீர்கள் என்பதற்கான சிறந்த கணிப்பு. East Agile Tracker வேகத்தைத் தானாகக் கணக்கிடுகிறது — சமீபத்திய மறுசுழற்சிகளின் சராசரி, கட்டமைக்கக்கூடிய உத்தி — மேலும் அடுத்த மறுசுழற்சியின் கொள்ளளவைத் தானாகத் திட்டமிட அதைப் பயன்படுத்துகிறது.

Acceptance Tests → Reviews

tracker-இல் உள்ள ஸ்டோரி reviews ஏற்றுக்கொள்ளலுக்கு வரைபடமாகின்றன. ஒரு reviewer-ஐ (வாடிக்கையாளர், product owner, அல்லது ஒன்றாக செயல்படும் ஒரு ஏஜெண்ட்) ஒதுக்கவும். அவர்கள் approve செய்கிறார்கள் அல்லது reject செய்கிறார்கள். Rejected ஸ்டோரியை Started-க்குத் திருப்பி அனுப்புகிறது.

Pair Programming → Co-ownership

XP அணிகள் குறியீட்டில் ஜோடி சேர்கின்றன. tracker-இல், இது ஒரு ஸ்டோரியில் பல உரிமையாளர்கள் என தோன்றுகிறது. ஸ்டோரிக்கு இரண்டு ஜோடிகளையும் ஒதுக்கவும்; இரண்டு பெயர்களும் கார்டில் தோன்றும்.

ஏஜெண்ட்களுடன் XP — புதிய நடைமுறை

AI ஏஜெண்ட்கள் மென்பொருளுக்கு அர்த்தமுள்ள பங்களிப்பு செய்வதற்கு முன்பே XP எழுதப்பட்டது. இது இருபத்தைந்து ஆண்டுகளில் XP-க்கான மிக முக்கியமான புதுப்பிப்பு என்று நாங்கள் நினைக்கிறோம்.

எங்கள் நடைமுறையில் — மற்றும் tracker எதற்காகக் கட்டமைக்கப்பட்டுள்ளதோ — ஒரு ஏஜெண்ட் என்பது பெயரிடப்பட்ட ஒரு XP அணி உறுப்பினர். அதற்கு அதன் சொந்த பாத்திரம், அதன் சொந்த ஜோடி பங்காளி (மனிதர் அல்லது ஏஜெண்ட்), மற்றும் அதன் சொந்த தணிக்கைச் சுவடு உள்ளது. ஒரு மனித அணி உறுப்பினர் திட்டமிடல் மேற்பரப்பில் செய்யக்கூடிய எதையும் அது செய்ய முடியும்: மதிப்பிட, ஸ்டோரிகளுக்கு உரிமை கொள்ள, கருத்துத் தெரிவிக்க, மாற்ற, reviews ஏற்றுக்கொள்ள.

XP மதிப்புகள் இன்னும் நிலைத்திருக்கின்றன. Communication: ஏஜெண்ட்கள் நிகழ்வு ஓடையைப் படித்தும் கருத்துகளை இடுகையிட்டும் தொடர்பு கொள்கின்றன. Simplicity: ஏஜெண்ட்கள் நீங்கள் வழங்கும் பாத்திரங்களுக்கு வரம்பிடப்படுகின்றன. Feedback: ஒவ்வொரு ஏஜெண்ட் செயலும் தணிக்கைப் பதிவில் உள்ளது, உடனடியாக மதிப்பாய்வு செய்யக்கூடியது. Courage: உங்கள் ஏஜெண்ட்கள் எதைச் சரியாகச் செய்தன, எதைச் செய்யவில்லை என்பது பற்றி நேர்மையாக இருங்கள். Respect: ஏஜெண்ட் அணி உறுப்பினர்கள் மதிப்பு பங்களிக்கிறார்கள் — அதை அங்கீகரியுங்கள்.

நாங்கள் ஏஜெண்ட்களை tracker-க்குள் வைத்து குறியீட்டாக்கம் செய்வதில்லை. திட்டமிடல் மேற்பரப்பை மனிதர்களுக்கும் மற்றும் ஏஜெண்ட்களுக்கும் ஒன்றாக வேலை செய்ய நாங்கள் கொடுக்கிறோம். நீங்கள் கோடிங் ஏஜெண்டைக் கொண்டுவாருங்கள் — Claude Code, Codex, உங்களுடையது — மேலும் அதை API வழியாக tracker-உடன் இணைக்கவும். ஏஜெண்ட் ஸ்டோரிகளை எடுக்கிறது, வேலையைச் செய்கிறது, கருத்துத் தெரிவிக்கிறது, மாற்றுகிறது. நீங்கள் சுவட்டை மதிப்பாய்வு செய்து ஏற்றுக்கொள்கிறீர்கள்.

இதுவே Inclusive Agile Planning. இது XP, அது உண்மையில் கொண்டிருக்கும் அணியுடன்.

மேலும் வாசிப்பு

• Extreme Programming Explained — Kent Beck-இன் அடித்தளப் புத்தகம், 1999.
• அஜைல் அறிக்கை — குடும்பம் தொடங்கிய இடம்.
• அஜைல் மேம்பாடு — பரந்த படம்.
• இயக்க வழிமுறைகள் — tracker-க்கான நடைமுறை வழிகாட்டி.
• API வழிகாட்டி — உங்கள் கோடிங் ஏஜெண்டை இணைத்தல்.