एजाइल मेथोडोलॉजी: ए बिगिनर गाइड टू एजाइल मेथड एंड स्क्रैम

agile methodology beginner s guide agile method

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

ऑपरेटिंग सिस्टम का चयन करें प्रक्षेपण का एक कार्यक्रम चुनें (वैकल्पिक रूप से)

अपनी समस्या का वर्णन करें

चंचल कार्यप्रणाली के लिए एक संपूर्ण मार्गदर्शिका: (20+ विस्तृत चंचल विक्रम पद्धति ट्यूटोरियल)

यह सॉफ्टवेयर डेवलपर्स और परीक्षकों के लिए बहुत प्रसिद्ध पर काम करने को समझने और शुरू करने के लिए गाइड है सॉफ्टवेयर विकास और परीक्षण के लिए चुस्त SCRUM पद्धति । संपूर्ण प्रक्रिया के वास्तविक उदाहरण के साथ एजाइल स्क्रैम प्रक्रिया में उपयोग की जाने वाली बुनियादी लेकिन महत्वपूर्ण शब्दावली जानें।

हमने आपकी सुविधा के लिए इस श्रृंखला के सभी एजाइल ट्यूटोरियल सूचीबद्ध किए हैं। आशा है कि वे आपकी बहुत मदद करेंगे।

शामिल विषय: फुर्तीली क्या है, सॉफ्टवेयर डेवलपमेंट एंड टेस्टिंग में एग्री, मेथड, एगाइल मेथोडोलॉजी, एग्री टेस्टिंग, एगाइल स्क्रैम प्रोसेस, स्क्रैम मेथडोलॉजी विद स्क्रेम टीम और स्क्रेम मास्टर।

चुस्त विकास के लिए परिचय

आप क्या सीखेंगे:

चंचल कार्यप्रणाली ट्यूटोरियल सूची
चंचल विकास का परिचय
चंचल कार्यप्रणाली
स्क्रम पद्धति

चंचल कार्यप्रणाली ट्यूटोरियल सूची

अधिक अनुशंसित चुस्त स्क्रेम ट्यूटोरियल:

उपकरण और साक्षात्कार प्रश्न:

ट्यूटोरियल # 18: चंचल परीक्षण उपकरण
ट्यूटोरियल # 19: सर्वश्रेष्ठ चुस्त परियोजना प्रबंधन उपकरण
ट्यूटोरियल # 20: शीर्ष चुस्त साक्षात्कार प्रश्न
ट्यूटोरियल # 21: शीर्ष स्क्रम साक्षात्कार प्रश्न

आइए श्रृंखला में पहले ट्यूटोरियल से शुरू करें - एजाइल स्क्रैम परिचय।

चंचल विकास का परिचय

सॉफ्टवेयर विकास में फुर्तीली:

एजाइल दुनिया के सबसे व्यापक रूप से इस्तेमाल और मान्यता प्राप्त सॉफ्टवेयर विकास ढांचे में से एक है।

अधिकांश संगठनों ने इसे किसी न किसी रूप में अपनाया है, लेकिन उनके गोद लेने के कार्यक्रमों की परिपक्वता में अभी भी एक लंबा रास्ता तय करना है। ट्यूटोरियल की इस श्रृंखला का एकमात्र उद्देश्य तकनीक और गैर-प्रौद्योगिकी पेशेवरों को एजाइल वर्ल्ड में ऑनबोर्ड करना है।

हम आपको चरणबद्ध तरीके से फुर्तीली यात्रा के माध्यम से ले जाएंगे, जब तक कि आप एजाइल का उपयोग करने के पीछे के दर्शन को नहीं समझते हैं, इसके फायदे और इसका अभ्यास कैसे करें। इस श्रृंखला का उद्देश्य पाठकों को अपने काम में एजाइल और स्क्रैम सीखने को लागू करने से लैस करना और सक्षम बनाना है।

यह विशेष ट्यूटोरियल आपको यह समझाने के लिए समर्पित है कि एजाइल की आवश्यकता क्यों थी और यह कैसे बना। यहां मौलिक रूप से आपको सॉफ्टवेयर डेवलपमेंट इंडस्ट्रीज में एजाइल एडॉप्शन की अवधारणा को समझना है।

चंचल का इतिहास

चुस्त तब पैदा हुआ जब एक ठीक दिन जब विभिन्न विकास विधियों की पृष्ठभूमि वाले 17 लोग, बुद्धिशीलता के साथ मिल गए अगर सॉफ्टवेयर विकास के लिए एक संभव वैकल्पिक समाधान था जो तेजी से विकास के समय को जन्म दे सकता था और कम प्रलेखन भारी था।

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

इस प्रकार विभिन्न सॉफ्टवेयर इंजीनियरिंग तकनीकों के ये चैंपियन एक साथ हो गए और उनकी बैठक का अंतिम परिणाम था, जिसे उन्होंने 'फुर्तीला घोषणापत्र' कहा, जिस पर हम इस श्रृंखला के अगले ट्यूटोरियल में विस्तार से चर्चा करेंगे।

लेकिन उस दिन पैदा हुआ फुर्तीला वह नहीं है जो आज हम संगठनों में देखते हैं। उन विशेषज्ञों ने जिस पद्धति पर सहमति व्यक्त की, उसे 'हल्का' और तेज बताया गया। लेकिन इस बैठक से मुख्य जीत यह सोचा गया था कि एक उत्पाद का तेजी से वितरण और निरंतर प्रतिक्रिया सॉफ्टवेयर विकास में सफलता प्राप्त करने की कुंजी थी।

मौजूदा जलप्रपात तकनीकें बहुत बोझिल थीं और अंतिम उत्पाद देने के लिए तैयार होने तक प्रतिक्रिया का कोई प्रावधान नहीं था। इसका मतलब यह था कि पाठ्यक्रम में सुधार की कोई गुंजाइश नहीं थी और ग्राहक के पास पूरे उत्पाद तैयार होने तक प्रगति पर कोई विचार नहीं था। और यही इन विशेषज्ञों से बचना चाहते थे।

वे एक ऐसा समाधान चाहते थे जिसमें बाद के चरण में पुनरावृत्ति की लागत से बचने के लिए निरंतर प्रतिक्रिया की गुंजाइश हो।

चंचल चुनौतियां

उस समय मौजूदा जलप्रपात तकनीकें बहुत बोझिल थीं और अंतिम उत्पाद देने के लिए तैयार होने तक प्रतिक्रिया का कोई प्रावधान नहीं था। इसे विकास का एक झरना मॉडल कहा जाता था क्योंकि टीमों ने पहले एक कदम पूरी तरह से समाप्त किया और उसके बाद ही वे अगले कदम पर आगे बढ़े।

इसका मतलब यह था कि पाठ्यक्रम में सुधार की कोई गुंजाइश नहीं थी और ग्राहक के पास पूरे उत्पाद तैयार होने तक प्रगति पर कोई विचार नहीं था। और यही इन विशेषज्ञों से बचना चाहते थे। वे एक ऐसा समाधान चाहते थे जिसमें बाद के चरण में पुनरावृत्ति की लागत से बचने के लिए निरंतर प्रतिक्रिया की गुंजाइश हो।

