खुद को कैसे नहीं चलाना है?

Question

मुझे अक्सर लगता है कि मैं विशेष रूप से डिजाइन चरण में एक सुविधा पर पूरा काम करने से कम करता हूं। मैं कई कारणों का पता लगाने:

1. मैं अति-आशावादी
2. मैं त्वरित समाधान प्रदान करने की आवश्यकता महसूस करते हैं, तो कभी कभी मैं डिजाइन सोच में अपने आप को मूर्ख मूर्ख प्रूफ है जब वास्तव में यह अभी भी छेद से भरा हुआ है , नौकरी तेजी से करने के लिए। बेशक मैं बाद में भुगतान करना समाप्त कर देता हूं।

मुझे कुछ समय के लिए मेरा व्यवहार इस बारे में पता है, फिर भी मुझे लगता है कि मैं क्षतिपूर्ति करने का प्रबंधन नहीं करता हूं। क्या आपको ऐसी ही समस्याएं आई हैं? आप उन्हें सुलझाने के लिए कैसे पहुंचते हैं?

Answer 1

मैं इस समस्या में बहुत कुछ चलाता हूं।

मेरा समाधान एक नोटबुक है। (पुराने फैशन पेपर प्रकार)।

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

अक्सर, उस प्रक्रिया के दौरान, मैं उन मुद्दों पर आ जाता हूं जिनके बारे में मैंने नहीं सोचा था।

बेशक, 80/20 नियम अभी भी लागू होता है ... मैं अभी भी चीजों में आ जाता हूं जब मैं वास्तव में कार्यान्वयन कर रहा हूं जो मेरे साथ नहीं हुआ था, लेकिन अनुभव के साथ ये कम हो जाते हैं।

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

Answer 2

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

प्रबंधन से दबाव मिलने पर, मैं उन्हें बताता हूं कि मुझे वैसे भी विचार करना होगा, इसलिए जब यह सस्ता हो तो मुझे इसे करना चाहिए। मैं कागज पर भी सोचता हूं, इसलिए मैं वास्तव में साबित कर सकता हूं कि मैं कुछ कर रहा हूं और यह मेरी उंगलियों को कीबोर्ड पर रखता है, जिनमें से दोनों प्रबंधन के लिए सुखद प्रभाव प्रदान करते हैं। ;-)

Answer 3

जब आप एक परियोजना के नियोजन चरण में हैं, खासकर सॉफ्टवेयर विकास क्षेत्र में बढ़ते मामलों और विवरण को याद करना बहुत आम है। कृपया महसूस न करें कि यह एक व्यक्तिगत विफलता है; यह कुछ स्थानिक है।

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

http://en.wikipedia.org/wiki/Agile_methods

http://en.wikipedia.org/wiki/Scrum_%28development%29

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

यदि आपकी समस्या समय प्रबंधन से अधिक संबंधित है, तो मैं होटिंग थिंग्स डोन दृष्टिकोण (http://en.wikipedia.org/wiki/Getting_things_done) की अनुशंसा करता हूं। यह व्यावहारिक और सरल है, जो आपको उस जानकारी के साथ अधिभारित किए बिना उत्पादक बनाने पर ध्यान केंद्रित करता है जो आपके वर्तमान काम के लिए तत्काल प्रासंगिक नहीं है। मैंने पाया है कि मैं कभी-कभी प्रोजेक्ट/फीचर विचारों से अभिभूत हूं और यह वास्तव में सबकुछ लिखने में मदद करता है और इसे बाद में फाइल करता है जब मेरे पास प्रभावी ढंग से काम करने के लिए संसाधन उपलब्ध होते हैं।

मुझे आशा है कि इससे मदद मिलेगी और शुभकामनाएं!

Answer 4

स्पष्ट ध्वनि के जोखिम पर - निराशावादी बनें। मेरे पास कुछ अनुभव थे जहां मैंने सोचा था कि "कुछ घंटों का समय लेना चाहिए" और यह अप्रत्याशित रूप से पॉप अप होने वाली सभी छोटी चीजों के कारण दिन लेना समाप्त हो गया।

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

प्रोग्रामर के रूप में यह बहुत कठिन है कि वास्तविक रूप से डिबगिंग समय प्रोजेक्ट करना - कोड लिखना आसान है, लेकिन काम करने में इसे डिबग करना, वैध कोड पूरी तरह से कुछ और है। इसलिए मुझे लगता है कि इसमें कोई सटीक विज्ञान नहीं है, लेकिन मैं सिर्फ पूरे समूह द्वारा पैड कार्य करता हूं, ताकि मेरे पास डीबगिंग के लिए बहुत सांस लेने का कमरा हो।

Evidence Based Scheduling भी देखें जो फोगब्रीज़ उत्पाद के लिए फोगक्रीक द्वारा विकसित शेड्यूलिंग में एक आकर्षक अवधारणा है।

Answer 5

आप और बाकी दुनिया।

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

for (i=1; i<=10; i++) {} 

) से बहुत अधिक समय लेना। मिसाइल सिस्टम पर एकाउंटिंग पैकेज के लिए यह वास्तव में लायक है।

