eXtreme Programming

eXtreme Programming — आमतौर पर बस XP — एजाइल परिवार का सबसे माँगलिक सदस्य है। East Agile Tracker XP के लिए सबसे पहले बनाया गया है; बाकी सब कुछ इससे निकलता है।

यह पेज कवर करता है कि XP क्या है, यह क्यों काम करता है, और ट्रैकर को अपनी योजना सतह के रूप में रखते हुए इसका अभ्यास कैसे करें।

XP क्या है

XP को Kent Beck द्वारा 1990 के दशक के अंत में बनाया गया था। पहली पुस्तक — Extreme Programming Explained: Embrace Change — 1999 में प्रकाशित हुई। यह, कई चीज़ों की तरह, Chrysler में एक पेरोल सिस्टम शिप करने की कोशिश कर रही एक हताश टीम से शुरू हुई।

XP का दाँव यह है कि सॉफ़्टवेयर में अनिश्चितता को संभालने का सही तरीका उन चीज़ों को करना है जो काम करती हैं, और उन्हें अधिक बार करना है। टेस्ट? हर समय टेस्ट करें। एकीकृत करें? हर घंटे एकीकृत करें। बात करें? लगातार बात करें। योजना बनाएँ? हर इटरेशन की योजना बनाएँ, और जैसे-जैसे आप सीखते हैं फिर से योजना बनाएँ।

“XP वैसी छोटी-से-मध्यम-आकार की टीमों के लिए एक हल्की कार्यप्रणाली है जो अस्पष्ट या तेज़ी से बदलती आवश्यकताओं का सामना करते हुए सॉफ़्टवेयर विकसित करती हैं।” — Kent Beck

पाँच मूल्य

XP पाँच मूल्यों का नाम लेता है जिन पर बाकी सब कुछ टिका हुआ है:

1. संचार — टीम बात करती है। प्रतिदिन। काम, डिज़ाइन, बाधाओं के बारे में। जब संभव हो आमने-सामने। साइलो दुश्मन हैं।
2. सादगी — वह सबसे सरल काम करें जो संभवतः काम कर सकता है। यदि आपको वास्तव में ज़रूरत है तो आप बाद में जटिलता जोड़ सकते हैं। आपको शायद ज़रूरत नहीं होगी।
3. प्रतिक्रिया — कोड से (टेस्ट), टीम से (पेयर प्रोग्रामिंग, रिव्यू), उपयोगकर्ता से (बार-बार रिलीज़)। इसे तेज़ी से प्राप्त करें।
4. साहस — प्रगति, अनुमानों, और डिज़ाइन के बारे में सच बोलें। जो कोड काम नहीं करता उसे फेंक दें। जो आपको रोक रहा है उसे रीफ़ैक्टर करें।
5. सम्मान — टीम में हर कोई — और अब, टीम में हर एजेंट — मूल्य का योगदान करता है। एक-दूसरे के साथ तदनुसार व्यवहार करें।

प्रथाएँ

XP अपनी बारह मूल प्रथाओं के लिए प्रसिद्ध है, जो चार क्षेत्रों में व्यवस्थित हैं:

योजना

• Planning Game — टीम और ग्राहक एक साथ योजना बनाते हैं: आगे क्या आ रहा है, किस क्रम में, हर टुकड़ा कितना बड़ा है।
• Small Releases — बार-बार शिप करें। दिन, महीने नहीं। किसी ठोस चीज़ पर प्रतिक्रिया प्राप्त करें।
• User Stories — आवश्यकताएँ बातचीत हैं, जिन्हें उपयोगकर्ता के दृष्टिकोण से छोटी स्टोरी के रूप में कैप्चर किया जाता है। “एक उपयोगकर्ता के रूप में, मैं X चाहता हूँ, ताकि Y।“

डिज़ाइनिंग

• Simple Design — सबसे सरल डिज़ाइन जो टेस्ट पास करता है और हर ज़रूरी अवधारणा को व्यक्त करता है। इससे ज़्यादा नहीं।
• Refactoring — पहले से काम कर रहे कोड के डिज़ाइन में सुधार करें। लगातार।
• System Metaphor — सिस्टम कैसे काम करता है इसकी एक साझा कहानी, डिज़ाइन निर्णयों को सुसंगत बनाने के लिए उपयोग की जाती है।

कोडिंग

