eXtreme Programming — සාමාන්යයෙන් සරලව XP — යනු ඇජයිල් පවුලේ වඩාත්ම ඉල්ලුම් සහිත සාමාජිකයාය. East Agile Tracker මුලින්ම XP සඳහා ගොඩනඟා ඇත; අනෙක් සියල්ල එයින් මතු වේ.
මෙම පිටුව XP යනු කුමක්ද, එය ක්රියා කරන්නේ ඇයි, සහ tracker එක ඔබේ සැලසුම් මතුපිට ලෙස සිට එය ප්රගුණ කරන්නේ කෙසේද යන්න ආවරණය කරයි.
XP යනු කුමක්ද
Section titled “XP යනු කුමක්ද”XP 1990 දශකයේ අගභාගයේ Kent Beck විසින් නිර්මාණය කරන ලදී. පළමු පොත — Extreme Programming Explained: Embrace Change — 1999 දී ප්රකාශයට පත් විය. බොහෝ දේ මෙන්, එය Chrysler හි payroll පද්ධතියක් නැව්ගත කිරීමට උත්සාහ කරන කලකිරුණු කණ්ඩායමකින් ආරම්භ විය.
XP හි ඔට්ටුව නම්, මෘදුකාංගවල අවිනිශ්චිතතාව හැසිරවීමට නිවැරදි ක්රමය ක්රියා කරන දේ කිරීම, සහ ඒවා නිතර කිරීම බවයි. Test? සැම විටම test. Integrate? පැයකට වරක් integrate. Talk? නිරන්තරයෙන් කතා කරන්න. Plan? සෑම ඉටරේෂන් එකක්ම සැලසුම් කරන්න, සහ ඔබ ඉගෙන ගන්නා විට නැවත සැලසුම් කරන්න.
“XP යනු අපැහැදිලි හෝ වේගයෙන් වෙනස්වන අවශ්යතා මුහුණ දෙමින් මෘදුකාංග සංවර්ධනය කරන කුඩා-සිට-මධ්යම ප්රමාණයේ කණ්ඩායම් සඳහා සැහැල්ලු ක්රමවේදයකි.” — Kent Beck
වටිනාකම් පහ
Section titled “වටිනාකම් පහ”XP අනෙක් සියල්ල එල්ලෙන වටිනාකම් පහක් නම් කරයි:
- සන්නිවේදනය — කණ්ඩායම කතා කරයි. දිනපතා. වැඩ ගැන, සැලසුම ගැන, බාධක ගැන. හැකි විට මුහුණට මුහුණ. Silos යනු සතුරාය.
- සරලකම — ක්රියා කළ හැකි සරලම දේ කරන්න. ඔබට සැබවින්ම අවශ්ය නම් පසුව සංකීර්ණතාව එක් කළ හැකිය. ඔබට බොහෝ විට අවශ්ය නොවනු ඇත.
- ප්රතිපෝෂණය — කේතයෙන් (tests), කණ්ඩායමෙන් (pair programming, reviews), පරිශීලකයාගෙන් (නිතර releases). එය වේගයෙන් ලබා ගන්න.
- නිර්භීතකම — ප්රගතිය, තක්සේරු, සහ සැලසුම් ගැන සත්යය කියන්න. ක්රියා නොකරන කේතය ඉවත දමන්න. ඔබව රඳවා ඇති දේ refactor කරන්න.
- ගෞරවය — කණ්ඩායමේ සෑම කෙනෙක්ම — සහ දැන්, කණ්ඩායමේ සෑම ඒජන්තයෙක්ම — වටිනාකම දායක කරයි. ඒ අනුව එකිනෙකා සලකන්න.
භාවිතයන්
Section titled “භාවිතයන්”XP එහි මුල් භාවිතයන් දොළහ සඳහා ප්රසිද්ධය, ක්ෂේත්ර හතරකට සංවිධානය කර ඇත:
සැලසුම් කිරීම
Section titled “සැලසුම් කිරීම”- Planning Game — කණ්ඩායම සහ පාරිභෝගිකයා එක්ව සැලසුම් කරයි: ඊළඟට එන්නේ කුමක්ද, කුමන අනුපිළිවෙලකින්ද, එක් එක් කොටස කොතරම් විශාලද.
- Small Releases — නිතර නැව්ගත කරන්න. දින, මාස නොව. තහවුරු දෙයක් මත ප්රතිපෝෂණ ලබා ගන්න.
- User Stories — අවශ්යතා යනු සංවාද, පරිශීලකයාගේ දෘෂ්ටිකෝණයෙන් කෙටි ස්ටෝරි ලෙස ග්රහණය කරගෙන ඇත. “පරිශීලකයෙකු ලෙස, මට X අවශ්යයි, එවිට Y.”
නිර්මාණය
Section titled “නිර්මාණය”- Simple Design — tests සමත් වන සහ අවශ්ය සෑම සංකල්පයක්ම ප්රකාශ කරන සරලම සැලසුම. ඊට වඩා නැත.
- Refactoring — දැනටමත් ක්රියා කරන කේතයේ සැලසුම වැඩිදියුණු කරන්න. නිරන්තරයෙන්.
- System Metaphor — සැලසුම් තීරණ අනුකූල කිරීමට භාවිතා කරන, පද්ධතිය ක්රියා කරන ආකාරය පිළිබඳ බෙදාගත් කතාවක්.
කේතකරණය
Section titled “කේතකරණය”- Pair Programming — සංවර්ධකයන් දෙදෙනෙක්, එක් යතුරුපුවරුවක්. එක්කෙනෙක් ධාවනය කරයි, එක්කෙනෙක් සංචලනය කරයි. නිතර මාරු කරන්න.
- Collective Code Ownership — ඕනෑම කෙනෙකුට ඕනෑම කේතයක් වැඩිදියුණු කළ හැකිය. ආධිපත්ය නැත.
- Continuous Integration — දිනකට කිහිප වතාවක් කේතය integrate කර test කරන්න. බිඳීම් වහාම අල්ලා ගන්න.
- Coding Standards — එක් පුද්ගලයෙකු ලියූවාක් මෙන් කේතය කියවෙන ලෙස එකඟ වූ විලාසය.
පරීක්ෂා කිරීම
Section titled “පරීක්ෂා කිරීම”- Test-Driven Development (TDD) — මුලින් අසාර්ථක වන test එක ලියන්න, ඉන්පසු එය සමත් කරවන කේතය.
- Acceptance Tests — එක් එක් ස්ටෝරිය සඳහා “done” යන්නෙහි අර්ථය පාරිභෝගිකයා කේතයෙන් හෝ ක්රියාත්මක කළ හැකි ආකාරයෙන් නිර්වචනය කරයි.
XP ක්රියා කරන්නේ ඇයි
Section titled “XP ක්රියා කරන්නේ ඇයි”XP අපහසුය. Pair programming ඔබට හඬ නඟා සිතීමට බල කරයි. TDD ඔබට කේතය ලිවීමට පෙර සාර්ථකත්වය පෙනෙන්නේ කෙසේද යන්න දැන ගැනීමට බල කරයි. Continuous integration ඔබේ ප්රියතම දිගුකාලීන branches මරා දමයි. Small releases යනු ඔබට මාස හයක roadmap එකක් පිටුපස සැඟවිය නොහැකි බවයි.
එය ක්රියා කරන්නේ මේ සියලු දේ ප්රතිපෝෂණ ලූප කෙටි කරන නිසාය. ඔබ වැරදි බව ඉක්මනින් සොයා ගන්නා තරමට, නිවැරදි කිරීම ලාභදායී වේ. XP, මූලික වශයෙන්, ප්රතිපෝෂණ ලූපය හැකි තරම් තද කිරීම ගැන ය.
එය නිර්භීතකම සහ ගෞරවය ගැනද වේ. එකිනෙකා හඬ නඟා වැරදි වීමට තරම් විශ්වාස කරන කණ්ඩායමක XP කළ හැක්කේ පමණි.
විනයගරුක ස්ටෝරි ආකෘතිය
Section titled “විනයගරුක ස්ටෝරි ආකෘතිය”East Agile Tracker සැලසුම් කිරීමේ නිශ්චිත න්යායක් කේතනය කරයි. දත්ත ආකෘතිය පෙනෙන ආකාරය ඇයි යන්න සඳහා මෙම කොටස ක්රියාකරණ අත්පොත ලෙස සලකන්න — සහ ප්රායෝගිකව කළ යුතු (සහ නොකළ යුතු) දේ සඳහා ක්ෂේත්ර මාර්ගෝපදේශය ලෙස.
ස්ටෝරි වර්ග හතර වැදගත් වන්නේ ඇයි
Section titled “ස්ටෝරි වර්ග හතර වැදගත් වන්නේ ඇයි”සියල්ල ස්ටෝරියකි, නමුත් වර්ග හතරක් ඇත, සහ වෙනස තමයි මුළු අරමුණ:
- Features පොයින්ට් දරයි සහ වෙලොසිටියට “ගණන් ගන්නා” එකම දෙයයි. පරිශීලකයාට නිරීක්ෂණය කළ හැකි වටිනාකමට වැඩ කපා බෙදීමට මෙය ඔබට බල කරයි.
- Bugs පොයින්ට් රහිතය (ශුන්ය). දෝෂ ක්රෙඩිට් උපයන්නේ නැත, එමඟින් නැවත වැඩ කිරීමේ පිරිවැය ත්යාගයක් ලෙස වෙනුවට දෘශ්යමාන කරයි.
- Chores ද පොයින්ට් රහිතය — සෘජු පරිශීලක වටිනාකමක් නැති අවශ්ය වැඩ (infra, refactors, setup). ඒවා ශුන්යයේ තබා ගැනීම, වටිනාකම් රාමුව අවංක ලෙස පවත්වා ගැනීම සඳහා හැකි සෑම තැනකම ඒවා features වලට බැඳීමට කණ්ඩායමට පීඩනය යොදයි.
- Releases යනු සන්ධිස්ථාන නැංගුරම් කිරීමට සහ මෙවලමට දිනයක් ප්රක්ෂේපණය කිරීමට ඉඩ දීමට භාවිතා කරන ශුන්ය-පොයින්ට් සලකුණු වේ.
වැදගත් වන්නේ චර්යාත්මක බලපෑමයි: bugs සහ chores ලකුණු නොකරන විට, කණ්ඩායමක් ස්වභාවිකවම වැඩ පරිශීලක-නැඹුරු ක්රියාකාරිත්වයක් ලෙස ප්රකාශ කිරීමට තල්ලු කරයි, සහ එය දෝෂ පිරිවැය පිළිබඳව තියුණු ලෙස දැනුවත් වේ. එය දත්ත ආකෘතියේ කේතනය කරන ලද සැලසුම් විනයකි.
තනි අනුපිළිවෙලට සකස් කළ backlog එක
Section titled “තනි අනුපිළිවෙලට සකස් කළ backlog එක”කලාප තුනක්, නීති එකක්.
- Icebox යනු ප්රමුඛතා නොකළ අදහස් එකතුවයි.
- Backlog යනු දැඩි ලෙස අනුපිළිවෙලට සකස් කළ, තනි-ප්රමුඛතා ලැයිස්තුවකි — සමානකම් නැත, “P1/P1/P1” නැත.
- Current කලාපය සක්රිය ඉටරේෂන්(ය) දරයි.
ඉහළ සිට පහළට අනුපිළිවෙල product owner සතු වන අතර, නියතය නම් backlog එකේ ඉහළ කොටස සැමවිටම වඩාත්ම වැදගත් සහ වඩාත් හොඳින් සඳහන් කරන ලද එක වන අතර, ඔබ පහළට යන විට පැහැදිලිකම නීත්යානුකූලව අඩු වීමයි. අපැහැදිලි පිළිගැනීමේ නිර්ණායක සහිත ඉහළට ආසන්න ස්ටෝරියක් සැලසුම් දෝෂයකි. Icebox එකට සොහොන්පොළක් වීමට අවසර ඇත; Backlog එකට නැත.
Velocity-පාදක ස්වයංක්රීය සැලසුම්කරණය
Section titled “Velocity-පාදක ස්වයංක්රීය සැලසුම්කරණය”මෙය බොහෝ කණ්ඩායම් වෙනත් තැන්වල නරක ලෙස නැවත ක්රියාත්මක කරන කොටසයි. Tracker-විලාසයේ සැලසුම්කරණය මෑතකදී පිළිගත් පොයින්ට් වලින් රෝලිං සාමාන්ය වෙලොසිටියක් ගණනය කර එම පොයින්ට් ගණන ස්ටෝරි ස්වයංක්රීයව ඊළඟ ඉටරේෂන් එකට ඇද ගනියි — ඔබ අතින් sprint එකකට “commit” නොකරයි, ආනුභවික දත්ත ඔබ වෙනුවෙන් එය කරයි. සංරක්ෂණය කිරීමට වටිනා ප්රතිඵල දෙකක්:
- ඔබ features පමණක් තක්සේරු කරයි, සාපේක්ෂ පොයින්ට් භාවිතා කරමින් (Fibonacci 1/2/3/5/8 හෝ අපගේ තද 0/1/2/3), පැය නොව. තක්සේරු කිරීම ප්රමාණ සංවාදයක් මිස පොරොන්දුවක් නොවේ.
- ඔබ වෙලොසිටි game නොකරයි. “වේගවත් ලෙස පෙනීමට” පොයින්ට් පුම්බීම, හෝ chores පොයින්ට් කිරීම, මුළු පද්ධතිය අවංක කරන ප්රක්ෂේපනය බිඳ දමයි. වෙලොසිටි යනු මැනුම් උපකරණයකි, සහ ඔබ ඔබේම උපකරණයට හානි නොකරයි.
ප්රතිලාභය නම්, නියෝජන දින ප්රක්ෂේපනය සාකච්ඡාවක් වෙනුවට ගණනය කිරීමක් බවට පත් වන අතර, පාර්ශවකරුවන් සමඟ සංවාදය “ඔබට සිකුරාදා වන විට X කිරීමට බැඳෙන්න පුළුවන්ද” යන්නෙන් “වර්තමාන වෙලොසිටි එකේදී, මෙම නියෝජනය Y දිනය පමණ ලඟා වේ — මෙන්න විෂය පථ/දින හුවමාරුව” දක්වා මාරු වීමයි.
ස්ටෝරි ජීවන චක්රය සහ පිළිගැනීමේ ලූපය
Section titled “ස්ටෝරි ජීවන චක්රය සහ පිළිගැනීමේ ලූපය”තත්ත්ව යන්ත්රය Start → Finish → Deliver → Accept / Reject වේ. තීරණාත්මක තත්ත්වය වන්නේ Deliver: ඉංජිනේරුවෙකු ස්ටෝරියක් delivered ලෙස සලකුණු කරයි, නමුත් product owner එය එහි පිළිගැනීමේ නිර්ණායක වලට එරෙහිව පැහැදිලිව accept කරන තෙක් — හෝ reject කර එය නැවත තල්ලු කරන තෙක් — එය done නොවේ. මෙය sprint අවසන් demo එකකට පිළිගැනීම කල් දැමීම වෙනුවට සෑම තනි ස්ටෝරියකටම පාරිභෝගික-ප්රතිපෝෂණ ලූපයක් පුළුස්සා ගනියි.
පිළිගැනීමේ නිර්ණායක ස්ටෝරිය ආරම්භ කිරීමට පෙර ස්ටෝරියට අයත් වේ, වඩාත් සුදුසු ලෙස Given/When/Then ආකාරයෙන් එවිට ඒවා කෙලින්ම පිළිගැනීමේ පරීක්ෂණ වලට සිතියම්ගත වේ. ස්ටෝරියක් හොඳින් සැකසී ඇත්දැයි පරීක්ෂා කිරීම INVEST වේ:
- Independent — වෙනත් ස්ටෝරි නොමැතිව නිකුත් කළ හැකිය.
- Negotiable — හිමි කරවන අරමුණ, ශීත කළ පිරිවිතරයක් නොවේ.
- Valuable — පරිශීලකයෙකුට හෝ පාර්ශවකරුවෙකුට.
- Estimable — කණ්ඩායමට එය ප්රමාණ කළ හැකිය.
- Small — ඉටරේෂන් එකකට පහසුවෙන් ගැළපේ.
- Testable — ක්රියාත්මක කළ හැකි පිළිගැනීමේ නිර්ණායක ඇත.
රිද්මය
Section titled “රිද්මය”සැලසුම් උත්සව සැහැල්ලු සහ නිතිපතා වේ:
- backlog එකේ ඉහළ නව ස්ටෝරි පොයින්ට් කිරීමට සහ පිළිගැනීමේ නිර්ණායක තහවුරු කිරීමට සතිපතා Iteration Planning Meeting එකක්.
- ගලායාම සහ blockers කෙරෙහි අවධානය යොමු කරන කෙටි daily standup එකක්.
- ක්රියාවලිය සකස් කිරීමට එක් එක් ඉටරේෂන් එකකට retrospective එකක්.
ඉටරේෂන් සාමාන්යයෙන් සතියක් හෝ දෙකක් — නරක තක්සේරුවක් සොයා ගැනීමට ලාභදායී වන තරම් කෙටිය.
සැලසුම් කිරීම ක්රියා කරවන ඉංජිනේරු භාවිතයන්
Section titled “සැලසුම් කිරීම ක්රියා කරවන ඉංජිනේරු භාවිතයන්”Tracker-විලාසයේ සැලසුම්කරණය යනු XP හි දෘශ්ය භාගයයි; එය ඉංජිනේරු භාගය නොමැතිව බිඳ වැටේ.
- Test-first / TDD සහ සැබෑ acceptance-test කට්ටලයක් “delivered” යන්නට යමක් අර්ථවත් කරවන දේ වේ.
- Continuous integration සහ කුඩා, නිතර releases, cycle time කෙටි කර තබයි, ඒ නිසා වෙලොසිටි ගැටිති වෙනුවට ස්ථාවර වේ.
- Pair programming (හෝ ශක්තිමත් review) වැඩ-ප්රගතියේ-පවතින දේ අඩුවෙන් තබයි — ආරම්භ කිරීමට පෙර අවසන් කරන්න — එය cycle time එක මත ඇති විශාලතම තනි කොන්දේසියයි.
- ලබා ගත හැකි product owner කෙනෙක් accept/reject ලූපය නැවතීමෙන් වළක්වයි.
බැලීමට ඇති ප්රති-රටා
Section titled “බැලීමට ඇති ප්රති-රටා”පුනරාවර්තන අසාර්ථකතා:
- Backlog එක සැබෑ ප්රමුඛතා අනුපිළිවෙලක් වෙනුවට වාහන නැවැත්වීමේ ස්ථානයක් ලෙස සැලකීම.
- වෙලොසිටි වඩා හොඳ ලෙස පෙන්වීමට bugs සහ chores තක්සේරු කිරීම.
- ඉටරේෂන් එකකදී අවසන් කළ නොහැකි විශාල ස්ටෝරි දැරීම. එක් එක් එක ස්වාධීනව බෙදාහැරිය හැකි වන තෙක් බෙදන්න.
- කිසිවෙකු accept නොකරන නිසා Delivered හි ස්ටෝරි ගොඩ ගැසීමට ඉඩ දීම.
මේවායින් ඕනෑම එකක් නිහඬව ආනුභවික පද්ධතියක් නැවත ආශාකාමී සැලසුම් කිරීමට පරිවර්තනය කරයි. tracker එකට ඔබව ඒවා කිරීමෙන් වැළැක්විය නොහැක; එයට ඒවා දෘශ්යමාන කළ හැක්කේ පමණි. සෑම ඉටරේෂන් එකක අවසානයේම ඔබේ Delivered තීරුව දෙස බලන්න — එය වර්ධනය වේ නම්, එය ඔබේ සංඥාවයි.
East Agile Tracker සමඟ XP
Section titled “East Agile Tracker සමඟ XP”XP කණ්ඩායම් Pivotal Tracker දිනවල සිට අවශ්ය වූ සැලසුම් මතුපිට tracker එකයි. සෑම සංකල්පයක්ම කෙලින්ම සිතියම්ගත වේ:
User Stories → Stories
Section titled “User Stories → Stories”XP user stories යනු East Agile Tracker stories වේ. ඒවා Feature වර්ගයෙන් ලියන්න. සංවාදය සඳහා විස්තරය භාවිතා කරන්න; අඛණ්ඩ සාකච්ඡාව සඳහා comments භාවිතා කරන්න. පිළිගැනීමේ නිර්ණායක විස්තරයට අයත් වේ.
Planning Game → බෝඩ් එක
Section titled “Planning Game → බෝඩ් එක”XP හි Planning Game යනු ව්යාපාර සහ කණ්ඩායම අතර ප්රමුඛතාව සහ ප්රමාණය පිළිබඳ සංවාදයකි. East Agile Tracker හි:
- ව්යාපාරික පුද්ගලයා Backlog එකේ ස්ටෝරි ලියා ඒවා ප්රමුඛතාව අනුව අනුපිළිවෙල කරයි.
- කණ්ඩායම features පොයින්ට් වලින් තක්සේරු කරයි (Fibonacci හෝ East Agile පරිමාණය).
- පද්ධතිය වෙලොසිටියෙන් ඉටරේෂන් ස්වයං-සැලසුම් කරයි.
- කණ්ඩායම Current තීරුවේ ඉහළ සිට ස්ටෝරි ආරම්භ කරයි.
එච්චරයි. “game” එක සංවාදයේ ජීවත් වේ; tracker එක ලකුණු තබා ගන්නා පමණි.
Small Releases → Releases (ස්ටෝරි වර්ගය)
Section titled “Small Releases → Releases (ස්ටෝරි වර්ගය)”XP කියන්නේ නිතර release කරන්න කියාය. Release යනු East Agile Tracker හි ස්ටෝරි වර්ග හතරෙන් එකකි. සෑම නැව්ගත කිරීමේ සන්ධිස්ථානයකටම release එකක් සාදන්න; එය නැව්ගත වන ඉටරේෂන් එකට එය ඇද දමන්න. Releases Started/Finished/Delivered මඟ හැර ඔබ නැව්ගත කරන විට කෙලින්ම Accepted වෙත යයි.
Continuous Integration → ස්ටෝරි තත්ත්ව යන්ත්රය
Section titled “Continuous Integration → ස්ටෝරි තත්ත්ව යන්ත්රය”තත්ත්ව යන්ත්රය CI එක නොවේ — එය ඔබේ build system එක — නමුත් Finished → Delivered → Accepted මාර්ගය XP විස්තර කරන පාරිභෝගික-පිළිගැනීමේ ලූපය පිළිබිඹු කරයි. වැඩ අවසන් කරන්න, එය පාරිභෝගිකයාට බෙදාහරින්න, ක්රියා කරන බව තහවුරු වූ විට accept කරන්න.
Velocity → “ඊයේ කාලගුණය”
Section titled “Velocity → “ඊයේ කාලගුණය””XP එය ඊයේ කාලගුණය ලෙස හඳුන්වයි: ඔබ පසුගිය ඉටරේෂන් එකේදී කොපමණ කළාද යන්න මෙම ඉටරේෂන් එකේදී ඔබ කොපමණ කරයිද යන්නට හොඳම පුරෝකථනයයි. East Agile Tracker වෙලොසිටි ස්වයංක්රීයව ගණනය කරයි — මෑත ඉටරේෂන් වල සාමාන්යය, වින්යාසගත කළ හැකි උපාය මාර්ගය — සහ ඊළඟ ඉටරේෂන් එකේ ධාරිතාව ස්වයං-සැලසුම් කිරීමට එය භාවිතා කරයි.
Acceptance Tests → Reviews
Section titled “Acceptance Tests → Reviews”tracker එකේ ස්ටෝරි reviews පිළිගැනීමට සිතියම්ගත වේ. reviewer කෙනෙකු (පාරිභෝගිකයා, product owner, හෝ එකක් ලෙස කටයුතු කරන ඒජන්තයෙකු පවා) පවරන්න. ඔවුන් approve හෝ reject කරයි. Rejected ස්ටෝරිය Started වෙත නැවත එවයි.
Pair Programming → Co-ownership
Section titled “Pair Programming → Co-ownership”XP කණ්ඩායම් කේතය මත pair කරයි. tracker එකේ, මෙය ස්ටෝරියක බහු owners ලෙස පෙන්වයි. ස්ටෝරියට යුගල දෙකම පවරන්න; නම් දෙකම කාඩ්පතේ දිස්වේ.
ඒජන්තයන් සමඟ XP — නව භාවිතය
Section titled “ඒජන්තයන් සමඟ XP — නව භාවිතය”AI ඒජන්තයන්ට මෘදුකාංගයට අර්ථවත් ලෙස දායක විය හැකි වීමට පෙර XP ලියන ලදී. අපි සිතන්නේ මෙය වසර විසිපහක් තුළ XP වෙත වැදගත්ම යාවත්කාලීනය බවයි.
අපගේ භාවිතයේ — සහ tracker එක ගොඩනඟා ඇති දේ — ඒජන්තයෙකු යනු නම් කරන ලද XP කණ්ඩායම් සාමාජිකයෙකි. එයට තමන්ගේම භූමිකාවක්, තමන්ගේම pair partner කෙනෙක් (මානව හෝ ඒජන්ට්), සහ තමන්ගේම විගණන මාර්ගයක් ඇත. එයට සැලසුම් මතුපිට තුළ මානව කණ්ඩායම් සාමාජිකයෙකුට කළ හැකි ඕනෑම දෙයක් කළ හැකිය: තක්සේරු කරන්න, ස්ටෝරි හිමි කරගන්න, අදහස් දක්වන්න, මාරු කරන්න, reviews accept කරන්න.
XP වටිනාකම් තවමත් පවතී. සන්නිවේදනය: ඒජන්තයන් event stream එක කියවා comments පළ කිරීමෙන් සන්නිවේදනය කරයි. සරලකම: ඔබ ලබා දෙන භූමිකාවන්ට ඒජන්තයන් සීමා වේ. ප්රතිපෝෂණය: සෑම ඒජන්ට් ක්රියාවක්ම විගණන ලොගයේ ඇත, වහාම සමාලෝචනය කළ හැකිය. නිර්භීතකම: ඔබේ ඒජන්තයන් නිවැරදිව කළ දේ සහ නොකළ දේ ගැන අවංක වන්න. ගෞරවය: ඒජන්ට් කණ්ඩායම් සාමාජිකයන් වටිනාකම දායක කරයි — එය හඳුනා ගන්න.
අපි ඒජන්තයන් tracker එක තුළ කේතකරණය කරමින් නොතබමු. අපි සැලසුම් මතුපිට මානවයන් සහ ඒජන්තයන්ට එක්ව වැඩ කිරීමට ලබා දෙමු. ඔබ කෝඩිං ඒජන්ට් ගෙන එයි — Claude Code, Codex, ඔබේම — සහ එය API හරහා tracker එකට සම්බන්ධ කරයි. ඒජන්තයා ස්ටෝරි භාරගනියි, වැඩ කරයි, comment කරයි, මාරු කරයි. ඔබ මාර්ගය සමාලෝචනය කර accept කරයි.
මෙය Inclusive Agile Planning වේ. එය XP වේ, එයට සැබවින්ම ඇති කණ්ඩායම සමඟ.
තවදුරටත් කියවීම
Section titled “තවදුරටත් කියවීම”- Extreme Programming Explained — Kent Beck ගේ මූලික පොත, 1999.
- ඇජයිල් ප්රකාශනය — පවුල ආරම්භ වූ තැන.
- ඇජයිල් සංවර්ධනය — පුළුල් චිත්රය.
- ක්රියාකරණ උපදෙස් — tracker එකට ප්රායෝගික මාර්ගෝපදේශය.
- API මාර්ගෝපදේශය — ඔබේ කෝඩිං ඒජන්ට් සම්බන්ධ කිරීම.