---

Scrum Master प्रमाणन हुआ किफायती: चरणबद्ध योजना

हमें बताते हुए गर्व है कि यह लेख प्रकाशित हुआ...
यहाँ LinkedIn पर >>>

जब से Scrum फ्रेमवर्क सॉफ्टवेयर विकसित करने और देने के सर्वोत्तम तरीकों में शामिल हुआ है, सभी का लक्ष्य समान लगता है।

सुबह उठें, लैपटॉप खोलें और यह होने की खुशी तथा सुकून महसूस करें:

Scrum Master प्रमाणन।

यही सपना है, है न?

बेहतरीन प्रदान करें सॉफ्टवेयर अपने नियोक्ताओं और ग्राहकों को।

Scrum प्रक्रिया के कौशल और ज्ञान तथा अपने प्रमाणन से शानदार करियर बनाएँ Scrum Master प्रमाणन.

अधिकांश लोग Scrum फ्रेमवर्क की शुरुआत Scrum Master प्रमाणन से करते हैं।

इस लेख में पहली बार मैं Scrum Master प्रमाणन पाने में मदद के लिए एक उन्नत और विस्तृत चरणबद्ध मार्गदर्शिका साझा करना चाहती हूँ।

किफायती, तेज, ऑनलाइन और बिना परेशानी!

केवल चार आसान चरणों में आप एक उत्कृष्ट Scrum पेशेवर बन सकते हैं, अपने Scrum Master प्रमाणन के साथ।

इस लेख का उद्देश्य दिखाना है कि Scrum आपके करियर में कैसे मदद कर सकता है और पेशेवर प्रभावशीलता कैसे बढ़ा सकता है। साथ ही, आपको Scrum Master के कौशल और क्षमताएँ विकसित करना जल्द क्यों जारी रखना चाहिए।

परिभाषा — Scrum Master प्रमाणन क्या है?

इसकी सर्वोत्तम परिभाषा आप पा सकते हैं कि Scrum Master प्रमाणन क्या है, यहाँ International Scrum Institute™का Scrum Master Accredited Certification™.

Scrum Master प्रमाणन है Scrum सॉफ्टवेयर विकास और डिलीवरी प्रक्रिया में आपकी योग्यता का प्रमाण। Scrum Master प्रमाणन मान्यता देता है औपचारिक बहुविकल्पीय परीक्षण मूल्यांकन के बाद Scrum फ्रेमवर्क में आपके प्रदर्शित ज्ञान और उत्कृष्ट विशेषज्ञता को।

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

यदि आप अब भी सोच रहे हैं, तो मैं आश्वस्त करना चाहती हूँ कि Scrum Master प्रमाणन के बिना बढ़ते करियर की कल्पना अब नहीं की जा सकती। यह आपकी भूमिका, पद या अनुभव से स्वतंत्र है सूचना प्रौद्योगिकी (IT) परिवेश में।

Scrum क्या है और कैसे काम करता है, यह समझने तथा Scrum Master प्रमाणन पाने के लिए अब IT पेशेवर होना भी जरूरी नहीं है।

आप आजीविका के लिए कुछ भी करते हों, IT विभाग में हों या न हों, एक आवश्यक और निर्विवाद तथ्य है। संगठन के लिए आपके कार्य और पेशेवर व्यावसायिक मूल्य निर्भर हैं तथा जुड़े हैं IT, सॉफ्टवेयर और Agile Scrum प्रक्रिया और सिद्धांतों से.

इसके अलावा, पारंपरिक व्यावसायिक मॉडल बदलकर सेवा के रूप में सॉफ्टवेयर (SaaS) संचालित व्यवसाय या तथाकथित डिजिटलीकरण आंदोलन, बनने के कारण IT विभाग के भीतर या बाहर किसी पेशेवर के लिए Scrum Master प्रमाणन अब स्वैच्छिक निर्णय नहीं रहा। आज Scrum Master प्रमाणन लेना आवश्यक है।

आप करियर की शुरुआत कर रहे हों या अनुभवी IT पेशेवर हों, इससे फर्क नहीं पड़ता। आपको Scrum Master प्रमाणन चाहिए।

आपकी भूमिका में लोगों और विभागों का प्रबंधन शामिल हो या न हो, इससे भी फर्क नहीं पड़ता; आपको फिर भी Scrum Master प्रमाणन चाहिए।

आपका पद इनमें से हो सकता है:

• व्यवसाय विश्लेषक,
• सॉफ्टवेयर आर्किटेक्ट,
• एंटरप्राइज आर्किटेक्ट,
• सॉफ्टवेयर डिजाइनर
• उपयोगकर्ता अनुभव (UX) डिजाइनर,
• उपयोगकर्ता इंटरफेस (UI) डिजाइनर,
• सॉफ्टवेयर डेवलपर,
• सॉफ्टवेयर विकास प्रबंधक,
• परीक्षण इंजीनियर,
• परीक्षण स्वचालन विशेषज्ञ,
• परीक्षण प्रबंधक,
• IT प्रणाली संचालन विशेषज्ञ,
• Unix/Linux प्रशासक,
• सूचना सुरक्षा (InfoSec) इंजीनियर,
• IT नेटवर्क इंजीनियर,
• डेटाबेस प्रशासक (DBA),
• परियोजना प्रबंधक,
• कार्यक्रम प्रबंधक,
• उत्पाद प्रबंधक,
• टीम लीडर, प्रबंधक, निदेशक या कार्यकारी,
• या कोई अन्य पद जिसका यहाँ उल्लेख नहीं है।

आज ही Scrum सॉफ्टवेयर विकास फ्रेमवर्क सीखें और Scrum Master बनें, अपना प्राप्त करके Scrum Master प्रमाणन.

Agile Scrum प्रक्रिया और Scrum Master प्रमाणनों से पहले की अराजकता तथा निराशा के 3 तत्व

सॉफ्टवेयर इंजीनियरिंग पद्धतियों और व्यवसायों पर Scrum फ्रेमवर्क का प्रभाव बेहतर समझने के लिए जीवन के एक दिन (या जीवन की एक सॉफ्टवेयर परियोजना) को देखना उपयोगी है।

इसलिए मैं संगठनों में Scrum विकास और सॉफ्टवेयर डिलीवरी फ्रेमवर्क अपनाने से पहले की एक सॉफ्टवेयर परियोजना पर संक्षेप में बात करना चाहती हूँ।

ये पंक्तियाँ लिखने से कुछ दिन पहले मैंने एक पूर्व सहकर्मी के साथ दोपहर का भोजन किया, जिसके साथ लगभग 20 साल पहले काम करती थी। Marcus ने Scrum Master और Scrum Product Owner प्रमाणन प्राप्त किया है International Scrum Institute™.

वह अब Agile परियोजना प्रबंधन सॉफ्टवेयर क्षेत्र की एक अग्रणी कंपनी में Scrum Master है।

Scrum Master के रूप में Marcus अब ऐसी Agile Scrum टीम की सहायता करता है जिसके सदस्य दुनियाभर के विभिन्न स्थानों पर हैं।

भोजन के दौरान Marcus ने माना कि विभिन्न स्थानों की Agile Scrum टीमों में कई सामान्य चुनौतियाँ होती हैं। अपनी परियोजना व्यवस्था से जुड़ी कुछ समस्याएँ उसने खास तौर पर बताईं:

• Scrum टीम सदस्यों की कार्यशैलियों में अंतर,
• समय क्षेत्र के अंतर,
• सांस्कृतिक असंगति, और
• भाषा की सीमाएँ।

इन कठिनाइयों के बावजूद Marcus ने कहा कि Agile Scrum प्रक्रिया से सॉफ्टवेयर परियोजना चलाना, 20 साल पहले के हमारे काम की तुलना में अधिक आनंददायक, उत्पादक और समृद्ध अनुभव है। उन दिनों की तुलना में जब हम Scrum सॉफ्टवेयर विकास और डिलीवरी प्रक्रियाओं के बिना काम करते थे।

