हमारी टीम में, चुस्त-दुरूस्त रहने के बाद से, हम यह समझने की कोशिश कर रहे हैं कि वास्तव में कितने प्रलेखन की आवश्यकता है। मैं आपके साथ साझा कर सकता हूं कि हमने अब तक क्या सीखा है।
कुछ और करने से पहले, इस लेख को Agile / Lean Documentation पर पढ़ना सुनिश्चित करें । बहुत अच्छा पढ़ा।
दूसरी बात, मैं आपको कहानियों पर प्रारंभिक काम के बाद डिजाइन दस्तावेज़ों पर पुनर्विचार करने की दृढ़ता से सलाह दूंगा। हमने कोशिश की है कि पहले और यह बेकार साबित हुआ है। अंतिम रिलीज़ के बीच में हमने डिज़ाइन डॉक्स को अपडेट करने का फैसला किया है, केवल कहानी के लिए कोड दिए जाने के बाद। और अब मैं सोच रहा हूँ कि बहुत जल्द।
आपको अपने आप से यह पूछने की आवश्यकता है कि आप कोडिंग से पहले डिज़ाइन डॉक्स क्यों करना चाहते हैं। हमारे लिए ये कारण थे:
- हमें एक टीम के रूप में यह समझने की जरूरत है कि कहानी डिजाइन को कैसे प्रभावित करेगी।
- जब नए (या अस्थायी) सदस्य टीम में शामिल होते हैं या जब कोई एक साल से अधिक के लिए काम नहीं करता है तो कोड में लौटते समय डिज़ाइन दस्तावेज़ होना उपयोगी साबित होता है। इसलिए वे यह समझने में मदद करने के लिए संगठनात्मक स्मृति के लिए उपयोगी हैं कि कोड कैसे काम करता है।
- डिज़ाइन दस्तावेज़ रखरखाव इंजीनियरों के लिए उपयोगी होते हैं जिन्हें रिलीज़ के बाद कोड का निवारण करना पड़ सकता है।
संतुष्ट करने के लिए (1) आपको एक वास्तविक डिज़ाइन दस्तावेज़ बनाने की आवश्यकता नहीं है। आपकी टीम के पास कोडिंग से पहले एक डिज़ाइन चरण होना चाहिए, लेकिन वह चरण एक व्हाइटबोर्ड या नैपकिन के सामने 15 मिनट के सत्र के रूप में सरल हो सकता है। आपको एक वास्तविक दस्तावेज़ बनाने की ज़रूरत नहीं है जो डिज़ाइन परिवर्तनों पर चर्चा करने के लिए केवल लिखने में घंटों (यदि दिन नहीं) लेगा।
(2) या (3) वर्तमान कहानी के विकास के दौरान की आवश्यकता नहीं है और अधिक से अधिक संभावना है कि वे बाद के पुनरावृत्तियों के लिए आवश्यक नहीं होंगे।
यह भी ध्यान रखें कि हर बार टीम का सदस्य डिजाइन डॉक्स को अपडेट / अपडेट कर रहा है, यही समय है कि कोड नहीं लिखा जा रहा है। जब आप वास्तविक कोड से पहले डॉक्स लिखते हैं, तो लगभग 100% संभावना होती है कि उन्हें अपडेट करने की आवश्यकता होगी क्योंकि एक बार कोडिंग डिज़ाइन शुरू करने के बाद हमेशा बदल जाता है। और यहां तक कि अगर आप कोड के बाद डिजाइन डॉक्स लिखते हैं, जैसा कि हमारी टीम ने सीखा है, तो बाद की कहानियों से रिफैक्टिंग करना अभी भी डिजाइन को बदल देता है।
तो मैं क्या सुझाऊंगा:
- प्रारंभ में अस्थायी डिजाइन / मॉडल का पर्याप्त उत्पादन करें ताकि आपकी टीम कोडिंग से पहले एक बुद्धिमान बातचीत कर सके। इन्हें रखने की अपेक्षा न करें और इन्हें औपचारिक रूप देने में समय बर्बाद न करें।
- केवल आधिकारिक डिज़ाइन प्रलेखन का उत्पादन करें यदि किसी को इसकी आवश्यकता होगी (यानी आपकी टीम को संगठनात्मक स्मृति की वास्तविक आवश्यकता है)
- केवल कोड पर डिज़ाइन प्रलेखन का उत्पादन करें जिसे स्थिर किया गया है। ऐसे किसी मॉड्यूल को प्रलेखित करने की कोशिश करने का कोई मतलब नहीं है जो हर पुनरावृत्ति में परिवर्तित होता रहे।
- डिजाइन दस्तावेजों का उत्पादन करें जो पूरी तरह से एक मॉड्यूल (या उत्पाद के हिस्से) का वर्णन करते हैं। पूर्व में हम डिज़ाइन डॉक्स लिखते थे जो कि किए गए परिवर्तनों का दस्तावेजीकरण करते थे। रिलीज होते ही वे डॉक्स पूरी तरह से बेकार हो गए।
- दस्तावेज़ को बहुत उच्च-स्तर पर रखें। यदि आप आर्किटेक्चर को कवर करने वाले 20 पेज लिखते हैं और बहुत उच्च-स्तरीय डिज़ाइन करते हैं, तो वह दस्तावेज़ a) वास्तव में अन्य लोगों द्वारा पढ़ा जाएगा और b) लोगों को आपके कोड के सामान्य लेआउट से परिचित होने में मदद करेगा। विवरण के लिए लोग सीधे कोड में जा सकते हैं। यदि आप विस्तृत विवरण के 700 पृष्ठ लिखते हैं, तो वे लगभग हमेशा वास्तविकता से मेल नहीं खाते हैं, यह किसी के लिए भी पढ़ने के लिए बहुत अधिक है और जब भी भविष्य में परिवर्तन होते हैं, तो आप 20 के बजाय 700 पृष्ठों को बनाए रखने और अपडेट करने के लिए समाप्त हो जाएंगे।