स्क्रम का परिचय

स्क्रम का इतिहास

1970 में विंस्टन रॉयस की "मैनेजिंग द डेवलपमेंट ऑफ लार्ज सॉफ्टवेयर सिस्टम्स" रिपोर्ट के प्रकाशन के बाद से, कई लोगों ने ऐसी पद्धति खोजने की कोशिश की है जो जलप्रपात विकास मॉडल के नुकसान को खत्म कर सके। "झरना" का एक विकल्प स्क्रम विधि थी, जिस पर अब चर्चा की जाएगी।

स्क्रम को अपना नाम 1986 में Takeuchi और Nonaki के कार्य द न्यू रूल्स फॉर न्यू प्रोडक्ट डेवलपमेंट से मिला। इस दस्तावेज़ का तर्क है कि लक्ष्य प्राप्त करने का सबसे प्रभावी तरीका डेवलपर्स को एक स्पष्ट कार्य योजना देना है।

1995 में, सदरलैंड और श्वेइबर द्वारा एक और गाइड, "सॉफ्टवेयर डेवलपमेंट विथ स्क्रम," दिखाई दिया। यह प्रकाशन तब से कई बार अद्यतन किया गया है। अब इसे इस पद्धति के विकास का मुख्य मार्गदर्शक माना जाता है। स्क्रम गाइड के वर्तमान संस्करण में 2020 में अपडेट की गई जानकारी शामिल है।

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

स्क्रम में भूमिकाएँ

स्क्रम में तीन भूमिकाएँ हैं, जिनमें से सभी एक स्क्रम टीम बनाती हैं:

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

डेवलपर्स को तकनीकी कार्यों के कार्यान्वयन के लिए सौंपा गया है, जिसकी क्रॉस-कार्यक्षमता आवेदन के दायरे पर निर्भर करती है। डेवलपर्स स्प्रिंट बैकलॉग बनाने, कोड लिखने, स्प्रिंट लक्ष्य के लिए प्रोजेक्ट तैयार करने और अन्य कार्यों में व्यस्त हैं।

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

स्क्रम में घटनाएँ

स्क्रम घटनाएँ 5 प्रकार की होती हैं:

स्प्रिंट स्क्रम का सबसे महत्वपूर्ण हिस्सा है। इसमें स्प्रिंट योजना, दैनिक स्टैंड-अप (दैनिक स्क्रम), स्प्रिंट की समीक्षा और पूर्वव्यापी शामिल हैं।

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

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

स्प्रिंट समीक्षा (डेमो) - स्प्रिंट के दौरान बनाए गए परिणाम दिखाएं। आमतौर पर यह आयोजन अंतिम चरण में होता है। सभी इच्छुक व्यक्ति इसमें भाग लें।

स्प्रिंट रेट्रोस्पेक्टिव - स्प्रिंट के परिणामों की चर्चा। टीम के सदस्य इस बारे में अपनी राय साझा करते हैं कि उन्हें सौंपे गए कार्यों का उन्होंने कैसे सामना किया और भविष्य में काम के परिणामों को कैसे बेहतर बनाया जाए।

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

कलाकृतियों

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

स्प्रिंट कलाकृतियों में शामिल घटक:

उत्पाद बैकलॉग - इंटरफ़ेस और बैकएंड सुविधाएँ।

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

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

उत्पाद बैकलॉग आइटम - इसे स्प्रिंट पुनरावृत्ति के दौरान पूरा किया जाना चाहिए। एक नियम के रूप में, तत्व को कई छोटे कार्यों में बांटा गया है।

स्प्रिंट लक्ष्य वे कार्य हैं जिन्हें पूरा करने की आवश्यकता है (एक बैकलॉग आइटम या अन्य कार्य बनाएं)।

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

उत्पाद रिलीज़/उत्पाद बर्न-डाउन चार्ट अगले स्प्रिंट के अंत से पहले स्क्रम मास्टर द्वारा तैयार किया गया चार्ट है। क्षैतिज अक्ष स्प्रिंट है, ऊर्ध्वाधर अक्ष शेष कार्य की मात्रा है।

स्क्रम फ्रेमवर्क नियम

भूमिकाएँ, घटनाएँ और कलाकृतियाँ स्क्रम का आधार हैं, लेकिन इसके अलावा अन्य नियम भी हैं। ये सभी कार्य प्रक्रिया की दक्षता को बढ़ाते हैं। यहां उन नियमों की सूची दी गई है:

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

स्क्रम में सीमाएं

स्पष्ट लाभों के साथ, स्क्रम के नुकसान भी हैं:

• स्क्रम अक्सर एक सामान्य समय सीमा की कमी के कारण किए गए कार्य की मात्रा में कमी की ओर जाता है।
• परियोजना प्रतिभागियों के बीच कम भागीदारी या सहयोग करने की अनिच्छा के साथ, परिणाम विफल होने की काफी संभावनाएं हैं।
• बड़ी टीमों में स्क्रम संरचना का उपयोग करना कठिन है, लेकिन फिर भी यह संभव है। इसके लिए स्केलिंग फ्रेमवर्क हैं: LeSS, SAFe, Nexus और अन्य।
• परियोजना के बीच में टीम से एक या एक से अधिक सदस्यों का प्रस्थान परियोजना को बहुत अच्छी तरह प्रभावित नहीं करता है।