Marcus का कथन एक सफल और अनुभवी प्रबंधक, Scrum Master तथा Product Owner की ओर से Scrum फ्रेमवर्क के पक्ष में बड़ी गवाही था।

धन्यवाद, Marcus!

फिर मैंने उसे Scrum फ्रेमवर्क से परिचित होने से पहले की एक परियोजना बताई। मुझे विश्वास है कि कई Scrum Master इस अनुभव को प्रमाणन से पहले की अपनी परियोजनाओं जैसा पाएँगे।

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

यह जटिल परियोजना थी, जिसमें कई परस्पर निर्भर हार्डवेयर तथा सॉफ्टवेयर टीमें थीं। बहुत अधिक करना पड़ा अनुसंधान और विकास (R&D) पूरी कार्यशील हार्डवेयर और सॉफ्टवेयर प्रणाली के लिए।

याद रखें, ये उससे पहले के दिन थे जब हमारे पास था न्यूनतम व्यवहार्य उत्पाद (MVP) की अवधारणा का, जिससे प्रयोग, निर्माण, सीख और फिर प्रयोग करते।

Agile पद्धति में MVP बनाना और जानना चाहें, तो यह देखें लेख Cleevio का, जो इस जटिल प्रक्रिया की बेहतर समझ देगा।

Scrum के बिना, कई हार्डवेयर और सॉफ्टवेयर तत्वों वाला इतना जटिल ढाँचा बनाना वास्तविक चुनौती थी।

हमारी टीमों में Scrum Master या उसका प्रमाणन रखने वाला कोई व्यक्ति न होने पर तीन बड़ी कठिनाइयाँ थीं।

Scrum Master प्रमाणन के बिना अराजकता और निराशा का पहला तत्व: परियोजना को समझने से पहले ही पूरी योजना बनानी पड़ती थी

Scrum के बिना हमारी टीमों ने ऐसे पूरी तरह गलत सॉफ्टवेयर और हार्डवेयर उत्पाद बनाए तथा दिए जो ग्राहक की माँग पूरी नहीं करते थे।

हमारे पेशेवर जीवन में ऐसा समय था जब कुछ बाहरी कंपनियाँ तय करती थीं कि हमें सॉफ्टवेयर उत्पाद या सेवाएँ कैसे बनानी चाहिए।

क्षमता परिपक्वता मॉडल (CMM), ISO 9001:2008 और अन्य व्युत्पन्न पद्धतियाँ कंपनियों को सही तरीके से सही सॉफ्टवेयर बनाने में मदद करने का प्रयास करती थीं।

वे कितनी सफल थीं, यह इस लेख का विषय नहीं है। इसका ध्यान Scrum प्रक्रिया और Scrum Master प्रमाणन के गुणों पर है, गुणवत्ता प्रबंधन तथा प्रक्रिया सुधार मानकों को Scrum के विलुप्त विकल्प मानने पर नहीं।

लेकिन जोड़ना चाहती हूँ कि Scrum सॉफ्टवेयर इंजीनियरिंग फ्रेमवर्क से पहले ये प्रक्रिया सुधार फ्रेमवर्क परियोजनाओं में चरणबद्ध रूप से लागू किए जाते थे। हमने चरणबद्ध सॉफ्टवेयर इंजीनियरिंग तरीका अपनाया, जिसे कहते थे वॉटरफॉल सॉफ्टवेयर इंजीनियरिंग मॉडल.

वॉटरफॉल मॉडल में हर परियोजना आवश्यकता विश्लेषण से शुरू होनी थी, जिसमें हम समझने का प्रयास करते थे कि ग्राहक को क्या चाहिए।

फिर हम आवश्यकताओं का डिजाइन, कार्यान्वयन, परीक्षण (सत्यापन) और सॉफ्टवेयर प्रोडक्शन परिवेश में रखरखाव करते थे। अंततः सॉफ्टवेयर इंजीनियरिंग जीवनचक्र के अंत तक पहुँचते थे।

लेकिन वास्तविकता ऐसी नहीं थी!

वॉटरफॉल मॉडल के किसी चरण में अनपेक्षित देरी का बुरा असर अगले सॉफ्टवेयर इंजीनियरिंग चरणों पर पड़ना अनिवार्य था।

Scrum फ्रेमवर्क से पहले जीवन ऐसा था।

Scrum Master प्रमाणित पेशेवरों के मार्गदर्शन के बिना सॉफ्टवेयर को टीमों के बीच बार-बार भेजने से हमारा काम नौकरशाही वाला, जटिल और अनुत्पादक हो गया।

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

Scrum Master प्रमाणन के बिना अराजकता और निराशा का दूसरा तत्व: अलग-अलग टीमों में प्रतिबद्धता, परिवर्तन प्रबंधन और साथ काम करने के अनुशासन की कमी

स्क्रम से पहले के प्रक्रिया सुधार ढाँचों की सबसे बड़ी कमजोरी थी: वे मुख्यतः नेतृत्व की स्वार्थपूर्ण संगठनात्मक माँगों पर ध्यान देते थे।

जैसे निगरानी, अनुपालन और पूर्वानुमेयता। ग्राहकों की अच्छी सेवा और कर्मचारियों का मनोबल बढ़ाने पर बिल्कुल ध्यान नहीं था।

इसलिए सॉफ्टवेयर प्रबंधन और आंतरिक/बाहरी हितधारक निश्चित समयसीमा तथा चरणों की आसान निगरानी चाहते थे।

योजना से बाहर जाने पर लोगों को दंड देते और तय पूर्णता से पहले समस्याएँ सुधारने की आशा रखते थे।

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

व्यावसायिक मिशन और कर्मचारियों की पेशेवर (व्यावसायिक) परिपक्वता के बजाय इस अलगाव वाली सोच का कारण जानते हैं?

सरल कारण है मैट्रिक्स प्रबंधन। संगठन और कर्मचारी की यह संरचना 1970 के दशक से है। पहली नजर में इसका अलग विचार समझदार लगता है।

नेतृत्व समान कार्यात्मक और तकनीकी कौशल वाले कर्मचारियों को एक ही या अधिक-से-अधिक पास के अलग विभागों में रखकर संगठनात्मक संरचना बनाता है।

उन दिनों कंपनियों में तथाकथित “दक्षता केंद्र” लोकप्रिय थे, जहाँ हर केंद्र स्वतंत्र और स्वायत्त विभाग होता था।

एक C++ डेवलपर्स, दूसरा डेटाबेस प्रशासक और विदेश में अलग गुणवत्ता आश्वासन केंद्र, और भी कई। सोचिए!

मैट्रिक्स संरचना की सबसे बड़ी चुनौती थी: Scrum फ्रेमवर्क और Scrum Master के बिना परियोजना देने के लिए प्रबंधकों को विभागों से कर्मचारी अस्थायी तौर पर लेने पड़ते थे।

ये कर्मचारी भौतिक रूप से भी परियोजना टीम के साथ नहीं बैठते थे; अपने दक्षता केंद्र के कमरों में ही रहते थे।

परियोजना पूरी होने पर अस्थायी टीमें भंग हो जाती थीं और सदस्य दूसरी परियोजनाओं के अगले कार्यों पर चले जाते थे।

इसलिए परियोजनाओं के लक्ष्य व्यावसायिक मूल्य इन स्वतंत्र विभागों की सर्वोच्च प्राथमिकता कभी नहीं थे।

वे काम को यहाँ एक और वहाँ दूसरी परियोजना के टिक करने वाले खाने मानते थे।

नेतृत्व तथा मैट्रिक्स ने नहीं सिखाया कि बिक्री, राजस्व और लाभ बढ़ाने के लिए पेशेवर कैसे प्रतिबद्ध हों।