Answer 6

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

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

मेरे पास अंतर्ज्ञान है कि इस तरह की सफलताओं की एक छोटी सूची है (जैसे http://www.threeriversinstitute.org/FirstOneThenMany.html) जिसमें अधिकांश डिज़ाइन शामिल होंगे। इस बीच, मैं याद रखने की कोशिश करता हूं कि "दिन के लिए पर्याप्त समस्याएं हैं"।

Answer 7

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

तो आज मैं स्वीकार करता हूं कि एक डिजाइन को लागू करते समय मैं इसके बारे में बहुत सी नई चीजें सीखूंगा, और उस सीख को वापस डिजाइन में खिलाने की आवश्यकता होगी। ऐसा करना एक ऐसा कौशल है जो सीखने में मजेदार है, जिसमें इसे सरल, मुक्त डुप्लिकेशंस और समेकित और decoupled से मुक्त डिज़ाइन को लचीला रखने के कौशल, छोटे, नियंत्रित चरणों (= refactoring) में डिज़ाइन बदलने और आवश्यक लिखने के कौशल शामिल हैं। स्वचालित परीक्षणों का व्यापक सूट जो इस तरह के परिवर्तनों को सुरक्षित बनाता है।

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

Answer 8

संचार।

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

जवाबदेही चेकलिस्ट:

1. हम इस का समर्थन करते हैं कैसे?
2. कौन जानता है कि क्या बदल गया है?
3. हम इसे पहले स्थान पर क्यों कर रहे हैं?
4. क्या कोई ऐसा व्यक्ति होगा जो यह नहीं बदलना चाहता?
5. क्या कोई और समझ जाएगा कि मैंने यह कैसे किया?
6. उपयोगकर्ता इस परिवर्तन को कैसे समझेंगे और उपयोग करेगा?

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

Answer 9

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

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

Answer 10

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

मुझे एक सहकर्मी/मित्र होने के लिए भी मूल्यवान लगता है जिसे मैं समीक्षा करने से पहले जो समीक्षा करता हूं उसकी समीक्षा करता हूं। कोई और लगभग हमेशा कुछ ऐसा देखता है जिसे मैंने नहीं सोचा या गलत नहीं किया।

Answer 11

मुझे यहां दूसरों के जैसा करना पसंद है। छद्म कोड में लिखें कि आपके ऐप का प्रवाह क्या होगा। यह तुरंत कुछ विस्तृत क्षेत्रों पर प्रकाश डाला गया है जिन पर आगे ध्यान देने की आवश्यकता हो सकती है कि जहां सामने नहीं दिखाई देता है।

छद्म कोड व्यावसायिक उपयोगकर्ताओं को भी पठनीय है जो आपकी दृष्टिकोण को उनकी आवश्यकताओं को पूरा कर सकते हैं।

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

बस एक या दो घंटे लिखने छद्म कोड ले, पर बाद में कुछ अमूल्य समय की बचत टुकड़े पैदावार: 1. एक ऑब्जेक्ट मॉडल 2. कार्यक्रम के प्रवाह स्पष्ट रूप से दूसरों 3. के लिए परिभाषित किया गया है उभर यह प्रलेखन के रूप में इस्तेमाल किया जा सकता कुछ परिष्करण के साथ आपके डिजाइन का 4. टिप्पणियां जोड़ना आसान है और आपके कोड की समीक्षा करने वाले किसी और के लिए स्पष्ट होगा।

आपको शुभकामनाएँ!

Answer 12

मैंने पाया है कि यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपने एक अच्छा डिज़ाइन चुना है, यह सुनिश्चित करना है कि आप समस्या को समझें, अपनी सीमाओं को जानें, और जानें कि चीजें क्या हैं- haves बनाम अच्छा- करने के लिए अमीर।

समस्या को समझने में उन लोगों से बात करना शामिल होगा जिनके पास आवश्यकता है और उन्हें पहले यह करने के लिए क्या करना चाहिए, इसके बजाय उन्हें क्या करना चाहिए, इसके बजाय उन्हें क्या करना चाहिए। एक बार जब आपको पता चले कि वास्तव में क्या होना है, तो आप वापस जा सकते हैं और इसके बारे में आवश्यकताओं पर बात कर सकते हैं।

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

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

सुनिश्चित करें कि आप यह सब लिख लें! यहां तक ​​कि अगर यह रास्ते में विकसित होता है, या डिज़ाइन छोटा होता है, तो "यह वही है जो हम अभी करने की योजना बना रहे हैं" मार्गदर्शिका के संदर्भ में जब आपको संसाधनों को करने के बारे में निर्णय लेने की आवश्यकता होती है तो इसे लागू करने से खुद को रोकना आसान हो जाता है एक उबाऊ जरूरी चीज के बजाय वास्तव में एक अच्छा whiz-bang सुविधा।

Answer 13

चूंकि आप पहचानते हैं कि आपको त्वरित समाधान प्रदान करने की आवश्यकता महसूस हो रही है, शायद यह आपको यह समझने में धीमा कर देगा कि आप शायद समस्या को तेजी से हल कर सकते हैं और यदि आप डिज़ाइन में अधिक समय व्यतीत करते हैं तो इसे जल्द से जल्द वितरित कर सकते हैं। उदाहरण के लिए यदि आप 3 घंटे डिज़ाइनिंग और 30 घंटे लिखने वाले कोड खर्च करते हैं, तो शायद इसका अर्थ यह है कि यदि आप 6 घंटे डिज़ाइन करते हैं तो आपको केवल 10 घंटे कोड लिखने की आवश्यकता हो सकती है। (ये वास्तविक आंकड़े सिर्फ उदाहरण नहीं हैं)। आप अपनी अगली कुछ परियोजनाओं पर अपने लिए इसे प्रमाणित करने का प्रयास कर सकते हैं।एक जोड़े को करें जहां आप सामान्य रूप से व्यवहार करते हैं और देखें कि डिज़ाइन/कोडरिटिंग/परीक्षण & डिबगिंग का वास्तव में आप क्या करते हैं। फिर अगली परियोजना पर जानबूझकर डिजाइन चरण पर खर्च किए गए समय का प्रतिशत बढ़ाएं और देखें कि क्या यह अन्य चरणों के लिए आवश्यक समय को कम करता है। परियोजनाओं को काफी अलग होने के बाद से आपको एक वास्तविक बेसलाइन प्राप्त करने के लिए इस पर कई परियोजनाओं के लिए प्रयास करना होगा। यह जांचने के लिए एक परीक्षण के रूप में करें कि क्या आप अन्य चरणों पर अपना प्रदर्शन सुधार सकते हैं और इस प्रकार यदि आप 20% अधिक समय या 50% अधिक समय या डिजाइन पर 100% अधिक समय व्यतीत करते हैं तो एक तेज उत्पाद प्रदान करते हैं।

प्रक्रिया में बाद में याद रखें कि आपको एक डिजाइन के साथ समस्या को कठिन (और अधिक समय लेने वाला) ठीक करना है।