क्या स्क्रेम उन परियोजनाओं के लिए अतिरिक्त ओवरहेड बनाता है जहां आवश्यकताएं नहीं बदलती हैं?


29

मैं गनथ वेरहेन द्वारा स्क्रम - ए पॉकेट गाइड पढ़ रहा हूं और यह कहता है:

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

इसलिए मेरा एक सहकर्मी के साथ एक तर्क है जो कहता है कि कुछ परियोजनाओं के लिए (जैसे दवा / सेना जहां आवश्यकताओं में बदलाव नहीं होता है), एजाइल (और, विशेष रूप से, स्क्रैम) सभी बैठकों आदि के साथ उपरि है और यह अधिक तार्किक है उदाहरण के लिए, झरना का उपयोग करना।

मेरा दृष्टिकोण यह है कि इस तरह की परियोजनाओं में स्क्रैम को अपनाया जाना चाहिए क्योंकि यह प्रक्रिया को अधिक पारदर्शी बना देगा और एक टीम की उत्पादकता बढ़ाएगा। मुझे यह भी लगता है कि स्क्रेम की घटनाओं में ज्यादा समय नहीं लगेगा यदि इसकी आवश्यकता नहीं है क्योंकि हमें 1 महीने के स्प्रिंट के लिए स्प्रिंट योजना में पूरे 8 घंटे बैठने की आवश्यकता नहीं है। हम यह सुनिश्चित करने के लिए 5 मिनट अतिरिक्त कर सकते हैं कि हम सभी एक ही पृष्ठ पर हैं और काम करना शुरू कर रहे हैं।

तो, क्या स्क्रैम एक ऐसी परियोजना के लिए अतिरिक्त ओवरहेड बनाएगा जहां आवश्यकताएं नहीं बदलती हैं?


50
सैन्य परियोजना की आवश्यकताओं में लगातार बदलाव होता है - जो कि वे बजट पर बड़े पैमाने पर समाप्त होते हैं और देरी से
HorusKol

26
केवल वही परियोजनाएँ जहाँ आवश्यकताओं में परिवर्तन नहीं होता है वे रद्द या समाप्त परियोजनाएँ हैं। हो सकता है कि कुछ उद्योगों में विचार से लेकर तैनात उत्पाद तक का चक्र अन्य उद्योगों की तुलना में लंबा हो, लेकिन यह इस तथ्य को नहीं बदलता है कि विचार / आवश्यकताएं लगातार बदलती रहती हैं।
बार्ट वैन इनगेन शनाउ

24
मैं उन सैन्य परियोजनाओं से जुड़ा हूं, जहां आवश्यकताएं "नहीं बदलीं" क्योंकि वे इतनी बेकार थीं कि बेकार हो गईं। उदाहरण के लिए, एक लड़ाकू विमान के इंजन के लिए प्रदर्शन की आवश्यकताएं: "इंजन विमान के पूर्ण उड़ान लिफाफे पर संतोषजनक प्रदर्शन करेगा"। वह एक वाक्य पूरी कल्पना थी। अधिक विवरण के लिए एक अनुरोध का जवाब था "ठीक है, हम नहीं जानते कि जब तक हम प्रोटोटाइप विमान को नहीं उड़ाते हैं तब तक पूरी उड़ान का लिफाफा क्या होगा"। और नहीं, मैं इस सामान को नहीं बना रहा हूं।
एलेफ़ेज़ेरो

7
CHAOS रिपोर्ट में समस्याएँ हैं - उदाहरण के लिए, some.vu.nl/~x/chaos/chaos.pdf - और, जबकि, संतुलन पर, चुस्त और स्क्रम तरीकों की प्रभावशीलता में अनुसंधान एक सकारात्मक प्रभाव दिखाता है, के साथ व्यवस्थित समस्याएं हैं "गैर-चुस्त" के बाद से तुलनित्र समूहों को इसकी तुलना में कम अच्छी तरह से परिभाषित किया गया है।
जैक ऐडली

