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