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