McKinsey & Company के McKinsey Quarterly लेख ने भी स्पष्ट दिखाया मैट्रिक्स संगठन से आगे लागत अनुकूलन का यह भ्रम.

मूल लेख विश्वव्यापी वार्षिक आँकड़े का Gartner अनुमान उद्धृत करता है IT प्रणालियाँ बहाल करने में 600 अरब USD खर्च करते हैं अनियोजित रखरखाव और दोषों के कारण।

अब थोड़ा समय लेकर देखें कि सॉफ्टवेयर परियोजनाओं में परिवर्तन प्रबंधन और बाधाओं को संभालना कैसे होता था। वॉटरफॉल मॉडल, मैट्रिक्स संगठन और Scrum प्रक्रिया के बिना परियोजना व्यवस्था में वे कैसे होते थे।

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

इसलिए परियोजना में बदलाव देरी का पर्याय थे। उनसे अक्सर लगातार देरी का डोमिनो प्रभाव बनता था। दोषों और बाधाओं पर टीमों को आरोप और दोषारोपण के लिए कोई चाहिए होता था।

त्रुटियाँ संसाधित, ठीक और सीखने की व्यवस्था नहीं थी, इसलिए वही गलतियाँ दोहरती थीं।

इसके अलावा, वे लगातार बढ़ाते रहे इसकी मात्रा तकनीकी ऋण जबकि निष्क्रिय ढंग से समस्याएँ सँभालने की कोशिश करते थे।

Scrum Master प्रमाणन के बिना अराजकता और निराशा का तीसरा तत्व: निरंकुश फैसलों ने लोकतांत्रिक फैसलों को दबा दिया

Steve Jobs ने एक बार कहा:

“बुद्धिमान लोगों को नियुक्त करके बताना कि क्या करें, उचित नहीं। हम उन्हें इसलिए नियुक्त करते हैं कि वे हमें बताएँ क्या करना चाहिए।”

लेकिन यह Scrum युग से पहले मुख्यधारा के अधिकांश नेतृत्व के निर्णय लेने के तरीके के बिल्कुल विपरीत है।

संगठनों में Scrum प्रक्रिया आने से पहले नेताओं के निरंकुश निर्णय टीमों की सामूहिक बुद्धिमत्ता पर हावी होते थे।

वे वास्तविक काम करने वाले समूहों की लोकतांत्रिक निर्णय क्षमता निष्प्रभावी कर देते थे जो सॉफ्टवेयर की कल्पना से संचालन तक पूरे जीवनचक्र में काम करते थे।

निर्णय उससे प्रभावित कार्य केंद्रों (टीमों) से जितनी दूर ले जाया जाता, सही अत्यावश्यक निर्णय लेना उतना कठिन होता।

नेताओं के निर्णय अक्सर आवेगपूर्ण, अधूरे विचार वाले, देर से और अनिश्चित, लेकिन कभी बहुत जल्दी होते थे।

ये निरंकुश निर्णय ऊपर से थोपे जाने पर कर्मचारी कम मूल्यवान महसूस करते थे। वे प्रतिस्पर्धी व्यवसाय तथा सॉफ्टवेयर चुनौतियों के रचनात्मक, नए समाधान की क्षमता पूरी रोकते थे।

इसके अलावा, निर्णय में योगदान माँगते समय वे सॉफ्टवेयर इंजीनियरिंग टीमों को राय देने से हतोत्साहित करते थे।

यह संगठन में Scrum फ्रेमवर्क अपनाने से पहले सॉफ्टवेयर सेवाएँ और सेवा उत्पाद बनाने तथा देने का संक्षिप्त विवरण था। अब देखें कि Scrum प्रक्रिया से हमने अराजकता और निराशा के इन तत्वों को कैसे दूर किया।

स्क्रम क्या है?

पहले स्पष्ट करना चाहती हूँ कि यह अनुभाग Scrum फ्रेमवर्क के हर प्रश्न का उत्तर देने वाला संपूर्ण संदर्भ बनाने के लिए नहीं लिखा। फिर भी यह सामग्री शुरुआती और मध्यम स्तर के अधिकांश Scrum पेशेवरों को गहन शुरुआती समझ देगी।

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

Scrum क्या है? बातें अधिक जटिल किए बिना इसे इस तरह परिभाषित किया जा सकता है:

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

हालाँकि सॉफ्टवेयर Scrum फ्रेमवर्क का मुख्य केंद्र है, पुनरावृत्त और Agile Scrum प्रक्रिया सॉफ्टवेयर उद्योग के बाहर भी लागू की जा सकती है और की जा रही है।

IT उद्योग के अधिकांश लोग मानते हैं कि “Scrum” शब्द 2000 के दशक की शुरुआत में उभरते Agile सॉफ्टवेयर विकास और डिलीवरी रुझानों के साथ गढ़ा गया था। यह जानकारी गलत है!

जनवरी 1986 के Harvard Business Review लेख में उत्पाद विकास का ऐसा तरीका बताया गया जो बाद के Scrum फ्रेमवर्क से पहले आया था। Hirotaka Takeuchi और Ikujiro Nonaka ने लेख लिखा: The New New Product Development Game। (हाँ, दो बार New)

आपको देखना चाहिए “The New New Product Development Game” ताकि जान सकें कि Scrum की शुरुआत कैसे हुई!

IT उद्योग में Scrum फ्रेमवर्क की बात करते समय “Scrum” के साथ “Agile Scrum” शब्द भी अक्सर सुनते हैं। इससे कुछ लोग दोनों में अंतर सोचने और खोजने लगे।

अच्छी खबर है। “Agile Scrum” और “Scrum”, दोनों एक ही चीज बताते हैं। दोनों Scrum सॉफ्टवेयर इंजीनियरिंग प्रक्रिया हैं। फिर कभी-कभी “Scrum” से पहले “Agile” क्यों लगाते हैं?

क्योंकि Scrum फ्रेमवर्क ने पूरी तरह अपनाया और समाहित किया है Agile Manifesto (Agile सॉफ्टवेयर विकास का घोषणापत्र) अपनी मूल प्रक्रिया, सिद्धांतों और अंतर्निहित दर्शन में। इसलिए तकनीकी पहलुओं में जाने से पहले Agile Manifesto और Scrum प्रक्रिया के मूल्यों को बेहतर समझें।

Agile Manifesto (Agile सॉफ्टवेयर विकास का घोषणापत्र)

एजाइल मैनिफेस्टो के मूल्य:

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

दाईं ओर के तत्वों का भी काफी मूल्य है, लेकिन Agile Manifesto बाईं ओर के तत्वों को अधिक महत्व और प्राथमिकता देता है।

एजाइल मैनिफेस्टो में प्राथमिकता पाए तत्वों को समय की कसौटी पर परखा गया है और सावधानी से इसलिए चुना गया है कि वे:

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

Scrum फ्रेमवर्क के मूल्य

मैं पहले बता चुकी हूँ कि Scrum फ्रेमवर्क केवल सॉफ्टवेयर इंजीनियरिंग प्रक्रिया नहीं है। इसके पीछे मजबूत सिद्धांत भी हैं।

वास्तव में अधिकतर पेशेवर व्यावसायिक क्षेत्रों में इनका उपयोग संभव है।

Scrum में बहुत सफल होने के लिए केवल Scrum Master प्रमाणन पर्याप्त नहीं है। सफलता के लिए Scrum मूल्यों की मजबूत समझ चाहिए।

ताकि बेहतरीन काम और ग्राहक तथा नियोक्ता की पसंद का सॉफ्टवेयर दें। अब Scrum प्रक्रिया के इन सिद्धांतों के बारे में और बताती हूँ।

साहस

