गेम प्लानिंग और सॉफ्टवेयर डिजाइन? मुझे लगता है कि यूएमएल सुविधाजनक नहीं है


21

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

मैंने अपने दोस्त के साथ एक गेम कोडिंग शुरू करने की योजना बनाई। यह मेरी पहली टीम वर्क होगी, इसलिए कोई भी पेशेवर सलाह खुशी की बात होगी। क्या यूएमएल के अलावा कोई अन्य विकल्प है?

एक और सवाल यह है कि "प्रोटोटाइपिंग" सामान्य रूप से कैसा दिखता है?


26
यूएमएल बकवास है। यह एक बुरी तरह से तैयार किया गया प्रतिमान है कि व्यवसायी ऐसा महसूस करते हैं कि वे उत्पादन कर रहे हैं और कुछ समझ रहे हैं जबकि वे वास्तव में केवल बेकार बाधाओं को पैदा कर रहे हैं।
ओ ० '।

हालांकि मैं निश्चित रूप से सोचता हूं कि यूएमएल का व्यवसाय सॉफ्टवेयर में एक स्थान है, यह कुछ भी इंटरैक्टिव डिजाइन करने के लिए डिज़ाइन नहीं किया गया है। मौजूदा गेम के लिए कुछ गेम डिज़ाइन दस्तावेज़ों को खोजने की कोशिश करें कि वे कैसे औपचारिक सामान को संभालते हैं, कुछ इस तरह से: delta3d.org/filemgmt_data/files/… बहुत विरोध प्रदर्शन करने के लिए ध्यान रखने की कोशिश करें और डरो मत 'दूर फेंक' सामान (यहां फेंकने का मतलब है आपके स्रोत नियंत्रण प्रणाली में शेल्फ और सक्रिय रूप से इसका उपयोग नहीं करना)।
रॉय टी।

4
मैं सब कुछ के बारे में योजना बनाने के लिए xmind का उपयोग करता हूं । जब तक मुझे मजबूर नहीं किया जाता, मैं यूएमएल जैसी तकनीकी चीज का उपयोग नहीं करूंगा। तकनीकी जाने से पहले चीजों की कल्पना करना महत्वपूर्ण है। माइंड मैपिंग आपका दोस्त है। आप इसका उपयोग तकनीकी चीजों की योजना बनाने के लिए भी कर सकते हैं।
उन्होंने

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

जवाबों:


18

मैं सिर्फ एक पेशेवर सलाह चाहता हूं कि मुझे अपना गेम डिजाइनिंग कैसे शुरू करना चाहिए?

गेम डिज़ाइन गेमप्ले, संपत्ति, स्कोरिंग सिस्टम आदि का विनिर्देश है - ये सॉफ़्टवेयर-विशिष्ट नहीं हैं। जैसे, UML उस कार्य के लिए गलत उपकरण है।

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

थोड़ी देर के लिए कोडिंग के बाद, चीजें खराब योजना के कारण टूटने लगती हैं (जब मैं नई सुविधा जोड़ता हूं, तो यह मुझे पूरा कार्यक्रम फिर से बनाने के लिए जाता है)।

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

इसलिए, मुझे अपने खेल की योजना बनाने की कोई सलाह कैसे देनी चाहिए? मुझे इसे दृश्य चित्रों में कैसे डालना चाहिए, ताकि मैं और मेरे दोस्त डिजाइनों का अवलोकन कर सकें?

ऐसा लगता है कि आप यहाँ 2 समस्याओं, गेम डिज़ाइन और कोड डिज़ाइन का मिश्रण कर रहे हैं।

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

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

इसके अलावा, छोटे, कम महत्वाकांक्षी परियोजनाओं पर काम करने की कोशिश करें। आपको व्यापक योजना या पुनर्लेखन की आवश्यकता के बिना, अच्छा, काम करने वाला कोड लिखने की आदत होगी।


मुझे लगता है कि मैंने इसे मिलाया। मुझे लगता है कि मैं कह सकता हूं कि मेरे पास वास्तव में कुछ गेम सिस्टम विचार हैं। हालांकि, मैं जानना चाहूंगा कि मैं अपने "कोड" डिज़ाइन की समस्या से प्रभावी रूप से कैसे निपट सकता हूं? या दूसरे शब्द में, कोड में मेरी खेल संरचना का प्रभावी ढंग से अनुवाद करें? मुझे आमतौर पर कोड को सामान्य करने या तेजी से विशिष्ट कोडिंग के लिए लंबा समय लेने के बीच चयन करना पड़ता है। आमतौर पर पहले एक ने मुझे नरक से निकाल लिया, इसलिए मैं दूसरे पर चला गया और बाद में एक दीवार से टकरा गया ...
user1542

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

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

