प्रोग्रामिंग बनाम योजना [बंद]


15

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

क्या कोई उच्च स्तरीय योजनाकार के बिना भी एक अच्छा प्रोग्रामर हो सकता है?

एक वरिष्ठ प्रोग्रामर के रूप में, क्या पूरे उत्पाद की योजना बनाने और पूरा होने की तारीख चुनने में अच्छा होने की उम्मीद है?


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

हाँ यह संभव है। इस मामले में हालांकि आपकी उत्पादकता इस बात पर निर्भर करेगी कि आपका प्रबंधक / टीम लीड कितना अच्छा है
gnat

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

1
वह बोली कि कैसे जाना है? "कोडिंग के दिन नियोजन के घंटे बचा सकते हैं" या उस प्रभाव के लिए कुछ।
ड्रेक क्लेरिस

जवाबों:


17

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

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

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

चंचल मैनिफेस्टो पढ़ें और स्क्रैम में देखें । परियोजना का मार्गदर्शन करने के लिए Iterative Development और Dynamic Systems Development विधि का उपयोग करें ।

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

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


4
"विस्तृत दीर्घकालिक परियोजना योजनाएं आमतौर पर बेतहाशा गलत होने के लिए कुख्यात हैं।" DING DING DING +1
रियान काइल

11

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


1
मुझे उस काम की योजना बनाने में कोई आपत्ति नहीं है जो मैं अभी कर रहा हूं / अगले 2 सप्ताह में। मतलब, अगर मैं जो लिखने जा रहा हूं, उसमें कई टुकड़े शामिल हैं, तो मुझे इस बात की कोई योजना नहीं है कि उच्च स्तर पर और फिर ऐसा करना (वास्तव में - मैं यही करूंगा)। मैं भविष्य में एक तारीख के महीनों के साथ आने की कोशिश करने में सफल नहीं हूं - फिर यह पता लगाने की कोशिश कर रहा है कि हम इसे क्यों नहीं मार रहे हैं। यहीं से मेरी व्यक्तिगत निराशा चरम पर पहुंच जाती है।
मैटवे

मैं व्यक्तिगत रूप से मुझे निराश नहीं होने देता। मैं परियोजना प्रबंधकों पर सामान की तरह पिन करने की कोशिश;)।
ब्लेज़ स्वानविक

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

9

क्या एक अच्छा प्रोग्रामर बनना संभव है और उच्च स्तरीय योजनाकार नहीं?

थोड़ी देर के लिए, हाँ। क्या लंबे समय तक ऐसा करना संभव है? नहीं।

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


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

1
मुझे कहना चाहिए था कि उद्योग-प्रतिस्पर्धी जीवन-यापन लागतों के बजाय उठाता है। मैंने अपने उत्तर को सिर्फ कहने के लिए संपादित किया। उन उद्योग-प्रतिस्पर्धी उठाता युवा वयस्कों के लिए बहुत मीठा है, आम तौर पर मुद्रास्फीति की तुलना में बहुत बेहतर है। जीवित उठने की लागत पुराने फोगियों के लिए है। कोई समस्या है जब कोई मुद्रास्फीति से अधिक हो जाता है, लेकिन उस व्यक्ति का कौशल नए सिरे से बना रहता है।
डेविड हैमेन

पकड़ लिया! स्पष्ट करने के लिए धन्यवाद, यह निश्चित रूप से समझ में आता है।
एथेल इवांस

मेरा तर्क है, दुख की बात है कि समय के साथ प्रोग्रामिंग कौशल सीखना आसान हो रहा है, और इसलिए मौजूदा, गैर-विकास, COL से परे एक इंजीनियर अवमूल्यन का कौशल।
न्यू अलेक्जेंड्रिया

6

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

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

यदि आप उस स्थिति से खुश हैं, तो आपके लिए अधिक शक्ति है। अधिकांश लोग इस बात से कम संतुष्ट होते हैं कि उन्हें जितना अधिक अनुभव होगा।

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


"गंदे छोटे रहस्य कोई भी लंबे समय की योजना और अनुमान पर बहुत अच्छा नहीं है।" सच नहीं है! इसके लिए सिर्फ +1। एक अच्छे इतिहास के साथ भी, बहुत सारी संख्याएँ हैं जिन्हें स्पष्ट नीले आकाश से गिराने की आवश्यकता है क्योंकि अगली परियोजना किसी भी पिछली परियोजना की सटीक प्रतिलिपि नहीं है। यदि यह था, तो हम सभी कोड को पुन: उपयोग करने में सक्षम होंगे-और इसके साथ ASAP किया जाएगा। हमेशा कुछ नया होता है, और पिछले प्रदर्शन हमेशा एक अच्छा संकेतक नहीं होते हैं कि उस नए सामान के लिए प्रयास की आवश्यकता कैसे होती है।
डेविड हैमेन 14

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

3

क्या एक अच्छा प्रोग्रामर बनना संभव है और उच्च स्तरीय योजनाकार नहीं?

संक्षिप्त उत्तर: हां यह संभव है।

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

एक अन्य संभावित मार्ग यह है कि एक प्रोग्रामर जो एक अच्छा योजनाकार बन जाता है, अंततः प्रोजेक्ट मैनेजमेंट की ओर भी अग्रसर होता है। इस प्रकार, यदि आप परियोजनाओं के प्रबंधन में रुचि रखते हैं तो आप उस दिशा में कुछ अतिरिक्त प्रयास कर सकते हैं।


1

हां और नहीं आपके जवाब हैं।

एक ओर, आप परियोजना प्रबंधन की ओर लपके जा रहे हैं। IMO, सभी अच्छे प्रोग्रामर के पास कुछ हद तक प्रोजेक्ट मैनेजमेंट क्षमता होती है, लेकिन वे अलग-अलग स्किल सेट होते हैं। लंबी अवधि के लिए योजना बनाने की क्षमता वास्तविक परियोजना प्रबंधन के साथ संवाद करने की आपकी क्षमता में सुधार करती है। तो "नहीं" आप लंबी अवधि की योजना बनाने की क्षमता के बिना एक अच्छा प्रोग्रामर नहीं हो सकते।

कहा गया है कि, परियोजना प्रबंधन एक अलग कौशल सेट है जो उन पहलुओं के लिए अपील करता है जो संबंधित हैं लेकिन प्रोग्रामिंग से अलग हैं। तो यहाँ "हाँ" खेल में आता है। आप एक महान प्रोग्रामर होने के लिए एक परियोजना प्रबंधक होने की जरूरत नहीं है।

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


1

योजना और बंग-बॉस

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

योजना का संगठनात्मक संदर्भ

यदि आप योजना बनाने में असहज हैं, तो शायद आप विपणन या अन्य हितधारकों के लिए प्रतिबद्धताओं के लिए जवाबदेह होने के साथ असहज हैं, इससे पहले कि समस्याओं को हल किया जाए या उन्हें समझा जाए। यह एक अच्छी वृत्ति है।

नियोजन एक महत्वपूर्ण उपकरण है। इसकी उपेक्षा न करें। इसे गलत मत समझिए।

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

एक सरल योजना उदाहरण - सॉफ्टवेयर के बारे में नहीं होना चाहिए ...

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

बेहतर नियोजक बनना

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

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

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

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

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

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

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

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