कभी ग्राहकों को सर्वोत्तम मूल्य और लाभ देने वाला सही काम सबसे आसान नहीं होता। ऐसे समय Scrum Master, Scrum Product Owner और सदस्यों को अपना कर्तव्य और दायित्व याद रखना चाहिए।

अर्थात व्यवसाय और IT क्षेत्र में सर्वोत्तम उत्पाद तथा सेवाएँ। सामान्य से बेहतर होने के लिए, Scrum टीम को देर-सबेर ऐसे कठिन फैसले लेने पड़ते हैं जो उसके हितधारकों के परिवेश में सबको खुश नहीं करेंगे।

इससे निपटने के लिए सभी सदस्यों को Scrum Master प्रमाणन प्रशिक्षण की सीख याद रखनी चाहिए।

उन्हें साहसी रहना और साहस के साथ निर्णय तथा कार्रवाई करना सीखना चाहिए।

एकाग्रता

Scrum में “ध्यान” मूल्य सुनते समय दो बातों पर विचार करें:

• सही काम की पहचान: मेरे Sprint के लक्ष्य पूरे करने के लिए कौन-से कार्य जरूरी हैं? ग्राहकों के लिए बेहतरीन सॉफ्टवेयर उत्पाद और सेवाएँ बनाने को क्या आवश्यक है, ताकि वे मेरे काम से प्रसन्न हों?
• प्राथमिकता: आगे किस कार्य पर काम करूँ?

हर क्षण एक महत्वपूर्ण प्रश्न है जिसका उत्तर Scrum Master और Product Owner सहित पूरी टीम को देना चाहिए। वह प्रश्न है: “नियोक्ता ने हमें जिन कारणों से नियुक्त किया था, उन्हें पूरा करने के लिए अभी हमें कौन-से सबसे महत्वपूर्ण काम करने चाहिए?”

Scrum फ्रेमवर्क में यूजर स्टोरी और कार्यों की उचित प्राथमिकता के लिए कई अंतर्निहित इवेंट (अनुष्ठान) हैं। Scrum के अनुसार यूजर स्टोरी और संबंधित कार्यों की प्राथमिकता तय करने को लगातार प्राथमिकता मिलनी चाहिए।

इससे सुनिश्चित होता है कि टीम सही चीजों पर सही क्रम में काम करे। औपचारिक Scrum इवेंट और संबंधित परिष्करण पद्धतियाँ हमारे ध्यान की जाँच और काम को अनुकूलित करने में मदद करती हैं:

• Scrum ग्रूमिंग बैठक: परिष्करण आगामी Product Backlog मदें स्पष्ट करता, बाँटता और उनका आकार तय करता है तथा क्रम तय करने में जानकारी देता है। इस निरंतर गतिविधि के लिए बैठक एक विकल्प है।
• Sprint Planning बैठक: स्टोरी देने की निर्भरता और सही कार्य क्रम दिखाती है।
• Daily Scrum बैठक: Daily Scrum (दैनिक स्टैंड-अप) बैठकें आने वाले कार्यदिवस की दिशा तय करने में मदद करती हैं। ध्यान वहीं लगाएँ जहाँ सबसे जरूरी हो।
• Sprint Review बैठक: Sprint Review बैठक अप्रत्यक्ष रूप से बताती है कि भविष्य की समीक्षाएँ अधिक सफल बनाने के लिए टीम को कहाँ जोर देना चाहिए।
• Sprint Retrospective बैठक: ये बैठकें इंजीनियरिंग प्रक्रिया के पहले सुधारे जाने वाले पहलुओं की प्राथमिकता तय करने में मदद करती हैं।

इस अनुभाग में मैंने Scrum अनुष्ठानों को केवल ध्यान के दृष्टिकोण से समझाया। अधिक विस्तृत विवरण मिलेगा इस लेख में आगे Scrum समारोहों के बारे में.

यह सब पढ़ने के बाद स्पष्ट होगा कि Scrum में प्राथमिकता और ध्यान कितने आवश्यक हैं।

प्रतिबद्धता

Scrum Master, Scrum Product Owner और टीम की प्रतिबद्धता के बिना सॉफ्टवेयर से बेहतरीन परिणाम देना संभव नहीं है।

Scrum सॉफ्टवेयर विकास की दुनिया में अधिकतर लोग प्रतिबद्धता को दिए Sprint के डिलीवेरेबल के लक्ष्यों पर सहमति और उनसे बँधे रहने के रूप में समझते हैं।

यह सार्थक है, पर समझ पूरी तरह दोषरहित नहीं। Scrum मूल्यों में “प्रतिबद्धता” सुनने पर लेखक समर्पण पर जोर देने के लिए “जुनून” शब्द इस्तेमाल करता है। Scrum की परिभाषा में प्रतिबद्धता टीम के लक्ष्यों और पारस्परिक सहायता से जुड़ी है; इसके लिए जरूरत से अधिक काम या पूर्वानुमान की हर मद पर निश्चितता जरूरी नहीं है।

सॉफ्टवेयर इंजीनियरिंग, जीवन और व्यवसाय में सफल होने के लिए अपने लक्ष्यों के प्रति जुनून चाहिए। इसलिए Scrum प्रक्रिया के संदर्भ में, ग्राहकों की समस्याएँ हल करने का बेहतरीन सॉफ्टवेयर बनाने का जुनून रखें।

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

फिर Scrum Master और टीम Product Owner को Sprint लक्ष्य न दे पाने के कारण उचित साबित करने वाले स्पष्टीकरण बनाने लगेंगे। औसत से बेहतर टीम बनना चाहते हैं, तो बहानों के लिए अब जगह नहीं होनी चाहिए।

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

सम्मान

उम्र, लिंग, नस्ल, विश्वास, अनुभव, योग्यता, राय और कार्य प्रदर्शन से स्वतंत्र, हर सदस्य को एक-दूसरे का सम्मान और भरोसा करना चाहिए।

यह सम्मान केवल टीम तक सीमित नहीं है। उससे संवाद करने वाले सभी आंतरिक और बाहरी IT तथा व्यावसायिक हितधारकों का भी पूरा सम्मान और स्वागत होता है।

अनुभवी सदस्यों को ध्यान रखना चाहिए कि कम अनुभवी सदस्यों की योगदान देने की इच्छा दबे नहीं।

खास तौर पर विपरीत राय को उचित ढंग से सुनना और उत्तर देना जरूरी है, भले बहुमत उससे सहमत न हो।

खुलापन

“खुलापन” अक्सर औसत और उच्च प्रदर्शन वाली Scrum टीम में मुख्य अंतर होता है। टीम के खुलेपन को खुले विचारों वाले व्यक्तियों के समूह की विशाल क्षमता जैसा समझें।

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

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

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

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

Scrum फ्रेमवर्क के मुख्य घटक

Scrum Team में एक Product Owner, एक Scrum Master और Developers होते हैं, जिनकी तीन अलग जवाबदेहियाँ हैं। इस लेख का पहले का “Scrum Team Member” शब्द विकास समूह को बताता है, चौथी जवाबदेही या अलग पूरी Scrum Team को नहीं।

विश्व के छात्रों के अन्य कार्यक्रमों के अलावा, International Scrum Institute™ इन तीन भूमिकाओं के तीन मुख्य प्रशिक्षण और प्रमाणन कार्यक्रम देता है।

ये कार्यक्रम हैं Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), और Scrum Team Member Accredited Certification™ (STMAC™).

उचित Scrum संगठन में इन तीनों प्रकार के कौशल वाले पर्याप्त लोग होने चाहिए। Scrum सॉफ्टवेयर विकास फ्रेमवर्क में सफलता के लिए यह विशेष रूप से आवश्यक है।

