स्क्रम (सॉफ़्टवेयर विकास)
| Part of a series on |
| Software development |
|---|
स्क्रम एक सफुर्तिमान परियोजना प्रबंधन प्रणाली है जिसका उपयोग सामान्यतः सॉफ्टवेयर विकास में किया जाता है, यद्यपि इसका उपयोग अनुसंधान, बिक्री, विपणन, शिक्षा और उन्नत प्रौद्योगिकियों सहित अन्य क्षेत्रों में भी किया जाता है।[1] इसे दस या उससे कम सदस्यों की टीमों के लिए डिज़ाइन किया गया है जो अपने काम को समय-सीमा वाले पुनरावृत्तियों के भीतर पूरा करने के लिए लक्ष्यों में विभाजित करते हैं, जिन्हें स्प्रिंट कहा जाता है।[2]
प्रत्येक स्प्रिंट एक महीने से अधिक लंबा नहीं होता है और आमतौर पर दो सप्ताह तक चलता है। स्क्रम टीम टाइमबॉक्सिंग में प्रगति का आकलन करती है। 15 मिनट तक की टाइम-बॉक्स वाली दैनिक बैठकें, जिन्हें दैनिक स्क्रम (एक आमने - सामने की मीटिंग) कहा जाता है। स्प्रिंट के अंत में, टीम दो और बैठकें आयोजित करती है: एक स्प्रिंट समीक्षा का उद्देश्य हितधारक (कॉर्पोरेट) के लिए किए गए कार्यों को प्रदर्शित करना और प्रतिक्रिया मांगना है, और एक रेट्रोस्पेक्टिव#सॉफ़्टवेयर विकास का उद्देश्य टीम को प्रतिबिंबित करने और सुधार करने में सक्षम बनाना है।
नाम
सॉफ़्टवेयर डेवलपमेंट शब्द स्क्रम का उपयोग पहली बार 1986 में हिरोताका टेकुची और शिशु देखभाल कक्ष के अंदर द्वारा द न्यू न्यू प्रोडक्ट डेवलपमेंट गेम नामक पेपर में किया गया था।[4] स्क्रम (रग्बी) शब्द रग्बी फुटबॉल से लिया गया है, जिसका अर्थ है खिलाड़ियों का गठन। पेपर के लेखकों ने टीम वर्क पर जोर देने के लिए इस खेल शब्द, स्क्रम का इस्तेमाल किया, क्योंकि टीम के सदस्यों का करीबी, दैनिक सहयोग परियोजना प्रबंधन ढांचे की एक विशिष्ट विशेषता है।[5] यह पेपर हार्वर्ड बिजनेस रिव्यू के जनवरी 1986 अंक में प्रकाशित हुआ था।
स्क्रम को कभी-कभी सभी बड़े अक्षरों में SCRUM के रूप में लिखा हुआ देखा जाता है।[6] हालाँकि यह शब्द स्वयं एक संक्षिप्त शब्द नहीं है, इसकी बड़े अक्षरों में शैली संभवतः केन श्वाबर के एक प्रारंभिक पेपर से आई है[7] जिसने अपने शीर्षक में SCRUM को बड़े अक्षरों में लिखा है।[8] स्क्रम शब्द पहले श्वाबर द्वारा ट्रेडमार्क था, लेकिन पंजीकरण समाप्त हो गया है। यह अनुमान लगाया गया है कि श्वाबर ने इस शब्द के व्यापक सामुदायिक उपयोग को पहचानने और सक्षम करने के इरादे से इसे चूक जाने दिया।[9]
मुख्य विचार
स्क्रम जटिल उत्पादों को विकसित करने, वितरित करने और बनाए रखने के लिए एक हल्का, पुनरावृत्त डिजाइन और पुनरावृत्तीय और वृद्धिशील विकास ढांचा है।[10][11] उत्पाद विकास के अनुक्रमिक दृष्टिकोण के विपरीत, स्क्रम फ्रेमवर्क को निरंतर प्रतिक्रिया और लचीलेपन की अनुमति देने के लिए विकसित किया गया था, जिससे टीमों को सभी टीम के सदस्यों के भौतिक सह-स्थान (व्यवसाय) | सह-स्थान या ऑनलाइन सहयोग को प्रोत्साहित करके स्वयं को व्यवस्थित करने की आवश्यकता होती है, साथ ही टीम के सभी सदस्यों और इसमें शामिल विषयों के बीच दैनिक आमने-सामने संचार।[12] स्क्रम का एक प्रमुख सिद्धांत दोहरी मान्यता है कि ग्राहक जो चाहते हैं उसका दायरा बदल देंगे (जिसे अक्सर आवश्यकताओं की अस्थिरता कहा जाता है)[13]) और अप्रत्याशित चुनौतियाँ होंगी - जिनके लिए पूर्वानुमानित या नियोजित दृष्टिकोण उपयुक्त नहीं है। ये परिवर्तन विभिन्न स्रोतों से आते हैं, लेकिन स्क्रम के अनुसार, यह समझना कि क्यों अप्रासंगिक है, और परिवर्तन को आसानी से स्वीकार किया जाना चाहिए, अपनाया जाना चाहिए और लाभों के लिए विश्लेषण किया जाना चाहिए।
इतिहास
हिरोताका टेकुची और इकुजिरो नोनाका ने अपने 1986 के हार्वर्ड बिजनेस रिव्यू लेख, 'द न्यू नया उत्पाद विकास गेम' में नए उत्पाद विकास के संदर्भ में स्क्रम शब्द की शुरुआत की।[14] ताकेउची और नोनाका ने बाद में द नॉलेज क्रिएटिंग कंपनी में बहस की[15] यह संगठनात्मक ज्ञान सृजन का एक रूप है, [...] विशेष रूप से निरंतर, वृद्धिशील और सर्पिल रूप से नवाचार लाने में अच्छा है।
ऑटोमोटिव, फोटोकॉपियर और प्रिंटर आर्थिक क्षेत्र में विनिर्माण फर्मों के केस अध्ययनों के आधार पर, लेखकों ने वाणिज्यिक उत्पाद विकास के लिए एक नए दृष्टिकोण का वर्णन किया है जो गति और लचीलेपन को बढ़ाएगा।[14]उन्होंने इसे रग्बी फुटबॉल दृष्टिकोण कहा, क्योंकि यह प्रक्रिया एक विभिन्न क्षेत्र के मिलाकर एक सामान्य उद्देश्य की प्राप्ति के लिए बनाई गई टीम द्वारा कई ओवरलैपिंग चरणों में की जाती है, जिसमें टीम गेंद को आगे और पीछे पास करते हुए एक इकाई के रूप में दूरी तय करने की कोशिश करती है।[14]
स्क्रम रूपरेखा ड्यूपॉन्ट रिसर्च स्टेशन और डेलावेयर विश्वविद्यालय में बाबाटुंडे ओगुन्नाइके के साथ श्वाबर के शोध पर आधारित थी।[16]ओगुन्नाइक का सुझाव है कि सॉफ़्टवेयर जैसे जटिल उत्पादों को विकसित करने का प्रयास, जो अनुभववाद पर आधारित नहीं थे, प्रारंभिक स्थितियों और धारणाओं में बदलाव के कारण उच्च जोखिम और विफलता की दर का अनुभव कर सकते हैं।
1990 के दशक की शुरुआत में, केन श्वाबर ने अपनी कंपनी, एडवांस्ड डेवलपमेंट मेथड्स में स्क्रम का इस्तेमाल किया; जबकि जेफ सदरलैंड, जॉन स्कुम्निओटेल्स और जेफ़ मैककेना ने ईज़ल कॉर्पोरेशन में एक समान दृष्टिकोण विकसित किया, जिसमें इसे एकल शब्द स्क्रम का उपयोग करके संदर्भित किया गया।[17] सदरलैंड और श्वाबर ने अपने विचारों को एक ही ढांचे में एकीकृत करने के लिए मिलकर काम किया: स्क्रम। उन्होंने स्क्रम का परीक्षण किया और उसमें लगातार सुधार किया, जिससे उनका 1995 का पेपर तैयार हुआ,[18]2001 में एजाइल सॉफ्टवेयर डेवलपमेंट के लिए घोषणापत्र,[19] और 2002 से दुनिया भर में स्क्रम का प्रसार और उपयोग।
1995 में, सदरलैंड और श्वाबर ने संयुक्त रूप से ऑस्टिन, टेक्सास में OOPSLA|ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग, सिस्टम, लैंग्वेजेज और एप्लिकेशन '95 (OOPSLA '95) के हिस्से के रूप में आयोजित बिजनेस ऑब्जेक्ट डिजाइन और कार्यान्वयन कार्यशाला में स्क्रम फ्रेमवर्क का वर्णन करते हुए एक पेपर प्रस्तुत किया।[18] अगले वर्षों में, श्वाबर और सदरलैंड ने इस सामग्री को अपने अनुभव और विकसित अच्छे अभ्यास के साथ संयोजित करने के लिए सहयोग किया, जिसे स्क्रम के रूप में जाना जाने लगा।[20] 2001 में, श्वाबर ने एजाइल सॉफ्टवेयर डेवलपमेंट विद स्क्रम नामक पुस्तक में विधि का वर्णन करने के लिए माइक बीडल के साथ काम किया।[21] उत्पाद विकास की योजना और प्रबंधन के लिए स्क्रम के दृष्टिकोण में निर्णय लेने के अधिकार को संचालन गुणों और निश्चितताओं के स्तर पर लाना शामिल है।[16] 2002 में, श्वाबर ने अन्य लोगों के साथ स्क्रम एलायंस की स्थापना की[22] और प्रमाणित स्क्रम मान्यता श्रृंखला की स्थापना की। श्वाबर ने 2009 के अंत में स्क्रम एलायंस छोड़ दिया और Scrum.org की स्थापना की[23] जो समानांतर व्यावसायिक स्क्रम मान्यता श्रृंखला की देखरेख करता है।[24]
2009 से, द स्क्रम गाइड नामक एक सार्वजनिक दस्तावेज़[20]श्वाबर और सदरलैंड द्वारा प्रकाशित और अद्यतन किया गया है। इसे 6 बार संशोधित किया गया है, वर्तमान संस्करण नवंबर 2020 है।
स्क्रम टीम
 | This section possibly contains original research. (April 2019) (Learn how and when to remove this template message) |