और यही कारण है कि फुर्तीली भी अनुकूली और निरंतर सुधार के बारे में है, जितना कि यह निरंतर प्रतिक्रिया और प्रसव की गति के बारे में है।

चंचल वादे क्या हैं?

चंचल वचन

एजाइल केवल विकासशील सॉफ्टवेयर में सेट प्रथाओं को लागू करने के बारे में नहीं है। यह टीम की मानसिकता में भी बदलाव लाता है जो उन्हें बेहतर सॉफ्टवेयर बनाने, एक साथ काम करने और अंततः उन्हें एक खुश ग्राहक बनाने की दिशा में ले जाता है।

फुर्तीली मूल्य और सिद्धांत टीम को अपना ध्यान केंद्रित करने और बेहतर सॉफ्टवेयर बनाने की अपनी विचार प्रक्रिया को बदलने में सक्षम बनाते हैं।

वास्तव में फुर्तीली क्या है?

चंचल नियमों का एक सेट नहीं है। चपल दिशा निर्देशों का एक सेट नहीं है। चंचलता भी कोई पद्धति नहीं है। बल्कि, एजाइल सिद्धांतों का एक समूह है जो योजनाओं और प्रक्रियाओं पर लचीलापन, अनुकूलनशीलता, संचार और काम करने वाले सॉफ़्टवेयर को प्रोत्साहित करता है। यह बहुत ही सहज रूप से कब्जा कर लिया है जिसे चुस्त घोषणापत्र कहा जाता है।

चुस्त सॉफ्टवेयर विकास टीम को जटिल परियोजनाओं के विकास में अधिक कुशलतापूर्वक और प्रभावी ढंग से एक साथ काम करने की अनुमति देता है। इसमें ऐसे अभ्यास शामिल हैं जो पुनरावृत्त और वृद्धिशील तकनीकों का उपयोग करते हैं जो आसानी से अपनाए जाते हैं और शानदार परिणाम प्रदर्शित करते हैं।

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

इतना ही नहीं, चुस्त तरीके और तरीके भी प्रत्येक प्रसव के अभिन्न अंग के रूप में प्रक्रिया में सुधार की गुंजाइश खोलते हैं।

एजाइल एक सॉफ्टवेयर विकास दृष्टिकोण है जहां एक आत्मनिर्भर और क्रॉस-फंक्शनल टीम पुनरावृत्तियों के माध्यम से निरंतर वितरण करने पर काम करती है और अंतिम उपयोगकर्ताओं से प्रतिक्रिया एकत्र करके पूरी प्रक्रिया में विकसित होती है।

चंचलता का अभ्यास कैसे करें?

विभिन्न चुस्त तरीके हैं जो विभिन्न विविध उद्योगों में व्यवहार में हैं।

चुस्त तरीके

हालांकि, उन सभी के बीच सबसे लोकप्रिय तरीके हैं:

जमघट
Kanban
चरम कार्यक्रम

ये सभी पद्धतियाँ दुबले सॉफ्टवेयर विकास पर ध्यान केंद्रित करती हैं और प्रभावी रूप से और कुशलता से बेहतर सॉफ्टवेयर बनाने में मदद करती हैं।

यह सब एजाइल परिचय के साथ है। यह हिस्सा आपको उन मुख्य मूल्यों और सिद्धांतों को समझने में मदद करने के लिए संरचित है, जिन्हें एक एजाइल मोड और मानसिकता में काम करने वाली टीम के लिए अपनाया जाएगा।

चुस्त क्रियाविधि

चंचल मॉडल का परिचय:

चंचल कार्यप्रणाली

इंटरनेट अनुप्रयोगों के उदाहरण

जैसा कि हम सभी जानते हैं कि एजाइल एक सॉफ्टवेयर डेवलपमेंट पद्धति है।

हमने उन मूल्यों और सिद्धांतों के बारे में भी सीखा है जिनका उल्लेख फुर्तीले के संस्थापकों द्वारा फुर्तीले घोषणापत्र में किया गया था। अपनी शुरुआती चर्चाओं में, हमने फुर्तीले और पारंपरिक झरने के मॉडल के बीच अंतर पर भी ध्यान दिया।

इस ट्यूटोरियल में, हम चुस्त कार्यप्रणाली के फायदे और नुकसान के बारे में जानेंगे।

हम देखेंगे कि क्या घोटाला है? और यह चुस्त से कैसे अलग है। फिर हम विभिन्न चुस्त कार्यप्रणाली को समझेंगे, जिनका उपयोग विभिन्न संगठनों द्वारा किया जा रहा है और हम उनका उपयोग करके चुस्त कैसे लागू कर सकते हैं।

आप इन पद्धतियों के अंतर / फायदे और नुकसान की भी सराहना कर पाएंगे।

फुर्तीली कार्यप्रणाली के लाभ

नीचे दिए गए चंचल कार्यप्रणाली के विभिन्न फायदे हैं:

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

चंचल कार्यप्रणाली का नुकसान

हालांकि एजाइल कार्यप्रणाली के कई फायदे हैं, लेकिन इसमें कुछ नुकसान भी शामिल हैं।

वे:

# 1) व्यापक दस्तावेज़ीकरण को प्राथमिकता नहीं दी जाती है, जो चुस्त टीमों को गलत तरीके से व्याख्या कर सकती है क्योंकि चुस्त दस्तावेज़ की आवश्यकता नहीं है। तो प्रलेखन पर कठोरता खो जाती है। आगे बढ़ने के लिए पर्याप्त जानकारी है या नहीं, यह पूछकर खुद से लगातार बचना चाहिए।

#दो) कभी-कभी, परियोजनाओं की शुरुआत में, आवश्यकताएं स्पष्ट नहीं होती हैं। टीमें आगे बढ़ सकती हैं और पा सकती हैं कि ग्राहकों का दृष्टिकोण फिर से विकसित हो गया है और ऐसी स्थितियों में, टीमों को कई बदलावों को शामिल करने की आवश्यकता है और अंतिम परिणाम को भी समझना मुश्किल है।

चुस्त तरीके के प्रकार

दुनिया भर में कई चुस्त कार्यप्रणाली हैं। हम चार सबसे लोकप्रिय लोगों के बारे में विस्तार से जानने जा रहे हैं।

चुस्त तरीके

(1) स्क्रेम

स्क्रम को आसानी से सबसे लोकप्रिय चुस्त ढांचा माना जा सकता है। अधिकांश चिकित्सकों द्वारा 'फुर्तीले' शब्द को 'फुर्तीले' का पर्याय माना जाता है। लेकिन वह एक गलत धारणा है। स्क्रम केवल उन रूपरेखाओं में से एक है, जिनके द्वारा आप चुस्तता को लागू कर सकते हैं।

स्क्रैम शब्द स्पोर्ट्स रग्बी से आया है। जहां खिलाड़ी परस्पर विरोधी स्थिति में विरोधियों को धकेलते हुए आपस में भिड़ जाते हैं। प्रत्येक खिलाड़ी की अपनी स्थिति में एक परिभाषित भूमिका होती है और स्थिति की मांग के अनुसार आक्रामक और रक्षात्मक दोनों खेल सकते हैं।