Scrum की हर जवाबदेही पूरी होनी चाहिए। जिम्मेदारियाँ अलग रहती हैं; Product Owner या Scrum Master, Sprint Backlog का काम करते हुए Developer का योगदान भी दे सकता है, अपनी अन्य जवाबदेही की जिम्मेदारियाँ खोए बिना।

एक उत्पाद पर काम करती कई Scrum टीमें एक Product Owner, Product Goal और Product Backlog साझा करती हैं। हर टीम में Scrum Master की जवाबदेही और प्रभावी सहायता चाहिए; Scrum यह निर्धारित नहीं करता कि एक व्यक्ति केवल एक टीम की सहायता कर सकता है।

इन भूमिकाओं का उद्देश्य और कार्य समझने तथा उपयुक्त प्रतिभा नियुक्त करने की अहमियत कम न आँकें। हमने कई बार देखा कि टीम की कठिनाइयों का मूल कारण भूमिकाएँ न समझना या सही लोग न नियुक्त करना है।

अब इन तीन भूमिकाओं पर बात करें।

तीन Scrum भूमिकाएँ — Scrum Product Owner की भूमिका

Scrum Product Owner उत्पाद मूल्य अधिकतम करने के लिए Product Backlog का क्रम तय करती है और उत्पाद तथा रिलीज के निर्णयों पर हितधारकों के साथ काम करती है। Developers वह काम चुनते हैं जिसे Sprint में पूरा कर पाने का पूर्वानुमान है; रिलीज व्यवस्था उत्पाद के संदर्भ पर निर्भर है। वह अंतिम उपयोगकर्ताओं की कार्यात्मक और गैर-कार्यात्मक माँगों का प्रतिनिधित्व करती है।

यह पारंपरिक परियोजना, कार्यक्रम या उत्पाद प्रबंधन से कहीं व्यापक है।

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

Scrum Product Owner के आवश्यक कार्य हैं:

• आवश्यकताएँ सँभालना और स्पष्ट करना,
• रिलीज मार्गदर्शन और निवेश प्रतिफल (ROI) सुनिश्चित करना,
• Scrum टीम के साथ निकटता से काम करना,
• हितधारकों का प्रबंधन करना।

तीन Scrum भूमिकाएँ — Scrum टीम सदस्य की भूमिका

Scrum टीम सॉफ्टवेयर लागू करती है। Developers चुनते हैं कि इस दौरान कितना काम पूरा कर सकने का पूर्वानुमान है स्प्रिंट। Sprint निश्चित अवधि का इवेंट है; इस दौरान बना उपयोग योग्य उत्पाद परिणाम Increment होता है, जो पूर्णता की परिभाषा को पूरा करता है।

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

वे मिलकर उत्कृष्ट सॉफ़्टवेयर बनाते और देते हैं, जिसके लिए उनका ग्राहक भुगतान कर रहा है।

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

संगठन में पुराने स्थान से स्वतंत्र, सदस्य अपनी Scrum परियोजना से जुड़े होते हैं। उनका काम Product Owner की आवश्यकताएँ पूरी करने के लिए सर्वोत्तम सॉफ्टवेयर बनाना है।

Scrum टीमों की विशेषताएँ:

• सशक्त,
• स्वायत्त,
• विभिन्न कौशलों वाली,
• स्व-संगठित,
• छोटी,
• पर्याप्त उपलब्ध सदस्य (पूर्णकालिक सहभागिता आम संगठनात्मक विकल्प है),
• निकट सहयोग में सक्षम, चाहे साथ हों या विभिन्न स्थानों पर,
• एक सबके लिए, सब एक के लिए।

तीन Scrum भूमिकाएँ — Scrum Master की भूमिका

Scrum Master परियोजना के सभी प्रतिभागियों और बाहरी हितधारकों को Scrum फ्रेमवर्क सही समझने तथा लागू करने में सेवा देती है। वह टीम को Scrum प्रक्रिया सफलतापूर्वक चलाने और उत्पादकता तथा प्रदर्शन निरंतर सुधारने में मदद करती है।

Scrum Master की भूमिका Scrum प्रक्रिया तथा सोचने और काम करने का नया तरीका स्थापित करना है।

Scrum Master परिवर्तनकारी भूमिका भी निभाती है। वह टीम को नए मानदंड और मानक विकसित करने की कोचिंग देती है। वह टीम के लिए सुलभ रहती है; भौतिक निकटता सहायक हो सकती है, पर Scrum में अनिवार्य नहीं है।

Scrum Master की मुख्य जिम्मेदारियाँ:

• अपने व्यवसाय और IT परिवेश में Scrum स्थापित करना,
• टीम को Scrum मूल्य समझने और अपनाने की कोचिंग देना,
• Scrum Product Owner और टीम में निकट सहयोग सुनिश्चित करना,
• बाधाएँ दूर करना,
• सेवा करके नेतृत्व देना,
• प्रभावी Scrum इवेंट में मदद और जरूरत पर संचालन करना, जबकि Daily Scrum पर Developers का स्वामित्व बना रहे।

Product Backlog (Scrum Backlog)

उत्पाद बैकलॉग (स्क्रम बैकलॉग) या स्क्रम उत्पाद बैकलॉग Scrum परियोजना की सभी ज्ञात आवश्यकताओं के प्रबंधन का केंद्रीय तत्व है।

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

Product Backlog में फीचर अनुरोध और उनके उच्च स्तरीय यूजर स्टोरी। इनमें परीक्षण और विकास परिवेश बनाने जैसी पूर्व-आवश्यक या पूरक परियोजना आवश्यकताएँ भी हो सकती हैं। ज्ञात बग हल करने, तकनीकी ऋण घटाने या सॉफ्टवेयर फीचर सुधारने की अन्य यूजर स्टोरी का भी Product Backlog में स्थान है।

हर उत्पाद का अपना Product Backlog है। उसे बनाना, बनाए रखना और परिष्कृत करना Scrum Product Owner की जिम्मेदारी है। Product Backlog इसका उत्तर नहीं देता और देना भी नहीं चाहिए कि ये आवश्यकताएँ कैसे विकसित और डिलीवर होंगी।

यह Scrum टीम का कर्तव्य है। टीम आवश्यकताएँ पूरी करने के जरूरी कार्य तय करके Sprint Backlog में दर्ज करती है। ध्यान दें कि Product Backlog और Sprint Backlog अलग आर्टिफैक्ट हैं, जरूरी नहीं कि भौतिक रूप से अलग दस्तावेज या टूल हों, हालाँकि Product Backlog की प्रविष्टियाँ Sprint Backlog की सामग्री तय करती हैं।

Product Backlog निरंतर बदलता दस्तावेज है। सॉफ्टवेयर के क्रमिक सुधार की तरह टीम के सीखने पर Product Backlog बदलता है; इसमें जोड़ना, हटाना और क्रम बदलना शामिल है। Scrum में अपने आप में अलग परिवर्तन प्रबंधन प्रक्रिया जरूरी नहीं है। Product Owner, उत्पाद की अपनी सर्वोत्तम शुरुआती समझ से Product Backlog के पहले संस्करण बनाता है।

वह हर Sprint में उभरते उत्पाद को ध्यान से देखती है और ग्राहक आवश्यकताओं का ज्ञान बढ़ने पर Product Backlog में आवश्यकताएँ जोड़ती, हटाती और परिष्कृत करती है।

Scrum Product Owner, Product Backlog की आवश्यकताओं की प्राथमिकता तय करता है। Product Backlog में मद की प्राथमिकता जितनी अधिक हो, उसमें उतना अधिक विवरण होना चाहिए। इससे टीम उच्च प्राथमिकता की आवश्यकताएँ आसानी से समझकर उन्हें बनाने के कार्य तय कर सके।

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

Sprint

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

