आप प्रोग्रामिंग से परिचित हैं, लेकिन एक्सट्रीम प्रोग्रामिंग (लघु XP) अभी भी आपके लिए एक रहस्य है।
नाम को बदनाम न होने दें, आप उपयोगी जानकारी से वंचित होने का जोखिम उठाते हैं।
इस लेख में, हम आपको एक्सट्रीम प्रोग्रामिंग के बारे में जानने के लिए आवश्यक सब कुछ शामिल करने जा रहे हैं ताकि आप इसे अपने लाभ के लिए उपयोग कर सकें।
एक्सट्रीम प्रोग्रामिंग एक सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी है जो सामूहिक रूप से फुर्तीली मेथडोलॉजी के रूप में जानी जाने वाली का हिस्सा है। XP मूल्यों, सिद्धांतों और प्रथाओं पर बनाया गया है, और इसका लक्ष्य छोटे और मध्यम आकार की टीमों को उच्च-गुणवत्ता वाले सॉफ़्टवेयर का उत्पादन करने और हमेशा-बदलते और विकसित होने वाली आवश्यकताओं के अनुकूल बनाने में सक्षम बनाना है।
XP को अन्य फुर्तीली पद्धतियों से अलग करने वाली बात यह है कि XP सॉफ्टवेयर विकास के तकनीकी पहलुओं पर जोर देता है। चरम प्रोग्रामिंग इस बारे में सटीक है कि इंजीनियर कैसे काम करते हैं क्योंकि निम्नलिखित इंजीनियरिंग प्रथाओं से टीमों को एक स्थायी गति से उच्च गुणवत्ता कोड वितरित करने की अनुमति मिलती है।
चरम प्रोग्रामिंग, संक्षेप में, अच्छी प्रथाओं को चरम पर ले जाती है। चूंकि जोड़ी प्रोग्रामिंग अच्छी है, आइए इसे हर समय करें। चूंकि पहले से परीक्षण करना अच्छा है, हम उत्पादन कोड लिखे जाने से पहले ही परीक्षण कर लेते हैं।
XP, अन्य पद्धतियों के विपरीत, उन मूल्यों और सिद्धांतों पर आधारित है जो इंजीनियरिंग प्रथाओं के संदर्भ में महत्वपूर्ण और प्रासंगिक हैं।
मूल्य समूहों को उद्देश्य प्रदान करते हैं। वे उच्च स्तर पर आपके निर्णयों का मार्गदर्शन करने के लिए "उत्तरी सितारे" के रूप में कार्य करते हैं। हालाँकि, मान अमूर्त हैं और विशिष्ट मार्गदर्शन के लिए बहुत अस्पष्ट हैं। उदाहरण के लिए: यह कहना कि आप संचार को महत्व देते हैं, कई अलग-अलग परिणाम दे सकते हैं।
प्रथाएँ, एक अर्थ में, मूल्यों के विपरीत हैं। वे ठोस और ज़मीन से जुड़े हुए हैं, defiक्या करना है इसकी विशिष्टताएँ निर्धारित करना। अभ्यास से टीमों को मूल्यों के प्रति खुद को जवाबदेह बनाए रखने में मदद मिलती है। उदाहरण के लिए, सूचना कार्यक्षेत्रों का अभ्यास पारदर्शी और सरल संचार को बढ़ावा देता है।
सिद्धांत डोमेन-विशिष्ट दिशानिर्देश हैं जो प्रथाओं और मूल्यों के बीच की खाई को पाटते हैं।
XP मूल्य: संचार, सादगी, प्रतिक्रिया, साहस और सम्मान। आइए उनमें से प्रत्येक को अधिक विस्तार से देखें।
प्रारूपण BlogInnovazione.यह छवि का alexsoft.com
संचार: संचार का अभाव ज्ञान को एक टीम के भीतर प्रवाहित होने से रोकता है। अक्सर, जब कोई समस्या होती है, तो कोई पहले से ही जानता है कि इसे कैसे ठीक किया जाए। लेकिन संचार की कमी उन्हें समस्या के बारे में जानने या उसके समाधान में योगदान करने से रोकती है। इस प्रकार, समस्या दो बार हल हो जाती है, जिससे अपशिष्ट उत्पन्न होता है।
सादगी: सरलता कहती है कि आप हमेशा सबसे सरल काम करने का प्रयास करते हैं जो काम करता है। यह अक्सर गलत समझा जाता है और "जो काम करता है" भाग को अनदेखा करते हुए, सबसे सरल चीज, अवधि के रूप में लिया जाता है।
यह याद रखना भी महत्वपूर्ण है कि सादगी अत्यधिक प्रासंगिक है। एक टीम के लिए जो सरल है वह दूसरे के लिए जटिल है और पूरी तरह से प्रत्येक टीम के कौशल, अनुभव और ज्ञान पर निर्भर करता है।
फीडबैक: अधिक पारंपरिक, व्यापक सॉफ्टवेयर विकास पद्धतियों में प्रतिक्रिया अक्सर "बहुत कम, बहुत देर से" होती है।
हालाँकि, XP परिवर्तन को गले लगाता है और XP टीमें समय पर और निरंतर प्रतिक्रिया के लिए प्रयास करती हैं। यदि पाठ्यक्रम सुधार की आवश्यकता है, तो XPers जल्द से जल्द जानना चाहते हैं।
प्रारूपण BlogInnovazione.यह छवि का alexsoft.com
फीडबैक कई आकार और आकारों में आता है। जब आप प्रोग्रामिंग में भागीदारी करते हैं, तो आपके सहकर्मी की टिप्पणियां महत्वपूर्ण प्रतिक्रिया होती हैं। तो एक विचार पर टीम के अन्य सदस्यों की राय है, जिसमें ग्राहक भी शामिल है, जो आदर्श रूप से टीम का सदस्य है।
परीक्षण मूल्यवान प्रतिक्रिया का एक और स्रोत है जो परीक्षण के परिणामों से परे है। परीक्षण लिखना आसान है या कठिन, फीडबैक भी ऐसा ही है। यदि आपको परीक्षण लिखने में समस्या हो रही है, तो संभवतः आपकी परियोजना बहुत जटिल है। प्रतिक्रिया सुनें और अपने डिजाइन को सुव्यवस्थित करें।
कोई चीज़ जो एक महान विचार की तरह लगती है, व्यवहार में इतनी अच्छी तरह से काम नहीं कर सकती है। इसलिए, एक वितरित उत्पाद के रूप में तैयार कोड भी प्रतिक्रिया का एक स्रोत है।
अंत में, ध्यान रखें कि बहुत अधिक प्रतिक्रिया है। यदि कोई टीम अपनी क्षमता से अधिक प्रतिक्रिया उत्पन्न करती है, तो महत्वपूर्ण प्रतिक्रिया राडार से गिर सकती है। इसलिए यह धीमा करना और यह पता लगाना आवश्यक है कि अतिरिक्त प्रतिक्रिया का कारण क्या है और इसे ठीक करें।
कोरैगियो: केंट बेक defiसाहस "डर के सामने प्रभावी कार्रवाई" के रूप में उभरता है। एक सॉफ्टवेयर इंजीनियर के रूप में, आपके पास डरने के लिए बहुत कुछ है और इसलिए साहस दिखाने के लिए बहुत सारे अवसर हैं।
सच बोलने के लिए साहस चाहिए, विशेष रूप से अप्रिय बातें, जैसे कि ईमानदार अनुमान। प्रतिक्रिया देना और प्राप्त करना भी साहस लेता है। और डूबती हुई लागत के भ्रम में पड़ने से बचने और असफल समाधान को त्यागने के लिए साहस चाहिए, जिसने पर्याप्त निवेश प्राप्त किया है।
आदर करना: XP का एक मूलभूत आधार यह है कि हर कोई अपने काम की परवाह करता है। यदि देखभाल और सम्मान नहीं है तो कोई भी तकनीकी उत्कृष्टता किसी परियोजना को नहीं बचा सकती है।
प्रत्येक व्यक्ति गरिमा और सम्मान के योग्य है, और इसमें निश्चित रूप से, सॉफ्टवेयर विकास परियोजना में शामिल लोग शामिल हैं। जब आप और आपकी टीम के सदस्य एक-दूसरे, क्लाइंट, प्रोजेक्ट और उसके भविष्य के उपयोगकर्ताओं का सम्मान करते हैं और उनकी परवाह करते हैं, तो सभी को लाभ होता है
सिद्धांत मूल्यों की तुलना में अधिक विशिष्ट मार्गदर्शन प्रदान करते हैं। वे दिशानिर्देश हैं जो मूल्यों को स्पष्ट करते हैं और उन्हें अधिक स्पष्ट और कम अस्पष्ट बनाते हैं।
प्रारूपण BlogInnovazione.यह छवि का alexsoft.com
उदाहरण के लिए, अकेले साहस के मूल्य के आधार पर, आप यह निष्कर्ष निकाल सकते हैं कि अपने शेड्यूल में तुरंत एक बड़ा बदलाव करने की सलाह दी जाती है। हालाँकि, बेबी स्टेप्स सिद्धांत हमें बताता है कि बड़े बदलाव जोखिम भरे हैं। इसलिए, इसके बजाय छोटे वाले को प्राथमिकता दें।
उमनिटा: इंसान इंसानों के लिए सॉफ्टवेयर बनाता है, यह एक ऐसा तथ्य है जिसकी अक्सर अनदेखी की जाती है। लेकिन बुनियादी मानवीय जरूरतों, ताकत और कमजोरियों को ध्यान में रखते हुए ऐसे उत्पाद तैयार किए जाते हैं जिनका मनुष्य उपयोग करना चाहता है। और एक काम का माहौल जो आपको पूर्ति और विकास का अवसर प्रदान करता है, अपनेपन और बुनियादी सुरक्षा की भावना, एक ऐसी जगह है जहाँ आप दूसरों की ज़रूरतों पर अधिक आसानी से विचार करते हैं।
अर्थव्यवस्था: XP में, टीमें हमेशा सॉफ्टवेयर विकास की आर्थिक वास्तविकताओं पर ध्यान देती हैं, लगातार आर्थिक जोखिमों और परियोजना की जरूरतों का मूल्यांकन करती हैं।
उदाहरण के लिए, वे तकनीकी चिंताओं के बजाय अपने व्यावसायिक मूल्य के आधार पर उपयोगकर्ता कहानियों को लागू करेंगे।
साँझा लाभ: XP के बाद, आप उन समाधानों से बचते हैं जो एक पक्ष को दूसरे पक्ष की कीमत पर लाभ पहुँचाते हैं। उदाहरण के लिए, विस्तृत विवरण किसी और को इसे समझने में मदद कर सकते हैं, लेकिन यह आपको इसे लागू करने से विचलित करता है और आपके उपयोगकर्ताओं के लिए इसे विलंबित करता है।
स्वचालित स्वीकृति परीक्षणों का उपयोग करना एक पारस्परिक रूप से लाभकारी समाधान है। अपने कार्यान्वयन पर तत्काल प्रतिक्रिया प्राप्त करें, आपके साथियों को कोड में सटीक विनिर्देश मिलते हैं, और उपयोगकर्ताओं को उनकी सुविधाएं पहले मिलती हैं। साथ ही, आप सभी के पास प्रतिगमन के खिलाफ एक सुरक्षा जाल होगा।
लाभ (पारस्परिक लाभ): यदि कोई समाधान एक स्तर पर कार्य करता है, तो वह उच्च या निम्न स्तर पर भी कार्य कर सकता है। उदाहरण के लिए, XP में अलग-अलग डिग्री के लिए शुरुआती और निरंतर प्रतिक्रिया प्राप्त करना दांव पर है।
सुधार: सुधार के सिद्धांत के अनुसार, टीमों का लक्ष्य प्रारंभिक कार्यान्वयन में पूर्णता के लिए नहीं है, बल्कि एक ऐसे कार्यान्वयन के लिए है जो काफी अच्छा हो, और फिर वास्तविक उपयोगकर्ताओं से प्रतिक्रिया के साथ इसे लगातार सीखें और सुधारें।
विविधता: आप और आपके सहकर्मी विविध दृष्टिकोणों, कौशलों और दृष्टिकोणों से लाभान्वित होते हैं। इस तरह की विविधता अक्सर संघर्ष की ओर ले जाती है, लेकिन यह ठीक है।
जब हर कोई साहस और सम्मान के मूल्यों से खेलता है तो संघर्ष और असहमति बेहतर विचारों के उभरने के अवसर होते हैं। विपरीत दृष्टिकोण व्यक्त करने का साहस, उन्हें नागरिक और समानुभूतिपूर्ण तरीके से व्यक्त करने में सम्मान। और यह सब एक प्रभावी संचार अभ्यास है।
प्रतिबिंब: महान टीमें अपने काम पर विचार करती हैं और विश्लेषण करती हैं कि कैसे बेहतर किया जा सकता है। XP इसके लिए कई अवसर प्रदान करता है। न केवल अपने साप्ताहिक और त्रैमासिक चक्रों में, बल्कि हर व्यवहार में यह बढ़ावा देता है।
तार्किक विश्लेषण के अलावा भावनाओं पर विचार करना महत्वपूर्ण है। इससे पहले कि आप किसी चीज के बारे में तर्क कर सकें, आपका आंत आपको सूचित कर सकता है। और इसलिए वह गैर-तकनीकी लोगों से बात कर सकता है, वे सवाल पूछ सकते हैं जो पूरी तरह से नई संभावनाएं खोलते हैं।
फ्लुसो: पारंपरिक सॉफ्टवेयर विकास पद्धतियों के अलग-अलग चरण होते हैं, जो लंबे समय तक चलते हैं और प्रतिक्रिया और पाठ्यक्रम सुधार के लिए बहुत कम अवसर होते हैं। इसके बजाय, XP में सॉफ्टवेयर विकास उन गतिविधियों में होता है जो मूल्य के एक सुसंगत "स्ट्रीम" में लगातार होती रहती हैं।
अवसर: सॉफ्टवेयर विकास में समस्याएं अपरिहार्य हैं। हालाँकि, हर समस्या सुधार का एक अवसर है। उन्हें इस तरह से देखना सीखें और आप रचनात्मक और लक्ष्य-उन्मुख समाधानों के साथ आने की अधिक संभावना रखते हैं जो उन्हें फिर से होने से रोकने के लिए भी काम करते हैं।
फालतूपन: अतिरेक का सिद्धांत कहता है कि यदि कोई समस्या गंभीर है, तो आपको इसका मुकाबला करने के लिए कई रणनीतियां अपनानी चाहिए।
खामियां लीजिए। ऐसी कोई एक रणनीति नहीं है जो सभी दोषों को उत्पादन से बचने से रोक सके।
तो XP का समाधान गुणवत्ता उपायों के एक सेट को ढेर करना है। जोड़ी प्रोग्रामिंग, परीक्षण, निरंतर एकीकरण। रक्षा की प्रत्येक पंक्ति, एक साथ वस्तुतः अभेद्य दीवार।
असफलता: असफलता बर्बादी नहीं है जब यह ज्ञान में बदल जाती है। कई विकल्पों में से चुनने पर अनिर्णय के कारण होने वाली निष्क्रियता की तुलना में कार्रवाई करना और जो काम नहीं करता है उसे जल्दी से सीखना बहुत अधिक उत्पादक है।
Qualita: लोग अक्सर सोचते हैं कि गुणवत्ता और गति के बीच दुविधा है।
यह दूसरा तरीका है: गुणवत्ता में सुधार करने के लिए जोर लगाने से आप तेजी से आगे बढ़ते हैं।
उदाहरण के लिए, रिफैक्टरिंग - कोड के व्यवहार को बदले बिना उसकी संरचना को बदलना - एक अभ्यास है जो कोड को समझने और बदलने में आसान बनाता है। नतीजतन, आपको कोड दोष पेश करने की कम संभावना है, जो आपको बग को ठीक न करके पहले अधिक मूल्य प्रदान करने की अनुमति देता है।
नन्हें कदम: बड़े बदलाव जोखिम भरे होते हैं। XP हर स्तर पर छोटे चरणों में बदलाव करके उस जोखिम को कम करता है।
प्रोग्रामर परीक्षण-संचालित विकास का उपयोग करके छोटे चरणों में कोड लिखते हैं। वे अपने कोड को हर कुछ हफ्तों या महीनों के बजाय दिन में कई बार मेनलाइन में एकीकृत करते हैं। परियोजना लंबे समय तक चलने वाले चरणों के बजाय छोटे चक्रों में होती है।
उत्तरदायित्व स्वीकार किया: XP में, जिम्मेदारी स्वीकार की जानी चाहिए, कभी सौंपी नहीं जानी चाहिए।
आप किसके लिए जिम्मेदार हैं, इसके बारे में निर्णय लेने के अधिकार के साथ जवाबदेही आनी चाहिए। उल्टा भी सही है। आप नहीं चाहते कि लोग निर्णय लें यदि उन्हें उनके परिणामों के साथ नहीं जीना है।
एक्सट्रीम प्रोग्रामिंग, एक फुर्तीली कार्यप्रणाली होने के नाते, इसे स्वीकार किया जा सकता है और कठोर योजनाओं का पालन किए बिना इसे अपनाना शुरू किया जा सकता है। यह एक बड़ी प्रारंभिक परियोजना के बजाय पुनरावृत्त डिजाइन है।
XP पारंपरिक तरीकों से काफी अलग है, यानी कैस्केडिंग, लंबे समय तक चलने वाले चरणों से बचना।
XP अन्य चुस्त पद्धतियों से कैसे भिन्न है?
एक्सट्रीम प्रोग्रामिंग, अपने स्वभाव से, अन्य फुर्तीली कार्यप्रणालियों के साथ बहुत कुछ समान है, लेकिन उनमें अद्वितीय भी है।
अधिकांश अन्य विकास पद्धतियाँ इस बारे में बहुत कुछ नहीं कहती हैं कि काम कैसे पूरा किया जाए। दूसरी ओर, जब इस बारे में XP की बात आती है तो यह बहुत ही स्वच्छंद होता है और सॉफ्टवेयर इंजीनियरिंग प्रथाओं पर बहुत जोर देता है।
स्क्रम एक अनुकूली तरीके से जटिल परियोजनाओं को विकसित करने में टीमों की मदद करने के लिए एक ढांचा है। स्क्रम डिक्टेट नहीं करता है कि डेवलपर्स अपना काम कैसे करते हैं। XP, जैसा कि उल्लेख किया गया है, अच्छी प्रोग्रामिंग प्रथाओं पर बहुत अधिक जोर देता है।
प्रारूपण BlogInnovazione.एन छवि शुद्ध समाधान
साथ ही, XP स्पष्ट रूप से प्रोग्रामिंग के बारे में है। दूसरी ओर, स्क्रम को किसी भी परियोजना पर लागू किया जा सकता है जो पुनरावृत्त दृष्टिकोण से लाभान्वित होता है।
XP अपने घटकों में परिवर्तन स्वीकार करता है। टीमों को उनकी विशिष्ट आवश्यकताओं के आधार पर प्रथाओं को संशोधित करने के लिए सशक्त और प्रोत्साहित किया जाता है। दूसरी ओर, स्क्रम गाइड इस बात पर अडिग है कि "यद्यपि स्क्रम के केवल भागों को लागू किया जा सकता है, परिणाम स्क्रम नहीं है"।
साथ ही, स्क्रम एक ढांचा है जिसे काम पूरा करने के लिए पद्धतियों और प्रथाओं के साथ पूरक होने की आवश्यकता है।
इसका मतलब है कि अत्यधिक प्रोग्रामिंग और स्क्रम में काम करने की अत्यधिक अनुशंसा की जाती है।
केंट बेक के अनुसार, एक परिपक्व XP टीम को कठोर भूमिकाएँ नहीं सौंपनी चाहिए, लेकिन यह पहचानना चाहिए कि नई टीमों के लिए भूमिकाएँ तब तक उपयोगी हो सकती हैं जब तक कि वे धीमा न होने लगें या सहयोग को कठिन न बना दें।
आइए कुछ प्रमुख भूमिकाओं पर नज़र डालते हैं:
ये XP में अपनाई गई प्रथाएं हैं। वे तीन मुख्य समूहों में विभाजित हैं: सॉफ्टवेयर इंजीनियरिंग, कार्यस्थल और परियोजना प्रबंधन।
जोड़ा प्रोग्राम तैयार करना: XP में आप मशीन पर बैठे जोड़े में कोड लिखते हैं। जिस सुविधा पर आप काम कर रहे हैं, उसका विश्लेषण, कार्यान्वयन और परीक्षण करते समय आप और आपका जोड़ा एक-दूसरे से बात करते हैं। जोड़ी प्रोग्रामिंग विशेष रूप से आकर्षक, मज़ेदार और थका देने वाले होते हुए भी कम बग वाले कोड का निर्माण करने में अच्छा है।
दस मिनट की सीमा: आवश्यक 10 मिनट में अधिकतम दस मिनट में सभी स्वचालित परीक्षणों को चलाने सहित संपूर्ण प्रोजेक्ट बनाने की अनुमति देता है। यह सीमा परीक्षण को सुव्यवस्थित और प्रभावी बनाए रखने के लिए है।
प्रोग्रामिंग से पहले टेस्ट: परीक्षण-प्रथम दृष्टिकोण का उपयोग करके सुविधाओं को लागू करें, जिसे भी कहा जाता है परीक्षण संचालित विकास (टीडीडी). टीडीडी में एक साधारण पुनरावृत्ति प्रक्रिया का उपयोग करके विकास होता है:
टीडीडी कई लाभ लाता है।
सबसे पहले, प्रतिक्रिया। यदि परीक्षण लिखना मुश्किल है, तो आप जिस डिज़ाइन की तलाश कर रहे हैं या जो आपको विरासत में मिली है वह शायद बहुत जटिल है और आपको इसे सरल बनाने की आवश्यकता है।
दूसरे, टीडीडी प्रोग्रामर को उनके द्वारा लिखे गए कोड पर भरोसा करने की अनुमति देता है और एक अच्छा लूपिंग रिदम बनाता है जहां अगला चरण हमेशा स्पष्ट होता है।
अंतिम लेकिन कम नहीं, शुरुआत से टीडीडी का उपयोग करना 100% कोड कवरेज सुनिश्चित करता है। परीक्षण सूट वास्तव में भविष्य के परिवर्तनों के लिए एक सुरक्षा जाल बन जाता है, कोड रीफैक्टरिंग को प्रोत्साहित करता है और गुणवत्ता का एक अच्छा चक्र बनाता है।
वृद्धिशील डिजाइन: वृद्धिशील डिजाइन के अभ्यास का मतलब है कि आपको हर दिन अपने एप्लिकेशन डिजाइन में निवेश करने की जरूरत है, दोहराव को दूर करने के अवसरों की तलाश में और आपके सिस्टम की आज की जरूरतों के लिए सर्वोत्तम संभव डिजाइन प्राप्त करने के लिए छोटे सुधार करें।
लगातार मेल जोल: XP में, आप अपने कार्य को दिन में कई बार मुख्य साझा रिपॉजिटरी में एकीकृत करते हैं, जिससे संपूर्ण सिस्टम का स्वत: निर्माण शुरू हो जाता है। जितनी जल्दी और जितनी बार संभव हो एकीकृत करना नाटकीय रूप से एकीकरण की लागत को कम कर देता है क्योंकि यह मर्ज करता है और तार्किक संघर्ष कम होने की संभावना है। यह पर्यावरण और व्यसन के मुद्दों को भी उजागर करता है।
साझा कोड (सामूहिक स्वामित्व): XP साझा कोड, या सामूहिक स्वामित्व को बढ़ावा देता है: प्रत्येक डेवलपर सभी कोड के लिए जिम्मेदार होता है। यदि हम विविधता के सिद्धांत पर विचार करें तो यह सूचना के आदान-प्रदान को प्रोत्साहित करता है, टीम बस कारक को कम करता है और प्रत्येक मॉड्यूल की समग्र गुणवत्ता को बढ़ाता है।
सिंगल कोडबेस: सिंगल कोडबेस को "ट्रंक-आधारित विकास" के रूप में भी जाना जाता है। इसका अर्थ है कि सत्य का केवल एक ही स्रोत है। इसलिए लंबे समय तक अलग-थलग रहने के बजाय, अपने योगदानों को जल्दी और बार-बार एक धारा में मर्ज करें। फ़ीचर फ़्लैग आपके द्वारा सुविधाओं के पूर्ण होने तक उनके उपयोग को सीमित करने में मदद करते हैं।
दैनिक वितरण: दिन में कम से कम एक बार उत्पादन में परिनियोजन निरंतर एकीकरण का एक तार्किक परिणाम है:। वास्तव में, आज कई टीमें और भी आगे जाती हैं और निरंतर कार्यान्वयन का अभ्यास करती हैं। यानी, जब भी कोई मेनलाइन में शामिल होता है, तो एप्लिकेशन को प्रोडक्शन में तैनात कर दिया जाता है।
कोड और परीक्षण: इस अभ्यास का मतलब है कि परीक्षण सहित स्रोत कोड, एक सॉफ्टवेयर प्रोजेक्ट का एकमात्र स्थायी आर्टिफैक्ट है। प्रलेखन सहित अन्य प्रकार की कलाकृतियों के उत्पादन में संलग्न होना अक्सर व्यर्थ होता है क्योंकि यह ग्राहक के लिए वास्तविक मूल्य उत्पन्न नहीं करता है।
यदि आपको अन्य कलाकृतियों या दस्तावेज़ों की आवश्यकता है, तो उन्हें उत्पादन कोड और परीक्षणों से उत्पन्न करने का प्रयास करें।
मूल कारण विश्लेषण: जब भी कोई दोष उत्पादन में जाता है, तो केवल दोष को ठीक न करें। सुनिश्चित करें कि आपने पहले यह पता लगा लिया है कि इसका कारण क्या है, आप और आपके साथी स्किड को रोकने में क्यों विफल रहे। फिर, यह सुनिश्चित करने के लिए कदम उठाएं कि ऐसा दोबारा न हो।
साथ मिलकर बैठें: XP में, टीमें खुली जगह में एक साथ काम करना पसंद करती हैं। यह अभ्यास संचार और एक टीम से संबंधित होने की भावना को बढ़ावा देता है।
पूरी मंडली: प्रोजेक्ट की सफलता के लिए आवश्यक सभी लोग XP टीम का हिस्सा हैं। यह अत्यधिक प्रासंगिक है - प्रत्येक टीम के लिए अलग - और गतिशील, यह एक टीम के भीतर बदल सकता है।
सूचना कार्यक्षेत्र: एक सूचना कार्यक्षेत्र टीम के भौतिक स्थान का उपयोग जानकारी प्रदर्शित करने के लिए करता है जो किसी को भी, एक नज़र में, परियोजना की प्रगति को जानने की अनुमति देता है। यह कैसे किया जाता है, यह अलग-अलग हो सकता है, भौतिक नोट्स और ग्राफ़ से लेकर कनबन बोर्ड दिखाने वाले स्क्रीनशॉट और परियोजना प्रबंधन सॉफ़्टवेयर के डैशबोर्ड तक।
उर्जावान कार्य: XP में आप तभी तक काम करते हैं जब तक आप ऊर्जावान काम कर सकते हैं। काम के घंटे अधिकतम 40 प्रति सप्ताह तक सीमित होने चाहिए।
analisi- उपयोगकर्ता विश्लेषण के रूप में ज्ञात प्रारूप में उपयोगकर्ता आवश्यकताओं को लिखें। एक उपयोगकर्ता विश्लेषण में एक छोटा, वर्णनात्मक नाम होता है और यह भी संक्षिप्त वर्णन होता है कि क्या लागू किया जाना चाहिए।
सुस्त: साइकिल की योजना बनाते समय, छोटे कार्यों को शामिल करें जिन्हें टीम आवश्यकता पड़ने पर छोड़ सकती है। यदि टीम बहुत अधिक डिलीवर करती है तो अधिक कहानियां हमेशा जोड़ी जा सकती हैं।
चक्र (मासिक और साप्ताहिक): XP में विकास दो मुख्य चक्रों में होता है: साप्ताहिक चक्र और मासिक चक्र।
बैठकें, चक्र, अनुसूचित रिलीज: XP में विकास दो मुख्य चक्रों में काम करता है: साप्ताहिक चक्र और त्रैमासिक चक्र। प्रारंभ में, केंट बेक ने दो सप्ताह के चक्र की सिफारिश की, लेकिन अपनी पुस्तक के दूसरे संस्करण में इसे बदल दिया।
साप्ताहिक चक्र: साप्ताहिक चक्र एक XP परियोजना की "नब्ज" है। चक्र एक बैठक के साथ शुरू होता है जिसमें ग्राहक चुनता है कि वह सप्ताह के दौरान कौन सी कहानियां बनाना चाहता है। इसके अतिरिक्त, टीम पिछले सप्ताह की प्रगति सहित अपने काम की समीक्षा करती है और अपनी प्रक्रिया को बेहतर बनाने के तरीकों के बारे में सोचती है।
मासिक चक्र: हर महीने, टीम अपनी प्रक्रिया में सुधार के अवसरों को दर्शाती है और उनकी पहचान करती है। क्लाइंट उस महीने के लिए एक या अधिक थीम चुनता है, साथ ही इन थीम में विश्लेषण भी करता है।
एक्सट्रीम प्रोग्रामिंग के साथ काम कैसे शुरू करें?
तकनीकी कौशल और XP की आदतें सीखना कठिन हो सकता है। कुछ प्रथाएँ उन प्रोग्रामरों के लिए विदेशी लग सकती हैं जो उनके अभ्यस्त नहीं हैं।
Ercole Palmeri
कैटेनिया पॉलीक्लिनिक में ऐप्पल विज़न प्रो कमर्शियल व्यूअर का उपयोग करके एक ऑप्थाल्मोप्लास्टी ऑपरेशन किया गया…
रंग भरने के माध्यम से बढ़िया मोटर कौशल विकसित करना बच्चों को लेखन जैसे अधिक जटिल कौशल के लिए तैयार करता है। रंग भरना…
नौसैनिक क्षेत्र एक सच्ची वैश्विक आर्थिक शक्ति है, जो 150 अरब के बाज़ार की ओर बढ़ चुका है...
पिछले सोमवार को, फाइनेंशियल टाइम्स ने OpenAI के साथ एक समझौते की घोषणा की। एफटी अपनी विश्व स्तरीय पत्रकारिता को लाइसेंस देता है...