8
@sense-28 का विचार है कि एक इंजीनियर "हर दिन अपने काम को एक गैर टेक को समझाने के लिए मजबूर किया जाता है" बताता है कि आपने कभी भी ऐसा कुछ नहीं किया है जो स्क्रैम गाइड के बारे में बात करता है। दुख की बात है कि जो लोग स्क्रम को करने का दावा करते हैं उनमें बहुत आम है।
एरिक

जवाबों:


68

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

चपलता उस प्रतिक्रिया चक्र को कम करने और किसी के हाथ में काम करने वाले सॉफ़्टवेयर को तेज़ी से प्राप्त करने, उस प्रतिक्रिया को प्राप्त करने और अगले कदम के बारे में निर्णय लेने के लिए सुनिश्चित करना चाहिए कि ग्राहक द्वारा सॉफ़्टवेयर को स्वीकार करने का निर्णय लेने पर क्या जोड़ा जाता है। यहां तक ​​कि कस्टम हार्डवेयर वाले एम्बेडेड सिस्टम जैसे (जैसे आप एयरोस्पेस, ऑटोमोटिव या मेडिकल डिवाइस जैसे डोमेन में पा सकते हैं), कार्यक्षमता के पतले स्लाइस को जल्दी से एकीकृत और प्रोटोटाइप के साथ वितरित करना यह सुनिश्चित करने में मदद कर सकता है कि सॉफ्टवेयर और हार्डवेयर सिस्टम जा रहा है इरादा के अनुसार काम करें और अंतिम उपयोगकर्ता की मदद करेंगे।

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


1
प्रतिक्रिया चक्र के प्रभाव के बारे में आगे पढ़ते हुए ब्लॉग। कोडिंगहोर
इंबोड्स-

क्षमा करें (एक) डाउनवॉटर को छोड़ देता है, लेकिन मेरे लिए यह जवाब वास्तव में सवाल का जवाब नहीं देता है। यह सिर्फ एक बयान है कि आप कैसे सोचते हैं कि चीजें होनी चाहिए।
साइमन बी

12

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

अधिक पूर्ण उत्तर यह है:

आम तौर पर बोलना प्रक्रिया नियंत्रण के तीन रूप हैं: परिभाषित प्रक्रिया नियंत्रण, सांख्यिकीय प्रक्रिया नियंत्रण और भावनात्मक प्रक्रिया नियंत्रण। निर्धारित प्रक्रिया नियंत्रण अब तक का सबसे सस्ता है। यह संभव है कि बार-बार दोहराए जाने वाले काम को समय के साथ परिष्कृत किया जाता है ताकि काम करने के लिए "सबसे अच्छा" तरीका मिल सके। सॉफ्टवेयर विकास में CI / CD इस श्रेणी में आता है। आप अपनी निर्माण प्रक्रिया में भिन्नता नहीं चाहते हैं, इसलिए आप इस प्रक्रिया को मानकीकृत करते हैं, तब तक समायोजित करते हैं जब तक आप इससे खुश नहीं होते हैं, फिर इसे स्वचालित करें। यह स्वचालित प्रक्रिया स्पष्ट रूप से एक तैनाती के माध्यम से लड़ने की तुलना में चलाने के लिए बहुत कम खर्चीली है।

सांख्यिकीय प्रक्रिया नियंत्रण अगले कम से कम महंगा है, लेकिन यह एक ज्ञात प्रक्रिया में बदलाव के लिए जिम्मेदार है। योजना के अनुसार जाने वाली चिकित्सा प्रक्रियाएं इस श्रेणी में आती हैं। मैं हर बार बाईपास सर्जरी को फिर से नहीं करना चाहता। मैं मूल प्रक्रिया का पालन करता हूं और भिन्नता के लिए समायोजित करता हूं। इसमें अपेक्षाकृत कम संज्ञानात्मक भार और सफलता की उच्च दर है।

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

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

दवा और सैन्य परियोजनाओं के बारे में प्रतिवाद करने के लिए, यह त्रुटिपूर्ण तर्क की तरह लगता है। यदि आप 500 हवाई जहाजों के लिए एक आदेश को पूरा कर रहे हैं, तो हाँ, आप बिल्कुल कुछ दोबारा बना रहे हैं और स्क्रैम शायद फायदेमंद नहीं है। यदि आप एक नया विमान बना रहे हैं और आपकी आवश्यकताएं कभी नहीं बदलती हैं, तो मैं उस विमान को नहीं उड़ाऊंगा।