Sprint को छोटी परियोजनाओं जैसा समझें। नाम के अनुसार Sprint लंबा नहीं चलता; यह एक महीने या उससे कम होता है। चार हफ्ते का Sprint एक सामान्य उदाहरण है, फ्रेमवर्क की सटीक अधिकतम कैलेंडर अवधि नहीं।

दौड़ से अलग, Sprint के अंत में टीम की साँस और शक्ति खत्म नहीं होनी चाहिए। उसे तरोताजा रहकर अगला Sprint उत्साह से शुरू करना चाहिए।

Scrum सॉफ्टवेयर विकास और डिलीवरी फ्रेमवर्क का उद्देश्य सदस्यों पर दबाव और तनाव डालना नहीं है। सब जानते हैं कि लोग ध्यान केंद्रित, निश्चिंत और बिना भटकाव काम कर सकें, तो सर्वोत्तम प्रदर्शन करते हैं। सही उपयोग पर Sprint यही संभव बनाता है।

हर Sprint इसकी शुरुआत से शुरू होता है Sprint Planning बैठक। Sprint Planning बैठक में टीम तय करती है कि इस Sprint में कौन-सी और कितनी आवश्यकताएँ लागू करेगी। फिर उन्हें पूरा करने की गतिविधियाँ शुरू करती है।

Daily Scrum (Daily Scrum बैठक) Sprint के हर कार्यदिवस में एक ही समय और स्थान पर होती है। Developers इससे Sprint Goal की ओर प्रगति जाँचते और अगले दिन की योजना अनुकूलित करते हैं। सदस्य ऐसी बाधाएँ दूर करने के लिए Scrum Master की मदद भी माँग सकते हैं जो Sprint की प्रगति धीमी या अवरुद्ध कर सकती हैं।

टीम Sprint Review और Sprint Retrospective बैठकों से Sprint पूरा करती है। Sprint Review बैठक टीम और प्रमुख हितधारकों को Sprint के परिणाम तथा Product Goal की ओर प्रगति जाँचने, फिर भविष्य के अनुकूलन पर चर्चा करने देती है। यह कामकाजी सत्र है, Product Owner की स्वीकृति का द्वार नहीं।

इसके दौरान, स्प्रिंट रेट्रोस्पेक्टिव बैठक, टीम साथ काम करने के तरीके, Scrum फ्रेमवर्क के उपयोग और सुधार के उपायों पर चिंतन करती है।

इसलिए अगली Sprint Planning बैठक में टीम मिलकर सुधार की संभावनाएँ और फीडबैक ध्यान में रखती है। स्प्रिंट, कम समय में काम के छोटे समूहों के साथ ऐसे प्रतिक्रिया चक्रों को संभव बनाते हैं। यह उन महत्वपूर्ण कारणों में से एक है जिनसे स्क्रम फ्रेमवर्क टीमों और संगठनों को लगातार अपना सुधार करने में मदद करता है।

Scrum में जाँच और अनुकूलन

Scrum में जाँच और अनुकूलन समझना सरल, लेकिन सही लागू करना और उसमें दक्ष होना सबसे कठिन है।

कंपनियों ने अंततः माना कि कोई परियोजना प्रबंधक जटिल प्रणालियों की पूरी तस्वीर पहले से नहीं देख सकता। वे शुरू से अंत तक विश्वसनीय योजना नहीं बना पाते थे। स्पष्ट था कि कुछ अलग आजमाना होगा।

इसके साथ लीन विनिर्माण (जिसे यह भी कहते हैं लीन आंदोलन के), कंपनियों को रणनीतिक रूप से सक्षम बनाने वाली प्रक्रिया विकसित करनी थी। उन्हें ऐसी मानक संचालन प्रक्रिया चाहिए थी जिससे परियोजनाएँ और संचालन चलाते समय सीख सकें और कार्रवाई की दिशा सुधार सकें।

यहीं जन्म हुआ Toyota Improvement Kata का, जो Scrum की जाँच और अनुकूलन से उपयोगी तुलना देती है। दोनों सुधार तरीकों का उद्देश्य संबंधित है, लेकिन Toyota Improvement Kata, Scrum के अनुभवजन्य स्तंभों का केवल दूसरा नाम नहीं है। “Scrum में जाँच और अनुकूलन” के अनुसार:

• चरण 1. जाँचें: हम अपने वर्तमान ज्ञान और समझ से परियोजना की मौजूदा स्थिति समझने का पूरा प्रयास करते हैं।
• चरण 2. अनुकूलित करें: हम अगले कदमों की दिशा और दृष्टि तय करते हैं, फिर रणनीति बनाकर दृष्टि लागू करते हैं।
• चरण 3. सीखें: हम ध्यान से देखते, सीखते और एक-दूसरे को सिखाते हैं। काम करते समय लगातार दर्ज करते हैं कि क्या काम करता है और क्या नहीं।
• चरण 4. फिर शुरू करें: फिर चरण 1 से शुरुआत करें।

ध्यान दें कि नीचे चार चरण शिक्षण की तुलना हैं, Scrum इवेंट की हूबहू परिभाषा नहीं। जाँच, अनुकूलन और सीख पूरे Sprint में होते हैं।

• चरण 1. जाँचें Sprint Review और Sprint Retrospective बैठकों जैसा है।
• चरण 2. अनुकूलित करें Sprint Planning बैठकों जैसा है।
• चरण 3. सीखें Daily Scrum बैठकों जैसा है।
• चरण 4. फिर शुरू करें एक Sprint खत्म होने और नया शुरू होने जैसा है।

स्व-संगठन

टीम स्वयं संगठित होती है। सदस्य Sprint के लक्ष्य देने के लिए आवश्यक कार्यों पर सर्वसम्मति से निर्णय लेते हैं। स्व-संगठित टीम को प्रबंधक या टीम लीडर नहीं चाहिए।

Scrum का स्व-संगठन बहुत अनुशासित है।

स्प्रिंट बैकलॉग और डेली स्क्रम बैठकें स्व-प्रबंधन में मदद करते हैं। एक Sprint बर्नडाउन चार्ट प्रगति दृश्य बनाने का एक वैकल्पिक तरीका है।

अधिकतर टीमों को अपना काम स्वयं व्यवस्थित करना सीखने का चरण चाहिए। प्रमाणित और सक्षम Scrum Master उन्हें स्व-संगठन में जल्दी उत्कृष्ट होने में मदद करते हैं।

स्व-संगठन में अलग विचारों और संभावित संघर्षों के बावजूद साथ काम करना भी है। इसमें साझा निर्णय प्रक्रियाओं का पालन और उन पर विश्वास आवश्यक है।

Scrum की इन निर्णय प्रक्रियाओं में नियोजन, अनुमान, कार्यान्वयन, रिपोर्टिंग और टीम के संयुक्त जिम्मेदारी वाले काम की समीक्षा सहित अन्य गतिविधियाँ हैं।

Scrum इवेंट और निरंतर बैकलॉग परिष्करण

Scrum इवेंट 1. Sprint Planning (क्यों, क्या और कैसे)

इसके दौरान, Sprint Planning बैठक, टीम व्यावहारिक Sprint Backlog बनाती है जो Sprint में लागू की जाने वाली आवश्यकताएँ तय करता है।

Sprint Planning बैठकों में अलग-अलग Scrum भूमिकाओं के कर्तव्य हैं:

• Product Owner प्रस्ताव देता है कि Sprint मूल्यवान क्यों हो सकता है। पूरी टीम Sprint Goal पर सहयोग करती है और Developers वे Product Backlog मदें चुनते हैं जिन्हें पूरा कर पाने का पूर्वानुमान है।
• टीम आवश्यक कार्य और अनुमान पहचानती है। पिछले प्रदर्शन, क्षमता और पूर्णता की परिभाषा के आधार पर Developers तय करते हैं कि Sprint में कौन-सी और कितनी मदें पूरी कर सकने का पूर्वानुमान है।
• Scrum Master बैठक संचालित करती है। वह टीम की स्व-संगठन और स्वतंत्र निर्णय क्षमता बनाए रखती है।

