उपयोगकर्ता कहानियों और चुस्त विकास को परिभाषित करना
आधुनिक विकास प्रक्रियाओं का मूल सिद्धांत चुस्त विकास है । यह विकास पद्धति छोटे, काटने के आकार की उपयोगकर्ता कहानियों का उपयोग करने पर जोर देती है ताकि यह परिभाषित किया जा सके कि उपयोगकर्ता के दृष्टिकोण से एक प्रणाली क्या करती है, तकनीकी नहीं। एक उपयोगकर्ता परवाह करता है कि कोई उत्पाद तेज़, उपयोग में आसान है, और उनकी समस्या का समाधान करता है। उन्हें परवाह नहीं है कि यह 3-स्तरीय वास्तुकला का पालन करता है, मोंगो डीबी है, या यदि यह रेल या एएसपीनेट का उपयोग कर रहा है।
प्रयोक्ता कहानियां:
- समझने में आसान हैं, और कोई भी भाग ले सकता है
- बार-बार काम करें; उन्हें बार-बार बदला या संशोधित किया जा सकता है और किया जाना चाहिए
- डेवलपर्स, उपयोगकर्ताओं और व्यावसायिक विशेषज्ञों को समान लक्ष्यों और अपेक्षाओं के अनुसार संरेखित करें
- 400-पृष्ठ की आवश्यकता वाले दस्तावेज़ों की तुलना में पढ़ना बहुत आसान है
Storyboard That चुस्त उपयोगकर्ता कहानियों को बनाने के लिए एक आदर्श मंच प्रदान करता है और एक प्रारूप में बातचीत को चिंगारी देता है जो पाठ की दीवार की तुलना में बहुत कम कर है।
महाकाव्य
उपयोगकर्ता कहानियों के संदर्भ में, एक "महाकाव्य" केवल एक बहुत व्यापक कहानी है जिसे बाद में कई विशिष्ट उपयोगकर्ता कहानियों में विभाजित किया जाएगा। एक महाकाव्य के साथ शुरू करना सभी को एकल, उच्च-स्तरीय दृष्टि के साथ संरेखित करता है। महाकाव्य कहानी एक परियोजना को ऊपर से नीचे तक लंगर डालती है, और यदि महाकाव्य का निर्माण करने का कोई मतलब नहीं है, तो सहायक कार्य भी प्रयास की बर्बादी होने वाला है।
इस कहानी में, यह बहुत स्पष्ट है कि दीर्घकालिक दृष्टि क्या है और सफलता कैसी दिखनी चाहिए। एक अच्छी महाकाव्य कहानी में शामिल होना चाहिए:
- सेटिंग या प्रसंग
- अभिनेता या उपयोगकर्ता
- लक्ष्य और उद्देश्य
- गतिविधियां और घटनाएं
उपयोगकर्ताओं को परिभाषित करना
विशेष रूप से सॉफ्टवेयर डिजाइन करते समय, यह महत्वपूर्ण है कि उपयोगकर्ता कैसा होगा, इसका एक अच्छा दृष्टिकोण होना चाहिए। प्रत्येक उपयोगकर्ता इस दृष्टि से सटीक रूप से मेल नहीं खाएगा, और उपयोगकर्ता की कई श्रेणियां हो सकती हैं, लेकिन इन अलग-अलग दृश्यों को अभिव्यक्ति की आवश्यकता होती है। उपयोगकर्ताओं के बारे में सोचने से पहले अति-इंजीनियरिंग और अति-जटिलता से बचाव होता है, एक नए उत्पाद को सभी के लिए कुछ होने से रोकता है और किसी के लिए उपयोगी नहीं होता है।
एक कहानी बनाना
एक बार एक महाकाव्य स्थापित हो जाने और उपयोगकर्ताओं को परिभाषित करने के बाद, विशेष उपयोगकर्ता अनुभवों के बारे में छोटी, अधिक विशिष्ट कहानियों का निर्माण किया जा सकता है। नीचे दी गई कहानियां ऊपर उल्लिखित को दो आख्यानों में विभाजित करती हैं: एक ऑर्डर को देखना और किसी उत्पाद को फिर से ऑर्डर करना।
इन आख्यानों में तकनीकी जानकारी नहीं है; उपयोगकर्ताओं को परवाह नहीं है कि परिणाम कैसे प्राप्त किए जाते हैं, जब तक कि यह वांछित कार्य करता है। इसी तरह, UX को सामान्य रूप से दर्शाया गया है, ताकि नवाचार को दबाने या पथ को मजबूर करने से बचा जा सके। सामान्य तौर पर, कहानियां होनी चाहिए:
- छोटा - 10 दिनों से कम का काम
- मूल्यवान - एक बार पूरा हो जाने पर उन्हें कुछ उपयोगी प्रदान करना चाहिए
- अनुमान लगाने योग्य - बॉलपार्क बनाने में सक्षम यह अनुमान लगाने में कि कितना प्रयास शामिल है
एक आदेश देख रहे हैं
पुन: क्रमित करना
परीक्षण के लिए बातचीत और योजना
इन कहानियों में बातचीत और प्रश्न आमंत्रित होने चाहिए, जैसे:
- क्या ये हमारे महाकाव्य से मेल खाने के लिए सही कहानियां हैं?
- और कौन सी कहानियाँ बनानी चाहिए?
- क्या ये कहानियां हमारे उपयोगकर्ताओं के बारे में हमारे द्वारा ज्ञात जानकारी के अनुरूप हैं?
कई कहानियाँ बनाना पूरी तरह से उचित है; वास्तव में, इसे प्रोत्साहित किया जाना चाहिए। इनमें से कुछ कहानियों का उपयोग कभी नहीं किया जाएगा, लेकिन उनके द्वारा निर्धारित पथ को देखना महत्वपूर्ण है। कहानियों का यह संग्रह अतिरिक्त आवश्यकताओं को दूर करेगा और परीक्षण को प्रभावित करेगा।
कहानियों को इस बारे में चर्चा को उत्तेजित और सूचित करना चाहिए कि सॉफ़्टवेयर का परीक्षण कैसे किया जाएगा और किन व्यावसायिक नियमों को स्पष्ट रूप से परिभाषित करने की आवश्यकता है। उदाहरण के लिए:
- लुकअप कितनी तेजी से होना चाहिए?
- क्या पुन: आदेश देने की कोई समय सीमा है?
- यदि यह दूसरा पुन: क्रम है तो सिस्टम को क्या करना चाहिए? पांचवां?
- आपके पास कौन से परीक्षण और अनुवर्ती प्रश्न होंगे?
© 2024 - Clever Prototypes, LLC - सर्वाधिकार सुरक्षित।
StoryboardThat Clever Prototypes , LLC का एक ट्रेडमार्क है, और यूएस पेटेंट और ट्रेडमार्क कार्यालय में पंजीकृत है