इसी तरह, आईटी में घोटाले को तीन विशिष्ट और स्पष्ट रूप से परिभाषित भूमिकाओं के साथ सशक्त स्व-प्रबंधित विकास टीमों में विश्वास है। इन भूमिकाओं में शामिल हैं - उत्पाद स्वामी (पीओ), स्क्रम मास्टर (एसएम) और विकास टीम जिसमें प्रोग्रामर और परीक्षक शामिल हैं । वे स्प्रिंट नामक पुनरावृति समय बॉक्सिंग अवधि में एक साथ काम करते हैं।

पहला कदम पीओ द्वारा उत्पाद बैकलॉग का निर्माण है। यह स्क्रम टीम द्वारा किए जाने वाले सामान की एक टू-डू सूची है। फिर स्क्रैम टीम शीर्ष प्राथमिकता वाले आइटम का चयन करती है और स्प्रिंट नामक टाइम बॉक्स के भीतर उन्हें खत्म करने की कोशिश करती है।

इस सब को याद रखने का एक आसान तरीका 3-3-5 की रूपरेखा को याद करना है। इसका मतलब है कि एक स्क्रैम प्रोजेक्ट में 3 भूमिकाएं, 3 कलाकृतियां और 5 इवेंट हैं।

ये -

भूमिकाएँ: पीओ, स्क्रम मास्टर और विकास टीम।

कलाकृतियाँ: उत्पाद बैकलॉग, स्प्रिंट बैकलॉगतथाउत्पाद वृद्धि।

आयोजन: स्प्रिंट, स्प्रिंट योजना, दैनिक स्क्रैम, स्प्रिंट समीक्षा और स्प्रिंट पूर्वव्यापी।

3-3-5 की रूपरेखा

हम अपने बाद के ट्यूटोरियल में इनमें से प्रत्येक के बारे में विस्तार से जानेंगे।

# 2) कानबन

कानबन एक जापानी शब्द है जिसका अर्थ है एक कार्ड। इन कार्डों में सॉफ्टवेयर पर किए जाने वाले कार्य का विवरण होता है। उद्देश्य दृश्य है। टीम के प्रत्येक सदस्य को इन दृश्य एड्स के माध्यम से किए जाने वाले कार्य के बारे में पता है।

टीमें निरंतर वितरण के लिए इन कानबन कार्डों का उपयोग करती हैं। स्क्रम की तरह, कानाबन भी टीमों को प्रभावी ढंग से काम करने में मदद करने के लिए है और स्व-प्रबंधित और सहयोगी टीमों को बढ़ावा देता है।

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

इसी तरह, एक और अंतर यह है कि जबकि स्क्रैम ने पीओ, स्क्रैम मास्टर और विकास टीमों की भूमिकाएं परिभाषित की हैं, कानन में ऐसी कोई पूर्व-निर्धारित भूमिकाएं नहीं हैं।

एक और अंतर यह है कि जबकि स्क्रैम उत्पाद बैकलॉग के एक प्राथमिकता का सुझाव देता है, कानबन को ऐसी कोई आवश्यकता नहीं है और यह पूरी तरह से वैकल्पिक है। इस प्रकार कंबन को कम संगठन की आवश्यकता होती है और गैर-मूल्य वर्धित गतिविधियों से बचा जाता है और उन प्रक्रियाओं के लिए उपयुक्त है जिनके लिए परिवर्तनों के लिए जवाबदेही की आवश्यकता होती है।

# 3) झुक जाओ

झुक एक दर्शन है जो कचरे को कम करने पर केंद्रित है। इससे ऐसा कैसे होता है?

दुबले में, आप एक प्रक्रिया को मूल्य-वर्धक गतिविधियों, गैर-मूल्य जोड़ने की गतिविधियों और आवश्यक गैर-मूल्य जोड़ने की गतिविधियों में विभाजित करते हैं। कोई भी गतिविधि जिसे गैर-मूल्य वर्धित गतिविधि के रूप में वर्गीकृत किया जा सकता है, एक बेकार है और हमें इसे दुबला बनाने के लिए प्रक्रिया में उस अपव्यय को दूर करने का प्रयास करना चाहिए।

एक लीनियर प्रक्रिया का अर्थ है तेजी से वितरण और उन कार्यों में कम प्रयास जो टीम के लक्ष्यों को प्राप्त करने में मदद नहीं करते हैं। यह सॉफ्टवेयर विकास चक्र में हर कदम को अनुकूलित करने में मदद करता है। यही कारण है कि दुबला सिद्धांतों को दुबला विनिर्माण से सॉफ्टवेयर विकास में बदल दिया गया था।

सात दुबले सिद्धांतों को लागू करके किसी भी आईटी परियोजना में लीन सॉफ्टवेयर विकास का उपयोग किया जा सकता है:

सात दुबले सिद्धांत

जैसा कि उनके नाम से पता चलता है ये काफी आत्म-व्याख्यात्मक हैं। अपव्यय को खत्म करना पहला और सबसे महत्वपूर्ण दुबला सिद्धांत है और हमने देखा कि ऐसा कैसे करना है, हम सिर्फ मूल्य और गैर-मूल्य के रूप में गतिविधियों को वर्गीकृत करते हैं।

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

शिक्षण को प्रवर्तित करने वाला दूसरा सिद्धांत फिर से समझना आसान है क्योंकि एक टीम को तेजी से बदलते परिवेश में उत्पादों को वितरित करने के लिए विभिन्न कौशल की आवश्यकता होती है, जिससे नई तकनीकें त्वरित अवधि में तैयार होती हैं।

देर से निर्णय लेने से उन परिस्थितियों में पुरस्कृत किया जा सकता है जहां यह फिर से काम करता है जैसे कि यदि कोई बदलाव अपेक्षित है, तो इसमें बेहतर देरी हो सकती है ताकि टीम को काम फिर से न करना पड़े क्योंकि व्यवसाय को बदलाव की आवश्यकता है।

लेकिन यहां हमेशा एक व्यापार बंद रहता है क्योंकि टीमों को तेजी से वितरित करने के चौथे सिद्धांत के साथ इसे संतुलित करने की आवश्यकता होती है। निर्णयों में देरी से समग्र वितरण प्रभावित नहीं होना चाहिए और काम की गति कम नहीं होनी चाहिए। एक आंख हमेशा पूरी तस्वीर पर होनी चाहिए।

सशक्त टीमों का होना भी आजकल बहुत आम है और यह एक ऐसी चीज है जो फुर्तीली भी है। सशक्त टीमें अधिक जिम्मेदार हैं और तेजी से फैसले ले सकती हैं। एक सशक्त टीम में स्वामित्व की भावना बेहतर परिणाम की ओर ले जाती है। एक टीम को सशक्त बनाने के लिए, उन्हें खुद को व्यवस्थित करने और अपने दम पर निर्णय लेने की अनुमति दी जानी चाहिए।

इस प्रकार हम देखते हैं कि दुबला और फुर्तीले में बहुत अंतर होता है, जबकि दुबली टीमें किसी उत्पाद को निखारने में मदद कर सकती हैं, फुर्तीली टीमें वे हैं जो वास्तव में उत्पाद का निर्माण करती हैं।