• Pair Programming — दो डेवलपर, एक कीबोर्ड। एक चलाता है, एक नेविगेट करता है। बार-बार बदलें।
• Collective Code Ownership — कोई भी किसी भी कोड में सुधार कर सकता है। कोई जागीरें नहीं।
• Continuous Integration — दिन में कई बार कोड को एकीकृत और टेस्ट करें। तुरंत टूट-फूट पकड़ें।
• Coding Standards — सहमत शैली ताकि कोड ऐसे पढ़ा जाए जैसे एक व्यक्ति ने लिखा हो।

टेस्टिंग

• Test-Driven Development (TDD) — पहले असफल टेस्ट लिखें, फिर वह कोड जो इसे पास करता है।
• Acceptance Tests — ग्राहक कोड या निष्पादन योग्य रूप में परिभाषित करता है कि हर स्टोरी के लिए “done” का क्या अर्थ है।

XP क्यों काम करता है

XP असहज है। पेयर प्रोग्रामिंग आपको ज़ोर से सोचने के लिए मजबूर करती है। TDD आपको कोड लिखने से पहले यह जानने के लिए मजबूर करता है कि सफलता कैसी दिखती है। निरंतर एकीकरण आपकी पसंदीदा दीर्घकालिक ब्रांच को मार देता है। छोटी रिलीज़ का मतलब है कि आप छह महीने के रोडमैप के पीछे नहीं छिप सकते।

यह इसलिए काम करता है क्योंकि ये सभी चीज़ें प्रतिक्रिया लूप को छोटा करती हैं। आप जितनी तेज़ी से पता लगाते हैं कि आप गलत थे, सुधार उतना ही सस्ता होता है। XP, मूल रूप से, प्रतिक्रिया लूप को जितना तंग हो सके उतना तंग बनाने के बारे में है।

यह साहस और सम्मान के बारे में भी है। आप केवल उसी टीम पर XP कर सकते हैं जो एक-दूसरे पर इतना भरोसा करती है कि ज़ोर से गलत हो सके।

अनुशासित स्टोरी मॉडल

East Agile Tracker योजना के एक विशिष्ट सिद्धांत को कूटबद्ध करता है। इस अनुभाग को इस बात के संचालन मैनुअल के रूप में मानें कि डेटा मॉडल जैसा दिखता है वैसा क्यों दिखता है — और व्यवहार में क्या करना (और न करना) इसके लिए फ़ील्ड गाइड के रूप में।

चार स्टोरी प्रकार क्यों मायने रखते हैं

सब कुछ एक स्टोरी है, लेकिन चार तरह की हैं, और यह अंतर ही पूरा मुद्दा है:

• Features पॉइंट लेकर चलती हैं और वेलोसिटी की ओर “गिनी जाने वाली” एकमात्र चीज़ हैं। यह आपको काम को उपयोगकर्ता-दृश्य मूल्य में विभाजित करने के लिए मजबूर करता है।
• Bugs बिना पॉइंट के हैं (शून्य)। दोष क्रेडिट नहीं कमाते, जिससे फिर से काम करने की लागत पुरस्कृत होने के बजाय दिखाई देती है।
• Chores भी बिना पॉइंट के हैं — बिना प्रत्यक्ष उपयोगकर्ता मूल्य के आवश्यक कार्य (इंफ़्रा, रीफ़ैक्टर, सेटअप)। उन्हें शून्य पर रखना टीम पर दबाव डालता है कि जहाँ भी संभव हो उन्हें फ़ीचर में बंडल करे ताकि मूल्य का ढाँचा ईमानदार बना रहे।
• Releases शून्य-पॉइंट मार्कर हैं जिनका उपयोग मील के पत्थर तय करने और टूल को एक तारीख प्रक्षेपित करने देने के लिए किया जाता है।

जो मायने रखता है वह व्यवहारिक प्रभाव है: जब बग और चोर स्कोर नहीं करते, तो एक टीम स्वाभाविक रूप से काम को उपयोगकर्ता-उन्मुख कार्यक्षमता के रूप में व्यक्त करने की ओर बढ़ती है, और यह दोष की लागत के प्रति तीव्र रूप से सचेत हो जाती है। यह डेटा मॉडल में कूटबद्ध एक योजना अनुशासन है।

एकल क्रमित बैकलॉग

तीन ज़ोन, एक नियम।

• Icebox अप्राथमिकता वाला विचार पूल है।
• Backlog एक सख़्ती से क्रमित, एकल-प्राथमिकता सूची है — कोई बराबरी नहीं, कोई “P1/P1/P1” नहीं।
• Current ज़ोन सक्रिय इटरेशन को धारण करता है।

