---

स्क्रम ढाँचे का विस्तार कैसे करें (वितरित और बड़ी स्क्रम परियोजनाएँ)? यह आपको चौंका सकता है!

अब तक बताए अनुसार स्क्रम ढाँचा एक स्थान पर कार्यरत एक स्क्रम टीम के लिए सबसे अच्छा काम करता है। लेकिन व्यवहार में अकेली स्क्रम टीम प्रायः पूरी परियोजना लागू नहीं कर सकती या सदस्यों को कई स्थानों पर काम करना पड़ता है।

एक टीम उत्पाद की जरूरतें पूरी न कर सके तो संगठन अतिरिक्त टीमों पर विचार कर सकता है। केवल भौगोलिक वितरण के कारण अधिक टीमें जरूरी नहीं होतीं और लोगों को जोड़ने से समन्वय की लागत बढ़ सकती है। कई मामलों में हमने यह भी देखा है कि ये टीमें भौगोलिक रूप से दूर स्थित स्थानों या महाद्वीपों में फैली होती हैं।

संगठनों को अपनी टीमें अलग-अलग स्थानों पर वितरित करने के कई कारण प्रेरित करते हैं:

• तकनीकी कारण: सॉफ्टवेयर के अलग घटक बनाने का कुछ आवश्यक ज्ञान मुख्यालय में स्थानीय रूप से उपलब्ध नहीं होता,
• विशेषज्ञता संबंधी कारण: सॉफ्टवेयर इंजीनियरिंग की विभिन्न गतिविधियाँ करने की कुछ क्षमताएँ स्थानीय रूप से उपलब्ध नहीं होतीं। उदाहरण के लिए, परीक्षण स्वचालन, उपयोगकर्ता इंटरफेस डिजाइन या आंतरिक सॉफ्टवेयर का अन्य विक्रेताओं के सॉफ्टवेयर से एकीकरण करने के लिए मुख्यालय से बाहर के विशेषज्ञ चाहिए हो सकते हैं,
• आकार संबंधी कारण: तय समयसीमा में ग्राहकों को परियोजना देने के लिए अधिक लोग जोड़े जाते हैं। तब परियोजना संगठन को एक स्क्रम टीम में व्यावहारिक रूप से समा सकने से अधिक सदस्य चाहिए होते हैं। इससे एक टीम को अनिश्चित रूप से बढ़ाने के बजाय कई सुसंगत स्क्रम टीमों की जरूरत हो सकती है,
• व्यवसाय संबंधी कारण: कम लागत वाले स्थानों से मानव संसाधन लेने या अलग समय क्षेत्रों के इंजीनियरों से काम की निरंतरता बनाए रखने का अच्छा व्यावसायिक आधार हो सकता है।

संचार स्क्रम ढाँचे का अभिन्न भाग है, इसलिए सभी सदस्यों को वितरित परियोजना वातावरण में काम की चुनौतियाँ दूर करने पर ध्यान देना चाहिए। इसके अलावा, सभी सदस्यों के पास ऑडियो/वीडियो कॉन्फ्रेंसिंग और स्क्रीन साझा करने सहित संचार साधन उपलब्ध होने चाहिए।

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

परियोजना संगठन: अनेक टीमें

बड़ी परियोजना में स्क्रम ढाँचे का विस्तार करने का सबसे सरल तरीका उसी स्थान पर टीमों की संख्या बढ़ाना है।

कई टीमों को मिलकर परियोजना लागू करनी हो तो टीमों की संख्या क्रमशः बढ़ाना बेहतर है।

आपके लिए इसका क्या अर्थ है?

एक स्थान पर अनेक टीमें

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

टीमों की संख्या बढ़ाना

नई स्क्रम टीमें बनाने के दो सामान्य तरीके हैं:

• मौजूदा स्क्रम टीम को कई टीमों में बाँटें और जहाँ तथा जब जरूरी हो नए सदस्य जोड़ें,
• ऐसे बिलकुल अलग इंजीनियरों से नई स्क्रम टीम बनाएँ जो अब तक परियोजना में शामिल नहीं थे।

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