# 4) एक्सट्रीम प्रोग्रामिंग (XP)

चरम प्रोग्रामिंग एक और सबसे लोकप्रिय चुस्त तकनीक है। Extremeprogramming.org के अनुसार, पहला XP प्रोजेक्ट 6 मार्च 1996 को शुरू किया गया था। उन्होंने यह भी उल्लेख किया है कि XP सॉफ्टवेयर प्रोजेक्ट के विकास को 5 अलग-अलग तरीकों से प्रभावित करता है - संचार, सादगी, प्रतिक्रिया, सम्मान और साहस। इन्हें XP के मान कहा जाता है।

इनमें से, यह सभी संचार के साथ शुरू होता है। XP टीमें नियमित आधार पर व्यावसायिक टीमों और साथी प्रोग्रामरों के साथ सहयोग करती हैं और पहले दिन से ही कोड बनाना शुरू कर देती हैं। यहाँ पर ध्यान अन्य फेस एड्स की मदद से जहाँ तक संभव हो संचार का सामना करने पर है।

चरम प्रोग्रामर भी एक सरल कोड बनाते हैं और पहले दिन से ही उस पर प्रतिक्रिया प्राप्त करना शुरू कर देते हैं। फोकस ओवरबोर्ड नहीं जाने या आवश्यकताओं की भविष्यवाणी करने पर नहीं है जिन्हें साझा नहीं किया गया है। यह डिजाइन को सरल रखता है और केवल न्यूनतम उत्पाद तैयार करता है जो आवश्यकताओं की पूर्ति करेगा।

फीडबैक से टीम को बेहतर गुणवत्ता और बेहतर कार्य करने में मदद मिलती है। इससे उन्हें एक-दूसरे के लिए सम्मान पैदा करने में मदद मिलती है क्योंकि वे एक-दूसरे से सीखते हैं और अपने विचारों को साझा करना सीखते हैं।

इससे उन्हें भी हिम्मत मिलती है क्योंकि वे जानते हैं कि उन्होंने सभी के सर्वश्रेष्ठ विचारों को एकत्र किया है और दूसरों से प्रतिक्रिया लेकर एक अच्छा उत्पाद तैयार किया है। इस प्रकार वे परिवर्तन को शामिल करने या अपने काम पर आगे की प्रतिक्रिया प्राप्त करने से डरते नहीं हैं।

यह उन परियोजनाओं में विशेष रूप से उपयोगी है जहां आवश्यकताएं अक्सर बदलने जा रही हैं। लगातार प्रतिक्रिया साहस के साथ इन परिवर्तनों को शामिल करने में टीमों की मदद करेगी।

इस प्रकार हमने अलग-अलग चुस्त कार्यप्रणालियों जैसे स्क्रैम, एक्सपी, कानबन और लीन को अपने-अपने फायदे और नुकसान के साथ देखा है।

अब, हम आसानी से उनके बीच अंतर कर सकते हैं और उनके बीच के उप-अंतर को भी सराह सकते हैं। हमने इन पद्धतियों में से प्रत्येक के मूल सिद्धांतों को भी सीखा और देखा कि उन्हें अपनी परियोजनाओं में कैसे और कब आवश्यकता के रूप में लागू किया जाए।

अगले भाग में, Scrum के बारे में सब कुछ समझ लेते हैं।

स्क्रम पद्धति

SCRUM फुर्तीली कार्यप्रणाली में एक प्रक्रिया है जो Iterative मॉडल और वृद्धिशील मॉडल का एक संयोजन है।

पारंपरिक में से एक प्रमुख बाधा झरना मॉडल वह था - जब तक कि पहला चरण पूरा नहीं हो जाता है, तब तक आवेदन दूसरे चरण में नहीं जाता है। और संयोग से, यदि चक्र के बाद के चरण में कुछ बदलाव हैं, तो उन परिवर्तनों को लागू करना बहुत चुनौतीपूर्ण हो जाता है, क्योंकि इसमें पहले के चरणों को फिर से शामिल करना और परिवर्तनों को फिर से लाना शामिल है।

फुर्तीली जांच

SCRUM की कुछ प्रमुख विशेषताओं में शामिल हैं:

स्व-संगठित और केंद्रित टीम।
कोई विशाल आवश्यकता दस्तावेज़ नहीं, बल्कि बहुत सटीक और बिंदु कहानियों के लिए है।
क्रॉस-फ़ंक्शनल टीमें एक एकल इकाई के रूप में एक साथ काम करती हैं।
सुविधाओं को समझने के लिए उपयोगकर्ता प्रतिनिधि के साथ निकट संचार।
अधिकतम एक महीने की निश्चित समयावधि है।
एक बार में पूरी 'बात' करने के बजाय, स्क्रैम एक निश्चित अंतराल पर सब कुछ करता है।
कुछ भी करने से पहले संसाधन क्षमता और उपलब्धता पर विचार किया जाता है।

इस पद्धति को अच्छी तरह से समझने के लिए, SCRUM में प्रमुख शब्दावली को समझना महत्वपूर्ण है।

यह भी पढ़ें => चुस्त समय प्रक्रिया का उपयोग करके कम समय की अवधि में उच्च-मूल्य वाले सॉफ़्टवेयर सुविधाओं को कैसे वितरित करें

महत्वपूर्ण SCRUM शब्दावली

1) स्क्रम टीम

स्क्रैम टीम एक टीम है जिसमें 7 + या - दो सदस्यों के साथ होती है। ये सदस्य दक्षताओं का मिश्रण होते हैं और इसमें उत्पाद के मालिक और एक शानदार मास्टर के साथ-साथ डेवलपर्स, परीक्षक, डेटाबेस के लोग, सहायक लोग आदि शामिल होते हैं।

ये सभी सदस्य उक्त विशेषताओं को विकसित और कार्यान्वित करने के लिए पुनरावर्ती और निश्चित अंतराल के लिए घनिष्ठ सहयोग में एक साथ काम करते हैं। SCRUM टीम के बैठने की व्यवस्था उनकी सहभागिता में बहुत महत्वपूर्ण भूमिका निभाती है, वे कभी भी क्यूबिकल या केबिन में नहीं बैठती हैं, बल्कि एक विशाल टेबल होती हैं।

स्क्रम टीम

2) स्प्रिंट

स्प्रिंट एक पूर्वनिर्धारित अंतराल या समय सीमा है जिसमें कार्य पूरा किया जाना है और इसे समीक्षा के लिए तैयार करना है या उत्पादन परिनियोजन के लिए तैयार करना है। यह समय बॉक्स आमतौर पर 2 सप्ताह से 1 महीने के बीच होता है।

कहाँ वाईफ़ाई के लिए नेटवर्क सुरक्षा कुंजी खोजने के लिए

हमारे दैनिक जीवन में जब हम कहते हैं कि हम 1 महीने के स्प्रिंट चक्र का पालन करते हैं, तो इसका सीधा सा मतलब है कि हम एक महीने के लिए काम करते हैं और उस महीने के अंत तक समीक्षा के लिए तैयार हो जाते हैं।

