मुझे यह कैसे याद रखना चाहिए कि मैं क्या कर रहा था और तीन महीने पहले एक परियोजना पर क्यों?


72

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

कल से, मैं पुराने प्रोजेक्ट पर वापस जा रहा हूँ। मुझे एहसास है कि मुझे याद नहीं है कि मैं वास्तव में क्या कर रहा था। मुझे नहीं पता कि कहां से शुरू करना है।

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


98
टिप्पणियां और संदेश देना, एक कारण है कि लोग आपको उन्हें छोड़ने के लिए कहते हैं
शाफ़्ट सनकी 12

5
क्या यह वास्तव में इस बात पर निर्भर नहीं करता है कि आप पहली बार प्रोजेक्ट को कैसे ट्रैक कर रहे थे? क्या हमें यह मान लेना चाहिए कि आप स्मृति से सब कुछ कर रहे थे और कोई अन्य दस्तावेज नहीं था?
जेफ

4
@ratchetfreak मैं यह कहने वाला था कि "यह केवल डेवलपर्स के लिए उपयोगी है" जब तक मुझे एहसास हुआ कि आप किसी भी चीज़ के लिए समान सिद्धांत लागू कर सकते हैं। अधिकांश दस्तावेज़ रिपॉजिटरी में एक नोट्स अनुभाग या एक विवरण है; ईमेल पर डिलिवरेबल्स में संदेश निकाय (अक्सर अनदेखा) होते हैं। दस्तावेज़ में परिवर्तन और एनोटेशन ट्रैक किए जा सकते हैं। पीएम की दुनिया में टिप्पणियों और प्रतिबद्ध संदेशों का एक पूरा पारिस्थितिकी तंत्र है! </ epiphany>
corsiKa

6
मैं पिछली बार क्या किया था, यह याद दिलाने के लिए मैं संस्करण नियंत्रण प्रणाली का उपयोग करता हूं, और यह जानने के लिए कि अभी भी क्या करने की जरूरत है, एक बग ट्रैकर।
रेयान

2
अरे हाँ, एक बार काम से तीन महीने के ब्रेक के बाद, मुझे अपने आखिरी प्रोजेक्ट का वर्णन करने के लिए एक नौकरी के लिए साक्षात्कार पर कहा गया था। मैंने ऐसा किया था, लेकिन जब उन्होंने विवरण मांगा, तो मैं उन्हें याद नहीं कर सका। अगर वे मुझे याद नहीं कर सकते हैं तो वे मुझे ठुकरा देते हैं, क्योंकि मैं एक मूर्ख हूँ। यह लगभग 15 साल पहले हुआ था, लेकिन मुझे अभी भी यह याद है।
एंड्रयू सविनाख

जवाबों:


35

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

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

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

  • परियोजना की गुणवत्ता के बारे में अवलोकन

    यह कोड कुछ रीफैक्टरिंग का उपयोग कर सकता है

    यह काम करने के लिए एक त्वरित कार्यान्वयन किया, लेकिन एबीसी बेहतर होगा।

  • टोडो आइटम / मुद्दे जिन्हें आप औपचारिक रूप से किसी समस्या ट्रैकर में रिकॉर्ड नहीं करना चाहेंगे

    "इस पद्धति को काम करना चाहिए, x < 0लेकिन वर्तमान में यह गुंजाइश से बाहर है।

  • डिजाइन निर्णय - विशेष रूप से गैर-तुच्छ वाले।

    हमारा मानक सॉर्ट फ़ंक्शन एक त्वरित सॉर्ट करता है, लेकिन यह सॉर्टिंग स्थिति के तहत समान आइटम के क्रम को संरक्षित नहीं करता है, जो हमें यहां चाहिए।

    स्पष्ट एल्गोरिथ्म एबीसी होगा लेकिन यह यहां विफल रहता है क्योंकि xनकारात्मक हो सकता है इसलिए हमें सामान्यीकृत रूप ( विकिपीडिया लिंक ) की आवश्यकता है।

  • समस्याओं का सामना करना पड़ा और आपने उन्हें कैसे हल किया। एक बहुत ही महत्वपूर्ण, मेरी व्यक्तिगत राय में: जब भी आप किसी समस्या में भाग लेते हैं तो उसे लॉग में नोट करें।

    कोड की जाँच की, लेकिन यह XYZ0123 त्रुटि दी, मुझे पता है कि मुझे पहले घटक C को संस्करण 1.2 या उच्चतर में अपग्रेड करना था।