2

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

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

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

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

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


2

मैं एक दोस्त (2-व्यक्ति टीम) के साथ कुछ स्वतंत्र गेम प्रोजेक्ट्स पर भी काम कर रहा हूं। जैसा कि आप के लिए एक समान स्थिति में, मैं कुछ tidbits की पेशकश कर सकता हूं जो मुझे मददगार मिली है।

  1. यदि आपके विचार मोटे हैं, तो सुपर छोटे प्रोटोटाइप परियोजनाओं में उन्हें एक बार लागू करने का प्रयास करें। उदाहरण के लिए, मैं अब एक 2D मंच खेल बना रहा हूं, और खिलाड़ी का कूदना सही होना मेरे लिए अत्यंत महत्वपूर्ण है। इसलिए, मैंने एक नया प्रोजेक्ट बनाया जहां केवल 2 चीजें होती हैं) a) स्क्रीन पर खिलाड़ी को आरेखित करना, और b) इनपुट का पता लगाना, और कूद को फिर से परिभाषित करना [चरित्र बाएं या दाएं भी नहीं चल सकता]
  2. कुछ लोग इस सलाह पर अमल कर सकते हैं, लेकिन पहले गेम मैनुअल लिखने के बारे में सोचें (अवधारणाओं, नियंत्रणों, उद्देश्यों को समझाने के लिए)। यह आपके लिए 2 चीजें कर सकता है - एक बहुत आवश्यक दस्तावेज उत्पन्न करता है, लेकिन आपके खेल के सबसिस्टम और खिलाड़ी के लिए किसी भी आवश्यक विवरण को भी रेखांकित करता है। यदि आप पहले से जानते हैं कि खिलाड़ी को क्या जानना है, तो आप पहले से जानते हैं कि आपको क्या करने की आवश्यकता है।
  3. कोड को छोटे पर्याप्त (उर्फ रूपांतरित ) वर्णों में लिखें कि फैक्टर्ड टुकड़ों को या तो चारों ओर स्थानांतरित किया जा सकता है, या बेहतर महसूस किया जा सकता है जैसे आप पास्ता की प्लेट से स्पेगेटी के सभी मध्य आकार के टुकड़ों को हटाने की कोशिश कर रहे हैं।

उम्मीद है कि आपको वहाँ कम से कम एक उपयोगी जानकारी मिली, और शुभकामनाएँ!


1

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

यूएमएल "एक सिस्टम की वास्तुकला की कल्पना करने का एक मानक तरीका है"

यूएमएल वर्णन करता है

  • गतिविधियों
  • अभिनेताओं
  • व्यापार प्रक्रिया
  • डेटाबेस स्कीमा
  • (तार्किक) घटक
  • प्रोग्रामिंग भाषा बयान
  • पुन: प्रयोज्य सॉफ्टवेयर घटक

लेकिन अगर आप एक सरल खेल बना रहे हैं, तो क्या आपको वास्तव में यह सब करने की ज़रूरत है?

  • अभिनेता: खिलाड़ी।

कितना मदद करता है?

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

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


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

@SinthiaV अभिनेता देव टीम के लिए नहीं हैं । अभिनेताओं को अंतिम उत्पाद के साथ बातचीत करने वाले लोग माना जाता है ।
बोबोबो

स्तर / संसाधन संपादकों और इंजनों के बारे में क्या? यही वह उपयोग मामला था जिसका मैं उल्लेख कर रहा था।
सिंथिया वी

0

यूएमएल एक चीज नहीं है यह उन चीजों का एक संग्रह है जिनमें से कुछ में मूल्य हैं दूसरों को इतना नहीं। पुरानी शैली का उपयोग करें मामले (कम से कम जिसे हम उपयोग के मामले कहते हैं) उस स्थिति में

  • नाम
  • आवश्यकताओं
  • पूर्व शर्त
  • ट्रिगर्स
  • कार्रवाई
  • वैकल्पिक क्रियाएं
  • अपवाद

काफी उपयोगी हो सकता है। यदि आप एक वेब खोज (चित्र) करते हैं, तो आप "उपयोग मामलों" के लिए क्या पाते हैं, सामान्य सॉफ्टवेयर के लिए अधिक हैं।

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

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

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


0

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

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

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

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

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