स्क्रम की मूल इकाई लोगों की एक छोटी टीम है, जिसमें एक उत्पाद स्वामी, एक स्क्रम मास्टर और डेवलपर्स शामिल होते हैं। टीम स्व-प्रबंधन, क्रॉस-फ़ंक्शनल है, और एक समय में एक उद्देश्य पर ध्यान केंद्रित करती है: उत्पाद लक्ष्य।
उत्पाद स्वामी
उत्पाद स्वामी, उत्पाद के हितधारक (कॉर्पोरेट) और ग्राहक की आवाज़ का प्रतिनिधित्व करता है (या किसी समिति की इच्छाओं का प्रतिनिधित्व कर सकता है)[25]), अच्छे व्यावसायिक परिणाम देने के लिए जिम्मेदार है।[26] इसलिए, उत्पाद स्वामी उत्पाद बैकलॉग के लिए और टीम द्वारा प्रदान किए जाने वाले मूल्य को अधिकतम करने के लिए जवाबदेह है।[25] उत्पाद स्वामी उत्पाद को ग्राहक केंद्रितता | ग्राहक-केंद्रित परिणामों (आमतौर पर - लेकिन उपयोगकर्ता की कहानी तक सीमित नहीं) के संदर्भ में परिभाषित करता है, उन्हें उत्पाद बैकलॉग में जोड़ता है, और महत्व और निर्भरता के आधार पर उन्हें प्राथमिकता देता है।[27] एक स्क्रम टीम में केवल एक उत्पाद स्वामी होना चाहिए (हालाँकि एक उत्पाद स्वामी एक से अधिक टीमों का समर्थन कर सकता है)[28]और इस भूमिका को स्क्रम मास्टर की भूमिका के साथ संयोजित करने के विरुद्ध दृढ़ता से सलाह दी जाती है। उत्पाद स्वामी को उत्पाद विकास के व्यावसायिक पक्ष पर ध्यान केंद्रित करना चाहिए और अधिकांश समय हितधारकों और टीम के साथ संपर्क में बिताना चाहिए। उत्पाद स्वामी यह निर्देशित नहीं करता है कि टीम किसी तकनीकी समाधान तक कैसे पहुंचती है, बल्कि वह टीम के सदस्यों के बीच आम सहमति चाहता है।[29][30][better source needed] यह भूमिका महत्वपूर्ण है और इसके लिए दोनों पक्षों की गहरी समझ की आवश्यकता है: व्यवसाय और स्क्रम टीम में इंजीनियर (डेवलपर्स)। इसलिए, एक अच्छे उत्पाद स्वामी को यह बताने में सक्षम होना चाहिए कि व्यवसाय को क्या चाहिए, पूछें कि उन्हें इसकी आवश्यकता क्यों है (क्योंकि इसे प्राप्त करने के बेहतर तरीके हो सकते हैं), और आवश्यकतानुसार तकनीकी भाषा का उपयोग करके डेवलपर्स सहित सभी हितधारकों को संदेश देना चाहिए। उत्पाद स्वामी जोखिम को नियंत्रित करने और मूल्य प्राप्त करने के दौरान अत्यधिक जटिल कार्य को प्रबंधित करने के लिए स्क्रम के अनुभवजन्य उपकरणों का उपयोग करता है।
संचार उत्पाद स्वामी की मुख्य जिम्मेदारी है। उत्पाद विकास को सही दिशा में ले जाने के लिए प्राथमिकताओं को बताने और टीम के सदस्यों और हितधारकों के साथ सहानुभूति रखने की क्षमता महत्वपूर्ण है। उत्पाद स्वामी की भूमिका टीम और उसके हितधारकों के बीच संचार अंतर को पाटती है, टीम के हितधारकों के लिए एक प्रॉक्सी के रूप में और समग्र हितधारक समुदाय के लिए एक टीम प्रतिनिधि के रूप में कार्य करती है।[31][32] हितधारकों के लिए टीम के चेहरे के रूप में, उत्पाद स्वामी के हितधारकों के साथ कुछ संचार कार्य निम्नलिखित हैं:[33]
- रिलीज को परिभाषित करें और घोषणा करें
- डिलीवरी और उत्पाद की स्थिति के बारे में बताएं
- शासन की बैठकों के दौरान प्रगति साझा करें
- हितधारकों के साथ महत्वपूर्ण आरआईडीए (परियोजना जोखिम प्रबंधन, बाधाएं, निर्भरता (परियोजना प्रबंधन), और धारणाएं) साझा करें
- प्राथमिकताओं, दायरे, फंडिंग और शेड्यूल पर बातचीत करें
- सुनिश्चित करें कि उत्पाद बैकलॉग दृश्यमान, पारदर्शी और स्पष्ट है
संबंधित होने की क्षमता किसी उत्पाद के मालिक के लिए एक प्रमुख विशेषता है - स्वयं को दूसरे के स्थान पर रखने की क्षमता। एक उत्पाद स्वामी विभिन्न पृष्ठभूमियों, कार्य भूमिकाओं और उद्देश्यों वाले विभिन्न हितधारकों के साथ बातचीत करता है - और उसे इन विभिन्न दृष्टिकोणों की सराहना करने में सक्षम होना चाहिए। प्रभावी होने के लिए, उत्पाद स्वामी के लिए यह जानना बुद्धिमानी है कि दर्शकों को किस स्तर के विवरण की आवश्यकता है। डेवलपर्स को संपूर्ण फीडबैक और विशिष्टताओं की आवश्यकता होती है ताकि वे अपेक्षा के अनुरूप उत्पाद बना सकें, जबकि एक कार्यकारी प्रायोजक को केवल प्रगति के सारांश की आवश्यकता हो सकती है। आवश्यकता से अधिक जानकारी प्रदान करने से हितधारक की रुचि कम हो सकती है और समय बर्बाद हो सकता है। अनुभवी उत्पाद मालिकों द्वारा संचार का सीधा साधन पसंद किया जाता है।[28] किसी उत्पाद स्वामी की प्रभावी ढंग से संवाद करने की क्षमता उन तकनीकों में कुशल होने से भी बढ़ती है जो हितधारकों की जरूरतों की पहचान करती हैं, हितधारकों के हितों के बीच प्राथमिकताओं पर बातचीत करती हैं और आवश्यकताओं के प्रभावी कार्यान्वयन को सुनिश्चित करने के लिए डेवलपर्स के साथ सहयोग करती हैं।
डेवलपर्स
डेवलपर्स प्रत्येक स्प्रिंट में मूल्य वृद्धि के निर्माण के लिए आवश्यक सभी कार्य करते हैं।[27]
डेवलपर्स शब्द[20] किसी ऐसे व्यक्ति को संदर्भित करता है जो सिस्टम या उत्पाद के विकास और समर्थन में भूमिका निभाता है और इसमें शोधकर्ता, आर्किटेक्ट, डिजाइनर, डेटा विशेषज्ञ, सांख्यिकीविद, विश्लेषक, इंजीनियर, प्रोग्रामर और परीक्षक शामिल हो सकते हैं।[34] हालाँकि, उस भ्रम के कारण जो तब उत्पन्न हो सकता है जब कुछ लोगों को नहीं लगता कि 'डेवलपर' शब्द उन पर लागू होता है, उन्हें अक्सर टीम के सदस्यों के रूप में संदर्भित किया जाता है।
टीम स्व-संगठित है। जबकि उत्पाद स्वामी के अलावा कोई भी काम टीम के पास नहीं आना चाहिए, और स्क्रम मास्टर से टीम को विकर्षणों से बचाने की अपेक्षा की जाती है, टीम को फीडबैक की अधिकतम समझ और तत्कालता प्राप्त करने के लिए ग्राहकों और/या हितधारकों के साथ सीधे बातचीत करने के लिए प्रोत्साहित किया जाता है।[27]
स्क्रम मास्टर
स्क्रम को एक स्क्रम मास्टर द्वारा सुविधा प्रदान की जाती है, जो स्क्रम गाइड में परिभाषित अनुसार स्क्रम की स्थापना के लिए जवाबदेह है। वे स्क्रम टीम और संगठन दोनों के भीतर हर किसी को स्क्रम सिद्धांत और अभ्यास को समझने में मदद करके ऐसा करते हैं।[3] स्क्रम मास्टर कोई पारंपरिक टीम लीडर या प्रोजेक्ट मैनेजर नहीं है। स्क्रम मास्टर यह सुनिश्चित करता है कि स्क्रम सिद्धांत और अवधारणाओं में टीम को प्रशिक्षित करके स्क्रम ढांचे का पालन किया जाता है, अक्सर महत्वपूर्ण घटनाओं को सुविधाजनक बनाया जाता है, और टीम को बढ़ने और सुधार करने के लिए प्रोत्साहित किया जाता है। भूमिका को टीम फैसिलिटेटर या नौकर नेतृत्व | नौकर-नेता (स्क्रम गाइड 2017) के रूप में भी संदर्भित किया गया है[35]) और ट्रू लीडर (स्क्रम गाइड 2020[3] इन दोहरे दृष्टिकोणों को सुदृढ़ करने के लिए।
स्क्रम मास्टर की मुख्य जिम्मेदारियों में शामिल हैं:[3]
- टीम के सदस्यों को स्व-प्रबंधन और क्रॉस-फ़ंक्शनलिटी में प्रशिक्षित करना
- स्क्रम टीम को उच्च-मूल्य वेतन वृद्धि बनाने पर ध्यान केंद्रित करने में मदद करना जो पूर्ण की परिभाषा को पूरा करती है
- स्क्रम टीम की प्रगति में आने वाली बाधाओं को दूर करना
- यह सुनिश्चित करना कि सभी स्क्रम ईवेंट घटित हों और सकारात्मक, उत्पादक हों और समय सीमा के भीतर रखे जाएं।
- उत्पाद स्वामी को प्रभावी उत्पाद लक्ष्य परिभाषा और उत्पाद बैकलॉग प्रबंधन के लिए तकनीक खोजने में मदद करना
- स्क्रम टीम को स्पष्ट और संक्षिप्त उत्पाद बैकलॉग आइटम की आवश्यकता को समझने में मदद करना
- जटिल वातावरण के लिए अनुभवजन्य उत्पाद योजना स्थापित करने में मदद करना
- अनुरोध या आवश्यकता के अनुसार हितधारक सहयोग की सुविधा प्रदान करना
- स्क्रम अपनाने में संगठन का नेतृत्व करना, प्रशिक्षण देना और प्रशिक्षण देना
- संगठन के भीतर स्क्रम कार्यान्वयन की योजना बनाना और सलाह देना
- कर्मचारियों और हितधारकों को जटिल कार्य के लिए अनुभवजन्य दृष्टिकोण को समझने और लागू करने में मदद करना
- हितधारकों और स्क्रम टीमों के बीच बाधाओं को दूर करना
स्क्रम मास्टर लोगों और संगठनों को निश्चितता और पूर्वानुमेयता की आशाओं को पीछे छोड़ते हुए अनुभवजन्य और दुबली सोच अपनाने में मदद करता है।
स्क्रम मास्टर की भूमिका प्रोजेक्ट मैनेजर से भिन्न होने का एक तरीका यह है कि प्रोजेक्ट मैनेजर के पास प्रबंधन जिम्मेदारियाँ हो सकती हैं और स्क्रम मास्टर के पास नहीं। एक स्क्रम मास्टर टीम में स्व-संगठन का समर्थन करता है। [36] स्क्रम परियोजना प्रबंधक की भूमिका का उपयोग नहीं करता है, क्योंकि स्क्रम एक उत्पाद प्रबंधन है न कि परियोजना प्रबंधन ढांचा। इसके अलावा, पारंपरिक कमांड और नियंत्रण की प्रवृत्ति और प्रबंधक के नेतृत्व वाले व्यवहार के परिणामस्वरूप टीमों का स्व-संगठन सीमित हो जाएगा।[37]
कार्यप्रवाह
स्प्रिंट
स्प्रिंट (इसे पुनरावृत्त और वृद्धिशील विकास, टाइमबॉक्सिंग या डिज़ाइन स्प्रिंट के रूप में भी जाना जाता है) स्क्रम में विकास की मूल इकाई है। स्प्रिंट एक टाइमबॉक्सिंग प्रयास है; अर्थात्, प्रत्येक स्प्रिंट के लिए लंबाई पहले से तय की जाती है और आम तौर पर एक सप्ताह और एक महीने के बीच होती है, जिसमें दो सप्ताह सबसे आम होते हैं।[16]
आमतौर पर, परियोजना की प्रगति और परियोजना को लागू करते समय टीम के किसी भी सदस्य के सामने आने वाली किसी भी कठिनाई पर चर्चा करने के लिए दैनिक बैठकें आयोजित की जाती हैं। स्प्रिंट का परिणाम कुछ पुनरावृत्तीय और वृद्धिशील विकास के साथ, वितरण योग्य है। स्क्रम का उपयोग वेब टेक्नोलॉजी या नए बाज़ार के लिए किसी उत्पाद के विकास जैसी परियोजनाओं के लिए किया जाता है, यानी कई आवश्यकताओं या तेजी से बदलती आवश्यकता वाले उत्पाद।
प्रत्येक स्प्रिंट एक स्प्रिंट योजना कार्यक्रम से शुरू होता है जिसमें एक स्प्रिंट लक्ष्य परिभाषित किया जाता है। आगामी स्प्रिंट के लिए प्राथमिकताएँ बैकलॉग से चुनी जाती हैं। प्रत्येक स्प्रिंट दो घटनाओं के साथ समाप्त होता है:
- एक स्प्रिंट समीक्षा (हितधारकों को उनकी प्रतिक्रिया प्राप्त करने के लिए दिखाई गई प्रगति)
- एक स्प्रिंट पूर्वव्यापी (अगले स्प्रिंट के लिए सबक और सुधार की पहचान करें)[17]
स्क्रम स्प्रिंट के अंत में मूल्यवान, कार्रवाई योग्य आउटपुट पर जोर देता है जो अभी पूरा हुआ है। प्रत्येक पुनरावृत्ति के आउटपुट को विकसित उत्पाद को बाज़ार की सफलता के करीब लाना चाहिए।[38] सॉफ़्टवेयर के मामले में, इसमें संभवतः यह शामिल है कि उत्पाद पूरी तरह से एकीकृत, परीक्षण और दस्तावेज़ीकृत हैं, और संभावित रूप से रिलीज़ करने योग्य हैं।[37]
स्प्रिंट योजना
स्प्रिंट की शुरुआत में, स्क्रम टीम एक स्प्रिंट योजना कार्यक्रम आयोजित करती है:
- स्प्रिंट लक्ष्य पर सहमत हों, उत्पाद स्वामी द्वारा निर्धारित प्राथमिकताओं के आधार पर, स्प्रिंट अंत तक वे क्या देने का अनुमान लगाते हैं इसका एक संक्षिप्त विवरण।
- उत्पाद बैकलॉग आइटम का चयन करें जो इस लक्ष्य में योगदान करते हैं
- उस स्प्रिंट के दौरान कौन से आइटम करने का इरादा है, इस पर पारस्परिक रूप से चर्चा और सहमति देकर स्प्रिंट बैकलॉग बनाएं
चार सप्ताह के स्प्रिंट के लिए स्प्रिंट योजना की अधिकतम अवधि आठ घंटे है।[20]जैसा कि विस्तृत कार्य विस्तृत है, कुछ स्प्रिंट बैकलॉग आइटम को विभाजित किया जा सकता है या उत्पाद बैकलॉग में वापस किया जा सकता है यदि टीम को लगता है कि वे उस कार्य को एक ही स्प्रिंट में पूरा नहीं कर सकते हैं।
दैनिक घोटाला
स्प्रिंट के दौरान प्रत्येक दिन, डेवलपर्स विशिष्ट दिशानिर्देशों के साथ एक दैनिक स्क्रम (कभी-कभी स्टैंड-अप मीटिंग आयोजित करते हैं) आयोजित करते हैं:[39][16]
सभी डेवलपर तैयार होकर आते हैं। दैनिक घोटाला:
- स्प्रिंट लक्ष्य की दिशा में प्रगति का निरीक्षण करने पर केंद्रित है
- हर दिन एक ही समय और स्थान पर होना चाहिए
- (टाइमबॉक्सिंग) पंद्रह मिनट तक सीमित है
- टीम जैसा निर्णय लेती है वैसे ही आयोजित किया जाता है
- इसमें अन्य भी शामिल हो सकते हैं, हालाँकि केवल डेवलपर्स को ही बोलना चाहिए।
- स्क्रम मास्टर द्वारा सुविधा प्रदान की जा सकती है
- प्रगति में बाधाओं की पहचान कर सकता है (उदाहरण के लिए, रुकावट, जोखिम, समस्या, विलंबित निर्भरता, निराधार साबित हुई धारणा)
- इसमें चर्चाएँ शामिल नहीं हैं
- प्रगति चार्ट को अद्यतन करने का साधन नहीं है
दूरस्थ वातावरण में, कई स्क्रम टीमें स्लैक (सॉफ़्टवेयर) जैसे टूल का उपयोग करके अपने दैनिक स्क्रम को मैसेजिंग प्रारूप में रखने का विकल्प चुनती हैं। ऐसा माना जाता है कि यह स्क्रम टीम के सदस्यों को दैनिक अपडेट को अतुल्यकालिक रूप से पढ़ने की अनुमति देता है, जिससे प्रत्येक व्यक्ति को अपने दैनिक अपडेट के बारे में बोलने के लिए आवश्यक समय की बचत होती है।[40] अक्सर, विशिष्ट सुविधाओं पर काम करने वाली टीमों को सीधे संवाद करने की आवश्यकता नहीं होती है। इस प्रारूप में, उत्पाद स्वामी या स्क्रम मास्टर के लिए आगे के सहयोग या संचार के लिए किसी भी बैठक का समन्वय करना महत्वपूर्ण है।
दैनिक कामकाज के दौरान कोई विस्तृत चर्चा नहीं होनी चाहिए। एक बार ख़त्म होने पर, व्यक्तिगत सदस्य मुद्दों पर विस्तार से चर्चा कर सकते हैं, जिसे अक्सर 'ब्रेकआउट सत्र' या 'आफ्टर पार्टी' के रूप में जाना जाता है।[41] समाधान की दिशा में काम करने की दृष्टि से पहचाने गए मुद्दों या बगों पर दैनिक विवाद के बाहर सामूहिक रूप से चर्चा की जानी चाहिए।
जहां टीम को इस घटना में मूल्य नहीं दिखता है, वहां यह निर्धारित करना स्क्रम मास्टर की ज़िम्मेदारी है कि क्यों[42] और टीम और हितधारकों को स्क्रम सिद्धांतों के बारे में शिक्षित करें,[43] या टीम को स्प्रिंट प्रगति के बारे में पूरी जानकारी रखने के लिए अपना स्वयं का तरीका डिज़ाइन करने के लिए प्रोत्साहित करें।
स्प्रिंट समीक्षा
स्प्रिंट के अंत में आयोजित टीम:
- हितधारकों को पूरा किया गया कार्य प्रस्तुत करता है (जैसे प्रौद्योगिकी डेमो)
- जैसे विषयों पर हितधारकों के साथ सहयोग करता है:
- पूर्ण उत्पाद वृद्धि के बारे में प्रतिक्रिया आमंत्रित करना
- अधूरे काम (योजनाबद्ध या अन्यथा) के प्रभाव पर चर्चा
- आगामी कार्य के लिए सुझाव प्राप्त करना (आगे क्या काम करना है इसका मार्गदर्शन)
उत्पाद मालिकों को इस आयोजन को हितधारकों के साथ उत्पाद बैकलॉग की समीक्षा करने और उसे परिष्कृत करने के एक मूल्यवान अवसर के रूप में देखना चाहिए। यदि समीक्षा से पता चलता है कि उत्पाद में कोई विचलन है, तो आगे के विचलन को नियंत्रित करने के लिए यथाशीघ्र समायोजन किया जाता है।
स्प्रिंट समीक्षा के लिए दिशानिर्देश:
- अधूरे कार्य का प्रदर्शन नहीं किया जाना चाहिए; हालाँकि हितधारकों को उन्हें प्राप्त होने वाले उत्पाद वेतन वृद्धि के साथ प्रस्तुत किया जाना चाहिए, लेकिन यदि आवश्यक हो तो कार्य प्रगति पर देखने का अनुरोध भी कर सकते हैं। हालाँकि, टीम को केवल यह दिखाने के लिए तैयार रहना चाहिए कि क्या किया गया है।
- दो सप्ताह के स्प्रिंट के लिए अनुशंसित अवधि दो घंटे है (अन्य स्प्रिंट-अवधिओं के लिए आनुपातिक)।[20]
स्प्रिंट पूर्वव्यापी
स्प्रिंट पूर्वव्यापी में, टीम:
- पिछले स्प्रिंट को दर्शाता है
- निरीक्षण करता है कि अंतिम स्प्रिंट कैसा रहा (व्यक्ति, इंटरैक्शन, प्रक्रियाएं, उपकरण, पूर्ण की परिभाषा)
- निरंतर सुधार प्रक्रिया कार्यों की पहचान करता है और उनसे सहमत होता है
स्प्रिंट पूर्वव्यापी के लिए दिशानिर्देश:[citation needed]
- स्प्रिंट रेट्रोस्पेक्टिव में विचार करने के लिए तीन सुझाए गए क्षेत्र हैं:
- स्प्रिंट के दौरान क्या अच्छा हुआ?
- क्या ठीक नहीं हुआ?
- हम अगले स्प्रिंट में क्या अलग कर सकते हैं?
- चार सप्ताह के स्प्रिंट के लिए अवधि अधिकतम तीन घंटे है, जो अन्य स्प्रिंट अवधि के लिए आनुपातिक है (उदाहरण के लिए दो सप्ताह के स्प्रिंट के लिए डेढ़ घंटे)।
स्क्रम मास्टर इस आयोजन को सुविधाजनक बना सकते हैं, लेकिन वे टीम के एक हिस्से के रूप में भी उपस्थित हो सकते हैं।
बैकलॉग परिशोधन
हालांकि मूल रूप से एक मुख्य स्क्रम अभ्यास नहीं है, बैकलॉग रिफ़ाइनमेंट (कंप्यूटिंग) (जिसे पहले ग्रूमिंग कहा जाता था) को स्क्रम गाइड में जोड़ा गया था और स्प्रिंट में प्रवेश करने वाले उत्पाद बैकलॉग आइटम की गुणवत्ता को प्रबंधित करने के एक तरीके के रूप में अपनाया गया था। यह नई जानकारी के आलोक में उत्पाद बैकलॉग आइटम की समीक्षा और संशोधन/अद्यतन/पुनः ऑर्डर करने की सतत प्रक्रिया है।
बैकलॉग और भीतर की वस्तुओं को संशोधित करने के कारणों में शामिल हो सकते हैं:
- बड़ी वस्तुओं को कई छोटी वस्तुओं में तोड़ा जा सकता है
- स्वीकृति मानदंडों को स्पष्ट किया जा सकता है
- निर्भरता की पहचान और जांच की जा सकती है
- किसी आइटम को आगे की खोज और विश्लेषण की आवश्यकता हो सकती है
- प्राथमिकताएँ बदल गई होंगी; अपेक्षित रिटर्न अब अलग-अलग होंगे
परिशोधन का मतलब है कि वस्तुओं को उचित रूप से तैयार किया जाता है और इस तरह से व्यवस्थित किया जाता है जो उन्हें स्प्रिंट योजना के लिए डेवलपर्स के लिए स्पष्ट और निष्पादन योग्य बनाता है।
बैकलॉग में तकनीकी ऋण (जिसे डिज़ाइन ऋण या कोड ऋण भी कहा जाता है) भी शामिल हो सकता है। यह सॉफ्टवेयर विकास में एक अवधारणा है जो एक बेहतर दृष्टिकोण का उपयोग करने के बजाय अब एक आसान समाधान चुनने के कारण होने वाले अतिरिक्त पुनर्विक्रय की निहित लागत को दर्शाती है जिसमें अधिक समय लगेगा।
किसी टीम की स्प्रिंट क्षमता का 10 प्रतिशत तक निवेश करने की अनुशंसा की जाती है[20]बैकलॉग शोधन पर. अधिक परिपक्व टीमें इसे एक निर्धारित परिभाषित कार्यक्रम के रूप में नहीं बल्कि एक तदर्थ गतिविधि के रूप में देखेंगी जो प्राकृतिक वर्कफ़्लो का हिस्सा बनती है, जरूरत पड़ने पर उत्पाद बैकलॉग को परिष्कृत और समायोजित करती है।
स्प्रिंट रद्द करना
यदि आवश्यक हो तो उत्पाद स्वामी स्प्रिंट रद्द कर सकता है,[20]और ऐसा दूसरों (डेवलपर्स, स्क्रम मास्टर या प्रबंधन) के इनपुट के साथ या उसके बिना भी कर सकता है। उदाहरण के लिए, हाल की बाहरी परिस्थितियाँ स्प्रिंट लक्ष्य के मूल्य को नकार सकती हैं, इसलिए इसे जारी रखना व्यर्थ है।
जब एक स्प्रिंट असामान्य रूप से समाप्त हो जाता है, तो अगला कदम नई स्प्रिंट योजना बनाना होता है, जहां समाप्ति के कारण की समीक्षा की जाती है।
कलाकृतियाँ
 | This section needs additional citations for verification. (March 2013) (Learn how and when to remove this template message) |
कलाकृतियाँ परियोजना में कार्य के प्रबंधन के लिए उपयोग किए जाने वाले दस्तावेज़ को संदर्भित करती हैं।
उत्पाद बैकलॉग
उत्पाद बैकलॉग किए जाने वाले कार्यों का विवरण है और इसमें आवश्यकता की एक क्रमबद्ध सूची होती है जिसे टीम नए उत्पाद विकास के लिए बनाए रखती है। बैकलॉग आइटम के सामान्य प्रारूप में उपयोगकर्ता कहानी और उपयोग के मामले शामिल हैं।[37]ये आवश्यकताएँ सॉफ़्टवेयर सुविधाओं, पैच (कंप्यूटिंग), गैर-कार्यात्मक आवश्यकताओं आदि को परिभाषित करती हैं - जो कुछ भी एक व्यवहार्य उत्पाद प्रदान करता है। उत्पाद स्वामी जोखिम, व्यावसायिक मूल्य, निर्भरता, आकार और आवश्यक तिथि जैसे विचारों के आधार पर उत्पाद बैकलॉग आइटम (पीबीआई) को प्राथमिकता देता है।
उत्पाद बैकलॉग वह है जिसकी आवश्यकता होती है, जब इसकी आवश्यकता होती है तब ऑर्डर किया जाता है और यह सभी को दिखाई देता है, लेकिन इसे केवल उत्पाद स्वामी की सहमति से बदला जा सकता है, जो उत्पाद बैकलॉग आइटम के प्रबंधन और रखरखाव के लिए जिम्मेदार है।
उत्पाद बैकलॉग में उत्पाद स्वामी के व्यावसायिक मूल्य का मूल्यांकन शामिल होता है और इसमें टीम के प्रयास या जटिलता का मूल्यांकन शामिल हो सकता है, अक्सर, लेकिन हमेशा नहीं, जो फाइबोनैचि स्केल (फुर्तीली) का उपयोग करके योजना पोकर में बताया गया है। ये अनुमान उत्पाद स्वामी को समयरेखा का अनुमान लगाने में मदद करते हैं और उत्पाद बैकलॉग आइटम के ऑर्डर को प्रभावित कर सकते हैं; उदाहरण के लिए, समान व्यावसायिक मूल्य वाली दो सुविधाओं के लिए, उत्पाद स्वामी कम विकास प्रयास (क्योंकि निवेश पर रिटर्न अधिक है) या उच्च विकास प्रयास (क्योंकि यह अधिक जटिल या जोखिम भरा है) के साथ काम की पहले डिलीवरी शेड्यूल कर सकता है। , और वे उस जोखिम से पहले ही निवृत्त होना चाहते हैं)।[44] उत्पाद बैकलॉग और प्रत्येक उत्पाद बैकलॉग आइटम का व्यावसायिक मूल्य उत्पाद स्वामी की जिम्मेदारी है। प्रत्येक आइटम को वितरित करने के प्रयास का अनुमान कहानी बिंदुओं या समय में लगाया जा सकता है। कहानी के बिंदुओं का अनुमान लगाकर, टीम व्यक्तिगत डेवलपर्स की निर्भरता कम करती है; यह विशेष रूप से गतिशील टीमों के लिए उपयोगी है जहां डेवलपर्स को अक्सर स्प्रिंट डिलीवरी के बाद अन्य कार्य सौंपा जाता है। उदाहरण के लिए, यदि किसी उपयोगकर्ता की कहानी को प्रयास में 5 (फाइबोनैचि अनुक्रम का उपयोग करके) के रूप में अनुमानित किया गया है, तो यह 5 ही रहता है, भले ही कितने डेवलपर इस पर काम कर रहे हों
कहानी के बिंदु समय-सीमा में प्रयास को परिभाषित करते हैं, इसलिए वे समय के साथ नहीं बदलते हैं। उदाहरण के लिए, एक घंटे में एक व्यक्ति चल सकता है, दौड़ सकता है या चढ़ सकता है, लेकिन खर्च किया गया प्रयास स्पष्ट रूप से भिन्न होता है। फाइबोनैचि अनुक्रम में शब्दों के बीच अंतर प्रगति टीम को सावधानीपूर्वक विचार किए गए अनुमान देने के लिए प्रोत्साहित करती है। 1, 2 या 3 का अनुमान समान प्रयासों का संकेत देता है (1 तुच्छ है), लेकिन यदि टीम 8 या 13 (या अधिक) का अनुमान लगाती है, तो वितरण और बजट दोनों पर प्रभाव महत्वपूर्ण हो सकता है। कहानी बिंदुओं का उपयोग करने का महत्व यह है कि टीम पिछले स्प्रिंट के समान कार्य की तुलना करके उनका पुन: उपयोग कर सकती है, लेकिन यह माना जाना चाहिए कि अनुमान उस टीम के सापेक्ष हैं। उदाहरण के लिए, उच्च क्षमता वाले अधिक अनुभवी डेवलपर्स से बनी एक टीम के लिए 5 का अनुमान दूसरे के लिए 2 हो सकता है।
प्रत्येक टीम में एक उत्पाद स्वामी होना चाहिए, हालाँकि कई मामलों में एक उत्पाद स्वामी एक से अधिक टीमों के साथ काम कर सकता है।[28]उत्पाद स्वामी उत्पाद के मूल्य को अधिकतम करने के लिए जिम्मेदार है। उत्पाद स्वामी इनपुट एकत्र करता है और कई लोगों से फीडबैक लेता है, और उसकी पैरवी करता है, लेकिन अंततः क्या बनाया जाएगा इसके बारे में अंतिम निर्णय उसका ही होता है।
उत्पाद बैकलॉग:
- किसी उत्पाद को संशोधित करने के अनुरोधों को कैप्चर करता है - जिसमें नई सुविधाएँ, पुरानी सुविधाएँ बदलना, सुविधाएँ हटाना और समस्याओं को ठीक करना शामिल है
- सुनिश्चित करता है कि डेवलपर्स के पास ऐसा काम है जो उत्पाद के व्यावसायिक लाभ को अधिकतम करता है
आमतौर पर, पूरी टीम उत्पाद बैकलॉग को परिष्कृत करने के लिए एक साथ काम करती है, जो उत्पाद और उसके ग्राहकों के बारे में नई जानकारी सामने आने के साथ विकसित होती है, और इसलिए बाद में स्प्रिंट नए काम को संबोधित कर सकते हैं।
प्रबंधन
एक उत्पाद बैकलॉग, अपने सरलतम रूप में, काम करने के लिए वस्तुओं की एक सूची मात्र है। काम को कैसे जोड़ा, हटाया और ऑर्डर किया जाए, इसके बारे में अच्छी तरह से स्थापित नियम होने से पूरी टीम को उत्पाद को बदलने के तरीके के बारे में बेहतर निर्णय लेने में मदद मिलती है।[45] उत्पाद स्वामी उत्पाद बैकलॉग आइटम को प्राथमिकता देता है, जिसके आधार पर इसकी जल्द से जल्द आवश्यकता होती है। डेवलपर्स, स्प्रिंट लक्ष्य से प्रभावित होकर, आने वाले स्प्रिंट के लिए आइटम चुनते हैं, उन आइटम को उत्पाद बैकलॉग से स्प्रिंट बैकलॉग में ले जाते हैं, जो कि उन आइटमों की सूची है जिन्हें वे बनाएंगे। वैचारिक रूप से, स्प्रिंट लक्ष्य सूची के शीर्ष पर उच्च-प्राथमिकता वाली वस्तुओं से प्रभावित होता है, लेकिन यदि स्प्रिंट के भीतर अधिक काम को समायोजित करने के लिए समय बचा है तो डेवलपर्स को कुछ कम-प्राथमिकता वाली वस्तुओं को लेते हुए देखना असामान्य नहीं है।
उच्च-प्राथमिकता वाली वस्तुओं (बैकलॉग के शीर्ष पर) को अधिक विस्तार में विभाजित किया जाना चाहिए जो डेवलपर्स के काम करने के लिए उपयुक्त हों। बैकलॉग जितना नीचे होगा, आइटम उतने ही कम विस्तृत होंगे। जैसा कि श्वाबर और बीडल ने कहा, प्राथमिकता जितनी कम होगी, विवरण उतना ही कम होगा, जब तक कि आप बैकलॉग आइटम को मुश्किल से नहीं निकाल पाते।[16]
जैसा कि टीम बैकलॉग के माध्यम से काम करती है, यह माना जाना चाहिए कि परिवर्तन उनके वातावरण के बाहर होता है - टीम लाभ उठाने के लिए नए बाजार के अवसरों, उत्पन्न होने वाले प्रतिस्पर्धी खतरों और ग्राहकों से प्रतिक्रिया के बारे में सीख सकती है जो उत्पाद के उद्देश्य को बदल सकती है। काम करने के लिए। ये सभी नए विचार टीम को नए ज्ञान को शामिल करने के लिए बैकलॉग को अनुकूलित करने के लिए प्रेरित करते हैं। यह एक चुस्त टीम की मूलभूत मानसिकता का हिस्सा है। दुनिया बदल जाती है, बैकलॉग कभी ख़त्म नहीं होता।[46]
स्प्रिंट बैकलॉग
स्प्रिंट बैकलॉग उत्पाद बैकलॉग से आइटमों का सबसेट है जिसका उद्देश्य डेवलपर्स को आगामी स्प्रिंट में संबोधित करना है।[47] डेवलपर्स इस बैकलॉग को तब तक भरेंगे जब तक उन्हें नहीं लगता कि उनके पास स्प्रिंट भरने के लिए पर्याप्त काम है, अगले स्प्रिंट के लिए क्षमता का आकलन करने के लिए पिछले प्रदर्शन का उपयोग करते हुए, इसे एक दिशानिर्देश के रूप में उपयोग करते हुए कि वे कितना 'प्रयास' पूरा कर सकते हैं।
स्प्रिंट बैकलॉग पर काम कभी भी डेवलपर्स को नहीं सौंपा (या आगे बढ़ाया) जाता है; टीम के सदस्य बैकलॉग प्राथमिकता और अपने कौशल और क्षमता के अनुसार आवश्यकतानुसार काम करते हैं। यह डेवलपर्स के स्व-संगठन को बढ़ावा देता है।
स्प्रिंट बैकलॉग डेवलपर्स की संपत्ति है, और इसमें शामिल सभी अनुमान डेवलपर्स द्वारा प्रदान किए जाते हैं। हालाँकि यह स्क्रम का हिस्सा नहीं है, कुछ टीमें वर्तमान स्प्रिंट में काम की स्थिति की कल्पना करने के लिए एक साथ वाले बोर्ड का उपयोग करती हैं: टूडू, डूइंग, डन।
वृद्धि
वृद्धि स्प्रिंट का संभावित रिलीज़ योग्य आउटपुट है जो स्प्रिंट लक्ष्य को पूरा करता है। यह सभी पूर्ण स्प्रिंट बैकलॉग आइटमों से बनता है, जो पिछले सभी स्प्रिंट के काम के साथ एकीकृत होता है। स्क्रम टीम की डेफिनिशन ऑफ डन (डीओडी) के अनुसार वेतन वृद्धि पूर्ण होनी चाहिए, पूरी तरह से कार्यशील होनी चाहिए, और उपयोग करने योग्य स्थिति में होनी चाहिए, भले ही उत्पाद स्वामी वास्तव में इसे तैनात करने और इसका उपयोग करने का निर्णय लेता है या नहीं।
एक्सटेंशन
लोगों को स्क्रम का उपयोग करने में मदद करने के लिए निम्नलिखित कलाकृतियों और तकनीकों का उपयोग किया जा सकता है।[20]
बर्नडाउन चार्ट
अक्सर स्क्रम में उपयोग किया जाता है (लेकिन स्क्रम का हिस्सा नहीं), बर्नडाउन चार्ट एक सार्वजनिक रूप से प्रदर्शित चार्ट है जो शेष कार्य दिखाता है।[48] हर दिन अपडेट किया जाता है, यह संदर्भ के लिए त्वरित विज़ुअलाइज़ेशन प्रदान करता है। बर्नडाउन चार्ट का क्षैतिज अक्ष शेष दिनों को दर्शाता है, जबकि ऊर्ध्वाधर अक्ष प्रत्येक दिन शेष कार्य की मात्रा को दर्शाता है।
स्प्रिंट योजना के दौरान, आदर्श बर्नडाउन चार्ट तैयार किया जाता है। फिर, स्प्रिंट के दौरान, डेवलपर्स शेष कार्य के साथ चार्ट को अपडेट करते हैं ताकि चार्ट दिन-ब-दिन अपडेट होता रहे, वास्तविक और अनुमानित के बीच तुलना दिखाता रहे।
इसे अर्जित मूल्य प्रबंधन के साथ भ्रमित नहीं किया जाना चाहिए।
बर्न-अप चार्ट जारी करें
रिलीज़ बर्न-अप चार्ट टीम के लिए दृश्यता प्रदान करने और रिलीज़ की दिशा में प्रगति को ट्रैक करने का एक तरीका है। प्रत्येक स्प्रिंट के अंत में अपडेट किया गया, यह पूर्वानुमान का दायरा प्रदान करने की दिशा में प्रगति दिखाता है। रिलीज़ बर्न-अप चार्ट का क्षैतिज अक्ष रिलीज़ में स्प्रिंट को दर्शाता है, जबकि ऊर्ध्वाधर अक्ष प्रत्येक स्प्रिंट के अंत में पूर्ण किए गए कार्य की मात्रा को दर्शाता है (आमतौर पर पूर्ण किए गए कार्य के संचयी कहानी बिंदुओं का प्रतिनिधित्व करता है)। प्रगति को एक रेखा के रूप में चित्रित किया गया है जो एक क्षैतिज रेखा से मिलने के लिए बढ़ती है जो पूर्वानुमान के दायरे का प्रतिनिधित्व करती है; अक्सर आज तक की प्रगति के आधार पर पूर्वानुमान के साथ दिखाया जाता है, जो इंगित करता है कि किसी दिए गए रिलीज़ दिनांक तक कितना दायरा पूरा किया जा सकता है या दिए गए दायरे को पूरा करने में कितने स्प्रिंट लगेंगे।
रिलीज़ बर्न-अप चार्ट यह देखना आसान बनाता है कि कितना काम पूरा हो चुका है, कितना काम जोड़ा या हटाया गया है (यदि क्षैतिज स्कोप लाइन चलती है), और कितना काम किया जाना बाकी है।
तैयार (डीओआर) की परिभाषा
प्रारंभ मानदंड यह निर्धारित करने के लिए कि कार्य आइटम शुरू करने के लिए विनिर्देश और इनपुट स्पष्ट रूप से पर्याप्त रूप से सेट हैं या नहीं।
पूर्ण की परिभाषा (डीओडी)
यह निर्धारित करने के लिए निकास-मानदंड कि स्प्रिंट बैकलॉग आइटम पर काम पूरा हो गया है या नहीं, उदाहरण के लिए: DoD के लिए आवश्यक है कि सभी प्रतिगमन परीक्षण सफल हों। डन की परिभाषा एक टीम से दूसरी टीम में भिन्न हो सकती है लेकिन एक टीम के भीतर सुसंगत होनी चाहिए।[49]
वेग
एक स्प्रिंट के लिए एक टीम की कुल क्षमता का प्रयास, अंतिम स्प्रिंट में पूरे किए गए कार्य के मूल्यांकन से प्राप्त होता है। ऐतिहासिक वेग डेटा का संग्रह टीम को उनकी क्षमता को समझने में सहायता करने के लिए एक दिशानिर्देश है, यानी: वे कितना काम आराम से पूरा कर सकते हैं।
इस मीट्रिक ने स्क्रम समुदाय में विवाद को आकर्षित किया है:
- उपभोग किए गए स्टोरी पॉइंट दिए गए मूल्य के बराबर नहीं हैं: टीम काम पूरा होते देख सकती है और हितधारकों को दिए जाने वाले लाभों को अनदेखा कर सकती है
- ध्यान भटकाने वाली प्रथाओं का परिचय: अनुमान बनाम वास्तविक, विचरण जांच और पुन: अनुमान की नीति उत्पन्न होने लगती है
- प्रबंधन वेग को एक प्रदर्शन मीट्रिक के रूप में देखता है इसलिए इसे बढ़ाने का प्रयास करता है, जिसका अर्थ है:
- गुणवत्ता प्रभावित होती है—टीम अतिरिक्त कार्यभार को शामिल करने के लिए काम में कटौती करना शुरू कर देती है
- मनोबल ख़राब होता है - टीम आरामदायक स्थायी गति से काम करने में असमर्थ होती है और दबाव बढ़ने से जलन होती है
- अनुमान प्रभावित होता है - डेवलपर्स बफ़र्स बनाने और मेट्रिक्स को गेम करने के लिए अनुमान बढ़ाएंगे, एक ही प्रयास को एक अलग पैमाने पर मापेंगे
- मूल्य प्रभावित होता है - अंतिम प्रभाव हस्तक्षेप है जो व्यावसायिक मूल्य वितरण से ध्यान हटाने के परिणामस्वरूप हितधारक के असंतोष का कारण बनता है
हालाँकि किसी टीम की डिलीवरी क्षमता को समझने का महत्व है, वेग को टीम के लिए एक संकेतक माना जाना चाहिए न कि एक डायल जिसे समायोजित किया जा सकता है।
स्पाइक
किसी अवधारणा पर शोध करने या एक सरल प्रोटोटाइप बनाने के लिए टाइम-बॉक्स अवधि का उपयोग किया जाता है। स्पाइक्स को या तो स्प्रिंट के बीच में रखने की योजना बनाई जा सकती है या, बड़ी टीमों के लिए, स्पाइक को कई स्प्रिंट डिलीवरी उद्देश्यों में से एक के रूप में स्वीकार किया जा सकता है। बजट सुरक्षित करने, ज्ञान का विस्तार करने, या अवधारणा का प्रमाण प्रस्तुत करने के लिए स्पाइक्स को अक्सर बड़े या जटिल उत्पाद बैकलॉग आइटम की डिलीवरी से पहले पेश किया जाता है। स्पाइक की अवधि और उद्देश्य पर टीम शुरुआत से पहले सहमत होती है। स्प्रिंट प्रतिबद्धताओं के विपरीत, स्पाइक्स मूर्त, शिपिंग योग्य, मूल्यवान कार्यक्षमता प्रदान कर भी सकते हैं और नहीं भी। उदाहरण के लिए, स्पाइक का उद्देश्य कार्रवाई के किसी निर्णय पर सफलतापूर्वक पहुंचना हो सकता है। समय समाप्त होने पर स्पाइक खत्म हो जाती है, जरूरी नहीं कि जब उद्देश्य पूरा हो गया हो।[50]
ट्रेसर बुलेट
ड्रोन स्पाइक भी कहा जाता है, ट्रेसर बुलेट वर्तमान वास्तुकला, वर्तमान प्रौद्योगिकी सेट, सर्वोत्तम प्रथाओं के वर्तमान सेट के साथ एक स्पाइक है जिसके परिणामस्वरूप उत्पादन गुणवत्ता कोड होता है। यह कार्यक्षमता का एक बहुत ही संकीर्ण कार्यान्वयन हो सकता है लेकिन यह फेंके जाने वाला कोड नहीं है। यह उत्पादन गुणवत्ता का है, और बाकी पुनरावृत्तियों को इस कोड पर बनाया जा सकता है। नाम का सैन्य मूल ट्रेसर गोला-बारूद है जो गोली के मार्ग को दृश्यमान बनाता है, जिससे सुधार की अनुमति मिलती है। अक्सर ये कार्यान्वयन किसी एप्लिकेशन की सभी परतों के माध्यम से एक 'त्वरित शॉट' होते हैं, जैसे कि परतों को अपेक्षित रूप से कनेक्ट करने के लिए एकल फॉर्म के इनपुट फ़ील्ड को बैक-एंड से जोड़ना।[51]
शब्दावली
स्प्रिंट, स्प्रिंट बैकलॉग, डेली स्क्रम, स्प्रिंट रिव्यू और ऐसे अन्य आयोजनों के साथ मिलकर काम करता है।[35]
उत्पाद स्वामी
उत्पाद स्वामी उत्पाद के विकास की वर्तमान स्थिति और उत्पाद के मूल्य को अधिकतम करने के लिए जिम्मेदार है। उत्पाद स्वामी एक व्यक्ति हो सकता है, भले ही वे किसी समिति का प्रतिनिधित्व करते हों।[35]उनके कार्य में शामिल हैं:
- उत्पाद बैकलॉग में आइटम बनाए रखना
- बैकलॉग में आइटमों को ऑर्डर सौंपना
- यह सुनिश्चित करना कि उत्पाद बैकलॉग में आइटम विकास टीम के लिए स्पष्ट हैं[35]
विकास दल
स्प्रिंट बैकलॉग में लेखों के कार्यान्वयन के लिए विकास टीम जिम्मेदार है। हालाँकि विकास टीम के कई सदस्य अलग-अलग क्षेत्रों में विशेषज्ञ हो सकते हैं, लेकिन समग्र रूप से विकास टीम कार्यक्षमता के विकास के लिए जिम्मेदार है।[35]
स्प्रिंट बैकलॉग
स्प्रिंट बैकलॉग उत्पाद बैकलॉग के एक सबसेट को संदर्भित करता है जिसे स्प्रिंट के लिए उसकी डिलीवरी योजना के साथ चुना जाता है। स्प्रिंट बैकलॉग में आइटम के आधार पर, विकास टीम निर्णय लेती है कि वे एक पूर्ण उत्पाद कैसे बनाएंगे।[35]
दैनिक स्क्रम
डेली स्क्रम एक निश्चित समय, निश्चित स्थान की घटना है जो विकास टीम को पिछले डेली स्क्रम के बाद से किए गए काम की मात्रा के आधार पर अगले 24 घंटों के लिए काम को सिंक्रनाइज़ करने और योजना बनाने की अनुमति देता है।[35]दैनिक स्क्रम के दौरान, विकास दल के सदस्य समझाते हैं:
- मैंने कल क्या किया जिससे स्प्रिंट लक्ष्य प्राप्त करने में मदद मिली?
- मैं आज अपने स्प्रिंट लक्ष्य की दिशा में क्या करने जा रहा हूँ?
- मैं अपने स्प्रिंट लक्ष्य को पूरा करने में क्या बाधाएँ देखता हूँ?
दैनिक स्क्रम आमतौर पर 15 मिनट तक चलता है, लेकिन विस्तृत चर्चा के लिए इसके बाद अन्य बैठकें भी की जा सकती हैं।
स्प्रिंट समीक्षा
स्प्रिंट समीक्षा स्प्रिंट समाप्त होने के बाद निर्धारित की गई है। टीम और हितधारक किए गए कार्य की मात्रा का निरीक्षण करते हैं। यदि आवश्यक हो तो उत्पाद स्वामी उत्पाद बैकलॉग को अनुकूलित करता है।[35]स्प्रिंट समीक्षा प्रत्येक स्प्रिंट के अंत में एक निरीक्षण-और-अनुकूलन अवसर है।
स्प्रिंट पूर्वव्यापी
स्प्रिंट रेट्रोस्पेक्टिव का उपयोग यह विश्लेषण करने के लिए किया जाता है कि स्प्रिंट में क्या सही हुआ और क्या सुधार किया जा सकता है। स्क्रम टीम उस वेतन वृद्धि को बनाने के लिए उपयोग की जाने वाली प्रक्रिया की जांच करती है। यह पूर्वव्यापी प्रतिक्रिया स्प्रिंट में अनुसरण की जाने वाली प्रक्रिया को बेहतर बनाने में मदद करती है। स्प्रिंट रेट्रोस्पेक्टिव प्रत्येक स्प्रिंट के अंत में एक निरीक्षण-और-अनुकूलन अवसर है।[52]
सीमाएँ
स्क्रम के लाभों को प्राप्त करना अधिक कठिन हो सकता है:[53][54]
- टीमें जिनके सदस्य भौगोलिक रूप से फैले हुए हैं या अंशकालिक हैं: स्क्रम में, डेवलपर्स को घनिष्ठ और निरंतर बातचीत करनी चाहिए, आदर्श रूप से अधिकांश समय एक ही स्थान पर एक साथ काम करना चाहिए। जबकि प्रौद्योगिकी में हाल के सुधारों ने इन बाधाओं के प्रभाव को कम कर दिया है (उदाहरण के लिए, डिजिटल व्हाइटबोर्ड पर सहयोग करने में सक्षम होना), एजाइल घोषणापत्र का दावा है कि सबसे अच्छा संचार आमने-सामने है।[55]
- टीमें जिनके सदस्यों के पास बहुत विशिष्ट कौशल हैं: स्क्रम में, डेवलपर्स के पास टी-आकार का कौशल होना चाहिए, जिससे उन्हें अपनी विशेषज्ञता के बाहर के कार्यों पर काम करने की अनुमति मिल सके। इसे अच्छे स्क्रम नेतृत्व द्वारा प्रोत्साहित किया जा सकता है। जबकि बहुत विशिष्ट कौशल वाले टीम के सदस्य अच्छा योगदान दे सकते हैं और करते भी हैं, उन्हें अन्य विषयों के बारे में अधिक जानने और उनके साथ सहयोग करने के लिए प्रोत्साहित किया जाना चाहिए।
- कई बाहरी निर्भरता वाले उत्पाद: स्क्रम में, उत्पाद विकास को छोटे स्प्रिंट में विभाजित करने के लिए सावधानीपूर्वक योजना की आवश्यकता होती है; बाहरी निर्भरताएं, जैसे उपयोगकर्ता स्वीकृति परीक्षण या अन्य टीमों के साथ समन्वय, देरी और व्यक्तिगत स्प्रिंट की विफलता का कारण बन सकती हैं।
- उत्पाद जो उत्पाद जीवन-चक्र सिद्धांत या विरासत प्रणाली या विनियमित गुणवत्ता नियंत्रण के साथ हैं: स्क्रम में, उत्पाद वृद्धि को एक ही स्प्रिंट में पूरी तरह से विकसित और परीक्षण किया जाना चाहिए; जिन उत्पादों को प्रत्येक रिलीज़ के लिए बड़ी मात्रा में प्रतिगमन परीक्षण या सुरक्षा परीक्षण (उदाहरण के लिए, चिकित्सा उपकरण या वाहन नियंत्रण) की आवश्यकता होती है, वे लंबे झरना मॉडल रिलीज़ की तुलना में छोटे स्प्रिंट के लिए कम उपयुक्त होते हैं।
उपकरण उपलब्ध
अन्य चुस्त दृष्टिकोणों की तरह, उपलब्ध उपकरणों की एक विस्तृत श्रृंखला के माध्यम से स्क्रम को प्रभावी ढंग से अपनाने का समर्थन किया जा सकता है (लेकिन उस पर निर्भर नहीं)।
कई कंपनियां स्प्रिंट बैकलॉग बनाने और बनाए रखने के लिए स्प्रेडशीट जैसे सार्वभौमिक टूल का उपयोग करती हैं। ऐसे ओपन-सोर्स और मालिकाना सॉफ़्टवेयर पैकेज भी हैं जो उत्पाद विकास के लिए स्क्रम शब्दावली का उपयोग करते हैं या स्क्रम सहित कई उत्पाद विकास दृष्टिकोणों का समर्थन करते हैं।
अन्य संगठन सॉफ्टवेयर टूल के बिना स्क्रम लागू करते हैं और अपनी कलाकृतियों को कागज, व्हाइटबोर्ड और स्टिकी नोट्स जैसे हार्ड-कॉपी रूपों में बनाए रखते हैं।[56]
स्क्रम मान
स्क्रम एक फीडबैक-संचालित अनुभवजन्य दृष्टिकोण है, जो सभी अनुभवजन्य प्रक्रिया नियंत्रण की तरह, पारदर्शिता, निरीक्षण और अनुकूलन के तीन स्तंभों पर आधारित है। स्क्रम ढांचे के भीतर सभी कार्य परिणाम के लिए जिम्मेदार लोगों को दिखाई देने चाहिए: प्रक्रिया, वर्कफ़्लो, प्रगति, आदि। इन चीजों को दृश्यमान बनाने के लिए, स्क्रम टीमों को विकसित किए जा रहे उत्पाद का बार-बार निरीक्षण करने की आवश्यकता है और टीम कितनी अच्छी है कार्यरत। लगातार निरीक्षण से, टीम यह पता लगा सकती है कि उनका काम स्वीकार्य सीमा से बाहर है और अपनी प्रक्रिया या विकास के तहत उत्पाद को अनुकूलित कर सकता है।[27] इन तीन स्तंभों के लिए टीम में विश्वास और खुलेपन की आवश्यकता होती है, जिसे स्क्रम के निम्नलिखित पांच मूल्य सक्षम करते हैं:[20]
- प्रतिबद्धता: टीम के सदस्य व्यक्तिगत रूप से प्रत्येक स्प्रिंट (सॉफ़्टवेयर विकास) में अपनी टीम के लक्ष्यों को प्राप्त करने के लिए प्रतिबद्ध हैं
- साहस: टीम के सदस्यों को पता है कि उनमें संघर्ष और चुनौतियों से मिलकर काम करने का साहस है ताकि वे सही काम कर सकें
- फोकस: टीम के सदस्य विशेष रूप से अपनी टीम के लक्ष्यों और स्प्रिंट बैकलॉग पर ध्यान केंद्रित करते हैं; उनके बैकलॉग के अलावा कोई काम नहीं होना चाहिए
- खुलापन: टीम के सदस्य और उनके हितधारक अपने काम और उनके सामने आने वाली किसी भी चुनौती के बारे में पारदर्शी होने के लिए सहमत हैं
- सम्मान: टीम के सदस्य तकनीकी रूप से सक्षम होने और अच्छे इरादे से काम करने के लिए एक-दूसरे का सम्मान करते हैं
अनुकूलन
कई अलग-अलग उद्देश्यों को प्राप्त करने के लिए स्क्रम का उपयोग विभिन्न संदर्भों में किया जाता है। उन अलग-अलग लक्ष्यों को पूरा करने के लिए, स्क्रम को अक्सर अनुकूलित या अनुकूलित किया जाता है।[57] स्क्रम को अनुकूलित करने का एक सामान्य तरीका अन्य सॉफ़्टवेयर विकास पद्धतियों के साथ स्क्रम का संकरण है क्योंकि स्क्रम संपूर्ण सॉफ़्टवेयर जीवनचक्र को कवर नहीं करता है; इसलिए, संगठनों को अधिक व्यापक कार्यान्वयन बनाने के लिए अतिरिक्त प्रक्रियाओं को जोड़ने की आवश्यकता महसूस होती है। उदाहरण के लिए, उत्पाद विकास की शुरुआत में, संगठन आमतौर पर व्यावसायिक मामले पर प्रक्रिया मार्गदर्शन, आवश्यकताओं को इकट्ठा करना और प्राथमिकता देना, प्रारंभिक उच्च-स्तरीय डिज़ाइन और बजट और शेड्यूल पूर्वानुमान जोड़ते हैं।[58] विभिन्न लेखकों और स्क्रम का उपयोग करने वाले लोगों के समुदायों ने विशेष समस्याओं या संगठनों के लिए स्क्रम को कैसे लागू किया जाए या अनुकूलित किया जाए, इसके लिए अधिक विस्तृत तकनीकों का सुझाव दिया है। कई लोग इन पद्धतिगत तकनीकों को 'पैटर्न' के रूप में संदर्भित करते हैं - वास्तुकला और सॉफ्टवेयर में डिज़ाइन पैटर्न के अनुरूप।[59][60]
टूटना
स्क्रमबन एक सॉफ्टवेयर उत्पादन मॉडल है जो स्क्रम और कानबन (विकास) पर आधारित है। स्क्रंबन विशेष रूप से सॉफ़्टवेयर बग या प्रोग्रामिंग त्रुटियों जैसे बार-बार और अप्रत्याशित कार्य आइटम वाले सॉफ़्टवेयर रखरखाव के लिए उपयुक्त है। ऐसे मामलों में स्क्रम ढांचे के समय-सीमित स्प्रिंट को कम लाभकारी माना जा सकता है, हालांकि टीम और मौजूदा स्थिति के आधार पर स्क्रम की दैनिक घटनाओं और अन्य प्रथाओं को अभी भी लागू किया जा सकता है। कार्य चरणों का विज़ुअलाइज़ेशन और एक साथ अधूरे कार्य और दोषों की सीमाएं कानबन मॉडल से परिचित हैं। इन विधियों का उपयोग करते हुए, टीम के कार्यप्रवाह को इस तरह से निर्देशित किया जाता है कि प्रत्येक कार्य आइटम या प्रोग्रामिंग त्रुटि के लिए न्यूनतम पूरा होने का समय मिलता है, और दूसरी ओर यह सुनिश्चित होता है कि टीम का प्रत्येक सदस्य लगातार कार्यरत है।[61] काम के प्रत्येक चरण को स्पष्ट करने के लिए, एक ही स्थान पर काम करने वाली टीमें अक्सर पोस्ट-इट नोट्स या एक बड़े व्हाइटबोर्ड का उपयोग करती हैं।[62] विकेन्द्रीकृत टीमों के मामले में, ट्रैक के लिए इकट्ठा, जिरा (सॉफ्टवेयर) या एगिलो जैसे स्टेज-चित्रण सॉफ़्टवेयर का उपयोग किया जा सकता है।
स्क्रम और कानबन के बीच मुख्य अंतर यह है कि स्क्रम में काम को स्प्रिंट में विभाजित किया जाता है जो एक निश्चित समय तक चलता है, जबकि कानबन में काम का प्रवाह निरंतर होता है। यह कार्य चरण तालिकाओं में दिखाई देता है, जो स्क्रम में प्रत्येक स्प्रिंट के बाद खाली हो जाते हैं, जबकि कानबन में सभी कार्यों को एक ही तालिका में चिह्नित किया जाता है। स्क्रम बहुमुखी जानकारी वाली टीमों पर ध्यान केंद्रित करता है, जबकि कानबन विशिष्ट, कार्यात्मक टीमों को संभव बनाता है।[61]
जमघट का जमघट
स्क्रम ऑफ़ स्क्रम एक ही उत्पाद पर काम करने वाली कई टीमों के लिए बड़े पैमाने पर स्क्रम को संचालित करने की एक तकनीक है, जो उन्हें अपनी अन्योन्याश्रितताओं पर प्रगति पर चर्चा करने की अनुमति देती है, वितरण सॉफ़्टवेयर को समन्वयित करने के तरीके पर ध्यान केंद्रित करती है,[63]विशेषकर ओवरलैप और एकीकरण के क्षेत्रों पर। स्क्रम के स्क्रम के ताल (समय) के आधार पर, प्रत्येक स्क्रम टीम के लिए प्रासंगिक दैनिक स्क्रम अन्य टीमों के राजदूतों के साथ स्क्रम के स्क्रम में भाग लेने के लिए एक सदस्य को राजदूत के रूप में नामित करके समाप्त होता है। संदर्भ के आधार पर, राजदूत तकनीकी योगदानकर्ता या प्रत्येक टीम के स्क्रम मास्टर हो सकते हैं।[63] केवल प्रगति अद्यतन के बजाय, स्क्रम्स के समूह को इस बात पर ध्यान केंद्रित करना चाहिए कि पहचाने गए किसी भी जोखिम, बाधाओं, निर्भरताओं और मान्यताओं (आरआईडीए) को हल करने, कम करने या स्वीकार करने के लिए टीमें सामूहिक रूप से कैसे काम कर रही हैं। स्क्रम्स का समूह इन आरआईडीए को अपने स्वयं के बैकलॉग के माध्यम से ट्रैक करता है, जैसे जोखिम बोर्ड (कभी-कभी हल, स्वामित्व, स्वीकृत और कम किए गए के शुरुआती अक्षर के बाद आरओएएम बोर्ड के रूप में जाना जाता है),[64] जो आम तौर पर टीमों के बीच अधिक समन्वय और सहयोग की ओर ले जाता है।[63]
यह दैनिक घोटाले के समान चलना चाहिए, जिसमें प्रत्येक राजदूत निम्नलिखित चार प्रश्नों का उत्तर देगा:[65]
- पिछली मुलाकात के बाद से आपकी टीम ने किन जोखिमों, बाधाओं, निर्भरताओं या धारणाओं का समाधान किया है?
- दोबारा मिलने से पहले आपकी टीम किन जोखिमों, बाधाओं, निर्भरताओं या धारणाओं का समाधान करेगी?
- क्या कोई नए जोखिम, बाधाएं, निर्भरताएं या धारणाएं हैं जो आपकी टीम को धीमा कर रही हैं या उनके रास्ते में आ रही हैं?
- क्या आप कोई नया जोखिम, बाधा, निर्भरता, या धारणा पेश करने वाले हैं जो दूसरी टीम के रास्ते में आ जाएगी?
जैसा कि जेफ़ सदरलैंड ने टिप्पणी की,[63]
<ब्लॉककोट>चूंकि मैंने मूल रूप से स्क्रम ऑफ स्क्रम्स को परिभाषित किया था (केन श्वाबर आईडीएक्स में मेरे साथ काम कर रहे थे), मैं निश्चित रूप से कह सकता हूं कि स्क्रम्स ऑफ स्क्रम्स एक 'मेटा स्क्रम्स' नहीं है। जैसा कि मैंने उपयोग किया है, स्क्रम ऑफ़ स्क्रम सभी टीमों के कामकाजी सॉफ़्टवेयर को स्प्रिंट के अंत में डन की परिभाषा तक, या स्प्रिंट के दौरान रिलीज़ के लिए वितरित करने के लिए ज़िम्मेदार है। पेशेंटकीपर ने प्रति स्प्रिंट चार बार उत्पादन पहुंचाया। Ancestry.com प्रति दो सप्ताह के स्प्रिंट में 220 बार उत्पादन प्रदान करता है। हबस्पॉट दिन में 100-300 बार लाइव सॉफ़्टवेयर वितरित करता है। इस कार्य को करने के लिए स्क्रम ऑफ़ स्क्रम्स मास्टर को जिम्मेदार ठहराया जाता है। तो स्क्रम ऑफ स्क्रम्स एक परिचालन वितरण तंत्र है।
बड़े पैमाने का घोटाला
लार्ज-स्केल स्क्रम (LeSS) एक उत्पाद विकास ढांचा है जो स्क्रम के मूल उद्देश्यों को खोए बिना स्केलिंग नियमों और दिशानिर्देशों के साथ स्क्रम का विस्तार करता है।
रूपरेखा के दो स्तर हैं: पहला एलईएसएस स्तर अधिकतम आठ टीमों के लिए डिज़ाइन किया गया है; दूसरा स्तर, जिसे 'LeSS Huge' के नाम से जाना जाता है, सैकड़ों डेवलपर्स के साथ विकास के लिए अतिरिक्त स्केलिंग तत्व पेश करता है। स्केलिंग स्क्रम मानक वास्तविक एक-टीम स्क्रम को समझने और अपनाने में सक्षम होने से शुरू होती है। बड़े पैमाने के स्क्रम के लिए एकल-टीम स्क्रम तत्वों के उद्देश्य की जांच करना और यह पता लगाना आवश्यक है कि मानक स्क्रम नियमों की बाधाओं के भीतर रहते हुए उसी उद्देश्य तक कैसे पहुंचा जाए।[66] बास वोड्डे और क्रेग लर्मन ने बड़े पैमाने पर उत्पाद विकास, विशेष रूप से दूरसंचार और वित्त उद्योगों में काम करने के अपने अनुभवों से एलईएसएस ढांचे को विकसित किया। यह स्क्रम को लेकर और क्या काम करता है यह जानने के लिए कई अलग-अलग प्रयोगों को आजमाकर विकसित हुआ। 2013 में, प्रयोगों को LeSS फ्रेमवर्क नियमों में समेकित किया गया।[67] LeSS का इरादा संगठन की जटिलता को 'डीस्केल' करना, अनावश्यक जटिल संगठनात्मक समाधानों को समाप्त करना और उन्हें सरल तरीकों से हल करना है। कम भूमिकाएँ, कम प्रबंधन, कम संगठनात्मक संरचनाएँ।[68]
आलोचना
बताया गया है कि स्क्रम इवेंट उत्पादकता को नुकसान पहुंचा रहे हैं और समय बर्बाद कर रहे हैं जिसे वास्तविक उत्पादक कार्यों पर बेहतर तरीके से खर्च किया जा सकता है।[69][70] आमतौर पर घटना के उद्देश्य और लक्ष्य की गलतफहमी के कारण होता है।[71] कई स्क्रम कार्यान्वयनकर्ता, दैनिक स्क्रम की तरह, एक संक्षिप्त समय-सीमा वाली चर्चा के बजाय एक संपूर्ण स्थिति बैठक के रूप में आयोजन करते हैं। स्क्रम प्रथाएं बहुत तेजी से micromanagement के रूप में बदल सकती हैं और उसी शिथिलता को फिर से प्रस्तुत कर सकती हैं जिसे प्रथाओं ने दूर करने की मांग की थी। स्क्रम यह भी मानता है कि काम पूरा करने के लिए आवश्यक प्रयास का सटीक अनुमान लगाया जा सकता है, हालांकि अक्सर यह काफी पूर्वानुमानित हो सकता है।[72] स्क्रम जानबूझकर अनुदेशात्मक प्रथाओं को छोड़ देता है[73] अनुभवजन्य विश्लेषण और प्रयोग की स्वतंत्रता को प्रोत्साहित करना। सामान्य दुष्क्रियात्मक दृष्टिकोण[74] स्क्रम को अब एंटी-पैटर्न | एंटी-पैटर्न के रूप में मान्यता दी गई है, जिसमें डार्क स्क्रम भी शामिल है[75] और चिल्लाओ.[76]
यह भी देखें
- चंचल सॉफ्टवेयर विकास
- अनुशासित त्वरित वितरण
- स्क्रम सॉफ्टवेयर की तुलना
- उच्च प्रदर्शन वाली टीमें
- लीन सॉफ्टवेयर विकास
- परियोजना प्रबंधन
- एकीकृत प्रक्रिया
उद्धरण
- ↑ "Lessons learned: Using Scrum in non-technical teams". Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
- ↑ "How to Choose a Software Development Methodology" Robotics & Automation. Retrieved 2023-06-20.
- ↑ 3.0 3.1 3.2 3.3 Ken Schwaber, Jeff Sutherland. "स्क्रम गाइड" (PDF). Scrum.org. Retrieved June 15, 2023.
{{cite web}}: CS1 maint: uses authors parameter (link) - ↑ Takeuchi, Hirotaka; Nonaka, Ikujiro. "नया नया उत्पाद विकास खेल" (PDF). Archived from the original (PDF) on February 9, 2021. Retrieved April 7, 2021.
- ↑ "Scrum, What's in a Name? – DZone Agile". dzone.com.
- ↑ "Should "SCRUM" be written in all caps?". stackoverflow.com. Retrieved January 10, 2017.
- ↑ "Scrum.org केन श्वाबर". Retrieved February 13, 2022.
- ↑ Schwaber, Ken (2004). "SCRUM विकास प्रक्रिया" (PDF). Advanced Development Methods.
- ↑ Johnson, Hillary Louise (January 13, 2011). "ScrumMaster vs scrum master: What do you think?". agilelearninglabs.com. Retrieved May 10, 2017.
- ↑ "What is Scrum?". What is Scrum? An Agile Framework for Completing Complex Projects – Scrum Alliance. Scrum Alliance. Retrieved February 24, 2016.
- ↑ Verheyen, Gunther (March 21, 2013). "Scrum: Framework, not methodology". Gunther Verheyen. Gunther Verheyen. Retrieved February 24, 2016.
- ↑ Leaders, Emerging; Sennett, Phil (2022-01-24). "चुस्त बनाम पारंपरिक परियोजना प्रबंधन". Emerging Leaders (in English). Retrieved 2023-05-14.
- ↑ J. Henry and S. Henry. Quantitative assessment of the software maintenance process and requirements volatility. In Proc. of the ACM Conference on Computer Science, pages 346–351, 1993.
- ↑ 14.0 14.1 14.2 Takeuchi, Hirotaka; Nonaka, Ikujiro (January 1, 1986). "नया नया उत्पाद विकास खेल". Harvard Business Review. Retrieved June 9, 2010.
Moving the Scrum Downfield
- ↑ ज्ञान सृजन कंपनी. Oxford University Press. 1995. p. 3. ISBN 9780199762330. Retrieved March 12, 2013.
- ↑ 16.0 16.1 16.2 16.3 16.4 Schwaber, Ken (February 1, 2004). स्क्रम के साथ चुस्त परियोजना प्रबंधन. Microsoft Press. ISBN 978-0-7356-1993-7.
- ↑ 17.0 17.1 Sutherland, Jeff (October 2004). "Agile Development: Lessons learned from the first Scrum". Archived from the original (PDF) on June 30, 2014. Retrieved September 26, 2008.
- ↑ 18.0 18.1 Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business object design and implementation: OOPSLA '95 workshop proceedings. The University of Michigan. p. 118. ISBN 978-3-540-76096-2.
- ↑ "एजाइल सॉफ्टवेयर विकास के लिए घोषणापत्र". Retrieved October 17, 2019.
- ↑ 20.0 20.1 20.2 20.3 20.4 20.5 20.6 20.7 20.8 Sutherland, Jeff; Schwaber, Ken (2013). "स्क्रम मार्गदर्शिकाएँ". ScrumGuides.org. Retrieved June 15, 2023.
- ↑ Schwaber, Ken; Beedle, Mike (2002). स्क्रम के साथ चुस्त सॉफ्टवेयर विकास. Prentice Hall. ISBN 978-0-13-067634-4.
- ↑ Maximini, Dominik (January 8, 2015). The Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals. Cham: Springer (published 2015). p. 26. ISBN 9783319118277. Retrieved August 25, 2016.
Ken Schwaber and Jeff Sutherland presented Scrum for the first time at the OOPSLA conference in Austin, Texas, in 1995. [...] In 2001, the first book about Scrum was published. [...] One year later (2002), Ken founded the Scrum Alliance, aiming at providing worldwide Scrum training and certification.
- ↑ "घर". Scrum.org (in English). Retrieved January 6, 2020.
- ↑ Partogi, Joshua (July 7, 2013). "प्रमाणित स्क्रम मास्टर बनाम प्रोफेशनल स्क्रम मास्टर". Lean Agile Institute. Retrieved May 10, 2017.
- ↑ 25.0 25.1 McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage (in English). Addison-Wesley Professional. ISBN 9780134686653.
- ↑ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English), Addison-Wesley, p. 173, ISBN 978-0-13-704329-3
- ↑ 27.0 27.1 27.2 27.3 Morris, David (2017). Scrum: an ideal framework for agile projects. In Easy Steps. pp. 178–179. ISBN 9781840787313. OCLC 951453155.
- ↑ 28.0 28.1 28.2 Cohn, Mike (2010). Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0321579362.
- ↑ "स्क्रम गाइड" (PDF). Scrum.org. p. 6. Retrieved June 15, 2023.
- ↑ "उत्पाद स्वामी की भूमिका". Scrum Alliance. Retrieved May 26, 2018.
- ↑ Pichler, Roman (March 11, 2010). Agile Product Management with Scrum: Creating Products that Customers Love (in English). Addison-Wesley Professional. ISBN 978-0-321-68413-4.
- ↑ Ambler, Scott. "The Product Owner Role: A Stakeholder Proxy for Agile Teams". agilemodeling.com. Retrieved July 22, 2016.
[...] in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
- ↑ "उत्पाद स्वामी की भूमिका". Scrum Master Test Prep. Retrieved February 3, 2017.
- ↑ Rad, Nader K.; Turley, Frank (2018). एजाइल स्क्रम फाउंडेशन कोर्सवेयर, दूसरा संस्करण. 's-Hertogenbosch, Netherlands: Van Haren. p. 26. ISBN 9789401802796.
- ↑ 35.0 35.1 35.2 35.3 35.4 35.5 35.6 35.7 Ken Schwaber, Jeff Sutherland. "स्क्रम गाइड" (PDF). Scrum.org. Retrieved May 25, 2018.
{{cite web}}: CS1 maint: uses authors parameter (link) - ↑ Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken, NJ: John Wiley & Sons. p. 37. ISBN 9781118991046.
- ↑ 37.0 37.1 37.2 Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (December 17, 2012). "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)". InfoQ.
- ↑ Marta Dunajko (March 3, 2022). "Planning in Scrum – how to make it effective?". Neurosys.com. Retrieved 2022-08-04.
- ↑ "What is a Daily Scrum?". Scrum.org. Retrieved January 6, 2020.
- ↑ "Asynchronous Stand-Up Meetings: A Guide for Managers".
- ↑ Flewelling, Paul (2018). The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology. Birmingham, UK: Packt Publishing Ltd. p. 91. ISBN 9781787280205.
- ↑ McKenna, Dave (2016). The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility (in English). Aliquippa, PA: CA Press. p. 126. ISBN 9781484222768.
- ↑ Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps. Birmingham, UK: Packt Publishing Ltd. p. 43. ISBN 9781786467041.
- ↑ Higgins, Tony (March 31, 2009). "एक चंचल दुनिया में लेखन संबंधी आवश्यकताएँ". BA Times.
- ↑ "The product backlog: your ultimate to-do list". Atlassian. Retrieved July 20, 2016.
- ↑ Pichler, Roman. Agile Product Management with Scrum: Creating Products that Customers Love. Upper Saddle River, NJ: Addison-Wesley, 2010.[need quotation to verify]
- ↑ Russ J. Martinelli; Dragan Z. Milosevic (January 5, 2016). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. p. 304. ISBN 978-1-118-97320-2.
- ↑ Charles G. Cobb (January 27, 2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. John Wiley & Sons. p. 378. ISBN 978-1-118-99104-6.
- ↑ Ken Schwaber, Agile Project Management with Scrum, p.55
- ↑ "एक स्पाइक समाधान बनाएं". Extreme Programming.
- ↑ Sterling, Chris (October 22, 2007). "अनुसंधान, स्पाइक्स, ट्रेसर बुलेट्स, ओह माय!". Getting Agile. Retrieved October 23, 2016.
- ↑ Rubin, Kenneth (2012), Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English), Addison-Wesley (published 2013), p. 375, ISBN 978-0-13-704329-3
- ↑ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. "एजाइल सॉफ़्टवेयर प्रक्रियाओं की सीमाएँ". Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering: 43–46. arXiv:1409.6600.
- ↑ "स्क्रम कार्यान्वयन में मुद्दे और चुनौतियाँ" (PDF). International Journal of Scientific & Engineering Research. 3 (8). August 2012. Retrieved December 10, 2015.
- ↑ Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "एजाइल मेनिफेस्टो के पीछे के सिद्धांत". Agile Alliance. Retrieved August 7, 2017.
- ↑ Dubakov, Michael (2008). "चंचल उपकरण. अच्छा, बुरा और बदसूरत" (PDF). Retrieved August 30, 2010.
- ↑ Hron, Michal; Obwegeser, Nikolaus (January 1, 2022). "Why and how is Scrum being adapted in practice: A systematic review". Journal of Systems and Software (in English). 183: 111110. doi:10.1016/j.jss.2021.111110. ISSN 0164-1212. S2CID 240950847.
- ↑ Hron, M.; Obwegeser, N. (January 2018). "Scrum in practice: an overview of Scrum adaptations" (PDF). Proceedings of the 2018 51st Hawaii International Conference on System Sciences (HICSS), January 3–6, 2018.
- ↑ Bjørnvig, Gertrud; Coplien, Jim (June 21, 2008). "संगठनात्मक पैटर्न के रूप में स्क्रम". Gertrude & Cope.
- ↑ "स्क्रम पैटर्न समुदाय". ScrumPLoP.org. Retrieved July 22, 2016.
- ↑ 61.0 61.1 Kniberg, Henrik; Skarin, Mattias (December 21, 2009). "Kanban and Scrum – Making the most of both" (PDF). InfoQ. Retrieved July 22, 2016.
- ↑ Ladas, Corey (October 27, 2007). "स्क्रम में". Lean Software Engineering. Archived from the original on August 23, 2018. Retrieved September 13, 2012.
- ↑ 63.0 63.1 63.2 63.3 "स्क्रम का स्क्रम". Agile Alliance. December 17, 2015. Archived from the original on February 9, 2014. Retrieved December 17, 2013.
- ↑ "Risk Management – How to Stop Risks from Screwing Up Your Projects!". Kelly Waters.
- ↑ "स्क्रम का स्क्रम". Scrum Master Test Prep. Retrieved May 29, 2015.
- ↑ Larman; scrumyear=2013. "Scaling Agile Development (Crosstalk journal, November / December 2013)" (PDF).
- ↑ "बड़े पैमाने पर स्क्रम (LeSS)". 2014.
- ↑ Grgic (2015). "LeSS के साथ स्केलिंग संगठन (ब्लॉग)".
- ↑ Jenson, John (March 8, 2019). "Meetings: The productivity killer for developers". TandemSeven – The Experience Innovation Company. Retrieved June 5, 2020.
- ↑ "Not all developers like agile, and here are 5 reasons why". Business Matters. December 4, 2019. Retrieved June 5, 2020.
- ↑ "5 Dysfunctions of a Daily Scrum". Scrum.org (in English). Retrieved July 3, 2021.
- ↑ Cagle, Kurt. "चंचलता का अंत". Forbes. Retrieved June 5, 2020.
- ↑ James (MJ), Michael (March 29, 2021). "केन श्वाबर ने जानबूझकर स्क्रम से जो चीज़ें छोड़ीं". The Seattle Scrum Company (in English). Retrieved July 3, 2021.
- ↑ Derecskey, Dave (July 18, 2018). "5 Common Team Dysfunctions (and How the 5 Core Scrum Values Directly Address Them)". Medium (in English). Retrieved July 3, 2021.
- ↑ "डार्क स्क्रम". ronjeffries.com. Retrieved July 3, 2021.
- ↑ "चीख गाइड". Google Docs (in English). Retrieved July 3, 2021.
संदर्भ
- Vacaniti, Daniel (February 2018). "The Kanban Guide for Scrum Teams" (PDF). scrum.org. Retrieved March 12, 2018.
- Verheyen, Gunther (2013). Scrum – A Pocket Guide (A Smart Travel Companion) ISBN 978-9087537203.
- Münch, Jürgen; Armbrust, Ove; Soto, Martín; Kowalczyk, Martin (2012). Software Process Definition and Management. ISBN 978-3-642-24291-5.
- Rubin, Kenneth (2013). Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English). Addison-Wesley. p. 173. ISBN 978-0-13-704329-3.
- Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas (2009). "The Scrum Primer". Retrieved June 1, 2009.
- Janoff, N.S.; Rising, L. (2000). "The Scrum Software Development Process for Small Teams" (PDF). Archived from the original (PDF) on November 6, 2015. Retrieved February 26, 2015.
बाहरी संबंध
- Agile Alliance's Scrum library
- A scrum process description by the Eclipse process framework (EPF) project
| Fields | |||||||
|---|---|---|---|---|---|---|---|
| Concepts |
| ||||||
| Orientations | |||||||
| Models |
| ||||||
| Related fields | |||||||