बाद के दो अंक बहुत महत्वपूर्ण हैं। मैंने अक्सर एक समान स्थिति या समस्या का सामना किया है - कभी-कभी पूरी तरह से अलग परियोजना में - और सोचा "हम्म, मुझे इस पर एक दिन बिताना याद है, लेकिन फिर से समाधान क्या था?"

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


68

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

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

संपादित करें :

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


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

1
मैंने हाल ही में वह करना शुरू किया है जिसका आप अंतिम पैराग्राफ में उल्लेख करते हैं और इससे मुझे सुबह होने में मदद मिली।
TMH

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

3
कोड में TODO उत्कृष्ट हैं, लेकिन आपको उन्हें वहां रखने के बारे में मेहनती होना होगा, यहां तक ​​कि छोटी छोटी चीजों के लिए भी। todoअपने मेकफाइल में एक लक्ष्य होना जो उन्हें डंप करता है, उपयोगी भी है।
ब्लरफुल

4
trello.com एक जीवन रक्षक है। यहां तक ​​कि उन सोमवार मोनिंग टीम की बैठकों के लिए जहां मैं यह याद रखने के लिए संघर्ष करता हूं कि मैंने पिछले सप्ताह क्या किया था और मुझे इस सप्ताह क्या काम करना चाहिए। यह भी मुफ्त।
साइमनगेट्स

33

अब क्या करे?

अब, कल से मैं अपने पुराने प्रोजेक्ट पर वापस जाऊंगा और मुझे एहसास होगा कि मुझे याद नहीं है कि मैं वास्तव में क्या कर रहा था और कहाँ से शुरू करूँ!

मेरा अनुमान है कि आपने अगला भाग नहीं किया है। तो एक टूडू सूची को देखने से काम नहीं चलेगा।

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

भविष्य में अपने लिए इसे बेहतर कैसे बनाएं?

मैं यह जानना चाहता हूं कि इस परियोजना का दस्तावेज कैसे बनाऊं कि कभी भी मैं पीछे मुड़कर देखूं, जहां भी मैं गया वहां से जाने में मुझे कुछ मिनटों से अधिक समय नहीं लगेगा!

सबसे पहले, आपको अपने टॉड्स पर नज़र रखने के लिए एक सिस्टम होना चाहिए। क्या आपके पास अभी ऐसी व्यवस्था है? आप अपने वर्तमान प्रोजेक्टवर्क को कैसे प्रबंधित करते हैं?

मैं कल एक बस से टकरा सकता था और मेरी टीम को मेरे 90% से अधिक एक्शन आइटमों का अच्छा अंदाजा होगा। ऐसा इसलिए है क्योंकि मेरे पास मेरे दस्तावेज के लिए एक सामंजस्यपूर्ण प्रणाली है:

  • तत्काल todos (<1 सप्ताह आइटम)
  • "अच्छा लगा" todos
  • मील के पत्थर और मैक्रो todos (जहाँ विशेष अर्थपूर्ण नहीं हैं)
  • आवश्यकताएँ / बैठक नोट्स

साथ ही, मैं एक वीसीएस का उपयोग करता हूं और अपना कोड टिप्पणी करता हूं जहां उपयुक्त हो।

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

क्या बात है?

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

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


@ अन्य निर्भरता कोई समस्या नहीं, खुशी है कि यह मददगार था। वह स्थिति भारी हो सकती है।
एंडरलैंड

@ TheIndependentAquarius संभावना है क्योंकि आम तौर पर टिप्पणियों का उद्देश्य कम-से-कम / उसके / उसके बाद होने वाले स्टिक होते हैं। स्टैक एक्सचेंज ने जिस तरह से चीजों को सेटअप करने के लिए कहा है, "यह उत्तर बहुत अच्छा था" या तो उत्थान कर रहा है या एक उत्तर को स्वीकार कर रहा है। यहाँ टिप्पणियाँ आवश्यक रूप से पिछले करने के लिए अभिप्रेत नहीं हैं।
एंडरलैंड

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

@BTownTKD मैं कहता हूं कि मेरे जवाब में :)
एंडरलैंड

इसका एक अच्छा जवाब है; जोर देने के लिए जोड़ा।
बीटाउनटीकेडी

14

मेरी राय में, एक कोड परियोजना को "फिर से शुरू" करने के दो भाग हैं:

  1. निर्धारित करना कि आपने कहाँ छोड़ा है
  2. यह याद रखना कि तुम्हें क्या करना है

यह उन चीजों में से एक है, जो मुझे लगता है, अगर आप सही तरीके से संस्करण नियंत्रण कर रहे हैं तो यह आपका "अन्य मस्तिष्क" होगा।