3) उत्पाद स्वामी

उत्पाद स्वामी प्रमुख हितधारक या विकसित किए जाने वाले एप्लिकेशन का प्रमुख उपयोगकर्ता है। उत्पाद स्वामी वह व्यक्ति है जो ग्राहक पक्ष का प्रतिनिधित्व करता है। उसके पास अंतिम अधिकार है और उसे हमेशा टीम के लिए उपलब्ध रहना चाहिए।

जब किसी को कोई संदेह हो तो उसे स्पष्टीकरण देने की आवश्यकता होती है। उत्पाद स्वामी को स्प्रिंट के मध्य में या स्प्रिंट के शुरू होने पर किसी भी नई आवश्यकता को समझने और न बताने के लिए महत्वपूर्ण है।

4) स्क्रेम मास्टर

Scrum Master, scrum टीम का सूत्रधार है। वह / वह सुनिश्चित करता है कि स्क्रैम टीम उत्पादक और प्रगतिशील है। किसी भी बाधा के मामले में, स्क्रैम मास्टर का अनुसरण करता है और टीम के लिए उन्हें हल करता है। SCRUM मास्टर PO और टीम के बीच मध्यस्थ है।

वह स्प्रिंट की प्रगति के बारे में पीओ को सूचित करता है। यदि टीम के लिए कोई बाधा या चिंता है, तो पीओ के साथ चर्चा करें और उन्हें हल किया जाए। टीम के डेली स्टैंडअप की तरह, PO के साथ SCRUM मास्टर का एक स्टैंडअप हर दिन होता है।

अनुशंसित पढ़ा => चुस्त टीम वर्ल्ड में एक अच्छी टीम मेंटर, कोच और एक सच्चे टीम-डिफेंडर कैसे बनें?

5) व्यापार विश्लेषक (बीए)

SCRUM में एक बिजनेस एनालिस्ट बहुत महत्वपूर्ण भूमिका निभाता है। यह व्यक्ति आवश्यकता डॉक्स को अंतिम रूप देने और प्रारूपित करने के लिए ज़िम्मेदार है (जिसके आधार पर उपयोगकर्ता कहानियां बनाई जाती हैं)।

यदि उपयोगकर्ता की कहानियों / स्वीकार्यता मानदंडों में कोई अस्पष्टता है, तो वह / वह है जो तकनीकी (SCRUM) टीम द्वारा संपर्क किया जाता है और वह तब पीओ पर ले जाता है या यदि संभव हो तो अपने दम पर हल करता है। बड़े पैमाने पर परियोजनाओं में, 1 से अधिक बीए हो सकते हैं, लेकिन छोटे पैमाने पर परियोजनाओं में, एससीआरयूएमएम मास्टर बीए के रूप में भी काम कर सकता है।

प्रोजेक्ट किक शुरू होने पर बीए करना हमेशा एक अच्छा अभ्यास है।

6) उपयोगकर्ता कहानी

उपयोगकर्ता कहानियां कुछ भी नहीं हैं लेकिन आवश्यकताओं या विशेषता को लागू करना होगा।

इस घोटाले में, हमारे पास उन विशाल आवश्यकताओं के दस्तावेज नहीं हैं, बल्कि आवश्यकताओं को एक ही पैराग्राफ में परिभाषित किया गया है, आमतौर पर प्रारूप निम्नानुसार है:

के तौर पर
मैं चाहता हूं
प्राप्त करने के लिए

उदाहरण के लिए :

एक व्यवस्थापक के रूप में मैं एक पासवर्ड लॉक रखना चाहता हूं यदि उपयोगकर्ता अनधिकृत पहुंच को प्रतिबंधित करने के लिए लगातार 3 बार गलत पासवर्ड दर्ज करता है।

उपयोगकर्ता कहानियों की कुछ विशेषताएं हैं जिनका पालन किया जाना चाहिए। उपयोगकर्ता की कहानियां संक्षिप्त, यथार्थवादी होनी चाहिए, अनुमानित, पूर्ण, परक्राम्य और परीक्षण योग्य हो सकती हैं। स्प्रिंट के बीच में एक उपयोगकर्ता की कहानी कभी नहीं बदली जाती है या बदल जाती है।

यह सुनिश्चित करने के लिए SCRUM मास्टर और BA (यदि लागू हो) की जिम्मेदारी है कि PO ने स्वीकृत मापदंड के समुचित सेट के साथ उपयोगकर्ता कहानियों को सही ढंग से तैयार किया है। यदि स्प्रिंट रिलीज को प्रभावित करने वाले कोई भी बदलाव किए जाने हैं, तो ऐसी कहानियों को स्प्रिंट से बाहर निकाला जाता है या वे उपलब्ध घंटों के अनुसार किया जाता है।

प्रत्येक उपयोगकर्ता कहानी में एक स्वीकृति मानदंड होता है जिसे टीम द्वारा अच्छी तरह से परिभाषित और समझा जाना चाहिए।

स्वीकृति मानदंड उस उपयोगकर्ता कहानी का विवरण देते हैं जो सहायक दस्तावेज प्रदान करती हैं। यह उपयोगकर्ता की कहानी को और निखारने में मदद करता है। टीम से कोई भी स्वीकृति मानदंड लिख सकता है। परीक्षण टीम इन स्वीकृति मानदंडों पर उनके परीक्षण मामलों / शर्तों को आधार बनाती है।

7) महाकाव्य

महाकाव्य समान उपयोगकर्ता कहानियां हैं या हम कह सकते हैं कि ये उपयोगकर्ता कहानियां हैं जो परिभाषित नहीं हैं और भविष्य के स्प्रिंट के लिए रखी गई हैं।

बस इसे जीवन से संबंधित करने की कोशिश करें, कल्पना करें कि आप छुट्टी के लिए जा रहे हैं। जैसा कि आप अगले सप्ताह जा रहे हैं, आपके पास अपनी होटल बुकिंग, दर्शनीय स्थलों की यात्रा, यात्रियों की जांच आदि जैसी हर चीज मौजूद है, लेकिन अगले साल आपकी छुट्टियों की योजना के बारे में क्या? आपके पास केवल एक अस्पष्ट विचार है कि आप XYZ जगह पर जा सकते हैं, लेकिन आपके पास कोई विस्तृत योजना नहीं है।

अगले साल की छुट्टियों की योजना की तरह एक एपिक भी है, जहां आप सिर्फ यह जानते हैं कि आप जाना चाहते हैं, लेकिन कहां, कब, किसके साथ, इन सभी विवरणों का आपको इस समय कोई पता नहीं है।

इसी तरह से, ऐसी विशेषताएं हैं जिन्हें भविष्य में लागू किया जाना आवश्यक है जिनके विवरण अभी तक ज्ञात नहीं हैं। अधिकतर एक फीचर एपिक से शुरू होता है और फिर उन कहानियों को तोड़ दिया जाता है जिन्हें लागू किया जा सकता था।

8) उत्पाद बैकलॉग