उत्पाद ओनर ऊपर-से-नीचे क्रम का स्वामी है, और अपरिवर्तनीय नियम यह है कि बैकलॉग का शीर्ष हमेशा सबसे महत्वपूर्ण और सर्वोत्तम-निर्दिष्ट होता है, और नीचे जाते-जाते स्पष्टता का वैध रूप से घटना। अस्पष्ट स्वीकृति मानदंड के साथ शीर्ष के पास की कोई स्टोरी एक योजना बग है। Icebox को कब्रिस्तान होने की अनुमति है; Backlog को नहीं।

वेलोसिटी-संचालित स्वचालित योजना

यह वह हिस्सा है जिसे अधिकांश टीमें कहीं और बुरी तरह से फिर से लागू करती हैं। Tracker-शैली योजना हाल ही में स्वीकृत पॉइंट से एक चलती-फिरती औसत वेलोसिटी की गणना करती है और स्वतः उतने पॉइंट की स्टोरी अगले इटरेशन में खींचती है — आप मैन्युअल रूप से किसी स्प्रिंट के लिए “प्रतिबद्ध” नहीं होते, अनुभवजन्य डेटा आपके लिए यह करता है। संरक्षित करने योग्य दो परिणाम:

• आप केवल फ़ीचर का अनुमान लगाते हैं, सापेक्ष पॉइंट का उपयोग करते हुए (Fibonacci 1/2/3/5/8 या हमारा सघन 0/1/2/3), घंटों का नहीं। अनुमान लगाना एक आकार-निर्धारण की बातचीत है, कोई वादा नहीं।
• आप वेलोसिटी के साथ धोखा नहीं करते। “तेज़ दिखने” के लिए पॉइंट फुलाना, या चोर को पॉइंट देना, उस प्रक्षेपण को तोड़ देता है जो पूरे सिस्टम को ईमानदार बनाता है। वेलोसिटी एक मापन उपकरण है, और आप अपने ही उपकरण से छेड़छाड़ नहीं करते।

प्रतिफल यह है कि रिलीज़ तिथि का प्रक्षेपण एक बातचीत के बजाय एक गणना बन जाता है, और हितधारकों के साथ बातचीत “क्या आप शुक्रवार तक X देने का वादा कर सकते हैं” से बदलकर “वर्तमान वेलोसिटी पर, यह रिलीज़ लगभग तारीख Y के आसपास आती है — यह रहा स्कोप/तारीख समझौता” हो जाती है।

स्टोरी जीवनचक्र और स्वीकृति लूप

स्टेट मशीन Start → Finish → Deliver → Accept / Reject है। महत्वपूर्ण स्टेट Deliver है: एक इंजीनियर किसी स्टोरी को डिलीवर्ड के रूप में चिह्नित करता है, लेकिन यह तब तक पूर्ण नहीं होती जब तक उत्पाद ओनर इसे इसके स्वीकृति मानदंडों के विरुद्ध स्पष्ट रूप से स्वीकार नहीं करता — या अस्वीकार नहीं करता, इसे वापस भेजते हुए। यह हर एक स्टोरी में एक ग्राहक-प्रतिक्रिया लूप को बेक करता है, बजाय इसके कि स्वीकृति को स्प्रिंट-अंत डेमो तक टाला जाए।

स्वीकृति मानदंड स्टोरी पर शुरू होने से पहले होने चाहिए, आदर्श रूप से Given/When/Then रूप में ताकि वे सीधे स्वीकृति परीक्षणों पर मैप हों। INVEST यह जाँचने का साधन है कि कोई स्टोरी अच्छी तरह से गठित है या नहीं:

• Independent — अन्य स्टोरी के बिना रिलीज़ की जा सकती है।
• Negotiable — आशय को कैप्चर करती है, कोई स्थिर स्पेक नहीं।
• Valuable — किसी उपयोगकर्ता या हितधारक के लिए।
• Estimable — टीम इसका आकार निर्धारित कर सकती है।
• Small — एक इटरेशन में आराम से समाती है।
• Testable — ऐसे स्वीकृति मानदंड हैं जिन्हें चलाया जा सकता है।

लय

योजना समारोह हल्के और नियमित हैं:

• नई स्टोरी को पॉइंट देने और बैकलॉग के शीर्ष पर स्वीकृति मानदंड तय करने के लिए एक साप्ताहिक Iteration Planning Meeting।
• प्रवाह और ब्लॉकर पर केंद्रित एक छोटा दैनिक स्टैंडअप।
• प्रक्रिया को समायोजित करने के लिए प्रति इटरेशन एक रेट्रोस्पेक्टिव।

इटरेशन आमतौर पर एक या दो सप्ताह के होते हैं — इतने छोटे कि एक बुरा अनुमान खोजना सस्ता हो।

इंजीनियरिंग प्रथाएँ जो योजना को काम करती हैं

Tracker-शैली योजना XP का दृश्यमान आधा हिस्सा है; यह इंजीनियरिंग आधे के बिना ढह जाती है।

• Test-first / TDD और एक वास्तविक स्वीकृति-परीक्षण सूट ही “delivered” का कोई अर्थ रखने देते हैं।
• निरंतर एकीकरण और छोटी, बार-बार रिलीज़ साइकिल टाइम को छोटा रखती हैं ताकि वेलोसिटी ढेलेदार के बजाय स्थिर हो।
• पेयर प्रोग्रामिंग (या मज़बूत रिव्यू) कार्य-प्रगति-में को कम रखती है — शुरू करने से पहले समाप्त करें — जो साइकिल टाइम पर सबसे बड़ा लीवर है।
• एक उपलब्ध उत्पाद ओनर ही स्वीकार/अस्वीकार लूप को रुकने से बचाता है।

सावधान रहने योग्य एंटी-पैटर्न

बार-बार होने वाली विफलताएँ:

• Backlog को एक पार्किंग लॉट के रूप में मानना, एक सच्चे प्राथमिकता क्रम के बजाय।
• वेलोसिटी को बेहतर दिखाने के लिए बग और चोर का अनुमान लगाना।
• ऐसी विशाल स्टोरी ले जाना जो एक इटरेशन में पूरी नहीं हो सकतीं। तब तक विभाजित करें जब तक प्रत्येक स्वतंत्र रूप से डिलीवरी योग्य न हो।
• स्टोरी को Delivered में ढेर होने देना क्योंकि कोई स्वीकार नहीं कर रहा।

इनमें से कोई भी चुपचाप एक अनुभवजन्य सिस्टम को वापस इच्छाधारी योजना में बदल देता है। ट्रैकर आपको उन्हें करने से नहीं रोक सकता; यह केवल उन्हें दृश्यमान बना सकता है। हर इटरेशन के अंत में अपने Delivered कॉलम को देखें — यदि यह बढ़ रहा है, तो यह आपका संकेत है।

East Agile Tracker के साथ XP

ट्रैकर वह योजना सतह है जिसे XP टीमें Pivotal Tracker के दिनों से चाहती रही हैं। हर अवधारणा सीधे मैप होती है:

User Stories → Stories

XP यूज़र स्टोरी East Agile Tracker स्टोरी हैं। उन्हें Feature प्रकार में लिखें। बातचीत के लिए विवरण का उपयोग करें; निरंतर चर्चा के लिए टिप्पणियों का उपयोग करें। स्वीकृति मानदंड विवरण में होने चाहिए।

Planning Game → बोर्ड

XP में Planning Game प्राथमिकता और आकार के बारे में व्यवसाय और टीम के बीच एक बातचीत है। East Agile Tracker में:

1. उत्पाद व्यक्ति Backlog में स्टोरी लिखता है और उन्हें प्राथमिकता के अनुसार क्रमित करता है।
2. टीम पॉइंट में फ़ीचर का अनुमान लगाती है (Fibonacci या East Agile स्केल)।
3. सिस्टम वेलोसिटी से इटरेशन की स्वतः-योजना बनाता है।
4. टीम Current कॉलम के शीर्ष से स्टोरी शुरू करती है।

बस इतना ही। “गेम” बातचीत में रहता है; ट्रैकर बस स्कोर रखता है।

Small Releases → Releases (स्टोरी प्रकार)

XP कहता है बार-बार रिलीज़ करें। Release East Agile Tracker में चार स्टोरी प्रकारों में से एक है। हर शिपिंग मील के पत्थर के लिए एक रिलीज़ बनाएँ; इसे उस इटरेशन में खींचें जहाँ यह शिप होता है। रिलीज़ Started/Finished/Delivered को छोड़ देती हैं और जब आप शिप करते हैं तो सीधे Accepted पर जाती हैं।