कहाँ छोड़ दिया ? जब तक आपका कोड बार-बार कोड कर रहा है, तब तक अपने अंतिम बदलाव को देखें। यह सबसे अधिक संभावना है कि आपके दिमाग में कुछ जॉग करेगा। यदि नहीं, तो पिछले कुछ को देखें, सबसे पुराने और फिर से शुरू होने के साथ शुरू होता है।

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

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


10

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

1. कोई कार्य बहुत जल्द या बहुत छोटा नहीं है

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

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

2. बड़े-चित्र विचारों को पकड़ने के लिए अपने डेस्क पर व्हाइटबोर्ड का उपयोग करें

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

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

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

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

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

मैं आपको एक सभ्य व्हाइटबोर्ड खरीदने के लिए पैसे खर्च करने की सलाह देता हूं, कम से कम 3 "x 4", और इसे उस स्थान पर लटका दें जहां आप सामान्य रूप से काम करते हैं। किसी भी वर्चुअल सिस्टम पर एक भौतिक व्हाइटबोर्ड के कई फायदे हैं।

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

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

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

3. हितधारकों को एक परियोजना को बाधित करने की लागत से अवगत कराएं

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

परियोजनाओं के लिए इसका मतलब यह है कि एक परियोजना से दूसरे परियोजना में परिवर्तन करने से समय का एक बड़ा व्यय होता है और बहुत सारे नुकसान समाप्त हो जाते हैं जिनसे निपटना पड़ता है।

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

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

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


संक्षेप में:

  1. सब कुछ आप कर रहे हैं लिख के बारे में , ऐसा करने के लिए भले ही आपको नहीं लगता कि आप कभी भी संभवतः यह नीचे लिखा की जरूरत हो सकती है। यहां तक ​​कि एक छोटी पेंसिल एक लंबी स्मृति धड़कता है।
  2. एक भौतिक व्हाइटबोर्ड पर बड़ी तस्वीर का मंथन करें, जिसकी आपको लगातार पहुँच है।
  3. आप हो सकता है अगर आप इस तरह के निर्णय निर्माताओं के बारे में पता रुकावट के लिए एक लागत है कि वहाँ बनाने परियोजना हस्तक्षेपों से बचने, और कम से कम आप अपेक्षाएं निर्धारित करना होगा ताकि वे जान सकें जब आप इसे फिर से शुरू परियोजना लंबे समय तक एक सा ले जाएगा।

1
हितधारकों का मानना ​​है कि वे एक पेशेवर डेवलपर को भुगतान कर रहे हैं जो कोड पर टिप्पणी कर रहा है और दस्तावेज़ कर रहा है ताकि वह (बाद के समय में) या किसी और (किसी भी समय) परियोजना को संभाल सके। बेशक उनकी धारणा ज्यादातर समय गलत होती है।
जेफ

और आपको टिप्पणी और दस्तावेज करना चाहिए! मुझे आशा है कि आपको नहीं लगा कि मैं सुझाव दे रहा था अन्यथा। (और जिस तरह से मैं आपकी टिप्पणी से सहमत हूं।)
iconoclast

2

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


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

2

किसी समस्या-ट्रैकिंग सिस्टम (जैसे Redmine , या GitHub ) के साथ संयोजन में उचित ब्रांचिंग और मर्जिंग रणनीतियों के साथ एक स्रोत-नियंत्रण प्रणाली का उपयोग करना , आपके द्वारा किए गए परिवर्तनों को व्यवस्थित करने में मदद करता है, उन्हें दिशा देता है, और आपके लापता संदर्भ को इस रूप में दस्तावेज़ित करता है: वर्कफ़्लो का एक स्वाभाविक हिस्सा।

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

1

बहुत सारे लंबे उत्तर हैं। यह एक छोटी सी बात है जो मुझे सबसे ज्यादा मदद करती है:

  • साफ कोड।
  • साफ कोड।
  • साफ कोड।
  • संस्करण नियंत्रण (भिन्न होता है और टिप्पणी करता है)।
  • एक पोस्ट-इट नोट या एक टोडो-लिस्ट या कानबन-बोर्ड (उदाहरण के लिए ट्रेलो और एवरनोट देखें)

हालाँकि, डिफेंस, कमेंट्स, पोस्ट-इट नोट्स, टोडो-लिस्ट या कानबन-बोर्ड को संदर्भ की कमी के लिए समय के साथ गलत समझा जा सकता है। तो यहाँ एक बात है जो सबसे महत्वपूर्ण है:

सफाई कोड।


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