इसलिए नई टीमें बनते ही आमतौर पर कुछ हद तक उत्पादक होती हैं। मुख्य नुकसान यह है कि पहले से पूरी तरह काम कर रही टीम अब दो टीमों में बँट जाती है। इससे सदस्यों की प्रेरणा पर असर पड़ सकता है। खासकर तब, जब वरिष्ठ नेतृत्व ने बदलाव की पहले से सूचना और वजह न दी हो तथा सदस्य मानसिक और तकनीकी रूप से तैयार न हों।

पूरी तरह नई टीमें जोड़ने पर मौजूदा टीमें अपना गठन बनाए रखकर स्प्रिंट जारी रख सकती हैं। नई टीमों के साथ समन्वय, परिचय और एकीकरण पर फिर भी ध्यान चाहिए। हालांकि पूरी तरह नई स्क्रम टीमों को तैयार करने के लिए जरूरी ज्ञान और गति बनने में अधिक समय लगेगा।

संगठन में नई स्क्रम टीमें जोड़ने का तरीका जो भी चुनें, ये सिद्धांत याद रखें:

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

परियोजना संगठन: वितरित टीमें

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

अनेक स्थानों पर अनेक टीमें

इन चुनौतियों को न सँभालने के गंभीर परिणाम होते हैं।

इन क्षेत्रों में कौशल की कमी के कारण कंपनियों का अरबों डॉलर का IT बजट बर्बाद होता है: संगठनात्मक नेतृत्व और विस्तारित स्क्रम की विशेषज्ञता।

इन चुनौतियों से निपटने के लिए चार महत्वपूर्ण सुझाव हैं:

• सुनिश्चित करें कि नए स्क्रम टीम सदस्य स्क्रम ढाँचे में इस रूप में प्रशिक्षित हों: Scaled Scrum Expert,
• सुनिश्चित करें कि नए सदस्यों को परियोजना का पर्याप्त परिचय मिले, ताकि वे समझें कि किस उद्देश्य के लिए काम कर रहे हैं। यह समझ तकनीकी और पेशेवर व्यावसायिक मूल्य दोनों दृष्टियों से हो, जिससे वे अपने योगदान का मूल्य बढ़ाने वाले कार्य निर्णय ले सकें,
• सुनिश्चित करें कि परियोजना के नियम तय हों। एक स्क्रम टीम में संचार, योजना और काम पूरा करने के नियमों की तरह अनेक टीमों वाले परियोजना संगठन के भी उच्च स्तरीय नियम होने चाहिए। इससे टीमें मिलकर संवाद, योजना, संचालन और समस्या-समाधान कर सकेंगी तथा ग्राहक और व्यावसायिक मूल्य दे सकेंगी।
• सुनिश्चित करें कि नए सदस्य कम-से-कम अस्थायी रूप से अनुभवी परियोजना सदस्यों के साथ काम करें। इसके लिए दूरस्थ स्थलों का दौरा और काम के दौरान प्रशिक्षण चाहिए हो सकता है। यह उचित और वांछनीय है। इससे ज्ञान सहज रूप से हस्तांतरित हो सकता है तथा अलग टीमों और स्थानों के लोगों में दोतरफा व्यक्तिगत संवाद स्थापित हो सकता है।

वर्चुअल टीमें

वितरित स्क्रम टीम का एक और विकल्प है कि उसके सदस्य अनेक स्थानों पर हों। ऐसी टीम को “वर्चुअल टीम” कहते हैं।

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

वर्चुअल टीमें

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

स्क्रम प्रोडक्ट ओनर टीम

इस सामग्री में कई बार बताया गया है कि परियोजना की सफल डिलीवरी के लिए स्क्रम प्रोडक्ट ओनर और स्क्रम टीम के बीच नियमित संचार जरूरी है।

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

यह संस्करण “स्क्रम प्रोडक्ट ओनर टीम” और “मुख्य स्क्रम प्रोडक्ट ओनर” को संगठनात्मक सहयोग के तरीके के रूप में बताता है। प्रोडक्ट ओनर प्रतिनिधियों या अन्य उत्पाद विशेषज्ञों के साथ काम कर सकता है, लेकिन ये पद अतिरिक्त स्क्रम जवाबदेहियाँ नहीं हैं और एक उत्पाद के लिए जवाबदेह एकल प्रोडक्ट ओनर का स्थान नहीं लेते।

इस सहयोग की मदद से जवाबदेह प्रोडक्ट ओनर सुनिश्चित करने पर ध्यान देता है कि:

• ग्राहक की माँगें पूरी करने के लिए सही उत्पाद बनाया जाए,
• प्रोडक्ट ओनर और उसके प्रतिनिधि प्रभावी सहयोग करें तथा टीमों को ग्राहकों के लिए व्यावसायिक और तकनीकी मूल्य बनाने में मदद दें।

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

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

घटक टीमें बनाम फीचर टीमें

अलग-अलग टीमों में काम बाँटते समय हम उन्हें विशिष्ट सॉफ्टवेयर घटकों या सुविधाओं की जवाबदेही दे सकते हैं। इसीलिए हम उन्हें “घटक टीम” या “फीचर टीम” कहते हैं।

घटक टीमें

घटक टीमों के उपयोग में हर टीम पूरे सिस्टम के कुछ निर्धारित घटकों को लागू करने की ही जिम्मेदार होती है। यूजर स्टोरी पूरी करने के लिए आमतौर पर उसे छोटे हिस्सों में बाँटना पड़ता है, ताकि हर हिस्सा एक घटक में लागू हो सके। इन घटक टीमों के घटकों की निर्भरताएँ सफल डिलीवरी के लिए निरंतर एकीकरण अनिवार्य बनाती हैं।

स्क्रम प्रोडक्ट ओनर टीम

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

इससे जारी लेकिन अभी एकीकृत न हुए काम के बैच आकार और लीड टाइम बढ़ते हैं। यह अच्छा नहीं लगता, क्योंकि स्क्रम टीमों का लक्ष्य छोटे बैच और कम लीड टाइम में भेजने योग्य सॉफ्टवेयर इन्क्रिमेंट देना होना चाहिए।

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

दूसरी ओर, घटक टीमों के सदस्य पूरे सिस्टम के केवल अलग-अलग घटकों में विशेषज्ञ होते हैं। वे समग्र दृष्टि और सुविधाओं की व्यावसायिक जरूरत की समझ खो सकते हैं।

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

घटक टीमें

फीचर टीमें

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

फीचर टीमें

फीचर टीम के सदस्यों में विभिन्न कार्यों के कौशल होते हैं। तेज डिलीवरी के लिए वे यथासंभव स्वायत्त ढंग से काम करते हैं। फीचर टीमों का लाभ यह है कि टीम सिस्टम का ज्ञान बनाए रखती है, जिससे अपनी सुविधाओं को शेष सिस्टम में एकीकृत करना आसान होता है।

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

घटक टीमों और फीचर टीमों के बीच चुनाव कैसे करें?

व्यवहार में अधिकतर बड़े संगठन समर्पित घटक टीमों और फीचर टीमों, दोनों का उपयोग करते हैं।

घटक और फीचर टीमें

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

इससे फीचर टीमों में उन घटकों का ज्ञान रखने वाले योग्य लोगों की आवश्यक संख्या कम रखी जा सकती है।

वितरित परियोजना वातावरण में स्क्रम मास्टर

वितरित परियोजना वातावरण में स्क्रम मास्टर की भूमिका और भी महत्वपूर्ण है। ऐसी परियोजना व्यवस्थाओं में:

• टीमों को स्क्रम ढाँचे के मूल्यों के अनुरूप लाने में अतिरिक्त प्रयास चाहिए होगा,
• कई टीमों को प्रभावित करने वाले व्यक्तिगत टीम तथा परियोजना नियम (मानक) स्थापित करने में अधिक समय लगेगा,
• अंत में, टीमों और उनके परिणामों के बीच बढ़ी निर्भरताओं के कारण अनेक बाधाएँ होंगी।

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

• टीम की प्रगति की बाधाएँ दूर करवाने में मदद करे,
• टीम को प्रभावी कार्य समझौते बनाने में मदद करे, और
• स्क्रम ढाँचे का उपयोग बेहतर बनाने में मदद करे।

कुछ संगठन टीमों के बीच मार्गदर्शन और समन्वय में मदद के लिए प्रमुख (प्राथमिक) स्क्रम मास्टर रखते हैं। यह वैकल्पिक संगठनात्मक तरीका है; आवश्यक पदानुक्रम या हर स्क्रम टीम की जवाबदेहियों का विकल्प नहीं।

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