Continuous Integration → स्टोरी स्टेट मशीन

स्टेट मशीन अपने आप में CI नहीं है — वह आपका बिल्ड सिस्टम है — लेकिन Finished → Delivered → Accepted पथ XP द्वारा वर्णित ग्राहक-स्वीकृति लूप को प्रतिबिंबित करता है। काम समाप्त करें, इसे ग्राहक को डिलीवर करें, जब यह काम करने की पुष्टि हो जाए तो स्वीकार करें।

Velocity → “कल का मौसम”

XP इसे yesterday’s weather कहता है: पिछले इटरेशन में आपने कितना किया, वह इस बात की सबसे अच्छी भविष्यवाणी है कि इस बार आप कितना करेंगे। East Agile Tracker वेलोसिटी की स्वतः गणना करता है — हाल के इटरेशन का औसत, कॉन्फ़िगर करने योग्य रणनीति — और अगले इटरेशन की क्षमता की स्वतः-योजना बनाने के लिए इसका उपयोग करता है।

Acceptance Tests → Reviews

ट्रैकर में स्टोरी रिव्यू स्वीकृति से मैप होते हैं। एक रिव्यूअर असाइन करें (ग्राहक, उत्पाद ओनर, या एक के रूप में कार्य करने वाला एजेंट भी)। वे अनुमोदित या अस्वीकार करते हैं। अस्वीकृत स्टोरी को वापस Started पर भेज देता है।

Pair Programming → सह-स्वामित्व

XP टीमें कोड पर पेयर करती हैं। ट्रैकर में, यह किसी स्टोरी पर कई ओनर के रूप में दिखाई देता है। दोनों पेयर को स्टोरी में असाइन करें; दोनों नाम कार्ड पर दिखाई देते हैं।

एजेंट के साथ XP — नई प्रथा

XP तब लिखा गया था जब AI एजेंट सॉफ़्टवेयर में सार्थक रूप से योगदान नहीं कर सकते थे। हम सोचते हैं कि यह पच्चीस वर्षों में XP में सबसे महत्वपूर्ण अपडेट है।

हमारी प्रथा में — और जिसके लिए ट्रैकर बना है — एक एजेंट एक नामित XP टीम सदस्य है। इसकी अपनी भूमिका, अपना पेयर साथी (मानव या एजेंट), और अपनी ऑडिट ट्रेल होती है। यह वह सब कुछ कर सकता है जो एक मानव टीम सदस्य योजना सतह में कर सकता है: अनुमान लगाना, स्टोरी का स्वामित्व रखना, टिप्पणी करना, ट्रांज़िशन करना, रिव्यू स्वीकार करना।

XP मूल्य अभी भी कायम हैं। संचार: एजेंट इवेंट स्ट्रीम पढ़कर और टिप्पणियाँ पोस्ट करके संवाद करते हैं। सादगी: एजेंट आपके द्वारा दी गई भूमिकाओं तक सीमित हैं। प्रतिक्रिया: हर एजेंट क्रिया ऑडिट लॉग में है, तुरंत समीक्षा योग्य। साहस: इस बारे में ईमानदार रहें कि आपके एजेंट ने क्या सही किया और क्या नहीं। सम्मान: एजेंट साथी मूल्य का योगदान करते हैं — इसे पहचानें।

हम एजेंट को ट्रैकर के अंदर रखकर कोडिंग नहीं करवाते। हम योजना सतह मनुष्यों और एजेंट को एक साथ काम करते हुए देते हैं। आप कोडिंग एजेंट लाते हैं — Claude Code, Codex, अपना — और इसे API के माध्यम से ट्रैकर से जोड़ते हैं। एजेंट स्टोरी उठाता है, काम करता है, टिप्पणी करता है, ट्रांज़िशन करता है। आप ट्रेल की समीक्षा करते हैं और स्वीकार करते हैं।

यह Inclusive Agile Planning है। यह XP है, उस टीम के साथ जो इसके पास वास्तव में है।

आगे पढ़ने के लिए

• Extreme Programming Explained — Kent Beck की आधारभूत पुस्तक, 1999।
• एजाइल मेनिफ़ेस्टो — जहाँ परिवार शुरू हुआ।
• एजाइल विकास — व्यापक तस्वीर।
• संचालन निर्देश — ट्रैकर के लिए व्यावहारिक गाइड।
• API गाइड — अपने कोडिंग एजेंट को प्लग करना।