औपचारिक वास्तुकला विनिर्देश कैसे चुस्त विकास के साथ फिट करता है - अगर बिलकुल?Agile विकास और वास्तुकला
मैं विशेष रूप से स्क्रम के बारे में सोच रहा हूं, जो आधिकारिक कलाकृतियों के बीच एक वास्तुकला का कोई उल्लेख नहीं करता है।
क्या आप आर्किटेक्चर को "गलती से" विकसित करते हैं (इसलिए बोलने के लिए), क्या आप इसे अनौपचारिक रूप से कल्पना करते हैं, या अपने पहले उत्पाद बैकलॉग को इकट्ठा करने से पहले 4 + 1 स्पेक अप की तरह कुछ करने के लिए जगह है?
Agile को अक्सर "केवल वही करना है जो आपको करने की ज़रूरत है, और अगर आप और चीजों की आवश्यकता हो तो आप बाद में प्रतिक्रिया कर सकते हैं"।
यह बदतर है। इसे "जल्दी से कुछ बोझ" के रूप में पढ़ा जा सकता है, और फिर भविष्य में और चीजों को करने के लिए इसे अपग्रेड करने का तरीका बताएं "। जो दर्द और तकनीकी ऋण की दुनिया का नेतृत्व करेगा।
किसी भी सिस्टम के लिए आपको एक डिज़ाइन की आवश्यकता है। छोटे/सरल प्रणालियों के लिए यह डिज़ाइन आपके सिर में हो सकता है, लेकिन सिस्टम के बारे में शुरू करने से पहले आपको अभी भी सोचना होगा, और यह कैसे करना है।
तो आईएमएचओ एक एग्इल दृष्टिकोण में डिज़ाइन को शामिल करने का सही तरीका है अब यह डिजाइन करना है कि आप जानते हैं कि सिस्टम को अंततः क्या करने की उम्मीद है, और व्यापक स्ट्रोक यह बताते हैं कि यह कैसे करेगा। एक लचीला पर्याप्त डिजाइन के साथ आओ कि आप किसी भी पुल जला नहीं है। लेकिन हर अखरोट और बोल्ट के लिए औपचारिक विस्तृत विनिर्देश लिखने में समय बर्बाद न करें। एक स्तर पर डिज़ाइन करें जहां आप जानते हैं कि एक उपप्रणाली कहां और कैसे फिट होगी, लेकिन इसे "ब्लैक बॉक्स" के रूप में माना जा सकता है, जिसे स्वयं ही कार्यान्वित करने की आवश्यकता होने पर ही डिज़ाइन किया जा सकता है।
Agile विकास को औपचारिक वास्तुकला को बाहर नहीं करना चाहिए - इसका मतलब यह है कि आपको केवल औपचारिक वास्तुकला को पर्याप्त रूप से डिजाइन करना चाहिए कि जब आप समाप्त हो जाते हैं तो सभी बिट्स अच्छी तरह से फिट हो जाएंगे, और आप उस डिज़ाइन के छोटे विवरण निकाल देंगे केवल वैसे ही जब उनकी आवश्यकता होती है। कभी-कभी इसका मतलब है कि आपको अभी भी काफी विस्तृत डिजाइन की आवश्यकता है।
आपके दायरे पर निर्भर करता है। दिया जा सकता है, हरा क्षेत्र हो सकता है। बस समय में बस पर्याप्त वास्तुकला। आपको अपने पहले परीक्षण लिखने में सक्षम होने के लिए कुछ चाहिए, निरंतर एकीकरण करें।
यह एक दस्तावेज है, तो इसे किसकी आवश्यकता होगी, और क्या करना है?
स्क्रम मुख्य रूप से एक परियोजना प्रबंधन तकनीक है, यही कारण है कि यह वास्तुकला का उल्लेख नहीं करता है।
जितना संभव हो आर्किटेक्चर को वृद्धिशील रूप से परिभाषित किया गया है। परत द्वारा परत की बजाय अंत-अंत-अंत में कार्यान्वयन उस संबंध में मदद करता है: यह प्रत्येक परत में एक भाग को लागू करने की ओर जाता है।
आर्किटेक्चरल फैसले को वापस करना मुश्किल हो सकता है, इसलिए जब आपको सिस्टम और ग्राहकों की जरूरत होती है, तो उन्हें अंतिम जिम्मेदार पल में अच्छा और लेना होगा।
औपचारिक विनिर्देश के लिए कोई मजबूत आवश्यकता नहीं है।
Agile आर्किटेक्चर पर जितना जोर देना चाहिए उतना जोर नहीं देता है। यह इस संभावना को कम करता है कि सॉफ्टवेयर भविष्य में उपयोग योग्य होगा। सिंहासन पद्धति का खेल Agile के फायदे और सीमाओं से सीखता है; यह एक सॉफ्टवेयर बनाता है जो अधिक 'भविष्य-सबूत' और स्केल करने योग्य है। डिजिटल पशु ने इस पद्धति को स्थापित करने के लिए इस लेख को लिखा था। http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/
ऊपर दिए गए गुणवत्ता के उत्तर के अतिरिक्त: अपनी डिज़ाइन को आवश्यकताओं की परिभाषा बनाएं क्योंकि उपयोगकर्ता उन्हें देखेगा। यह उपयोगकर्ता पर ध्यान केंद्रित करते समय डोमेन मॉडल पर विचार करता है और अंत में उपयोगकर्ता इंटरफ़ेस (जो कि किसी भी सॉफ्टवेयर प्रोजेक्ट में सर्वोपरि होना चाहिए)। –