उत्पाद बैकलॉग एक प्रकार की बाल्टी या स्रोत है जहां सभी उपयोगकर्ता कहानियां रखी जाती हैं। यह उत्पाद स्वामी द्वारा बनाए रखा जाता है। उत्पाद बैकलॉग को उत्पाद के मालिक की इच्छा सूची के रूप में कल्पना की जा सकती है जो इसे व्यवसाय की जरूरतों के अनुसार प्राथमिकता देता है।

नियोजन बैठक (अगले भाग देखें) के दौरान, एक उपयोगकर्ता कहानी को उत्पाद बैकलॉग से लिया जाता है, फिर टीम विचार-मंथन करती है, इसे समझती है और इसे परिष्कृत करती है और सामूहिक रूप से निर्णय लेती है कि उत्पाद स्वामी के हस्तक्षेप के साथ कौन सी उपयोगकर्ता कहानियों को लेना है।

9) स्प्रिंट बैकलॉग

प्राथमिकता के आधार पर, उपयोगकर्ता कहानियां एक समय में उत्पाद बैकलॉग से ली जाती हैं। स्क्रम टीम ने इस पर मंथन किया और व्यवहार्यता को निर्धारित किया और एक विशेष स्प्रिंट पर काम करने के लिए कहानियों पर निर्णय लिया। उन सभी उपयोगकर्ता कहानियों की सामूहिक सूची जो एक विशेष स्प्रिंट पर काम करती है, स्प्रिंट बैकलॉग के रूप में जानी जाती है।

स्प्रिंट बैकलॉग

१०) कहानी के अंक

कहानी अंक एक उपयोगकर्ता कहानी की जटिलता का एक मात्रात्मक संकेत है। कहानी बिंदु के आधार पर, कहानी के लिए अनुमान और प्रयास निर्धारित किए जाते हैं।

एक कहानी बिंदु सापेक्ष है और निरपेक्ष नहीं है। यह सुनिश्चित करने के लिए कि हमारा अनुमान और प्रयास सही हैं, यह जांचना महत्वपूर्ण है कि उपयोगकर्ता कहानियां बड़ी नहीं हैं। उपयोगकर्ता कहानी जितनी सटीक और छोटी होगी, अनुमान उतना ही सटीक होगा।

प्रत्येक और हर उपयोगकर्ता की कहानी फिबोनाची श्रृंखला (1, 2, 3, 5, 8, 13 और 21) के आधार पर एक कहानी बिंदु को सौंपी जाती है। उच्चतर संख्या है, जटिल कहानी है।

सटीक होना

यदि आप 1/2/3 स्टोरी पॉइंट देते हैं तो इसका मतलब है कि कहानी छोटी और कम जटिलता की है।
यदि आप 5/8 के रूप में अंक देते हैं, तो यह एक मध्यम जटिल है और
13 और 21 अत्यधिक जटिल हैं।

यहां जटिलता में विकास और परीक्षण दोनों के प्रयास शामिल हैं।

एक कहानी बिंदु तय करने के लिए, मंथन टीम के भीतर विचार-मंथन होता है और टीम सामूहिक रूप से एक कहानी बिंदु तय करती है।

ऐसा हो सकता है कि विकास टीम किसी विशेष कहानी को 3 का कहानी बिंदु देती है, क्योंकि उनके लिए यह कोड परिवर्तन की 3 पंक्तियाँ हो सकती हैं, लेकिन परीक्षण टीम 8 कहानी बिंदु देती है क्योंकि उन्हें लगता है कि यह कोड परिवर्तन बड़े मॉड्यूल को प्रभावित करेगा परीक्षण का प्रयास बड़ा होगा। आप जो भी स्टोरी प्वाइंट दे रहे हैं, आपको उसे सही ठहराना है।

तो इस स्थिति में, बुद्धिशीलता होती है और टीम सामूहिक रूप से एक कहानी बिंदु पर सहमत होती है।

जब भी आप एक कहानी बिंदु पर निर्णय ले रहे हों, तो नीचे के कारकों को ध्यान में रखें:

अन्य एप्लिकेशन / मॉड्यूल के साथ कहानी की निर्भरता।
संसाधन का कौशल-सेट।
कहानी की जटिलता।
ऐतिहासिक शिक्षा।
उपयोगकर्ता कहानी की स्वीकृति मानदंड।

यदि आपको किसी विशेष कहानी की जानकारी नहीं है, तो उसे आकार न दें।

जब भी कोई कहानी = या> 8 अंक होती है, तो उसे 2 या अधिक कहानियों में तोड़ दिया जाता है।

11) नीचे चार्ट जलाएं

बर्न डाउन चार्ट एक ग्राफ है जो स्क्रैम कार्यों के अनुमानित v / s वास्तविक प्रयास को दर्शाता है।

यह एक ट्रैकिंग तंत्र है जिसके द्वारा किसी विशेष स्प्रिंट के लिए दिन के कार्यों को जांचने के लिए ट्रैक किया जाता है कि क्या कहानियां प्रतिबद्ध स्टोरी पॉइंट को पूरा करने की दिशा में आगे बढ़ रही हैं या नहीं।

उदाहरण : इसे समझने के लिए, नीचे दिया गया आंकड़ा देखें:

चार्ट 1 जलाएं

मैंने मान लिया है:

2 सप्ताह स्प्रिंट (10 दिन)
स्प्रिंट पर काम करने वाले 2 संसाधन वास्तविक।

'कहानी' -> यह कॉलम स्प्रिंट के लिए ली गई उपयोगकर्ता कहानियों को दर्शाता है।

'कार्य' -> यह कॉलम उपयोगकर्ता की कहानी से जुड़े कार्य की सूची दिखाता है।

'प्रयास है' -> यह कॉलम प्रयास दिखाता है। अब, यह उपाय कार्य को पूरा करने का कुल प्रयास है। यह किसी विशिष्ट व्यक्ति द्वारा किए गए प्रयास का चित्रण नहीं करता है।

'दिन 1 - दिन 10' -> यह कॉलम उन घंटों को दिखाता है जो कहानी को पूरा करने के लिए बचे हैं। कृपया देखें कि घंटा वह घंटा नहीं है जो पहले ही किया जा चुका है लेकिन अब भी कुछ घंटे बाकी हैं।

'अनुमानित प्रयास' -> कुल प्रयास है। 'प्रारंभ' के लिए यह संपूर्ण व्यक्तिगत कार्य का योग है: SUM (C5: C15)

1 दिन में पूरा करने के लिए किए जाने वाले प्रयासों की कुल संख्या 70/10 = 7. है, इसलिए दिन 1 के अंत में, प्रयास 70 - 7 = 63 तक कम हो जाना चाहिए। इसी तरह, यह सभी के लिए गणना की जाती है। दिन 10 तक, जब अनुमानित प्रयास 0 (पंक्ति 16) होना चाहिए

'वास्तविक प्रयास वाम' -> जैसा कि नाम से पता चलता है, क्या यह प्रयास वास्तव में कहानी को पूरा करने के लिए बचा है। यह भी हो सकता है कि अनुमानित प्रयासों की तुलना में वास्तविक प्रयास बढ़ता या घटता है।

इस इनडाउनडाउन चार्ट को बनाने के लिए आप एक्सेल में इनबिल्ट फंक्शन और चार्ट का उपयोग कर सकते हैं।