@ जेन्सजी: कोड वास्तुकला है। एक अच्छी तरह से लिखित कार्यक्रम में, मैं फ़ंक्शन में प्रोग्राम-आर्किटेक्चर के शीर्ष को देख सकता हूं main, जो कि काफी आकार के कार्यक्रम के लिए बल्कि सार होगा। मैं तब गहरा गोता लगा सकता हूं, और वास्तुकला को देख सकता हूं कि कैसे कार्यक्रम खुद को साफ करता है, उदाहरण के लिए। इसके अलावा, स्वच्छ कोड का मतलब है कि कार्य / चर / आदि। ऐसे नाम हैं जो समझ में आते हैं और उनके अर्थ के बारे में बयान करते हैं। यदि मैं इसके बजाय स्पेगेटी / राइट-ओनली कोड लिखता हूं, तो मैं अक्सर अगली सुबह / महीने / वर्ष जगाता हूं, मेरे कोड को देखता हूं, और केवल सोचा wtf-किया-i-do-there होगा। यह वैसा ही है .. जब
15:15

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

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

@ जेन्सजी: मैं आपकी बात को मानता हूं। मुझे लगता है कि हम सिर्फ व्याख्या कर रहे हैं "मुझे एहसास है कि मुझे याद नहीं है कि मैं वास्तव में क्या कर रहा था" अलग तरह से। मेरे लिए यह अधिक पसंद था "मुझे एहसास है कि मुझे याद नहीं है कि मैंने कौन से एल्गोरिदम और डेटा-संरचनाएं कोडित की हैं और मैं उन्हें कैसे बढ़ा सकता हूं", आपके लिए, यह (मुझे लगता है) अधिक पसंद था "मुझे एहसास है कि मुझे याद नहीं है कि क्या वास्तव में मैं इसे लागू करने और उसके लक्ष्य के लिए प्रयास कर रहा था "। अस्पष्ट मानवीय भाषा। ...
१०

1

मैं किसी परियोजना का दस्तावेज कैसे बना सकता हूं कि जब भी मैं पीछे मुड़कर देखूं तो मुझे जहां भी छोड़ा जाए वहां से जाने में कुछ मिनटों से ज्यादा समय नहीं लगेगा।

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

क्या सर्वोत्तम प्रथाएं हैं?

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

  1. संस्करण नियंत्रण का उपयोग करें यह आपको एक मुफ्त ट्रैक रिकॉर्ड देता है कि क्या हुआ, कब और किसने परिवर्तनों को लागू किया। यह आपको किसी भी समय पुराने संस्करण में वापस आने में आसानी देता है।

  2. अपने कोड को संशोधित करें (भाषा और प्रोग्रामिंग वातावरण के आधार पर, कक्षाओं, मॉड्यूल, पैकेज, घटकों का उपयोग करें)।

  3. अपने कोड का दस्तावेज़ दें। इसमें प्रत्येक फ़ाइल के शीर्ष पर सारांश प्रलेखन शामिल है (यह क्या करता है? क्यों? इसका उपयोग कैसे करें?), और फ़ंक्शंस, प्रक्रियाओं, कक्षाओं और विधियों के स्तर पर विशिष्ट टिप्पणियां (यह क्या करता है? तर्क और रिटर्न मान / प्रकार? साइड-इफेक्ट?)

  4. TODOFIXMEजब आप कोडिंग कर रहे हों तो जोड़ें और टिप्पणी करें । यह quirks के व्हाट्स और व्हाट्स को याद रखने में मदद करता है जो अनिवार्य रूप से आपके कोड आधार में प्रवेश करेगा और बाद में आपके पास WTF होगा !!! । उदाहरण के लिए:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. दस्तावेज़ संरचना और जटिल व्यवहार के लिए आरेख बनाने की आदत बनाएं जैसे कि मॉड्यूल / ऑब्जेक्ट / सिस्टम आदि के बीच कॉल के अनुक्रम। व्यक्तिगत रूप से मैं यूएमएलटी पसंद करता हूं क्योंकि यह उपयोग करने के लिए त्वरित है, अच्छा ग्राफिक्स बनाता है, और सबसे महत्वपूर्ण बात यह है कि आपके रास्ते में नहीं आता है । लेकिन निश्चित रूप से आपको किसी भी ड्राइंग टूल का उपयोग करना चाहिए जो आपको लगता है कि काम करता है। याद रखें कि इस तरह के किसी भी चित्र का उद्देश्य संक्षिप्त रूप से संवाद करना है, न कि सिस्टम को मिनट डिटेल (!!) में निर्दिष्ट करना।

  6. यूनिट परीक्षण जल्दी जोड़ें । यूनिट परीक्षण न केवल प्रतिगमन परीक्षण के लिए महान हैं, बल्कि आपके मॉड्यूल के लिए उपयोग प्रलेखन का एक रूप भी हैं।

  7. जल्दी कोड-बाहरी दस्तावेज़ जोड़ें । README के ​​साथ शुरू करें जो परियोजना को चलाने और विकसित करने के लिए आवश्यक निर्भरता का वर्णन करता है, इसे कैसे स्थापित किया जाए, इसे कैसे चलाया जाए।

  8. दोहराए जाने वाले कार्यों को स्वचालित करने की आदत डालें । उदाहरण के लिए संकलन / निर्माण / परीक्षण चक्रों को किसी न किसी रूप में (उदाहरण के लिए जावास्क्रिप्ट उपयोग में grunt, पायथन में fabric, जावा में Maven) स्क्रिप्ट किया जाना चाहिए । यह आपको वापस आने पर तेज़ी से गति करने में मदद करेगा।

  9. जैसे-जैसे आपकी परियोजना बढ़ती है, स्रोत-कोड डॉक्स (जावाडॉक-शैली की टिप्पणियों के कुछ रूप का उपयोग करके और HTML या पीडीएफ को इससे उत्पन्न करने के लिए एक उपयुक्त उपकरण) उत्पन्न करके अधिक प्रलेखन जोड़ें ।

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


