आधुनिक विकास प्रक्रियाओं का एक मुख्य सिद्धांत फुर्तीली विकास है । यह विकास पद्धति छोटे, काटने के आकार की उपयोगकर्ता कहानियों का उपयोग करके यह निर्धारित करने के लिए जोर देती है कि एक प्रणाली एक उपयोगकर्ता के दृष्टिकोण से क्या करती है, तकनीकी नहीं। एक उपयोगकर्ता परवाह करता है कि क्या कोई उत्पाद तेज, उपयोग करने में आसान है, और उनकी समस्या को हल करता है। वे परवाह नहीं करते हैं यदि यह 3-स्तरीय वास्तुकला का अनुसरण करता है, तो Mongo DB है, या यदि यह रेल या Asp.net का उपयोग कर रहा है।
Storyboard That एक आदर्श मंच प्रदान करता है जो फुर्तीली उपयोगकर्ता कहानियों और स्पार्क वार्तालाप को एक प्रारूप में बनाता है जो पाठ की दीवार की तुलना में बहुत कम कर होता है।
उपयोगकर्ता कहानियों के संदर्भ में, एक "महाकाव्य" बस एक बहुत व्यापक कहानी है जिसे बाद में कई विशिष्ट उपयोगकर्ता कहानियों में तोड़ दिया जाएगा। एक महाकाव्य के साथ शुरू करके एक एकल, उच्च-स्तरीय दृष्टि के साथ सभी को संरेखित करता है। महाकाव्य कहानी ऊपर से नीचे एक परियोजना का लंगर डालती है, और अगर यह एक महाकाव्य का निर्माण करने के लिए समझ में नहीं आता है, तो सहायक काम भी प्रयास की बर्बादी होने वाला है।
इस कहानी में, यह बहुत स्पष्ट है कि दीर्घकालिक दृष्टि क्या है और सफलता किस तरह दिखनी चाहिए। एक अच्छी महाकाव्य कहानी में शामिल होना चाहिए:
विशेष रूप से सॉफ्टवेयर डिजाइन करते समय, उपयोगकर्ताओं की क्या पसंद होगी, इसकी अच्छी दृष्टि होना जरूरी है। प्रत्येक उपयोगकर्ता इस दृष्टि से बिल्कुल मेल नहीं खाएगा, और उपयोगकर्ता की कई श्रेणियां हो सकती हैं, लेकिन इन असतत विज़न को आर्टिक्यूलेशन की आवश्यकता होती है। ओवर-इंजीनियरिंग और ओवर-कॉम्प्लीकेशन के खिलाफ पहले गार्ड के बारे में सोचना, एक नए उत्पाद को सभी के लिए कुछ होने से रोकना और किसी के लिए उपयोगी नहीं होना।
एक बार एक महाकाव्य स्थापित होने के बाद और उपयोगकर्ताओं को परिभाषित किया गया है, विशेष उपयोगकर्ता के अनुभवों के बारे में छोटे, अधिक विशिष्ट कहानियों का निर्माण किया जा सकता है। नीचे दी गई कहानियाँ ऊपर उल्लिखित दो कथनों में उल्लिखित हैं: एक ऑर्डर को देख रही हैं और एक उत्पाद को फिर से ऑर्डर कर रही हैं।
इन आख्यानों में तकनीकी जानकारी नहीं है; उपयोगकर्ताओं को परवाह नहीं है कि परिणाम कैसे प्राप्त किए जाते हैं, इसलिए जब तक यह वांछित कार्य करता है। इसी तरह, UX को उदारता से दर्शाया गया है, ताकि स्टिफ़लिंग इनोवेशन या एक रास्ता मजबूर करने से बचा जा सके। सामान्य तौर पर, कहानियाँ होनी चाहिए:
इन कहानियों को बातचीत और प्रश्नों को आमंत्रित करना चाहिए, जैसे:
कई कहानियाँ बनाना पूरी तरह से उचित है; वास्तव में, इसे प्रोत्साहित किया जाना चाहिए। इनमें से कुछ कहानियों का उपयोग कभी नहीं किया जाएगा, लेकिन उनके द्वारा निर्धारित पथ को देखना महत्वपूर्ण है। कहानियों का यह संग्रह अतिरिक्त आवश्यकताओं और प्रभाव परीक्षण को प्रभावित करेगा।
कहानियों को उकसाना चाहिए और इस बात की चर्चा करनी चाहिए कि सॉफ्टवेयर का परीक्षण कैसे किया जाएगा और व्यावसायिक नियमों को स्पष्ट रूप से परिभाषित करने की आवश्यकता क्या है। उदाहरण के लिए:
Storyboard That महान उपयोगकर्ता कहानियां बनाने के लिए एक शक्तिशाली उपकरण प्रदान करता है, लेकिन यह परियोजना प्रबंधन के लिए एक रूपरेखा के रूप में अकेले खड़े होने के लिए नहीं है। इस विषय पर हमारी कुछ पसंदीदा पुस्तकें यहाँ दी गई हैं।
हमारे बाकी लेख और संसाधनों की जांच करें!