Sprint Planning बैठकों में Scrum Product Owner की उपस्थिति अनिवार्य है। ताकि वह टीम के प्रश्नों का उत्तर और आवश्यकताओं तथा स्वीकृति मानदंडों का स्पष्टीकरण दे सके।

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

Scrum इवेंट 2. Daily Scrum बैठक (दैनिक स्टैंड-अप)

यह Daily Scrum बैठक अधिकतम 15 मिनट की बैठक है। यह हर कार्यदिवस एक ही समय और स्थान पर होती है। Sprint Backlog और Sprint Burndown Chart की सीधी पहुँच के साथ करना सर्वोत्तम है। इससे टीम सभी को दिखने वाले तथ्यों और प्रगति के आधार पर डेली स्क्रम चला सकती है।

डेली स्क्रम का लक्ष्य टीम के स्व-संगठन में मदद और व्यवस्थित रूप से बाधाएँ पहचानना है।

Daily Scrum, Developers के लिए है। Sprint Backlog मदों पर काम करने वाला Product Owner या Scrum Master, Developer की तरह भाग लेता है। अन्य सहभागिता में Developers का ध्यान और स्व-प्रबंधन बना रहना चाहिए; Scrum हर भूमिका या हितधारक की उपस्थिति अनिवार्य नहीं करता।

Developers, Sprint Goal और लागू करने योग्य योजना पर केंद्रित उपयोगी संरचना चुनते हैं। अगले तीन प्रश्न एक परिचित वैकल्पिक प्रारूप हैं, वर्तमान Scrum के निर्धारित प्रश्न नहीं।

• Daily Scrum बैठक — प्रश्न #1. पिछली डेली स्क्रम के बाद मैंने कौन-सी गतिविधियाँ की हैं?
• Daily Scrum बैठक — प्रश्न #2. अगली डेली स्क्रम तक मैं कौन-सी गतिविधियाँ करूँगा? मेरी कार्य योजना क्या है?
• Daily Scrum बैठक — प्रश्न #3. क्या कोई ऐसी बाधा मिली या अपेक्षित है जो मेरे काम की प्रगति धीमी या बंद कर सकती है?

डेवलपर्स अपना डेली स्क्रम चलाते हैं। जरूरत पर Scrum Master, Developers को उद्देश्य और प्रभावशीलता समझने में मदद करता है। इवेंट 15 मिनट का रहता है; तीन प्रश्नों का प्रारूप वैकल्पिक है।

Daily Scrum का लक्ष्य समय लेने वाले निर्णय या समस्याएँ सुलझाना नहीं है। निर्णयों पर सहमति और समस्या समाधान के लिए टीम जरूरत के अनुसार अलग बैठकें कर सकती है। ये अक्सर Daily Scrum के तुरंत बाद होती हैं।

Scrum Master पहचानी बाधाएँ और तिथियाँ अलग लॉग, फ्लिप चार्ट या रिपोर्ट में दर्ज करता है जो टीम को सुलभ हो। मुझे Daily Scrum के बिल्कुल अंत में खुली बाधाओं की स्थिति जल्दी अद्यतन करना बहुत लाभकारी लगता है।

Scrum इवेंट 3. Sprint Review बैठक

यह Sprint Review बैठक Sprint के अंत में होती है। कुछ टीमों के लिए एक से दो घंटे की Review उपयुक्त हो सकती है; एक महीने के Sprint में औपचारिक अधिकतम चार घंटे है और छोटे Sprint में आमतौर पर छोटे इवेंट उचित हैं। सॉफ्टवेयर और उपलब्ध ढाँचे के अनुसार बैठक कमरे, प्रयोगशाला या टीम के कमरे में होती है।

Sprint Review का लक्ष्य Sprint में बने भेजने योग्य Product Increment की समीक्षा और उत्पाद विकास में पारदर्शिता लाना है।

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

Sprint Review से टीम और हितधारक उत्पाद के परिणाम जाँचकर Product Backlog अनुकूलित कर सकते हैं। पूरी टीम बाद में अगले Sprint Goal पर सहयोग करती है। इसलिए, Sprint Review, “जाँच और अनुकूलन” का औपचारिक तथा व्यावहारिक उपयोग है।

Sprint Review में टीम, Scrum Product Owner और Scrum Master भाग लेते हैं। अंतिम उपयोगकर्ता, ग्राहक और व्यावसायिक प्रतिनिधि जैसे बाकी हितधारक वैकल्पिक रूप से जुड़ सकते हैं।

Sprint Review में वे दिखाए गए Product Increment पर फीडबैक दे सकते हैं। इस तरह टीम को उन हितधारकों से सीधी, बिना छनाई की राय मिलती है जिनके लिए सॉफ्टवेयर बना रही है।

Scrum इवेंट 4. Sprint Retrospective बैठक

यह स्प्रिंट रेट्रोस्पेक्टिव बैठक Sprint Review के बाद होती है और Sprint समाप्त करती है। एक महीने के Sprint में अधिकतम तीन घंटे है; छोटे Sprint में आमतौर पर कम होती है।

Sprint Retrospective का लक्ष्य सदस्यों का टीमवर्क और Scrum प्रक्रिया का उपयोग सुधारना है।

इससे उत्पादकता, सदस्यों का प्रदर्शन और सॉफ्टवेयर गुणवत्ता बढ़ती है।

Sprint Retrospective एक छोटी कार्योत्तर समीक्षा है, जिससे सुधार की संभावनाएँ तय और प्रक्रिया की बाधाएँ दूर होती हैं। परियोजनाओं में अक्सर दिखने वाली कुछ संभावनाएँ हैं:

• एजाइल सॉफ्टवेयर विकास पद्धतियाँ अपनाना, जैसे एक्सट्रीम प्रोग्रामिंग (XP) या परीक्षण-प्रेरित विकास (TDD).
• नए टीम मानदंड और सिद्धांत पहचानना या
• प्रोडक्ट ओनर की उपलब्धता बढ़ाना।

बिना अपवाद, हर Sprint के अंत में टीम Sprint Retrospective करती है। तभी टीम अपने उपयोग की Scrum प्रक्रिया को परियोजना की विशिष्टताओं के अनुसार व्यवस्थित ढंग से अनुकूलित और बेहतर कर सकती है।

संबंधित पद्धति: Product Backlog परिष्करण (ग्रूमिंग)

Scrum बैकलॉग परिष्करण (ग्रूमिंग) बैठकों का उद्देश्य Product Backlog अद्यतन रखना है। इससे उत्पाद बैकलॉग चालू स्क्रम परियोजना के बारे में टीम के सर्वोत्तम ज्ञान और समझ को दर्शाता है।

परिष्करण जरूरत पर या निर्धारित चर्चाओं में हो सकता है। प्रति हफ्ते 30 मिनट के दो सत्र एक व्यावहारिक उदाहरण हैं, अनिवार्य आवृत्ति या अधिकतम सीमा नहीं। Product Owner और Developers सहयोग करते हैं; Scrum Master तथा अन्य योगदानकर्ता जरूरत के अनुसार जुड़ते हैं।

Scrum Backlog परिष्करण (ग्रूमिंग) में प्रतिभागी इन कार्रवाइयों से Product Backlog परिष्कृत करते हैं:

• नई खोजी गई आवश्यकताओं के आधार पर नई यूजर स्टोरी जोड़ें।
• उत्पाद के लिए अब जरूरी न रहीं यूजर स्टोरी हटाएँ।
• यूजर स्टोरी के अनुमान परिष्कृत करें।
• यूजर स्टोरी की प्राथमिकताएँ अद्यतन करें।
• बहुत बड़ी यूजर स्टोरी को छोटी, आसानी से समझी जाने वाली स्टोरी में बाँटकर उचित प्राथमिकता दें।