बर्न डाउन चार्ट चरण होंगे:

सभी कहानियां दर्ज करें (कॉलम A5 - A15)।
सभी कार्य (कॉलम B5 - B15) दर्ज करें।
दिन (दिन 1 - दिन 10) दर्ज करें।
शुरुआती प्रयास दर्ज करें (कार्य C5 - C15 को योग करें)।
प्रत्येक दिन (दिन 1 से दिन 10) के लिए 'अनुमानित प्रयासों' की गणना करने के लिए सूत्र लागू करें। D15 (C16- $ C $ 16/10) पर सूत्र दर्ज करें और इसे सभी दिनों के लिए खींचें।
प्रत्येक दिन के लिए, वास्तविक प्रयासों में प्रवेश करें। D17 (SUM (D5: D15)) पर सूत्र को छोड़िए वास्तविक प्रयासों को संक्षेप में लिखें, और इसे अन्य सभी दिनों के लिए खींचें।
इसे चुनें और निम्नानुसार चार्ट बनाएं:

चार्ट 2 जलाएं

१२) वेग

कहानी बिंदु की कुल संख्या जो एक स्प्रिंट टीम एक स्प्रिंट में संग्रहीत करती है, वेग कहलाती है। स्क्रम टीम को उसके वेग से आंका या संदर्भित किया जाता है। यह कहने के बाद, यह ध्यान में रखा जाना चाहिए कि यहाँ उद्देश्य अधिकतम कहानी बिंदुओं को प्राप्त नहीं कर रहा है, बल्कि एक गुणवत्ता प्रदान करने योग्य है, जो कि स्क्रैम टीम के आराम स्तर का सम्मान करता है।

उदाहरण के लिए : एक विशेष स्प्रिंट के लिए: उपयोगकर्ता कहानियों की कुल संख्या 8 कहानी वाले बिंदु हैं जैसा कि नीचे दिखाया गया है।

स्क्रैम वेलोसिटी

तो यहाँ वेग कहानी के अंक = 30 का योग होगा

संपन्न की परिभाषा:

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

क्रियाएँ SCRUM पद्धति में संपन्न हुईं

(१) योजना बैठक

एक योजना बैठक स्प्रिंट का प्रारंभिक बिंदु है। यह वह बैठक है जहां पूरी स्क्रैम टीम एकत्र होती है, SCRUM मास्टर उत्पाद बैकलॉग की प्राथमिकता के आधार पर एक उपयोगकर्ता कहानी का चयन करता है और टीम इस पर विचार-विमर्श करती है।

चर्चा के आधार पर, स्क्रैम टीम कहानी की जटिलता को तय करती है और इसे फिबोनाची श्रृंखला के अनुसार आकार देती है। टीम प्रयासों (घंटों में) के साथ कार्यों की पहचान करती है जो उपयोगकर्ता कहानी के कार्यान्वयन को पूरा करने के लिए किया जाएगा।

कई बार, योजना बैठक 'पूर्व-योजना बैठक' से पहले होती है। यह औपचारिक काम पूरा करने के लिए बैठने से पहले होमवर्क जैसा ही होता है, जो scrum टीम करती है। टीम निर्भरता या अन्य कारकों को लिखने की कोशिश करती है, जिन पर वे योजना बैठक में चर्चा करना चाहते हैं।

# 2) स्प्रिंट कार्य का निष्पादन

जैसा कि नाम से पता चलता है, ये वास्तविक टीम द्वारा अपने कार्य को पूरा करने और उपयोगकर्ता कहानी को 'पूर्ण' स्थिति में ले जाने के लिए किया जाता है।

# 3) डेली स्टैंडअप

स्प्रिंट चक्र के दौरान, हर दिन स्क्रम टीम मिलती है, 15 मिनट से अधिक नहीं (एक स्टैंड-अप कॉल हो सकती है, दिन की शुरुआत के दौरान अनुशंसित है) और राज्य 3 अंक:

टीम के सदस्य ने कल क्या किया?
टीम के सदस्य ने आज क्या करने की योजना बनाई?
कोई बाधा (बाधाएं)?

यह स्क्रम मास्टर है जो इस बैठक की सुविधा देता है। मामले में, किसी भी टीम के सदस्य को किसी भी प्रकार की कठिनाइयों का सामना करना पड़ रहा है, इस घोटाले के मास्टर इसे हल करने के लिए। स्टैंड अप्स में, बोर्ड की समीक्षा भी की जाती है और अपने आप में टीम की प्रगति को दर्शाता है।

# 4) समीक्षा बैठक

हर स्प्रिंट चक्र के अंत में, SCRUM टीम फिर से मिलती है और उत्पाद के मालिक को कार्यान्वित उपयोगकर्ता कहानियों को प्रदर्शित करती है। उत्पाद स्वामी अपनी स्वीकृति मानदंडों के अनुसार कहानियों को सत्यापित कर सकता है। फिर से इस बैठक की अध्यक्षता करने के लिए स्क्रैम मास्टर की जिम्मेदारी है।

इसके अलावा SCRUM टूल में स्प्रिंट को बंद कर दिया जाता है और कार्यों को चिह्नित किया जाता है।

# 5) पूर्वव्यापी बैठक

समीक्षा बैठक के बाद पूर्वव्यापी बैठक होती है।

SCRUM टीम निम्नलिखित बिंदुओं को पूरा करती है, चर्चा करती है और उनका दस्तावेजीकरण करती है:

स्प्रिंट (सर्वोत्तम प्रथाओं) के दौरान क्या अच्छा हुआ?
स्प्रिंट में क्या अच्छा नहीं हुआ?
सीख सीखी
एक्शन आइटम्स।

स्क्रम टीम को सर्वश्रेष्ठ अभ्यास का पालन करना जारी रखना चाहिए, 'सर्वोत्तम प्रथाओं' को अनदेखा न करें और परिणामस्वरूप स्प्रिंट के दौरान सीखे गए पाठों को लागू करें। पूर्वव्यापी बैठक SCRUM प्रक्रिया के निरंतर सुधार को लागू करने में मदद करता है।

प्रक्रिया कैसे की जाती है? एक उदाहरण!

SCRUM के तकनीकी शब्दजाल के बारे में पढ़ने के बाद। मुझे एक उदाहरण के साथ पूरी प्रक्रिया को प्रदर्शित करने का प्रयास करने दें।

उदाहरण:

चरण 1 : चलिए 9 लोगों की एक SCRUM टीम है जिसमें 1 उत्पाद स्वामी, 1 स्क्रैम मास्टर, 2 परीक्षक, 4 डेवलपर्स और 1 DBA शामिल हैं।

चरण 2 : स्प्रिंट को 4 सप्ताह के चक्र का पालन करने का निर्णय लिया गया है। तो हमारे पास 1 महीने का स्प्रिंट 5 जून से 4 तक शुरू होता है^वेंजुलाई का।

चरण 3 : उत्पाद स्वामी की उत्पाद बैकलॉग में उपयोगकर्ता कहानियों की प्राथमिकता सूची है।

चरण 4: टीम ने 4 को मिलने का फैसला किया^वें'प्री प्लानिंग' बैठक के लिए जून।

