मैं अब लगभग तीन वर्षों से एक चुस्त कार्यप्रणाली (SCRUM) का उपयोग कर रहा हूं और मुझे इसके कुछ फ़ायदे दिख रहे हैं, विशेष रूप से कई स्तरों पर अल्पावधि प्रतिक्रिया में (ग्राहकों द्वारा कार्यान्वित सुविधाओं के लिए जल्दी पहुंच वाले, परीक्षकों से जो सुविधाओं का परीक्षण कर सकते हैं जैसे ही वे कार्यान्वित होते हैं, अन्य डेवलपर्स से जो समीक्षा आदि के माध्यम से नए कोड पर बहुत प्रारंभिक प्रतिक्रिया प्रदान कर सकते हैं)।
दूसरी ओर, मुझे दो खुली समस्याएं हैं, जिनमें से सबसे पहले मैं इस प्रश्न में समझाने की कोशिश करूंगा।
समस्या: एक अच्छा डिज़ाइन प्राप्त करने में कठिनाई
जैसे ही कोड गड़बड़ हो जाता है, मैं रीफैक्टरिंग करने की कोशिश करता हूं, मैं यूनिट टेस्ट उतना ही लिखता हूं जितना (जो सामान्य रूप से बग्स को रोकने में मदद करता है और विशेष रूप से रिफैक्टिंग करते समय)। दूसरी ओर, छोटे वेतन वृद्धि में कुछ जटिल विशेषता विकसित करना, दैनिक कमिट के साथ और लगातार कोड को फिर से जोड़ना जब यह असंरचित हो जाता है तो मुझे वास्तव में अच्छे डिजाइन का उत्पादन करने की अनुमति नहीं देता है।
एक ही अच्छी तरह से डिज़ाइन किया गया मॉड्यूल जिसे मैं हाल ही में प्राप्त कर सकता हूं एक अलग दृष्टिकोण लेकर: मैंने कुछ दिनों के लिए समस्या का विश्लेषण किया (मुझे वास्तव में कुछ महीनों तक मेरे दिमाग से गुजरने में समस्या थी, इससे पहले कि मैंने इस पर गंभीरता से काम करना शुरू कर दिया ), एक जोड़े के लिए सभी शामिल वर्गों और उनके संबंधों के अधिक विस्तृत डिज़ाइन को और अधिक दिनों तक स्केच किया, और फिर खुद को मेरे कार्यालय में बंद कर दिया और लगभग तीन सप्ताह तक बिना किसी रुकावट के काम करके पूरे कोड को लिख दिया। परिणाम कुछ ही समय में मेरे द्वारा उत्पादित सबसे अच्छी चीज थी, जिसमें बहुत कम कीड़े थे जिनका पता लगाना और ठीक करना आसान था, और बहुत स्पष्ट डिजाइन के साथ, जिसके बाद से किसी भी प्रासंगिक बदलाव की आवश्यकता नहीं थी।
इसलिए अब तक मुझे इस बात की अधिक प्रभावी जानकारी मिली कि मैं जो कुछ करना चाहता हूं, उससे पहले कि वह इस प्रक्रिया में छोटे वेतन वृद्धि में कोड लिखना शुरू करने की तुलना में मैं क्या करना चाहता हूं, की बड़ी तस्वीर जादुई रूप से उभरती है। मेरे सर्वोत्तम प्रयास के साथ, छोटे-वृद्धि के विकास के दृष्टिकोण ने मुझे हमेशा बदतर डिजाइन के लिए प्रेरित किया।
प्रश्न : क्या किसी को भी इसी तरह का अनुभव हुआ है? क्या मैं SCRUM को गलत तरीके से लागू कर रहा हूं या अगर मुझे छोटे वेतन वृद्धि में विकास करना है और अभी भी एक अच्छी तरह से डिज़ाइन किए गए सॉफ़्टवेयर के साथ समाप्त होना है तो मुझे क्या ध्यान देना चाहिए? या क्या मुझे वास्तविक कोडिंग शुरू करने से पहले एक डिज़ाइन उपयोगकर्ता कहानी शेड्यूल करनी चाहिए ? क्या यह एक अच्छा अभ्यास माना जाता है, कम से कम उन विशेषताओं के लिए जो औसत से अधिक जटिल हैं?
EDIT - नोट
मैं इस तथ्य से अवगत हूं कि अच्छा डिजाइन कुछ निरपेक्ष नहीं होता है और इसका अपने आप में कोई मूल्य नहीं होता है लेकिन यह संदर्भ पर निर्भर करता है, और किसी को ऐसे डिजाइन का लक्ष्य बनाना चाहिए जो हाथ में समस्या के लिए पर्याप्त हो ।
उदाहरण के लिए, मुझे अच्छे डिज़ाइन के बारे में परवाह नहीं है (अगर मुझे कोई सरल घटक लागू करना है) जो कि (१) जल्द से जल्द तैयार होना चाहिए, (२) केवल एक बार उपयोग होने वाला है, (३) नहीं है सिस्टम के अन्य भागों (YAGNI) द्वारा उपयोग किया जाता है।
मैं अच्छे डिजाइन की परवाह करता हूं जब एक घटक (1) का उपयोग कई बार किया जाएगा और उत्पाद के कई अलग-अलग रिलीज में किया जाएगा, (2) समय के साथ बनाए रखा और बढ़ाया जाना चाहिए, (3) इसके आधार पर बहुत सारे अन्य घटक हैं ।
The only well-designed module I could produce recently I obtained by taking a different approach-- आपने अपने प्रश्न का उत्तर खुद ही दे दिया। आपको अभी भी कुछ अप-फ्रंट डिज़ाइन की आवश्यकता है; आप एक अच्छी डिजाइन की उम्मीद नहीं कर सकते हैं बस refactoring से व्यवस्थित रूप से विकसित करने के लिए। यह उस तरह से काम नहीं करता है।