कार्यात्मक आवश्यकताओं के लिए उपयोगकर्ता कहानियां

Question

चूंकि हम एक छोटी कंपनी हैं, मैं एक प्रोजेक्ट मैनेजर और डेवलपर दोनों के रूप में काम करता हूं। क्लाइंट के लिए बनाए गए विनिर्देशों में प्रोजेक्ट को परिभाषित करने और परिभाषित करने के लिए उपयोग किए जाने वाले कई तत्व होते हैं, जिसमें किसी भी अन्य तत्वों के साथ उपयोगकर्ता कहानियां शामिल हैं जिन्हें मुझे प्रोजेक्ट को परिभाषित करने के लिए शामिल करने की आवश्यकता है (जैसे वायरफ्रेम, उपयोगकर्ताफ्लो, साइटमैप इत्यादि) क्लाइंट को परिभाषित करने के लिए।

यदि कोई कार्यात्मक विनिर्देश "वर्णन करता है कि कोई उत्पाद पूरी तरह से उपयोगकर्ता के परिप्रेक्ष्य से कैसे काम करेगा। यह परवाह नहीं करता कि चीज कैसे लागू की जाती है। यह सुविधाओं के बारे में बात करता है। " फिर किसी को वेबसाइट के लिए कार्यात्मक विनिर्देश परिभाषित करने के लिए उपयोगकर्ता कहानियों का उपयोग करने में कोई समस्या दिखाई देती है? क्या कोई वास्तव में इस तरह कार्यात्मक विनिर्देशों को करता है?

वास्तव में मैं अपने खेल को थोड़ा सा करने की कोशिश कर रहा हूं, और सोच रहा हूं कि यह दृष्टिकोण उन बड़े ग्राहकों के लिए काम करेगा जो शायद एक कार्यात्मक विनिर्देशन के बारे में अधिक कड़े विचार हैं, जिससे औपचारिक दृष्टिकोण की आवश्यकता हो सकती है। निश्चित रूप से इस समय हमारे ग्राहक दस्तावेज़ीकरण के उत्पादन की हमारी विधि को अच्छी तरह से प्रतिक्रिया देते हैं।

मुझे यह जानने में दिलचस्पी है कि परियोजना प्रबंधन पेशेवर जो लोग इस बारे में सोचते हैं।

Answer 1

मैं कुछ अन्य लोगों के साथ क्या बाधाओं में हूं।

सबसे पहले मैं सहमत हूं - कहानियां कार्यात्मक आवश्यकताओं को बताने का एक शानदार तरीका है। मेरे पैसे के लिए वे वास्तव में उन उपयोगकर्ताओं को वास्तव में संचार करने की सर्वोत्तम तरीकों में से एक हैं, जो अंत में उपयोगकर्ताओं को वास्तव में ले जाएंगे। मैंने बहुत सारे चश्मे देखे हैं जो कभी भी पढ़े बिना हस्ताक्षर किए जाते हैं।

एक बात जो मैं कहूंगा कि आप उन्हें जोड़ना चाहते हैं, वे गैर-कार्यात्मक आवश्यकताएं हैं - प्रदर्शन, सुरक्षा, डेटा वॉल्यूम्स, ऑडिट, संग्रह आदि को कवर करना। जबकि उन्हें कहानियों में शामिल किया जा सकता है, कभी-कभी वे बेहतर तरीके से कवर होते हैं जो सभी कहानियों को पार करते हैं।

चाहे यह बड़ी कंपनियों के लिए उपयुक्त है, यह वह जगह है जहां मैं असहमत हूं। मेरे अनुभव में (और मैंने शैल, अमेरिकन एक्सप्रेस, कुछ बहुराष्ट्रीय बैंकों और अन्य के लिए परियोजनाएं की हैं) वे अक्सर छोटी कंपनियों की तुलना में अधिक औपचारिक नहीं होते हैं, इसलिए वे कहानियों के साथ ठीक होंगे। हकीकत यह है कि एक बड़ी कंपनी में कोई उपयोगकर्ता कक्षा और अनुक्रम आरेखों को कहीं और पढ़ने की तुलना में बेहतर (या इच्छुक) नहीं है।