उत्पाद का मालिक उत्पाद बैकलॉग से 1 कहानी लेता है, इसका वर्णन करता है और टीम को इस पर विचार करने के लिए छोड़ देता है।
पूरी टीम उपयोगकर्ता की कहानी को स्पष्ट रूप से समझने के लिए उत्पाद स्वामी से सीधे चर्चा करती है और संवाद करती है।
इसी तरह से, विभिन्न अन्य उपयोगकर्ता कहानियां ली जाती हैं। यदि संभव हो, तो टीम आगे बढ़ सकती है और कहानियों को भी आकार दे सकती है।

सभी चर्चा के बाद, व्यक्तिगत टीम के सदस्य अपने कार्यस्थानों पर वापस जाते हैं और

प्रत्येक कहानी के लिए उनके व्यक्तिगत कार्यों को पहचानें।
उन सटीक घंटों की गणना करें जिन पर वे काम कर रहे होंगे। आइए देखें कि सदस्य इन घंटों का समापन कैसे करता है।

काम के घंटे की कुल संख्या = 9
ब्रेक के लिए माइनस 1 घंटे, मीटिंग्स के लिए माइनस 1 घंटे, ईमेल के लिए माइनस 1 घंटे, चर्चा, समस्या निवारण आदि।
तो वास्तविक काम के घंटे = 6।
स्प्रिंट के दौरान कार्य दिवसों की कुल संख्या = 21 दिन।
उपलब्ध घंटों की कुल संख्या = 21 * 6 = 126।
सदस्य 2 दिन = 12 घंटे के लिए छुट्टी पर है (यह प्रत्येक सदस्य के लिए भिन्न होता है, कुछ छुट्टी ले सकता है और कुछ नहीं हो सकता है।)
वास्तविक घंटों की संख्या = 126 - 12 = 114 घंटे।

इसका मतलब है कि सदस्य वास्तव में इस स्प्रिंट के लिए 114 घंटे उपलब्ध होंगे। इसलिए वह अपने व्यक्तिगत स्प्रिंट कार्य को इस तरह से तोड़ देगा कि कुल 114 घंटे तक पहुंच जाए।

चरण # 5 : 5 पर^वेंजून की पूरी स्क्राम टीम 'प्लानिंग मीटिंग' के लिए मिलती है।

उत्पाद बैकलॉग से उपयोगकर्ता कहानी का अंतिम फैसला किया जाता है और कहानी को स्प्रिंट बैकलॉग में स्थानांतरित कर दिया जाता है।
प्रत्येक कहानी के लिए, प्रत्येक टीम के सदस्य अपने पहचाने गए कार्यों की घोषणा करते हैं, यदि आवश्यक हो तो वे उन कार्यों पर चर्चा कर सकते हैं, आकार दे सकते हैं या उसका आकार बदल सकते हैं (याद रखें फिबोनाची श्रृंखला !!)।
स्क्रम मास्टर या टीम एक टूल में प्रत्येक कहानी के लिए अपने घंटों के साथ-साथ अपने व्यक्तिगत कार्यों में प्रवेश करते हैं।
सभी कहानियों के पूरा होने के बाद, स्क्रैम मास्टर प्रारंभिक वेग को नोट करता है और स्प्रिंट को औपचारिक रूप से शुरू करता है।

चरण # 6 : एक बार जब स्प्रिंट शुरू हो गया है, तो असाइन किए गए कार्यों के आधार पर, प्रत्येक टीम का सदस्य उन कार्यों पर काम करना शुरू कर देता है।

चरण # 7 : टीम रोजाना 15 मिनट तक बैठक करती है और 3 चीजों पर चर्चा करती है:

उन्होंने कल क्या किया?
वे आज क्या करने की योजना बना रहे हैं?
कोई बाधा (बाधाएं)?

चरण # 8 : स्क्रैम मास्टर 'बर्न डाउन चार्ट' की मदद से दैनिक आधार पर प्रगति को ट्रैक करता है।

चरण # 9 : किसी भी बाधा के मामले में, स्क्रैम मास्टर उन को हल करने के लिए अनुसरण करता है।

चरण # 10 : 4 पर^वेंजुलाई, टीम समीक्षा बैठक के लिए फिर से मिलती है। एक सदस्य उत्पाद स्वामी के लिए कार्यान्वित उपयोगकर्ता कहानी को प्रदर्शित करता है।

चरण # 11 : ५ पर^वेंजुलाई, टीम फिर से रेट्रोस्पेक्टिव के लिए मिलती है, जहां वे चर्चा करते हैं

क्या ठीक रहा?
क्या ठीक नहीं हुआ?
एक्शन आइटम्स।

चरण # 12 : 6 पर^वेंजुलाई, टीम अगले स्प्रिंट के लिए प्री-प्लानिंग मीटिंग के लिए फिर से मिलती है और चक्र जारी रहता है।

scrum फुर्तीली कार्यप्रणाली प्रक्रिया

SCRUM गतिविधि उपकरण

कई उपकरण हैं जिनका उपयोग बड़े पैमाने पर ट्रैकिंग गतिविधियों के लिए किया जा सकता है।

उनमें से कुछ में शामिल हैं:

आगामी ट्यूटोरियल में, हम एजाइल मेनिफेस्टो पर प्रकाश डालेंगे, जो एक धारणा है जो प्रभावी एजाइल टीम्स को चलाती है।

अगला ट्यूटोरियल

लेखक के बारे में: यह श्रृंखला निम्नलिखित एसटीएच टीम के सदस्यों द्वारा लिखी गई है: श्रुति श्रीवास्तव - बीएफएसआई, ई-कॉमर्स और बी 2 बी डोमेन के 9 वर्षों के अनुभव के साथ एक पेशेवर स्क्रम मास्टर। श्रुति ऑटोमेशन टेस्टिंग और प्रमुख स्क्रम टीमों में एक विशेषज्ञ है।

अंशुल कुमार श्रीवास्तव - BFSI और टेलीकॉम क्षेत्रों में 7 साल के अनुभव के साथ एक परिणाम-उन्मुख उत्पाद प्रबंधन पेशेवर और चुस्त व्यवसायी।

अनुशंसित पाठ

Agile Scrum ऑनलाइन क्विज़: Agile Scrum के अपने ज्ञान का परीक्षण करें
कानबन बनाम स्क्रम बनाम एजाइल: अंतर खोजने के लिए एक विस्तृत तुलना
चंचल प्रक्रिया का उपयोग करके अल्प समय अवधि में उच्च मूल्य सॉफ़्टवेयर सुविधाओं को कैसे वितरित करें
एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स
SAFe Agile Tutorial: स्केल एजाइल फ्रेमवर्क क्या है
30+ शीर्ष स्क्रम साक्षात्कार प्रश्न और उत्तर (2021 सूची)
फुर्तीली बनाम झरना: आपकी परियोजना के लिए सबसे अच्छी पद्धति कौन सी है?
शीर्ष 31 चुस्त साक्षात्कार प्रश्न और उत्तर

एजाइल मेथोडोलॉजी: ए बिगिनर गाइड टू एजाइल मेथड एंड स्क्रम