स्क्रम (सॉफ़्टवेयर विकास)
| Part of a series on |
| Software development |
|---|
स्क्रम एक सफुर्तिमान परियोजना प्रबंधन प्रणाली है जिसका उपयोग सामान्यतः सॉफ्टवेयर विकास में किया जाता है, यद्यपि इसका उपयोग अनुसंधान, बिक्री, विपणन, शिक्षा और उन्नत तकनीकी में उपयोग किया जाता है।[1] इसे दस या उससे कम सदस्यों की टीमों के लिए प्रारूपित किया गया है जो अपने काम को समय-सीमा के अंतर्गत पूरा करने के लिए लक्ष्यों में विभाजित करते हैं, जिन्हें स्प्रिंट के नाम से जाना जाता है।[2]
प्रत्येक स्प्रिंट एक महीने से अधिक का नहीं होता है और सामान्यतः यह दो सप्ताह तक रहता है। स्क्रम टीम द्वारा प्रगति का मूल्यांकन विशेषकर प्रतिदिन होता है यह बैठक अधिकतम 15 मिनट तक की होती है। और इसे दैनिक स्क्रम के नाम से जाना जाता है। स्प्रिंट के अंत में, टीम दो और बैठक करती है: पहली स्प्रिंट समीक्षा, जिसका उद्देश्य स्टॉक धारक के लिए किया गया काम दिखाना है और प्रतिक्रिया लेना है, और दूसरी स्प्रिंट अवलोकन, जिसका उद्देश्य टीम को प्रतिबिंबित करने और सुधार करने की सुविधा प्रदान करना है।
मुख्य विचार
स्क्रम जटिल उत्पादों को विकसित करने, वितरित करने और बनाए रखने के लिए एक सरल, पुनरावृत्त और वृद्धिशील संरचना है।[4][5]उत्पाद विकास के अनुक्रमिक दृष्टिकोण के विपरीत, स्क्रम संरचनाओ को निरंतर प्रतिक्रिया और लचीलेपन की अनुमति देने के लिए विकसित किया गया था, जिसमें टीमों को स्वयं-संगठित होने की अनुमति है और सभी टीम सदस्यों के बीच शारीरिक सहयोग या कटिबद्ध ऑनलाइन सहयोग को बढ़ावा देने के साथ ही सभी टीम सदस्यों और संबंधित विषयों के बीच प्रतिदिन मुखाक्षी संचार को भी प्रोत्साहित करता है।[6][7]
स्क्रम का एक प्रमुख सिद्धांत दोहरी मान्यता है कि ग्राहक विशेष चाहने वाले क्या हैं और अप्रत्याशित चुनौतियाँ होंगी, जिसके लिए एक पूर्वानुमानित या योजित दृष्टिकोण उपयुक्त नहीं होता। ये परिवर्तन विभिन्न स्रोतों से आते हैं, परंतु स्क्रम के अनुसार, इसके पीछे का कारण स्वार्थहीन है और परिवर्तन को सरलता से स्वीकार किया जाना चाहिए, और लाभों के लिए विश्लेषण किया जाना चाहिए।
स्क्रम के उत्पाद विकास की योजना और प्रबंधन के प्रति दृष्टिकोण में संचालन गुणों और निश्चितताओं के स्तर पर निर्णय लेने की सम्मिलित योजना होता है।
इतिहास
सॉफ़्टवेयर डेवलपमेंट शब्द स्क्रम का उपयोग पहली बार 1986 में हिरोताका टेकुची और इकुजिरो नोनाका द्वारा "द" न्यू प्रोडक्ट डेवलपमेंट गेम" शीर्षक वाले पेपर में किया गया था।[8] स्क्रम शब्द रग्बी से लिया गया है[9], जिसका अर्थ है खिलाड़ियों का गठन। पेपर के लेखकों ने टीम वर्क पर जोर देने के लिए इस खेल शब्द, स्क्रम का प्रयोग किया, क्योंकि टीम के सदस्यों का घनिष्ठ, दैनिक सहयोग परियोजना प्रबंधन के संरचनाओ की एक विशिष्ट विशेषता है। यह पेपर हार्वर्ड बिजनेस रिव्यू के जनवरी 1986 के अंक में प्रकाशित किया गया था।
टेकुची और नोनाका ने बाद में द नॉलेज क्रिएटिंग कंपनी में तर्क दिया कि यह "संगठनात्मक ज्ञान निर्माण का एक रूप है, [...] विशेष रूप से निरंतर, वृद्धिशील और सर्पिल रूप से नवाचार लाने में अच्छा है"
ऑटोमोटिव, फोटोकॉपियर और प्रिंटर उद्योगों में विनिर्माण फर्मों के केस अध्ययनों के आधार पर लेखकों ने वाणिज्यिक उत्पाद विकास के लिए एक नए दृष्टिकोण का वर्णन किया है जो गति और लचीलेपन को बढ़ाएगा। उन्होंने इसे रग्बी दृष्टिकोण कहा, क्योंकि यह प्रक्रिया एक क्रॉस-फ़ंक्शनल टीम द्वारा कई ओवरलैपिंग चरणों में की जाती है, जिसमें टीम "एक इकाई के रूप में दूरी तय करने की कोशिश करती है, गेंद को आगे और पीछे पास करती है[9]
स्क्रम रूपरेखा ड्यूपॉन्ट रिसर्च स्टेशन और डेलावेयर विश्वविद्यालय में बाबाटुंडे ओगुनैके के साथ श्वाबर के शोध पर आधारित थी। ओगुन्नाइक का सुझाव है कि सॉफ़्टवेयर जैसे जटिल उत्पादों को विकसित करने का प्रयास, जो अनुभववाद पर आधारित नहीं थे, प्रारंभिक स्थितियों और धारणाओं में बदलाव के कारण उच्च जोखिम और विफलता की दर का अनुभव कर सकते हैं।[10]
दशक 1990 के प्रारंभ में, केन श्वाबर ने अपनी कंपनी, एडवांस्ड डेवलपमेंट मैथड्स में वह प्रयोग किया था जो स्क्रम के रूप में बन गया है; जबकि जेफ सदरलैंड, जॉन स्कमनियोटेल्स और जेफ मकेना ने इसके समरूप दृष्टिकोण का विकास ईज़ल कॉरपोरेशन में किया, उसे इसी एकल शब्द स्क्रम का उपयोग करके संदर्भित किया गया।[11]
सदरलैंड और श्वाबर ने साथ मिलकर अपने विचारों को एक संयोजित ढांचे में एकीकृत करने के लिए काम किया: स्क्रम। उन्होंने स्क्रम का परीक्षण किया और निरंतर सुधार किया, जिससे 1995 के पेपर[12] 2001 में एजाइल सॉफ़्टवेयर विकास के लिए प्रमाणपत्र [19], और 2002 के बाद से स्क्रम का विश्वव्यापी प्रसार और उपयोग हुआ।[13]
1995 में, सदरलैंड और श्वाबर ने संयुक्त रूप से एक पेपर प्रस्तुत किया, जिसमें स्क्रम ढांचा का वर्णन किया गया, जो टेक्सास के ऑस्टिन में आयोजित ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग, सिस्टम, भाषाएं और अनुप्रयोगों '95 के भाग के रूप में हुए बिजनेस ऑब्जेक्ट डिज़ाइन और कार्यान्वयन के कार्यशाला में आयोजित हुआ। [13]आगामी वर्षों में, श्वाबर और सदरलैंड ने इस सामग्री को अपने अनुभव और विकसित अच्छे प्रथानुसार के साथ मिलाकर मिलाया और विकसित किया, जिसे बाद में स्क्रम के नाम से जाना जाने लगा।[14]
2001 में, श्वाबर ने माइक बीडल के साथ मिलकर किताब "एजाइल सॉफ़्टवेयर विकास विथ स्क्रम" में इस विधि का वर्णन किया। यह किताब सॉफ़्टवेयर विकास के संदर्भ में स्क्रम ढांचा को समझने और अमल में लाने के लिए एक संपूर्ण मार्गदर्शिका के रूप में कार्य करती है।[15]
2002 में, श्वाबर ने अन्य सहयोगियों के साथ स्क्रम एलायंस की स्थापना की और प्रमाणित स्क्रम प्रमाणीकरण श्रृंखला की स्थापना की।[10] श्वाबर ने 2009 के अंतिम दिनों में स्क्रम एलायंस को छोड़ दिया और स्क्रम.(Scrum.org) की स्थापना की, जो समानांतर व्यवसायी स्क्रम प्रमाणीकरण श्रृंखला का पर्यवेक्षण करता है।[16]
2009 से श्वाबर और सदरलैंड द्वारा 'द स्क्रम गाइड' नामक एक सार्वजनिक दस्तावेज़ प्रकाशित और अपडेट किया जा रहा है। इसे 6 बार संशोधित किया गया है, और वर्तमान संस्करण नवंबर 2020 है।
स्क्रम टीम
स्क्रम की मौलिक इकाई एक छोटी सी टीम होती है, जिसमें एक प्रोडक्ट ओनर, एक स्क्रम मास्टर और डेवलपर्स होते हैं। टीम आत्म-प्रबंधित, समसामयिक कार्यात्मक होती है और एक समय में केवल एक उद्देश्य पर ध्यान केंद्रित करती है।
प्रोडक्ट ओनर
प्रोडक्ट ओनर, उत्पाद के हितधारक और ग्राहक की आवाज का प्रतिनिधित्व करते हुए [17], अच्छे व्यावसायिक परिणाम देने के लिए उत्तरदायी होता है।[18] इसलिए, प्रोडक्ट ओनर उत्पाद बैकलॉग और टीम द्वारा प्रदान किए जाने वाले मूल्य को अधिकतम करने के लिए उत्तरदायी होता है। प्रोडक्ट ओनर उत्पाद को ग्राहक-केंद्रित परिणामों के संदर्भ में परिभाषित करता है, उन्हें उत्पाद बैकलॉग में जोड़ता है, और महत्व और अवधारणाओं के आधार पर उन्हें प्राथमिकता देता है।[19]
एक स्क्रम टीम में केवल एक प्रोडक्ट ओनर होना चाहिए (यद्यपि एक प्रोडक्ट ओनर एक से अधिक टीमों का समर्थन कर सकता है)[20]और इस भूमिका को स्क्रम मास्टर की भूमिका के साथ संयोजित करने के विरुद्ध दृढ़ता से सलाह दी जाती है। प्रोडक्ट ओन को उत्पाद विकास के व्यावसायिक पक्ष पर ध्यान केंद्रित करना चाहिए और अधिकांश समय हितधारकों और टीम के साथ संपर्क में बिताना चाहिए। प्रोडक्ट ओनर यह निर्देशित नहीं करता है कि टीम किसी तकनीकी समाधान तक कैसे पहुंचती है, बल्कि वह टीम के सदस्यों के बीच आम सहमति का प्रयास करता है।[21][22]
यह भूमिका महत्वपूर्ण है और इसमें व्यापार और अभियांत्रिकी के दोनों पक्षों की गहरी समझ की आवश्यकता होती है। इसलिए, एक अच्छा प्रोडक्ट ओनर को व्यापारिक आवश्यकताओं को संचारित करने की क्षमता होनी चाहिए, वह यह पूछ सकता है कि उन्हें इसकी क्या आवश्यकता है और उपयोगकर्ताओं को तकनीकी भाषा का उपयोग करके संदेश पहुंचा सकता है, जैसा कि आवश्यक होता है। प्रोडक्ट ओनर स्क्रम के अनुप्रयोगिक उपकरणों का उपयोग करके अत्यंत जटिल कार्य का प्रबंधन करता है, साथ ही जोखिम को नियंत्रित करता है और मूल्य प्राप्त करता है।
संचार प्रोडक्ट ओनर की प्राथमिक जिम्मेदारी है। प्राथमिकताओं को संचारित करने और टीम सदस्यों और हितधारकों के साथ सहभागिता करने की क्षमता, प्रोडक्ट विकास को सही दिशा में प्रवर्तित करने के लिए महत्वपूर्ण है।[23] प्रोडक्ट ओनर भूमिका टीम और हितधारकों के बीच संचार की गड़बड़ को दूर करती है,[24] जहां यह हितधारकों के प्रति टीम के प्रतिनिधि के रूप में काम करती है और समूह हितधारक समुदाय के प्रति टीम के प्रतिनिधि के रूप में सेवा करती है।[25]
हितधारकों के लिए टीम के प्रतिनिधि के रूप में, प्रोडक्ट ओनर के पास निम्नलिखित कुछ संचार कार्य होते हैं:
- रिलीज को परिभाषित करें और घोषणा करें
- डिलीवरी और उत्पाद की स्थिति के बारे में बताएं
- शासन समिति की बैठकों में प्रगति साझा करना
- हितधारकों के साथ महत्वपूर्ण रीडास (रिस्क, बाधाएं, आधारभूतताएं, और मान्यताएं) साझा करें।
- प्राथमिकताओं, दायरा, वित्तपोषण, और अनुसूची की वार्ता करें।
- सुनिश्चित करें कि प्रोडक्ट बैकलॉग दृश्यमान, पारदर्शी और स्पष्ट है।
संबंधित होने की क्षमता किसी उत्पाद के मालिक के लिए एक प्रमुख विशेषता है स्वयं को दूसरे के स्थान पर रखने की क्षमता। एक प्रोडक्ट ओनर विभिन्न पृष्ठभूमियों, कार्य भूमिकाओं और उद्देश्यों वाले विभिन्न हितधारकों के साथ बातचीत करता है और उसे इन विभिन्न दृष्टिकोणों की सराहना करने में सक्षम होना चाहिए। प्रभावी होने के लिए, प्रोडक्ट ओनर के लिए यह जानना बुद्धिमानी है कि दर्शकों को किस स्तर के विवरण की आवश्यकता है। डेवलपर्स को संपूर्ण फीडबैक और विशिष्टताओं की आवश्यकता होती है जिससे वे अपेक्षा के अनुरूप उत्पाद बना सकें, जबकि एक कार्यकारी प्रायोजक को केवल प्रगति के सारांश की आवश्यकता हो सकती है। आवश्यकता से अधिक जानकारी प्रदान करने से हितधारक की रुचि कम हो सकती है और समय बर्बाद हो सकता है। अनुभवी उत्पाद मालिकों द्वारा संचार का सीधा साधन पसंद किया जाता है।[20]किसी प्रोडक्ट ओनर की प्रभावी ढंग से संवाद करने की क्षमता उन तकनीकों में कुशल होने से भी बढ़ती है जो हितधारकों की जरूरतों की पहचान करती हैं, हितधारकों के हितों के बीच प्राथमिकताओं पर बातचीत करती हैं और आवश्यकताओं के प्रभावी कार्यान्वयन को सुनिश्चित करने के लिए डेवलपर्स के साथ सहयोग करती हैं।
डेवलपर्स
डेवलपर्स प्रत्येक स्प्रिंट में मूल्य वृद्धि के निर्माण के लिए आवश्यक सभी कार्य करते हैं।[19]
डेवलपर्स शब्द[14] किसी ऐसे व्यक्ति को संदर्भित करता है जो सिस्टम या उत्पाद के विकास और समर्थन में भूमिका निभाता है और इसमें शोधकर्ता, आर्किटेक्ट, डिजाइनर, डेटा विशेषज्ञ, सांख्यिकीविद, विश्लेषक, अभियांत्रिकी, प्रोग्रामर और परीक्षक सम्मिलित हो सकते हैं।[26] यद्यपि, उस भ्रम के कारण जो तब उत्पन्न हो सकता है जब कुछ लोगों को नहीं लगता कि 'डेवलपर' शब्द उन पर लागू होता है, उन्हें प्रायः टीम के सदस्यों के रूप में संदर्भित किया जाता है।
टीम स्व-संगठित है, जबकि प्रोडक्ट ओनर के अतिरिक्त कोई भी काम टीम के पास नहीं आना चाहिए, और स्क्रम मास्टर से टीम को विकर्षणों से बचाने की अपेक्षा की जाती है, टीम को फीडबैक की अधिकतम समझ और तत्कालता प्राप्त करने के लिए ग्राहकों और/या हितधारकों के साथ सीधे बातचीत करने के लिए प्रोत्साहित किया जाता है।[19]
स्क्रम मास्टर
स्क्रम मास्टर के द्वारा स्क्रम को स्थापित करने की जिम्मेदारी होती है, जैसा कि स्क्रम गाइड में परिभाषित होता है। वे इसे सहायता करके सभी को स्क्रम की सिद्धांत और अभ्यास को समझने में मदद करते हैं, स्क्रम टीम और संगठन के भीतर । स्क्रम मास्टर पारंपरिक टीम लीड या परियोजना प्रबंधक नहीं होता है।[3] स्क्रम मास्टर यह सुनिश्चित करता है कि स्क्रम सिद्धांत और अवधारणाओं में टीम को प्रशिक्षित करके स्क्रम ढांचे का पालन किया जाता है, प्रायः महत्वपूर्ण घटनाओं को सुविधाजनक बनाया जाता है, और टीम को बढ़ने और सुधार करने के लिए प्रोत्साहित किया जाता है। इस भूमिका को एक टीम सुविधाकर्ता या सेवक-नेता स्क्रम गाइड 2017 और "सच्चा नेता" स्क्रम गाइड 2020 के रूप में भी उद्घाटित किया गया है, जिससे इन द्वितीयक दृष्टिकोणों को मजबूत किया जा सके।[27]
स्क्रम मास्टर की मुख्य जिम्मेदारियाँ निम्नलिखित हो सकती हैं::[3]
- टीम के सदस्यों को स्व-प्रबंधन और पार कार्यक्षमता में प्रशिक्षित करना
- स्क्रम टीम को उच्च-मूल्य वेतन वृद्धि बनाने पर ध्यान केंद्रित करने में मदद करना जो पूर्ण की परिभाषा को पूरा करती है
- स्क्रम टीम की प्रगति में आने वाली बाधाओं को दूर करना
- यह सुनिश्चित करना कि सभी स्क्रम ईवेंट घटित हों और सकारात्मक, उत्पादक हों और समय सीमा के भीतर रखे जाएं।
- प्रोडक्ट ओनर को प्रभावी उत्पाद लक्ष्य परिभाषा और उत्पाद बैकलॉग प्रबंधन के लिए तकनीक खोजने में मदद करना
- स्क्रम टीम को स्पष्ट और संक्षिप्त उत्पाद बैकलॉग वस्तु की आवश्यकता को समझने में मदद करना
- जटिल वातावरण के लिए अनुभवजन्य उत्पाद योजना स्थापित करने में मदद करना
- अनुरोध या आवश्यकता के अनुसार हितधारक सहयोग की सुविधा प्रदान करना
- स्क्रम अपनाने में संगठन का नेतृत्व करना, प्रशिक्षण देना और प्रशिक्षण देना
- संगठन के भीतर स्क्रम कार्यान्वयन की योजना बनाना और सलाह देना
- कर्मचारियों और हितधारकों को जटिल कार्य के लिए अनुभवजन्य दृष्टिकोण को समझने और लागू करने में मदद करना
- हितधारकों और स्क्रम टीमों के बीच बाधाओं को दूर करना
स्क्रम मास्टर लोगों और संगठनों को प्रायोगिक और लीन सोच को अपनाने में मदद करते हैं, यह सुनिश्चित करते हुए कि निश्चितता और पूर्वानुमानशीलता की आशाओं को पीछे छोड़ दिया जाए।
स्क्रम मास्टर की भूमिका प्रोजेक्ट मैनेजर से भिन्न होने का एक विधि यह है कि प्रोजेक्ट मैनेजर के पास प्रबंधन उत्तरदायीियाँ हो सकती हैं और स्क्रम मास्टर के पास नहीं। एक स्क्रम मास्टर टीम में स्व-संगठन का समर्थन करता है। [28] स्क्रम परियोजना प्रबंधक की भूमिका का उपयोग नहीं करता है, क्योंकि स्क्रम एक उत्पाद प्रबंधन है न कि परियोजना प्रबंधन ढांचा। इसके अतिरिक्त, पारंपरिक आदेश और नियंत्रण की प्रवृत्ति और प्रबंधक के नेतृत्व वाले व्यवहार के परिणामस्वरूप टीमों का स्व-संगठन सीमित हो जाएगा।[29]
कार्यप्रवाह
स्प्रिंट
स्प्रिंट स्क्रम में विकास की मूल इकाई होता है। स्प्रिंट एक समय-बॉक्स श्रम होता है; अर्थात, प्रत्येक स्प्रिंट के लिए लंबाई पहले से सहमत की जाती है और निर्धारित होती है, सामान्यतः एक सप्ताह से एक महीने के बीच होती है, जबकि दो सप्ताह सबसे सरल हैं।[10]
सामान्यतः, परियोजना की प्रगति और परियोजना को लागू करते समय टीम के किसी भी सदस्य के सामने आने वाली किसी भी कठिनाई पर चर्चा करने के लिए दैनिक बैठकें आयोजित की जाती हैं। स्प्रिंट का परिणाम कुछ पुनरावृत्तीय और वृद्धिशील विकास के साथ, वितरण योग्य है। स्क्रम का उपयोग वेब टेक्नोलॉजी या नए बाज़ार के लिए किसी उत्पाद के विकास जैसी परियोजनाओं के लिए किया जाता है, अर्थात कई आवश्यकताओं या तेजी से बदलती आवश्यकता वाले उत्पाद।
प्रत्येक स्प्रिंट एक स्प्रिंट योजना कार्यक्रम से प्रारंभ होता है जिसमें एक स्प्रिंट लक्ष्य परिभाषित किया जाता है। आगामी स्प्रिंट के लिए प्राथमिकताएँ बैकलॉग से चुनी जाती हैं। प्रत्येक स्प्रिंट दो घटनाओं के साथ समाप्त होता है:
- एक स्प्रिंट समीक्षा- हितधारकों को उनकी प्रतिक्रिया प्राप्त करने के लिए दिखाई गई प्रगति
- एक स्प्रिंट पूर्वव्यापी- अगले स्प्रिंट के लिए सबक और सुधार की पहचान करें[11]
स्क्रम स्प्रिंट के अंत में मूल्यवान, कार्रवाई योग्य आउटपुट पर जोर देता है जो अभी पूरा हुआ है। प्रत्येक पुनरावृत्ति के आउटपुट को विकसित उत्पाद को बाज़ार की सफलता के नजदीक लाना चाहिए।[30] सॉफ़्टवेयर के विषय में, इसमें संभवतः यह सम्मिलित है कि उत्पाद पूरी तरह से एकीकृत, परीक्षण और दस्तावेज़ीकृत हैं, और संभावित रूप से प्रवाहित करने योग्य हैं।[29]
स्प्रिंट योजना
स्प्रिंट प्रारंभ में, स्क्रम टीम एक स्प्रिंट योजना कार्यक्रम आयोजित करती है:
- स्प्रिंट के लक्ष्य पर सहमति बनाई जाती है, जिसमें वे स्प्रिंट के अंत तक प्रस्तुत करने की आंकड़े या अनुमानित करते हैं, जो प्रोडक्ट ओनर द्वारा स्थापित प्राथमिकताओं पर आधारित होती है।
- इस लक्ष्य की ओर से योगदान देने वाले प्रोडक्ट बैकलॉग आइटम का चयन करते है।
- स्प्रिंट के समय किन आइटमों को करने की योजना है, उसे संयुक्त रूप से चर्चा करके और सहमति प्राप्त करके स्प्रिंट बैकलॉग बनाएं।
चार हफ्ते के स्प्रिंट के लिए स्प्रिंट प्लानिंग का अधिकतम समय आठ घंटे होता है। सबसे विस्तृत कार्य को विस्तारित करने के समय , कुछ स्प्रिंट बैकलॉग आइटमों को विभाजित किया जा सकता है या उन्हें प्रोडक्ट बैकलॉग में वापस भेजा जा सकता है[14] अगर टीम को लगता है कि वे एक ही स्प्रिंट में उस कार्य को पूरा नहीं कर सकेगी।
दैनिक घोटाला
स्प्रिंट के समय प्रत्येक दिन, डेवलपर्स विशिष्ट दिशानिर्देशों के साथ एक दैनिक स्क्रम (कभी-कभी स्टैंड-अप मीटिंग आयोजित करते हैं) आयोजित करते हैं:[31][10]
सभी डेवलपर तैयार होकर आते हैं। दैनिक घोटाला:
- स्प्रिंट लक्ष्य की दिशा में प्रगति का निरीक्षण करने पर केंद्रित है
- हर दिन एक ही समय और स्थान पर होना चाहिए
- (टाइमबॉक्सिंग) पंद्रह मिनट तक सीमित है
- टीम जैसा निर्णय लेती है वैसे ही आयोजित किया जाता है
- इसमें अन्य भी सम्मिलित हो सकते हैं, यद्यपि केवल डेवलपर्स को ही बोलना चाहिए।
- स्क्रम मास्टर द्वारा सुविधा प्रदान की जा सकती है
- प्रगति में बाधाओं की पहचान कर सकता है (उदाहरण के लिए, रुकावट, जोखिम, समस्या, विलंबित निर्भरता, निराधार प्रमाणित हुई धारणा)
- इसमें चर्चाएँ सम्मिलित नहीं हैं
- प्रगति चार्ट को अद्यतन करने का साधन नहीं है
दूरस्थ वातावरण में, कई स्क्रम टीमें स्लैक (सॉफ़्टवेयर) जैसे टूल का उपयोग करके अपने दैनिक स्क्रम को मैसेजिंग प्रारूप में रखने का विकल्प चुनती हैं। ऐसा माना जाता है कि यह स्क्रम टीम के सदस्यों को दैनिक अपडेट को अतुल्यकालिक रूप से पढ़ने की अनुमति देता है, जिससे प्रत्येक व्यक्ति को अपने दैनिक अपडेट के बारे में बोलने के लिए आवश्यक समय की बचत होती है।[32] प्रायः, विशिष्ट सुविधाओं पर काम करने वाली टीमों को सीधे संवाद करने की आवश्यकता नहीं होती है। इस प्रारूप में, प्रोडक्ट ओनर या स्क्रम मास्टर के लिए आगे के सहयोग या संचार के लिए किसी भी बैठक का समन्वय करना महत्वपूर्ण है।
दैनिक कामकाज के समय कोई विस्तृत चर्चा नहीं होनी चाहिए। एक बार ख़त्म होने पर, व्यक्तिगत सदस्य मुद्दों पर विस्तार से चर्चा कर सकते हैं, जिसे प्रायः 'ब्रेकआउट सत्र' या 'आफ्टर पार्टी' के रूप में जाना जाता है।[33] समाधान की दिशा में काम करने की दृष्टि से पहचाने गए मुद्दों या बगों पर दैनिक विवाद के बाहर सामूहिक रूप से चर्चा की जानी चाहिए।
जहां टीम को इस घटना में मूल्य नहीं दिखता है, वहां यह निर्धारित करना स्क्रम मास्टर की ज़िम्मेदारी है कि क्यों[34] और टीम और हितधारकों को स्क्रम सिद्धांतों के बारे में शिक्षित करें,[35] या टीम को स्प्रिंट प्रगति के बारे में पूरी जानकारी रखने के लिए अपना स्वयं का विधि प्रारूपित करने के लिए प्रोत्साहित करें।
स्प्रिंट समीक्षा
स्प्रिंट के अंत में आयोजित टीम:
- हितधारकों को पूरा किया गया कार्य प्रस्तुत करता है (जैसे प्रौद्योगिकी डेमो)
- जैसे विषयों पर हितधारकों के साथ सहयोग करता है:
- पूर्ण उत्पाद वृद्धि के बारे में प्रतिक्रिया आमंत्रित करना
- अधूरे काम (योजनाबद्ध या अन्यथा) के प्रभाव पर चर्चा
- आगामी कार्य के लिए सुझाव प्राप्त करना (आगे क्या काम करना है इसका मार्गदर्शन)
उत्पाद मालिकों को इस आयोजन को हितधारकों के साथ उत्पाद बैकलॉग की समीक्षा करने और उसे परिष्कृत करने के एक मूल्यवान अवसर के रूप में देखना चाहिए। यदि समीक्षा से पता चलता है कि उत्पाद में कोई विचलन है, तो आगे के विचलन को नियंत्रित करने के लिए यथाशीघ्र समायोजन किया जाता है।
स्प्रिंट समीक्षा के लिए दिशानिर्देश:
- अधूरे कार्य का प्रदर्शन नहीं किया जाना चाहिए; यद्यपि हितधारकों को उन्हें प्राप्त होने वाले उत्पाद वेतन वृद्धि के साथ प्रस्तुत किया जाना चाहिए, परंतु यदि आवश्यक हो तो कार्य प्रगति पर देखने का अनुरोध भी कर सकते हैं। यद्यपि, टीम को केवल यह दिखाने के लिए तैयार रहना चाहिए कि क्या किया गया है।
- दो सप्ताह के स्प्रिंट के लिए अनुशंसित अवधि दो घंटे है (अन्य स्प्रिंट-अवधिओं के लिए आनुपातिक)।[14]
स्प्रिंट पूर्वव्यापी
स्प्रिंट पूर्वव्यापी में, टीम:
- पिछले स्प्रिंट को दर्शाता है
- निरीक्षण करता है कि अंतिम स्प्रिंट कैसा रहा (व्यक्ति, इंटरैक्शन, प्रक्रियाएं, उपकरण, पूर्ण की परिभाषा)
- निरंतर सुधार प्रक्रिया कार्यों की पहचान करता है और उनसे सहमत होता है
स्प्रिंट पूर्वव्यापी के लिए दिशानिर्देश:
- स्प्रिंट रेट्रोस्पेक्टिव में विचार करने के लिए तीन सुझाए गए क्षेत्र हैं:
- स्प्रिंट के समय क्या अच्छा हुआ?
- क्या ठीक नहीं हुआ?
- हम अगले स्प्रिंट में क्या अलग कर सकते हैं?
- चार सप्ताह के स्प्रिंट के लिए अवधि अधिकतम तीन घंटे है, जो अन्य स्प्रिंट अवधि के लिए आनुपातिक है (उदाहरण के लिए दो सप्ताह के स्प्रिंट के लिए डेढ़ घंटे)।
स्क्रम मास्टर इस आयोजन को सुविधाजनक बना सकते हैं, परंतु वे टीम के एक हिस्से के रूप में भी उपस्थित हो सकते हैं।
बैकलॉग परिशोधन
यद्यपि मूल रूप से एक मुख्य स्क्रम अभ्यास नहीं है, बैकलॉग रिफ़ाइनमेंट को स्क्रम गाइड में जोड़ा गया था और स्प्रिंट में प्रवेश करने वाले उत्पाद बैकलॉग आइटम की गुणवत्ता को प्रबंधित करने के एक तरीके के रूप में अपनाया गया था। यह नई जानकारी के आलोक में उत्पाद बैकलॉग आइटम की समीक्षा और संशोधन/अद्यतन/पुनः ऑर्डर करने की सतत प्रक्रिया है।
बैकलॉग और भीतर की वस्तुओं को संशोधित करने के कारणों में सम्मिलित हो सकते हैं:
- बड़ी वस्तुओं को कई छोटी वस्तुओं में तोड़ा जा सकता है
- स्वीकृति मानदंडों को स्पष्ट किया जा सकता है
- निर्भरता की पहचान और जांच की जा सकती है
- किसी आइटम को आगे की खोज और विश्लेषण की आवश्यकता हो सकती है
- प्राथमिकताएँ बदल गई होंगी; अपेक्षित रिटर्न अब अलग-अलग होंगे
परिशोधन का मतलब है कि वस्तुओं को उचित रूप से तैयार किया जाता है और इस तरह से व्यवस्थित किया जाता है जो उन्हें स्प्रिंट योजना के लिए डेवलपर्स के लिए स्पष्ट और निष्पादन योग्य बनाता है।
बैकलॉग में तकनीकी ऋण भी सम्मिलित हो सकता है। यह सॉफ्टवेयर विकास में एक अवधारणा है जो एक बेहतर दृष्टिकोण का उपयोग करने के अतिरिक्त अब एक आसान समाधान चुनने के कारण होने वाले अतिरिक्त पुनर्विक्रय की निहित लागत को दर्शाती है जिसमें अधिक समय लगेगा।
किसी टीम की स्प्रिंट क्षमता का 10 प्रतिशत तक निवेश करने की अनुशंसा की जाती है[14]बैकलॉग शोधन पर. अधिक परिपक्व टीमें इसे एक निर्धारित परिभाषित कार्यक्रम के रूप में नहीं बल्कि एक तदर्थ गतिविधि के रूप में देखेंगी जो प्राकृतिक वर्कफ़्लो का हिस्सा बनती है, जरूरत पड़ने पर उत्पाद बैकलॉग को परिष्कृत और समायोजित करती है।
स्प्रिंट रद्द करना
यदि आवश्यक हो तो प्रोडक्ट ओनर स्प्रिंट रद्द कर सकता है,[14]और ऐसा दूसरों (डेवलपर्स, स्क्रम मास्टर या प्रबंधन) के इनपुट के साथ या उसके बिना भी कर सकता है। उदाहरण के लिए, हाल की बाहरी परिस्थितियाँ स्प्रिंट लक्ष्य के मूल्य को नकार सकती हैं, इसलिए इसे जारी रखना व्यर्थ है।
जब एक स्प्रिंट असामान्य रूप से समाप्त हो जाता है, तो अगला कदम नई स्प्रिंट योजना बनाना होता है, जहां समाप्ति के कारण की समीक्षा की जाती है।
कलाकृतियाँ
कलाकृतियाँ परियोजना में कार्य के प्रबंधन के लिए उपयोग किए जाने वाले दस्तावेज़ को संदर्भित करती हैं।
उत्पाद बैकलॉग
उत्पाद बैकलॉग किए जाने वाले कार्यों का विवरण है और इसमें आवश्यकता की एक क्रमबद्ध सूची होती है जिसे टीम नए उत्पाद विकास के लिए बनाए रखती है। बैकलॉग आइटम के सामान्य प्रारूप में उपयोगकर्ता कहानी और उपयोग के स्थितिया सम्मिलित हैं।[29]ये आवश्यकताएँ सॉफ़्टवेयर सुविधाओं, पैच (कंप्यूटिंग), गैर-कार्यात्मक आवश्यकताओं आदि को परिभाषित करती हैं - जो कुछ भी एक व्यवहार्य उत्पाद प्रदान करता है। प्रोडक्ट ओनर, व्यावसायिक मूल्य, निर्भरता, आकार और आवश्यक तिथि जैसे विचारों के आधार पर उत्पाद बैकलॉग आइटम (पीबीआई) को प्राथमिकता देता है।
उत्पाद बैकलॉग वह है जिसकी आवश्यकता होती है, जब इसकी आवश्यकता होती है तब ऑर्डर किया जाता है और यह सभी को दिखाई देता है, परंतु इसे केवल प्रोडक्ट ओनर की सहमति से बदला जा सकता है, जो उत्पाद बैकलॉग आइटम के प्रबंधन और रखरखाव के लिए उत्तरदायी है।
उत्पाद बैकलॉग में प्रोडक्ट ओनर के व्यावसायिक मूल्य का मूल्यांकन सम्मिलित होता है और इसमें टीम के प्रयास या जटिलता का मूल्यांकन सम्मिलित हो सकता है, प्रायः, परंतु हमेशा नहीं, जो फाइबोनैचि स्केल (फुर्तीली) का उपयोग करके योजना पोकर में बताया गया है। ये अनुमान प्रोडक्ट ओनर को समयरेखा का अनुमान लगाने में मदद करते हैं और उत्पाद बैकलॉग आइटम के ऑर्डर को प्रभावित कर सकते हैं; उदाहरण के लिए, समान व्यावसायिक मूल्य वाली दो सुविधाओं के लिए, प्रोडक्ट ओनर कम विकास प्रयास (क्योंकि निवेश पर रिटर्न अधिक है) या उच्च विकास प्रयास के साथ काम की पहले डिलीवरी शेड्यूल कर सकता है। और वे उस जोखिम से पहले ही निवृत्त होना चाहते हैं)।[36]उत्पाद बैकलॉग और प्रत्येक उत्पाद बैकलॉग आइटम का व्यावसायिक मूल्य प्रोडक्ट ओनर की उत्तरदायीी है। प्रत्येक आइटम को वितरित करने के प्रयास का अनुमान कहानी बिंदुओं या समय में लगाया जा सकता है। कहानी के बिंदुओं का अनुमान लगाकर, टीम व्यक्तिगत डेवलपर्स की निर्भरता कम करती है; यह विशेष रूप से गतिशील टीमों के लिए उपयोगी है जहां डेवलपर्स को प्रायः स्प्रिंट डिलीवरी के बाद अन्य कार्य सौंपा जाता है। उदाहरण के लिए, यदि किसी उपयोगकर्ता की कहानी को प्रयास में 5 के रूप में अनुमानित किया गया है, तो यह 5 ही रहता है, भले ही कितने डेवलपर इस पर काम कर रहे हों
कहानी के बिंदु समय-सीमा में प्रयास को परिभाषित करते हैं, इसलिए वे समय के साथ नहीं बदलते हैं। उदाहरण के लिए, एक घंटे में एक व्यक्ति चल सकता है, दौड़ सकता है या चढ़ सकता है, परंतु खर्च किया गया प्रयास स्पष्ट रूप से भिन्न होता है। फाइबोनैचि अनुक्रम में शब्दों के बीच अंतर प्रगति टीम को सावधानीपूर्वक विचार किए गए अनुमान देने के लिए प्रोत्साहित करती है। 1, 2 या 3 का अनुमान समान प्रयासों का संकेत देता है (1 तुच्छ है), परंतु यदि टीम 8 या 13 का अनुमान लगाती है, तो वितरण और बजट दोनों पर प्रभाव महत्वपूर्ण हो सकता है। कहानी बिंदुओं का उपयोग करने का महत्व यह है कि टीम पिछले स्प्रिंट के समान कार्य की तुलना करके उनका पुन: उपयोग कर सकती है, परंतु यह माना जाना चाहिए कि अनुमान उस टीम के सापेक्ष हैं। उदाहरण के लिए, उच्च क्षमता वाले अधिक अनुभवी डेवलपर्स से बनी एक टीम के लिए 5 का अनुमान दूसरे के लिए 2 हो सकता है।
प्रत्येक टीम में एक प्रोडक्ट ओनर होना चाहिए, यद्यपि कई स्थितियों में एक प्रोडक्ट ओनर एक से अधिक टीमों के साथ काम कर सकता है।[20]प्रोडक्ट ओनर त्पाद के मूल्य को अधिकतम करने के लिए उत्तरदायी है। प्रोडक्ट ओनर इनपुट एकत्र करता है और कई लोगों से फीडबैक लेता है, और उसकी पैरवी करता है, परंतु अंततः क्या बनाया जाएगा इसके बारे में अंतिम निर्णय उसका ही होता है।
उत्पाद बैकलॉग:
- किसी उत्पाद को संशोधित करने के अनुरोधों को कैप्चर करता है - जिसमें नई सुविधाएँ, पुरानी सुविधाएँ बदलना, सुविधाएँ हटाना और समस्याओं को ठीक करना सम्मिलित है
- सुनिश्चित करता है कि डेवलपर्स के पास ऐसा काम है जो उत्पाद के व्यावसायिक लाभ को अधिकतम करता है
सामान्यतः, पूरी टीम उत्पाद बैकलॉग को परिष्कृत करने के लिए एक साथ काम करती है, जो उत्पाद और उसके ग्राहकों के बारे में नई जानकारी सामने आने के साथ विकसित होती है, और इसलिए बाद में स्प्रिंट नए काम को संबोधित कर सकते हैं।
प्रबंधन
एक उत्पाद बैकलॉग, अपने सरलतम रूप में, काम करने के लिए वस्तुओं की एक सूची मात्र है। काम को कैसे जोड़ा, हटाया और ऑर्डर किया जाए, इसके बारे में अच्छी तरह से स्थापित नियम होने से पूरी टीम को उत्पाद को बदलने के तरीके के बारे में बेहतर निर्णय लेने में मदद मिलती है।[37] प्रोडक्ट ओनर उत्पाद बैकलॉग आइटम को प्राथमिकता देता है, जिसके आधार पर इसकी जल्द से जल्द आवश्यकता होती है। डेवलपर्स, स्प्रिंट लक्ष्य से प्रभावित होकर, आने वाले स्प्रिंट के लिए आइटम चुनते हैं, उन आइटम को उत्पाद बैकलॉग से स्प्रिंट बैकलॉग में ले जाते हैं, जो कि उन आइटमों की सूची है जिन्हें वे बनाएंगे। वैचारिक रूप से, स्प्रिंट लक्ष्य सूची के शीर्ष पर उच्च-प्राथमिकता वाली वस्तुओं से प्रभावित होता है, परंतु यदि स्प्रिंट के भीतर अधिक काम को समायोजित करने के लिए समय बचा है तो डेवलपर्स को कुछ कम-प्राथमिकता वाली वस्तुओं को लेते हुए देखना असामान्य नहीं है।
उच्च-प्राथमिकता वाली वस्तुओं (बैकलॉग के शीर्ष पर) को अधिक विस्तार में विभाजित किया जाना चाहिए जो डेवलपर्स के काम करने के लिए उपयुक्त हों। बैकलॉग जितना नीचे होगा, आइटम उतने ही कम विस्तृत होंगे। जैसा कि श्वाबर और बीडल ने कहा, प्राथमिकता जितनी कम होगी, विवरण उतना ही कम होगा, जब तक कि आप बैकलॉग आइटम को मुश्किल से नहीं निकाल पाते।[10]
जैसा कि टीम बैकलॉग के माध्यम से काम करती है, यह माना जाना चाहिए कि परिवर्तन उनके वातावरण के बाहर होता है - टीम लाभ उठाने के लिए नए बाजार के अवसरों, उत्पन्न होने वाले प्रतिस्पर्धी खतरों और ग्राहकों से प्रतिक्रिया के बारे में सीख सकती है जो उत्पाद के उद्देश्य को बदल सकती है। काम करने के लिए। ये सभी नए विचार टीम को नए ज्ञान को सम्मिलित करने के लिए बैकलॉग को अनुकूलित करने के लिए प्रेरित करते हैं। यह एक चुस्त टीम की मूलभूत मानसिकता का हिस्सा है। दुनिया बदल जाती है, बैकलॉग कभी ख़त्म नहीं होता।[38]
स्प्रिंट बैकलॉग
स्प्रिंट बैकलॉग उत्पाद बैकलॉग से आइटमों का उपसमुच्चय है जिसका उद्देश्य डेवलपर्स को आगामी स्प्रिंट में संबोधित करना है।[39] डेवलपर्स इस बैकलॉग को तब तक भरेंगे जब तक उन्हें नहीं लगता कि उनके पास स्प्रिंट भरने के लिए पर्याप्त काम है, अगले स्प्रिंट के लिए क्षमता का आकलन करने के लिए पिछले प्रदर्शन का उपयोग करते हुए, इसे एक दिशानिर्देश के रूप में उपयोग करते हुए कि वे कितना 'प्रयास' पूरा कर सकते हैं।
स्प्रिंट बैकलॉग पर काम कभी भी डेवलपर्स को आगे नहीं बढ़ाया जाता है; टीम के सदस्य बैकलॉग प्राथमिकता और अपने कौशल और क्षमता के अनुसार आवश्यकतानुसार काम करते हैं। यह डेवलपर्स के स्व-संगठन को बढ़ावा देता है।
स्प्रिंट बैकलॉग डेवलपर्स की संपत्ति है, और इसमें सम्मिलित सभी अनुमान डेवलपर्स द्वारा प्रदान किए जाते हैं। यद्यपि यह स्क्रम का हिस्सा नहीं है, कुछ टीमें वर्तमान स्प्रिंट में काम की स्थिति की कल्पना करने के लिए एक साथ वाले बोर्ड का उपयोग करती हैं: टूडू, डूइंग, डन।
वृद्धि
वृद्धि स्प्रिंट का संभावित रिलीज़ योग्य आउटपुट है जो स्प्रिंट लक्ष्य को पूरा करता है। यह सभी पूर्ण स्प्रिंट बैकलॉग आइटमों से बनता है, जो पिछले सभी स्प्रिंट के काम के साथ एकीकृत होता है। स्क्रम टीम की डेफिनिशन ऑफ डन (डीओडी) के अनुसार वेतन वृद्धि पूर्ण होनी चाहिए, पूरी तरह से कार्यशील होनी चाहिए, और उपयोग करने योग्य स्थिति में होनी चाहिए, भले ही प्रोडक्ट ओनर वास्तव में इसे तैनात करने और इसका उपयोग करने का निर्णय लेता है या नहीं।
एक्सटेंशन
लोगों को स्क्रम का उपयोग करने में मदद करने के लिए निम्नलिखित कलाकृतियों और तकनीकों का उपयोग किया जा सकता है।[14]
बर्नडाउन चार्ट
प्रायः स्क्रम में उपयोग किया जाता है बर्नडाउन चार्ट एक सार्वजनिक रूप से प्रदर्शित चार्ट है जो शेष कार्य दिखाता है।[40] हर दिन अपडेट किया जाता है, यह संदर्भ के लिए त्वरित विज़ुअलाइज़ेशन प्रदान करता है। बर्नडाउन चार्ट का क्षैतिज अक्ष शेष दिनों को दर्शाता है, जबकि ऊर्ध्वाधर अक्ष प्रत्येक दिन शेष कार्य की मात्रा को दर्शाता है।
स्प्रिंट योजना के समय, आदर्श बर्नडाउन चार्ट तैयार किया जाता है। फिर, स्प्रिंट के समय, डेवलपर्स शेष कार्य के साथ चार्ट को अपडेट करते हैं जिससे, वास्तविक और अनुमानित के बीच तुलना दिखाता रहे।
इसे अर्जित मूल्य प्रबंधन के साथ भ्रमित नहीं किया जाना चाहिए।
बर्न-अप चार्ट जारी करें
रिलीज़ बर्न-अप चार्ट टीम के लिए दृश्यता प्रदान करने और रिलीज़ की दिशा में प्रगति को ट्रैक करने का एक विधि है। प्रत्येक स्प्रिंट के अंत में अपडेट किया गया, यह पूर्वानुमान का दायरा प्रदान करने की दिशा में प्रगति दिखाता है। रिलीज़ बर्न-अप चार्ट का क्षैतिज अक्ष रिलीज़ में स्प्रिंट को दर्शाता है, जबकि ऊर्ध्वाधर अक्ष प्रत्येक स्प्रिंट के अंत में पूर्ण किए गए कार्य की मात्रा को दर्शाता है सामान्यतः पूर्ण किए गए कार्य के संचयी कहानी बिंदुओं का प्रतिनिधित्व करता है। प्रगति को एक रेखा के रूप में चित्रित किया गया है जो एक क्षैतिज रेखा से मिलने के लिए बढ़ती है जो पूर्वानुमान के दायरे का प्रतिनिधित्व करती है; प्रायः आज तक की प्रगति के आधार पर पूर्वानुमान के साथ दिखाया जाता है, जो इंगित करता है कि किसी दिए गए रिलीज़ दिनांक तक कितना दायरा पूरा किया जा सकता है या दिए गए दायरे को पूरा करने में कितने स्प्रिंट लगेंगे।
रिलीज़ बर्न-अप चार्ट यह देखना आसान बनाता है कि कितना काम पूरा हो चुका है, कितना काम जोड़ा या हटाया गया है, और कितना काम किया जाना बाकी है।
तैयार (डीओआर) की परिभाषा
प्रारंभ मानदंड यह निर्धारित करने के लिए कि कार्य आइटम प्रारंभ करने के लिए विनिर्देश और इनपुट स्पष्ट रूप से पर्याप्त रूप से सेट हैं या नहीं।
पूर्ण की परिभाषा (डीओडी)
यह निर्धारित करने के लिए निकास-मानदंड कि स्प्रिंट बैकलॉग आइटम पर काम पूरा हो गया है या नहीं, उदाहरण के लिए: डीओडी के लिए आवश्यक है कि सभी प्रतिगमन परीक्षण सफल हों। डीओडी की परिभाषा एक टीम से दूसरी टीम में भिन्न हो सकती है परंतु एक टीम के भीतर सुसंगत होनी चाहिए।[41]
वेग
एक स्प्रिंट के लिए एक टीम की कुल क्षमता का प्रयास, अंतिम स्प्रिंट में पूरे किए गए कार्य के मूल्यांकन से प्राप्त होता है। ऐतिहासिक वेग डेटा का संग्रह टीम को उनकी क्षमता को समझने में सहायता करने के लिए एक दिशानिर्देश है, यानी: वे कितना काम आराम से पूरा कर सकते हैं।
इस मीट्रिक ने स्क्रम समुदाय में विवाद को आकर्षित किया है:
- उपभोग किए गए स्टोरी पॉइंट दिए गए मूल्य के बराबर नहीं हैं: टीम काम पूरा होते देख सकती है और हितधारकों को दिए जाने वाले लाभों को अनदेखा कर सकती है
- ध्यान भटकाने वाली प्रथाओं का परिचय: अनुमान बनाम वास्तविक, विचरण जांच और पुन: अनुमान की नीति उत्पन्न होने लगती है
- प्रबंधन वेग को एक प्रदर्शन मीट्रिक के रूप में देखता है इसलिए इसे बढ़ाने का प्रयास करता है, जिसका अर्थ है:
- गुणवत्ता प्रभावित होती है- टीम अतिरिक्त कार्यभार को सम्मिलित करने के लिए काम में कटौती करना प्रारंभ कर देती है
- मनोबल ख़राब होता है - टीम आरामदायक स्थायी गति से काम करने में असमर्थ होती है और दबाव बढ़ने से जलन होती है
- अनुमान प्रभावित होता है - डेवलपर्स बफ़र्स बनाने और मेट्रिक्स को गेम करने के लिए अनुमान बढ़ाएंगे, एक ही प्रयास को एक अलग पैमाने पर मापेंगे
- मूल्य प्रभावित होता है - अंतिम प्रभाव हस्तक्षेप है जो व्यावसायिक मूल्य वितरण से ध्यान हटाने के परिणामस्वरूप हितधारक के असंतोष का कारण बनता है
यद्यपि किसी टीम की डिलीवरी क्षमता को समझने का महत्व है, वेग को टीम के लिए एक संकेतक माना जाना चाहिए न कि एक डायल जिसे समायोजित किया जा सकता है।
स्पाइक
किसी अवधारणा पर शोध करने या एक सरल प्रोटोटाइप बनाने के लिए टाइम-बॉक्स अवधि का उपयोग किया जाता है। स्पाइक्स को या तो स्प्रिंट के बीच में रखने की योजना बनाई जा सकती है या, बड़ी टीमों के लिए, स्पाइक को कई स्प्रिंट डिलीवरी उद्देश्यों में से एक के रूप में स्वीकार किया जा सकता है। बजट सुरक्षित करने, ज्ञान का विस्तार करने, या अवधारणा का प्रमाण प्रस्तुत करने के लिए स्पाइक्स को प्रायः बड़े या जटिल उत्पाद बैकलॉग आइटम की डिलीवरी से पहले प्रस्तुत किया जाता है। स्पाइक की अवधि और उद्देश्य पर टीम शुरुआत से पहले सहमत होती है। स्प्रिंट प्रतिबद्धताओं के विपरीत, स्पाइक्स मूर्त, शिपिंग योग्य, मूल्यवान कार्यक्षमता प्रदान कर भी सकते हैं और नहीं भी। उदाहरण के लिए, स्पाइक का उद्देश्य कार्रवाई के किसी निर्णय पर सफलतापूर्वक पहुंचना हो सकता है। समय समाप्त होने पर स्पाइक खत्म हो जाती है, जरूरी नहीं कि जब उद्देश्य पूरा हो गया हो।[42]
ट्रेसर बुलेट
ड्रोन स्पाइक भी कहा जाता है, ट्रेसर बुलेट वर्तमान वास्तुकला, वर्तमान प्रौद्योगिकी सेट, सर्वोत्तम प्रथाओं के वर्तमान सेट के साथ एक स्पाइक है जिसके परिणामस्वरूप उत्पादन गुणवत्ता कोड होता है। यह कार्यक्षमता का एक बहुत ही संकीर्ण कार्यान्वयन हो सकता है परंतु यह फेंके जाने वाला कोड नहीं है। यह उत्पादन गुणवत्ता का है, और बाकी पुनरावृत्तियों को इस कोड पर बनाया जा सकता है। नाम का सैन्य मूल ट्रेसर गोला-बारूद है जो गोली के मार्ग को दृश्यमान बनाता है, जिससे सुधार की अनुमति मिलती है। प्रायः ये कार्यान्वयन किसी एप्लिकेशन की सभी परतों के माध्यम से एक 'त्वरित शॉट' होते हैं, जैसे कि परतों को अपेक्षित रूप से कनेक्ट करने के लिए एकल फॉर्म के इनपुट फ़ील्ड को बैक-एंड से जोड़ना।[43]
शब्दावली
स्प्रिंट, स्प्रिंट बैकलॉग, डेली स्क्रम, स्प्रिंट रिव्यू और ऐसे अन्य आयोजनों के साथ मिलकर काम करता है।[27]
प्रोडक्ट ओनर
प्रोडक्ट ओनर उत्पाद के विकास की वर्तमान स्थिति और उत्पाद के मूल्य को अधिकतम करने के लिए उत्तरदायी है। प्रोडक्ट ओनर एक व्यक्ति हो सकता है, भले ही वे किसी समिति का प्रतिनिधित्व करते हों।[27]उनके कार्य में सम्मिलित हैं:
- उत्पाद बैकलॉग में आइटम बनाए रखना
- बैकलॉग में आइटमों को ऑर्डर सौंपना
- यह सुनिश्चित करना कि उत्पाद बैकलॉग में आइटम विकास टीम के लिए स्पष्ट हैं[27]
विकास दल
स्प्रिंट बैकलॉग में लेखों के कार्यान्वयन के लिए विकास टीम उत्तरदायी है। यद्यपि विकास टीम के कई सदस्य अलग-अलग क्षेत्रों में विशेषज्ञ हो सकते हैं, परंतु समग्र रूप से विकास टीम कार्यक्षमता के विकास के लिए उत्तरदायी है।[27]
स्प्रिंट बैकलॉग
स्प्रिंट बैकलॉग उत्पाद बैकलॉग के एक उपसमुच्चय को संदर्भित करता है जिसे स्प्रिंट के लिए उसकी डिलीवरी योजना के साथ चुना जाता है। स्प्रिंट बैकलॉग में आइटम के आधार पर, विकास टीम निर्णय लेती है कि वे एक पूर्ण उत्पाद कैसे बनाएंगे।[27]
दैनिक स्क्रम
डेली स्क्रम एक निश्चित समय, निश्चित स्थान की घटना है जो विकास टीम को पिछले डेली स्क्रम के बाद से किए गए काम की मात्रा के आधार पर अगले 24 घंटों के लिए काम को सिंक्रनाइज़ करने और योजना बनाने की अनुमति देता है।[27]दैनिक स्क्रम के समय, विकास दल के सदस्य समझाते हैं:
- मैंने कल क्या किया जिससे स्प्रिंट लक्ष्य प्राप्त करने में मदद मिली?
- मैं आज अपने स्प्रिंट लक्ष्य की दिशा में क्या करने जा रहा हूँ?
- मैं अपने स्प्रिंट लक्ष्य को पूरा करने में क्या बाधाएँ देखता हूँ?
दैनिक स्क्रम सामान्यतः 15 मिनट तक चलता है, परंतु विस्तृत चर्चा के लिए इसके बाद अन्य बैठकें भी की जा सकती हैं।
स्प्रिंट समीक्षा
स्प्रिंट समीक्षा स्प्रिंट समाप्त होने के बाद निर्धारित की गई है। टीम और हितधारक किए गए कार्य की मात्रा का निरीक्षण करते हैं। यदि आवश्यक हो तो प्रोडक्ट ओनर उत्पाद बैकलॉग को अनुकूलित करता है।[27]स्प्रिंट समीक्षा प्रत्येक स्प्रिंट के अंत में एक निरीक्षण और अनुकूल अवसर है।
स्प्रिंट पूर्वव्यापी
स्प्रिंट रेट्रोस्पेक्टिव का उपयोग यह विश्लेषण करने के लिए किया जाता है कि स्प्रिंट में क्या सही हुआ और क्या सुधार किया जा सकता है। स्क्रम टीम उस वेतन वृद्धि को बनाने के लिए उपयोग की जाने वाली प्रक्रिया की जांच करती है। यह पूर्वव्यापी प्रतिक्रिया स्प्रिंट में अनुसरण की जाने वाली प्रक्रिया को बेहतर बनाने में मदद करती है। स्प्रिंट रेट्रोस्पेक्टिव प्रत्येक स्प्रिंट के अंत में एक निरीक्षण-और-अनुकूल अवसर है।[44]
सीमाएँ
स्क्रम के लाभों को प्राप्त करना अधिक कठिन हो सकता है:[45][46]
- टीमें जिनके सदस्य भौगोलिक रूप से फैले हुए हैं या अंशकालिक हैं: स्क्रम में, डेवलपर्स को घनिष्ठ और निरंतर बातचीत करनी चाहिए, आदर्श रूप से अधिकांश समय एक ही स्थान पर एक साथ काम करना चाहिए। जबकि प्रौद्योगिकी में हाल के सुधारों ने इन बाधाओं के प्रभाव को कम कर दिया है एजाइल घोषणापत्र का दावा है कि सबसे अच्छा संचार आमने-सामने है।[47]
- टीमें जिनके सदस्यों के पास बहुत विशिष्ट कौशल हैं: स्क्रम में, डेवलपर्स के पास टी-आकार का कौशल होना चाहिए, जिससे उन्हें अपनी विशेषज्ञता के बाहर के कार्यों पर काम करने की अनुमति मिल सके। इसे अच्छे स्क्रम नेतृत्व द्वारा प्रोत्साहित किया जा सकता है। जबकि बहुत विशिष्ट कौशल वाले टीम के सदस्य अच्छा योगदान दे सकते हैं और करते भी हैं, उन्हें अन्य विषयों के बारे में अधिक जानने और उनके साथ सहयोग करने के लिए प्रोत्साहित किया जाना चाहिए।
- कई बाहरी निर्भरता वाले उत्पाद: स्क्रम में, उत्पाद विकास को छोटे स्प्रिंट में विभाजित करने के लिए सावधानीपूर्वक योजना की आवश्यकता होती है; बाहरी निर्भरताएं, जैसे उपयोगकर्ता स्वीकृति परीक्षण या अन्य टीमों के साथ समन्वय, देरी और व्यक्तिगत स्प्रिंट की विफलता का कारण बन सकती हैं।
- उत्पाद जो उत्पाद जीवन-चक्र सिद्धांत या विरासत प्रणाली या विनियमित गुणवत्ता नियंत्रण के साथ हैं: स्क्रम में, उत्पाद वृद्धि को एक ही स्प्रिंट में पूरी तरह से विकसित और परीक्षण किया जाना चाहिए; जिन उत्पादों को प्रत्येक रिलीज़ के लिए बड़ी मात्रा में प्रतिगमन परीक्षण या सुरक्षा परीक्षण की आवश्यकता होती है, वे लंबे झरना मॉडल रिलीज़ की तुलना में छोटे स्प्रिंट के लिए कम उपयुक्त होते हैं।
उपकरण उपलब्ध
अन्य चुस्त दृष्टिकोणों की तरह, उपलब्ध उपकरणों की एक विस्तृत श्रृंखला के माध्यम से स्क्रम को प्रभावी ढंग से अपनाने का समर्थन किया जा सकता है। कई कंपनियां स्प्रिंट बैकलॉग बनाने और बनाए रखने के लिए स्प्रेडशीट जैसे सार्वभौमिक टूल का उपयोग करती हैं। ऐसे ओपन-सोर्स और मालिकाना सॉफ़्टवेयर पैकेज भी हैं जो उत्पाद विकास के लिए स्क्रम शब्दावली का उपयोग करते हैं या स्क्रम सहित कई उत्पाद विकास दृष्टिकोणों का समर्थन करते हैं।
अन्य संगठन सॉफ्टवेयर टूल के बिना स्क्रम लागू करते हैं और अपनी कलाकृतियों को कागज, व्हाइटबोर्ड और स्टिकी नोट्स जैसे हार्ड-कॉपी रूपों में बनाए रखते हैं।[48]
स्क्रम मान
स्क्रम एक फीडबैक-संचालित अनुभवजन्य दृष्टिकोण है, जो सभी अनुभवजन्य प्रक्रिया नियंत्रण की तरह, पारदर्शिता, निरीक्षण और अनुकूलन के तीन स्तंभों पर आधारित है। स्क्रम ढांचे के भीतर सभी कार्य परिणाम के लिए उत्तरदायी लोगों को दिखाई देने चाहिए: प्रक्रिया, वर्कफ़्लो, प्रगति, आदि। इन चीजों को दृश्यमान बनाने के लिए, स्क्रम टीमों को विकसित किए जा रहे उत्पाद का बार-बार निरीक्षण करने की आवश्यकता है और टीम कितनी अच्छी है कार्यरत। लगातार निरीक्षण से, टीम यह पता लगा सकती है कि उनका काम स्वीकार्य सीमा से बाहर है और अपनी प्रक्रिया या विकास के तहत उत्पाद को अनुकूलित कर सकता है।[19]इन तीन स्तंभों के लिए टीम में विश्वास और खुलेपन की आवश्यकता होती है, जिसे स्क्रम के निम्नलिखित पांच मूल्य सक्षम करते हैं:[14]
- प्रतिबद्धता: टीम के सदस्य व्यक्तिगत रूप से प्रत्येक स्प्रिंट में अपनी टीम के लक्ष्यों को प्राप्त करने के लिए प्रतिबद्ध हैं
- साहस: टीम के सदस्यों को पता है कि उनमें संघर्ष और चुनौतियों से मिलकर काम करने का साहस है जिससे वे सही काम कर सकें
- फोकस: टीम के सदस्य विशेष रूप से अपनी टीम के लक्ष्यों और स्प्रिंट बैकलॉग पर ध्यान केंद्रित करते हैं; उनके बैकलॉग के अतिरिक्त कोई काम नहीं होना चाहिए
- खुलापन: टीम के सदस्य और उनके हितधारक अपने काम और उनके सामने आने वाली किसी भी चुनौती के बारे में पारदर्शी होने के लिए सहमत हैं
- सम्मान: टीम के सदस्य तकनीकी रूप से सक्षम होने और अच्छे विचार से काम करने के लिए एक-दूसरे का सम्मान करते हैं
अनुकूलन
कई अलग-अलग उद्देश्यों को प्राप्त करने के लिए स्क्रम का उपयोग विभिन्न संदर्भों में किया जाता है। उन अलग-अलग लक्ष्यों को पूरा करने के लिए, स्क्रम को प्रायः अनुकूलित या अनुकूलित किया जाता है।[49] स्क्रम को अनुकूलित करने का एक सामान्य विधि अन्य सॉफ़्टवेयर विकास पद्धतियों के साथ स्क्रम का संकरण है क्योंकि स्क्रम संपूर्ण सॉफ़्टवेयर जीवनचक्र को कवर नहीं करता है; इसलिए, संगठनों को अधिक व्यापक कार्यान्वयन बनाने के लिए अतिरिक्त प्रक्रियाओं को जोड़ने की आवश्यकता महसूस होती है। उदाहरण के लिए, उत्पाद विकास की शुरुआत में, संगठन सामान्यतः व्यावसायिक स्थितिया पर प्रक्रिया मार्गदर्शन, आवश्यकताओं को इकट्ठा करना और प्राथमिकता देना, प्रारंभिक उच्च-स्तरीय प्रारूपित और बजट और शेड्यूल पूर्वानुमान जोड़ते हैं।[50]
विभिन्न लेखकों और स्क्रम का उपयोग करने वाले लोगों के समुदायों ने विशेष समस्याओं या संगठनों के लिए स्क्रम को कैसे लागू किया जाए या अनुकूलित किया जाए, इसके लिए अधिक विस्तृत तकनीकों का सुझाव दिया है। कई लोग इन पद्धतिगत तकनीकों को 'पैटर्न' के रूप में संदर्भित करते हैं - वास्तुकला और सॉफ्टवेयर में प्रारूपित पैटर्न के अनुरूप।[51][52]
स्क्रम्बन
स्क्रमबन एक सॉफ्टवेयर उत्पादन मॉडल है जो स्क्रम और विकास पर आधारित है। स्क्रंबन विशेष रूप से सॉफ़्टवेयर बग या प्रोग्रामिंग त्रुटियों जैसे बार-बार और अप्रत्याशित कार्य आइटम वाले सॉफ़्टवेयर रखरखाव के लिए उपयुक्त है। ऐसे स्थितियों में स्क्रम ढांचे के समय-सीमित स्प्रिंट को कम लाभकारी माना जा सकता है, यद्यपि टीम और मौजूदा स्थिति के आधार पर स्क्रम की दैनिक घटनाओं और अन्य प्रथाओं को अभी भी लागू किया जा सकता है। कार्य चरणों का विज़ुअलाइज़ेशन और एक साथ अधूरे कार्य और दोषों की सीमाएं कानबन मॉडल से परिचित हैं। इन विधियों का उपयोग करते हुए, टीम के कार्यप्रवाह को इस तरह से निर्देशित किया जाता है कि प्रत्येक कार्य आइटम या प्रोग्रामिंग त्रुटि के लिए न्यूनतम पूरा होने का समय मिलता है, और दूसरी ओर यह सुनिश्चित होता है कि टीम का प्रत्येक सदस्य लगातार कार्यरत है।[53] काम के प्रत्येक चरण को स्पष्ट करने के लिए, एक ही स्थान पर काम करने वाली टीमें प्रायः पोस्ट-इट नोट्स या एक बड़े व्हाइटबोर्ड का उपयोग करती हैं।[54] विकेन्द्रीकृत टीमों के स्थितिया में, ट्रैक के लिए इकट्ठा, जिरा (सॉफ्टवेयर) या एगिलो जैसे स्टेज-चित्रण सॉफ़्टवेयर का उपयोग किया जा सकता है।
स्क्रम और कानबन के बीच मुख्य अंतर यह है कि स्क्रम में काम को स्प्रिंट में विभाजित किया जाता है जो एक निश्चित समय तक चलता है, जबकि कानबन में काम का प्रवाह निरंतर होता है। यह कार्य चरण तालिकाओं में दिखाई देता है, जो स्क्रम में प्रत्येक स्प्रिंट के बाद खाली हो जाते हैं, जबकि कानबन में सभी कार्यों को एक ही तालिका में चिह्नित किया जाता है। स्क्रम बहुमुखी जानकारी वाली टीमों पर ध्यान केंद्रित करता है, जबकि कानबन विशिष्ट, कार्यात्मक टीमों को संभव बनाता है।[53]
स्क्रम का स्क्रम्स
स्क्रम ऑफ़ स्क्रम एक ही उत्पाद पर काम करने वाली कई टीमों के लिए बड़े पैमाने पर स्क्रम को संचालित करने की एक तकनीक है, जो उन्हें अपनी अन्योन्याश्रितताओं पर प्रगति पर चर्चा करने की अनुमति देती है, वितरण सॉफ़्टवेयर को समन्वयित करने के तरीके पर ध्यान केंद्रित करती है,[55]विशेषकर ओवरलैप और एकीकरण के क्षेत्रों पर। स्क्रम के स्क्रम के समय के आधार पर, प्रत्येक स्क्रम टीम के लिए प्रासंगिक दैनिक स्क्रम अन्य टीमों के राजदूतों के साथ स्क्रम के स्क्रम में भाग लेने के लिए एक सदस्य को राजदूत के रूप में नामित करके समाप्त होता है। संदर्भ के आधार पर, राजदूत तकनीकी योगदानकर्ता या प्रत्येक टीम के स्क्रम मास्टर हो सकते हैं।[55]केवल प्रगति अद्यतन के अतिरिक्त, स्क्रम्स के समूह को इस बात पर ध्यान केंद्रित करना चाहिए कि पहचाने गए किसी भी जोखिम, बाधाओं, निर्भरताओं और मान्यताओं को हल करने, कम करने या स्वीकार करने के लिए टीमें सामूहिक रूप से कैसे काम कर रही हैं। स्क्रम्स का समूह इन आरआईडीए को अपने स्वयं के बैकलॉग के माध्यम से ट्रैक करता है, [56] जो सामान्यतः टीमों के बीच अधिक समन्वय और सहयोग की ओर ले जाता है।[55]
यह दैनिक घोटाले के समान चलना चाहिए, जिसमें प्रत्येक राजदूत निम्नलिखित चार प्रश्नों का उत्तर देगा:[57]
- पिछली मुलाकात के बाद से आपकी टीम ने किन जोखिमों, बाधाओं, निर्भरताओं या धारणाओं का समाधान किया है?
- दोबारा मिलने से पहले आपकी टीम किन जोखिमों, बाधाओं, निर्भरताओं या धारणाओं का समाधान करेगी?
- क्या कोई नए जोखिम, बाधाएं, निर्भरताएं या धारणाएं हैं जो आपकी टीम को धीमा कर रही हैं या उनके रास्ते में आ रही हैं?
- क्या आप कोई नया जोखिम, बाधा, निर्भरता, या धारणा प्रस्तुत करने वाले हैं जो दूसरी टीम के रास्ते में आ जाएगी?
जैसा कि जेफ़ सदरलैंड ने टिप्पणी की,[55]
चूंकि मैंने मूल रूप से स्क्रम ऑफ स्क्रम्स को परिभाषित किया था, मैं निश्चित रूप से कह सकता हूं कि स्क्रम्स ऑफ स्क्रम्स एक 'मेटा स्क्रम्स' नहीं है। जैसा कि मैंने उपयोग किया है, स्क्रम ऑफ़ स्क्रम सभी टीमों के कामकाजी सॉफ़्टवेयर को स्प्रिंट के अंत में डन की परिभाषा तक, या स्प्रिंट के समय रिलीज़ के लिए वितरित करने के लिए उत्तरदायी है। प्रस्तुत पेशेंटकीपर ने प्रति स्प्रिंट चार बार उत्पादन पहुंचाया। Ancestry.com प्रति दो सप्ताह के स्प्रिंट में 220 बार उत्पादन प्रदान करता है। हबस्पॉट दिन में 100-300 बार लाइव सॉफ़्टवेयर वितरित करता है। इस कार्य को करने के लिए स्क्रम ऑफ़ स्क्रम्स मास्टर को उत्तरदायी ठहराया जाता है। तो स्क्रम ऑफ स्क्रम्स एक परिचालन वितरण तंत्र है।
बड़े पैमाने का घोटाला
लार्ज-स्केल स्क्रम एक उत्पाद विकास ढांचा है जो स्क्रम के मूल उद्देश्यों को खोए बिना स्केलिंग नियमों और दिशानिर्देशों के साथ स्क्रम का विस्तार करता है।
रूपरेखा के दो स्तर हैं: पहला एलईएसएस स्तर अधिकतम आठ टीमों के लिए प्रारूपित किया गया है; दूसरा स्तर, जिसे कम विशाल' के नाम से जाना जाता है, सैकड़ों डेवलपर्स के साथ विकास के लिए अतिरिक्त स्केलिंग तत्व प्रस्तुत करता है। स्केलिंग स्क्रम मानक वास्तविक एक-टीम स्क्रम को समझने और अपनाने में सक्षम होने से प्रारंभ होती है। बड़े पैमाने के स्क्रम के लिए एकल-टीम स्क्रम तत्वों के उद्देश्य की जांच करना और यह पता लगाना आवश्यक है कि मानक स्क्रम नियमों की बाधाओं के भीतर रहते हुए उसी उद्देश्य तक कैसे पहुंचा जाए।[58]बास वोड्डे और क्रेग लर्मन ने बड़े पैमाने पर उत्पाद विकास, विशेष रूप से दूरसंचार और वित्त उद्योगों में काम करने के अपने अनुभवों से एलईएसएस ढांचे को विकसित किया। यह स्क्रम को लेकर और क्या काम करता है यह जानने के लिए कई अलग-अलग प्रयोगों को आजमाकर विकसित हुआ। 2013 में, प्रयोगों को लेस फ्रेमवर्क नियमों में समेकित किया गया।[59] लेस के संगठन की जटिलता को 'डीस्केल' करना, अनावश्यक जटिल संगठनात्मक समाधानों को समाप्त करना और उन्हें सरल विधियों से हल करना है।
आलोचना
बताया गया है कि स्क्रम इवेंट उत्पादकता को नुकसान पहुंचा रहे हैं और समय बर्बाद कर रहे हैं जिसे वास्तविक उत्पादक कार्यों पर बेहतर तरीके से खर्च किया जा सकता है।[60][61] सामान्यतः घटना के उद्देश्य और लक्ष्य की गलतफहमी के कारण होता है।[62] कई स्क्रम कार्यान्वयनकर्ता, दैनिक स्क्रम की तरह, एक संक्षिप्त समय-सीमा वाली चर्चा के अतिरिक्त एक संपूर्ण स्थिति बैठक के रूप में आयोजन करते हैं। स्क्रम प्रथाएं बहुत तेजी से सूक्ष्मप्रबंधक के रूप में बदल सकती हैं और उसी नियमावली को फिर से प्रस्तुत कर सकती हैं जिसे प्रथाओं ने दूर करने की मांग की थी। स्क्रम यह भी मानता है कि काम पूरा करने के लिए आवश्यक प्रयास का सटीक अनुमान लगाया जा सकता है, यद्यपि, यह पूर्वानुमानित हो सकता है।[63] स्क्रम अनुदेशात्मक प्रथाओं को छोड़ देता है[64] साम्प्रदायिक विश्लेषण और प्रयोग की स्वतंत्रता को प्रोत्साहित करने के लिएअब सामान्य रूप से स्क्रम के विकारी तरीके, जैसे डार्क स्क्रमऔर स्क्रीम को एंटी-पैटर्न के रूप में मान्यता प्राप्त की गई है।
यह भी देखें
- चंचल सॉफ्टवेयर विकास
- अनुशासित त्वरित वितरण
- स्क्रम सॉफ्टवेयर की तुलना
- उच्च प्रदर्शन वाली टीमें
- लीन सॉफ्टवेयर विकास
- परियोजना प्रबंधन
- एकीकृत प्रक्रिया
उद्धरण
- ↑ "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 Ken Schwaber, Jeff Sutherland. "स्क्रम गाइड" (PDF). Scrum.org. Retrieved June 15, 2023.
{{cite web}}: CS1 maint: uses authors parameter (link) - ↑ "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.
- ↑ ज्ञान सृजन कंपनी. Oxford University Press. 1995. p. 3. ISBN 9780199762330. Retrieved March 12, 2013.
- ↑ 9.0 9.1 Takeuchi, Hirotaka; Nonaka, Ikujiro (January 1, 1986). "नया नया उत्पाद विकास खेल". Harvard Business Review. Retrieved June 9, 2010.
Moving the Scrum Downfield
- ↑ 10.0 10.1 10.2 10.3 10.4 Schwaber, Ken (February 1, 2004). स्क्रम के साथ चुस्त परियोजना प्रबंधन. Microsoft Press. ISBN 978-0-7356-1993-7.
- ↑ 11.0 11.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.
- ↑ "एजाइल सॉफ्टवेयर विकास के लिए घोषणापत्र". Retrieved October 17, 2019.
- ↑ 13.0 13.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.
- ↑ 14.0 14.1 14.2 14.3 14.4 14.5 14.6 14.7 Sutherland, Jeff; Schwaber, Ken (2013). "स्क्रम मार्गदर्शिकाएँ". ScrumGuides.org. Retrieved June 15, 2023.
- ↑ Schwaber, Ken; Beedle, Mike (2002). स्क्रम के साथ चुस्त सॉफ्टवेयर विकास. Prentice Hall. ISBN 978-0-13-067634-4.
- ↑ Partogi, Joshua (July 7, 2013). "प्रमाणित स्क्रम मास्टर बनाम प्रोफेशनल स्क्रम मास्टर". Lean Agile Institute. Retrieved May 10, 2017.
- ↑ 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
- ↑ 19.0 19.1 19.2 19.3 Morris, David (2017). Scrum: an ideal framework for agile projects. In Easy Steps. pp. 178–179. ISBN 9781840787313. OCLC 951453155.
- ↑ 20.0 20.1 20.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.
- ↑ 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.
- ↑ 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.
- ↑ "उत्पाद स्वामी की भूमिका". Scrum Master Test Prep. Retrieved February 3, 2017.
- ↑ Rad, Nader K.; Turley, Frank (2018). एजाइल स्क्रम फाउंडेशन कोर्सवेयर, दूसरा संस्करण. 's-Hertogenbosch, Netherlands: Van Haren. p. 26. ISBN 9789401802796.
- ↑ 27.0 27.1 27.2 27.3 27.4 27.5 27.6 27.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.
- ↑ 29.0 29.1 29.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.
- ↑ 53.0 53.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.
- ↑ 55.0 55.1 55.2 55.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.
- ↑ 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.
संदर्भ
- 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 | |||||||