10

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

लेकिन अधिकांश सॉफ्टवेयर परियोजनाएं ऐसी नहीं हैं।

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

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

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

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

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


1

मुझे लगता है कि यह अच्छी तरह से विरोधाभासी हो सकता है @Cort Ammon क्या कह रहा है, लेकिन यहाँ मेरा लेना है:

बाहरी आवश्यकताओं ("डिलिवरेबल्स" का वर्णन) एक परियोजना में केवल आवश्यकताएं नहीं हैं। यहां तक ​​कि अगर बाहरी आवश्यकताएं नहीं बदलती हैं, तो भी "आंतरिक" आवश्यकताएं बदल जाएंगी, या आपको काम करने की अनुमति देने की आवश्यकता होगी। डेवलपर्स एक दृष्टिकोण के साथ बाधाओं या समस्याओं की खोज करेंगे, और यह टीम के अन्य लोगों के काम को प्रभावित करेगा। एक दैनिक स्टैंड-अप हर किसी को इन आंतरिक परिवर्तनों के साथ अद्यतित रखेगा।


1
हाँ, मैंने जलप्रपात परियोजनाओं पर काम किया है जहाँ निर्माण के दौरान एक भी आवश्यकता नहीं बदली है, लेकिन एक व्यक्ति ने बीमारी, छुट्टियों, अप्रत्याशित तकनीकी समस्याओं के लिए अनुमति देने के लिए लगभग सभी दिन परियोजना की योजना को बदलने में बिताए।
वेंडीज

1

उस पर विचार करे:

  • यहां तक ​​कि निश्चित कार्यात्मक आवश्यकताओं के साथ आपको उन्हें तकनीकी आवश्यकताओं में बदलने की आवश्यकता है। और यह पुनरावृत्तियों द्वारा बेहतर किया जा सकता है। आप परियोजना के मध्य में समस्या को हल करने के लिए बेहतर तरीके खोज सकते हैं।

  • कुछ आवश्यकताएं बहुत सामान्य या अस्पष्ट हो सकती हैं: "उपयोग में आसान हो", "सुरक्षित रहें"। किसी प्रणाली की सुरक्षा या उपयोगिता के बारे में उसका विश्लेषण करना कठिन है कि यह समाप्त न हो। कुछ में निहितार्थ निहित हो सकते हैं या अच्छी तरह से नहीं समझा जा सकता है।

  • कुछ आवश्यकताओं में सुधार किया जा सकता है। 200ms में प्रतिक्रिया देना अच्छा हो सकता है लेकिन 100 बेहतर हो सकता है। आप सर्वोत्तम संभावित परिणाम को लक्षित कर सकते हैं, लेकिन यदि परियोजना के दौरान इसकी आवश्यकता हो तो इसका त्याग करें।

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

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

  • जल्द ही कुछ देने से एकीकरण में मदद मिलेगी और यह दिखाएगा कि यह परियोजना परिणाम प्रदान कर सकती है।


0

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

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

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

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

क्या यह ऐसा करने में सफल होता है, यह खुली बहस का विषय है। अन्य लोगों ने इसके लिए कई मैट्रिक्स प्रदान किए हैं। मैं केवल इस बात पर ध्यान दूंगा कि यह सुनिश्चित करने के लिए नेतृत्व की ताकत पर निर्भर है कि उनके नीचे होने वाले पुनरावृत्तियों को सही ढंग से ऊपर संविदात्मक प्रणाली में डाइवेट किया जाए। यह विकास के किसी भी दृष्टिकोण के साथ सच है, लेकिन यह चुस्त दृष्टिकोणों में अधिक दिखाई देता है क्योंकि हम अधिक शीर्ष डाउन दृष्टिकोण "सामान्य" और प्रशिक्षित नेताओं को इस तरह मानने के लिए उठाए गए हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.