Scrum Master प्रमाणन पाने के चार आसान चरण

Scrum Master प्रमाणन पाने का तरीका सीधा, तेज और पूरी तरह ऑनलाइन है।

इनकी बदौलत International Scrum Institute™, अब आप पहले से अधिक तेजी और किफायती ढंग से Scrum Master प्रमाणित हो सकते हैं।

आपका पाने के चार आसान चरण Scrum Master प्रमाणन बिना समय और पैसा गँवाए तथा बिना परेशानी के, निम्न हैं।

• चरण #1. ऑनलाइन पंजीकरण करें

  अपने Scrum Master प्रमाणन के लिए ऑनलाइन पंजीकरण करें, उपयोग करके Scrum Master Accredited Certification™ पंजीकरण पेज।

  पंजीकरण के बाद International Scrum Institute™ तुरंत ऑनलाइन परीक्षा प्रवेश कोड देगा।

  निम्न लिंक से आप कर सकते हैं अपने Scrum Master प्रमाणन कार्यक्रम में पंजीकरण.

• पूरे आकार में चित्र खोलें ↗

  चरण #2. ऑनलाइन अध्ययन करें

  अपने Scrum Master प्रमाणन के लिए ऑनलाइन पढ़ें, उपयोग करके Scrum अध्ययन मार्गदर्शिका, The Scrum Framework™.

  The Scrum Framework™ पूरी तरह व्यावहारिक बनाने के लिए तैयार की गई है। इसकी सामग्री प्रतिभाशाली Scrum Master के रूप में नौकरी और करियर की दैनिक चुनौतियाँ संभालने में मदद करेगी। इसमें सफल Scrum Master के कामकाजी दिन दिखाने वाले केस अध्ययन और व्यावहारिक उदाहरण भरे हैं।

  निम्न लिंक से आप कर सकते हैं The Scrum Framework™ की अपनी निःशुल्क प्रति माँगें.

• चरण #3. Scrum Master प्रमाणन परीक्षा ऑनलाइन दें

  अपनी Scrum अध्ययन मार्गदर्शिका, The Scrum Framework™, ध्यान से पढ़ने, अध्ययन करने और समझने के बाद आप तैयार होंगे! आपको परीक्षा पास करने का पूरा विश्वास होना चाहिए।

  निम्न लिंक से आप कर सकते हैं अपनी Scrum Master प्रमाणन परीक्षा खोलें.

• चरण #4. अपना Scrum Master प्रमाणन पाएँ

  परीक्षा पास करते ही हम तुरंत आपका Scrum Master प्रमाणन देंगे।

  नियोक्ता और ग्राहक, नियोक्ताओं के लिए Scrum प्रमाणन सत्यापन टूल से आपके प्रमाणन की प्रामाणिकता जाँच सकते हैं। निम्न लिंक से आप कर सकते हैं नियोक्ताओं के लिए Scrum प्रमाणन सत्यापन टूल खोलना.

Scrum Master प्रमाणन पर मेरा निष्कर्ष

अब बात समेटने का समय है। यदि Scrum Master बनने की इस मार्गदर्शिका का हर शब्द नहीं पढ़ सके, तो मैं अपने विचार स्पष्ट कर देती हूँ। प्रमाणन के लाभ और नुकसान पर मेरे विचार ये हैं।

लाभ

कर्मचारियों, स्वतंत्र पेशेवरों, कोचों और प्रशिक्षकों के लिए लाभ

• Scrum Master प्रमाणन, Scrum क्षेत्र में आपकी योग्यता और अद्यतन ज्ञान की पहचान होगा।
• यह उन साथियों से आगे निकलने में मदद करेगा जिन्होंने अपना विकास छोड़ दिया है। प्रमाणित और सफल Scrum Master के रूप में मनचाही नौकरी पाने में मदद करेगा।
• यह दृष्टिकोण व्यापक करेगा और निरंतर सीखने के लिए मन और खोलेगा। अधिक जिम्मेदारियाँ तथा शानदार करियर अवसर पाने में मदद करेगा।
• यह बिल्कुल नए टूल देगा, जिनसे ग्राहकों और नियोक्ताओं की पसंद के बेहतरीन उत्पाद तथा सेवाएँ दे सकेंगे।

संगठनों और नियोक्ताओं के लिए लाभ

• Scrum Master प्रमाणन टीमों, गतिविधियों और प्रक्रियाओं की दक्षता सुधारकर लागत घटाएँगे।
• प्रशिक्षित और कुशल कर्मचारियों से ऐसी परियोजनाएँ जीतने में मदद करेंगे जिन्हें अन्यथा नहीं जीत सकते थे।
• प्रशिक्षण और कौशल विकास को प्रोत्साहित करके कर्मचारी संतुष्टि तथा प्रतिबद्धता बढ़ाएँगे।
• डिलीवेरेबल की गुणवत्ता, ग्राहक संतुष्टि और अंततः संगठन की सफलता तथा लाभप्रदता सुधारेंगे।

नुकसान

• Scrum Master प्रमाणन से आपका सीखना रुकना नहीं चाहिए। न भूलें कि यह केवल पहला कदम है।

  Scrum से सीखी “जाँच और अनुकूलन” की भावना के अनुसार निरंतर प्रयोग, अवलोकन और सीखना अब भी आपका कर्तव्य तथा दायित्व है।

• दुनिया के सभी संगठनों के लिए एक ही समाधान उपयुक्त नहीं है। Scrum सॉफ्टवेयर विकास और डिलीवरी फ्रेमवर्क भी इसका अपवाद नहीं है।

  हमने देखा कि Scrum से सर्वोत्तम प्रदर्शन न पा सकने वाले अधिकांश संगठनों में एक समान विशेषता है: वे Scrum को अपने व्यवसाय और IT परिवेश के अनुसार ढाल नहीं पाए।

  इसलिए “जाँच और अनुकूलन” की भावना से Scrum को सफलता की 100% गारंटी वाला नुस्खा न मानें। अपने व्यवसाय और IT की परिस्थितियों में ढालने की बौद्धिक क्षमता कम न आँकें। वेतन पाने वाले पेशेवर के रूप में सर्वोत्तम निष्पादन और व्यावसायिक परिणामों के लिए आपसे यही अपेक्षित है।

• स्क्रम ने IT की सभी समस्याएँ नहीं सुलझाईं। विकास जारी रखें, DevOps जैसी नई उभरती सॉफ्टवेयर विकास और डिलीवरी प्रक्रियाएँ।

  Scrum की ज्ञात कमियाँ और DevOps उन्हें कैसे संभालता है, यह बेहतर समझने के लिए बाद में यह प्रमुख लेख देखें: DevOps और Scrum में शीर्ष 6 अंतर क्या हैं?

अंत में, Scrum Master प्रमाणन Agile सॉफ्टवेयर विकास और डिलीवरी पद्धतियों की शुरुआत का बेहतरीन तरीका है।

Gartner अध्ययन के अनुसार “बेहतर स्क्रम मास्टर बनना” 2019 में प्रकाशित लेख का 2023 के लिए पूर्वानुमान था कि दुनियाभर की 92% और संयुक्त राज्य अमेरिका की 96% कंपनियाँ Agile Scrum पद्धतियाँ अपनाएँगी। यह मूल लेख का बताया पूर्वानुमान है, वर्तमान उपयोग की मापी गई दर नहीं।

इसलिए अभी से बेहतर समय नहीं,

• Scrum फ्रेमवर्क निःशुल्क सीखना शुरू करें और
• International Scrum Institute™ के अत्यंत किफायती शुल्क पर Scrum Master प्रमाणित हों.

एक प्रश्न बचता है: शुरू कब करेंगे?