परियोजना के आकार और जटिलता के लिए अधिक विस्तृत आवश्यकताओं की आवश्यकता हो सकती है, लेकिन यह परियोजना का आकार है, न कि उस कंपनी का आकार जो महत्वपूर्ण है कि आप यह निर्धारित कर रहे हैं कि आप कैसे दस्तावेज़ की आवश्यकताएं हैं।

मेरे लिए सबसे अच्छी आवश्यकता दस्तावेज दस्तावेज है जो इसके दर्शकों के लिए अनुकूल है, और मेरे लिए उपयोगकर्ता कहानियां ज्यादातर समय सिर पर नाखून हिट करती हैं - वे काफी कम हैं और पर्याप्त स्पष्ट हैं कि जब वे उन्हें साइन करते हैं तो उनका मतलब है कुछ ऐसा इसलिए है क्योंकि उन्होंने उन्हें पढ़ और समझ लिया है (जैसा कि 100 पेज स्पेस के साइन ऑफ के विपरीत है, जिसका अर्थ है कि उन्होंने वास्तव में इसे पढ़ा नहीं है), लेकिन डेवलपर्स के लिए भी काम करने के लिए पर्याप्त है।

Answer 2

हां, आप अपनी कार्यात्मक आवश्यकता के लिए उपयोगकर्ता कहानियों का उपयोग कर सकते हैं। मैं इसे हर समय करता हूं, और सालों से रहा हूं। मेरी राय में, यह वास्तव में अच्छी तरह से काम करता है, और मैंने उपयोग की अन्य प्रणालियों से बेहतर है।

क्या यह दृष्टिकोण बड़े ग्राहकों के लिए काम करेगा? सकल सामान्यीकरण करने के लिए, नहीं। उनके पास कुछ सिस्टम होने जा रहे हैं जो आवश्यकताओं को परिभाषित करने के लिए उपयोग करते हैं, और संभवतः इसकी उपयोगकर्ता कहानियां नहीं हैं। यदि आप उपयोगकर्ता कहानियों के साथ आते हैं, तो वर्तमान प्रथाओं के साथ डिस्कनेक्ट होने जा रहा है, जिसे आपको काम करना होगा।

मैं बड़े संगठनों के साथ उपयोगकर्ता कहानियों का उपयोग करके सफल रहा हूं, लेकिन यह एक समेकित प्रयास करता है, जिसे दोनों पक्षों को प्रतिबद्ध करने की आवश्यकता होती है।

Answer 3

जो आप वर्णन कर रहे हैं वह उपयोग-परिदृश्य परिदृश्य हैं जो सुविधाओं को परिभाषित करते हैं, यह उपयोगिता परिप्रेक्ष्य से आवश्यक है और यह वही है जो क्लाइंट समझ जाएगा और सहमत होगा। स्क्रीन मैक अप और फ्लो आरेख निश्चित रूप से क्लाइंट और डेवलपर्स दोनों की सहायता करेंगे।

कार्यान्वयन विनिर्देश तो क्या वास्तविक निर्माण में शामिल किए जाने की आवश्यकता पर डेवलपर्स का निर्देश देने की आवश्यकता हो सकती है, इस की गहराई अपने डेवलपर्स क्षमताओं है कि घर वास्तुकला/ढांचे और तरीकों/सम्मेलनों के अपने ज्ञान में शामिल हैं द्वारा निर्धारित किया जाएगा और इसमें आवेदन के विभिन्न हिस्सों को प्रभावित करने के बारे में विशिष्टताएं शामिल हो सकती हैं।

हम छोटी टीमों (कभी-कभी एक या दो डेवलपर्स) में भी काम करते हैं और मानते हैं कि उपरोक्त सब कुछ इस उदाहरण में आवश्यक है।

बड़ी कंपनियों के साथ बड़ी कंपनियां मॉडलिंग सॉफ्टवेयर, यूएमएल आरेख और अन्य विस्तृत विनिर्देशों का उपयोग कर सकती हैं। जिस मामले में आप प्राथमिक डेवलपर हैं, आपको अभी भी अपना आवेदन तैयार करने का समय बिताना चाहिए, लेकिन यदि कोई भी डिज़ाइन की समीक्षा करने और सभी औपचारिकताओं पर जोर देने के लिए नहीं जा रहा है, तो आपका समय सॉफ्टवेयर को लागू करने में बेहतर खर्च है।