0

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

बैठ जाइए, 'रन टेस्ट' करिए, और वहां से उठिए जहां आपने छोड़ा था।


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

1
@MainMa मैं ने कहा कि प्रतिबद्ध नहीं है। बस स्थानीय स्तर पर।
पीट

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

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

2
@ मेनमा: बैकअप के साथ संस्करण नियंत्रण में बहुत कुछ हो सकता है, लेकिन यह इसका प्राथमिक उद्देश्य नहीं है। यदि आपको एक बैकअप सिस्टम की आवश्यकता है, और आप जिस तरह से संस्करण नियंत्रण का उपयोग कर रहे हैं, वह उस उद्देश्य को पूरा करने से रोकता है, तो एक टाइम कैप्सूल या कुछ इसी तरह प्राप्त करें। आपको अपने वीसीएस को बैकअप के रूप में काम करने के लिए मजबूर करने के लिए कभी भी समय से पहले मजबूर नहीं होना चाहिए । और आपको कभी भी कुछ अन्यथा करने से रोका नहीं जाना चाहिए क्योंकि आप "तुरंत सब कुछ करने" की नीति का पालन कर रहे हैं।
आइकनोकॉस्ट

0

टिप्पणियों / टूडू सूचियों / कमिट के अलावा, यथार्थवादी होना जरूरी है।

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

पुराना पुराना धैर्य उपयोगी रहेगा।

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


0

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

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


ऐसा लगता नहीं है कि बनाए गए कुछ बिंदुओं पर पर्याप्त मात्रा में प्रस्ताव दिए गए हैं और पहले के 11 जवाबों में समझाया गया है
gnat

0

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

यहाँ OneNote में कुछ ऐसी चीज़ें दी गई हैं जो मुझे परियोजनाओं पर प्रगति को फिर से शुरू करने में मदद करती हैं:

  • दैनिक / साप्ताहिक लॉग - प्रगति का एक दैनिक या साप्ताहिक लॉग रखें, जिससे आपको उस प्रगति का पता लगाने में मदद मिल सके जो आपने पहले ही किसी परियोजना के साथ की है।

  • टू-डू लिस्ट - मेरे पास एक सामान्य टू-डू लिस्ट है, लेकिन मैं उन प्रोजेक्ट्स के लिए एक अलग टू-डू लिस्ट भी रखता हूं, जिन पर मैं काम कर रहा हूं, ताकि मुझे याद रहे कि एक प्रोजेक्ट के लिए मुझे क्या करना है। मैं कभी-कभी // TODO: मेरे कोड में आइटम भी छोड़ता हूं।

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

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


-2

सरल परियोजनाओं के लिए, मैं यह करता हूं:

  1. रूट डायरेक्टरी में एक साधारण README फाइल (जो, इसलिए, संस्करण नियंत्रण में भी समाप्त हो जाएगी) जहां मैं विकास करते समय जो कुछ भी नोट करता हूं: करने के लिए चीजें, बग, सुधार / विचार। यह पहली फाइल है जिसे मैं पढ़ूंगा मुझे प्रोजेक्ट को बैक बर्नर पर रखना होगा।
  2. TODO / FIXME / XXX टिप्पणियाँ
  3. मैं अक्सर ToDoList का भी उपयोग करता हूं
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.