2011-08-02 39 views
6

मुझे काम पर एक मुद्दा है जहां हमने विकास टीम के रूप में स्क्रम का उपयोग करना शुरू कर दिया है। मुझे उपयोगकर्ता कहानियों के साथ कुछ परेशानी हो रही है जिसमें हमें प्रदान किया गया है कि वे फिट नहीं लग रहे हैं कि उपयोगकर्ता की कहानी क्या है इसकी मेरी व्याख्या क्या है।उपयोगकर्ता की कहानी क्या है और क्या नहीं है?

  • एक वेबसाइट उपयोगकर्ता मैं इतना है कि मैं रजिस्टर और अपने विवरण की आपूर्ति कर सकते पंजीकरण पृष्ठ करना चाहते हैं के रूप में:

    यहां उपयोगकर्ता कहानियों हम इस स्प्रिंट के लिए दिया गया है की एक वास्तविक उदाहरण है।

  • एक व्यापारी उपयोगकर्ता मैं इतना है कि मैं सही जानकारी उपलब्ध कराने के पंजीकरण फार्म पर सत्यापन करना चाहते हैं के रूप में।

  • एक व्यापारी उपयोगकर्ता मैं समर्थन जब इतने दर्ज की है कि आवश्यक विवरण के बारे में है कि मैं किसी भी प्रश्न उत्तर दिया जाता है चाहता हूँ के रूप में (यह मान्यता फार्म से संबंधित है)। (यह फार्म पर उपकरण सुझावों से संबंधित है)

मेरे मन में पहले एक उपयोगकर्ता कहानी है। दूसरा दो पहली उपयोगकर्ता कहानी की पारंपरिक आवश्यकताओं की प्रतीत होता है और मुझे लगता है कि उन्हें शायद पहली उपयोगकर्ता कहानी के स्वीकृति मानदंड होना चाहिए।

अन्य भ्रम मैं पिछले स्प्रिंट हम था में है:

  • एक उपयोगकर्ता मैं वेबसाइट पर लॉगिन करने के लिए सक्षम होना चाहते हैं के रूप में।

  • एक उपयोगकर्ता के रूप में मैं एक उपयोगकर्ता नाम के साथ वेबसाइट पर लॉगिन करने में सक्षम होना चाहता हूँ।

उत्पाद मालिक का कहना है कि इस दो अलग-अलग उपयोगकर्ता कहानियों जो अलग से जांच की आवश्यकता होती है।

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

यह मुझे लगता है कि वर्तमान में हम उपयोगकर्ता को उपयोगकर्ता की कहानी के रूप में जो कुछ भी चाहते हैं उसे बनाने और उन्हें उचित उपयोगकर्ता कहानियों में आवश्यकताओं से फ़िल्टर करने में मदद नहीं कर रहे हैं। मुझे बताया गया है कि हमें रिपोर्टिंग के लिए उन्हें अलग रखने की जरूरत है ताकि हम उपयोगकर्ता द्वारा अनुरोध किए गए सब कुछ का लॉग रख सकें।

+0

उपयोगकर्ता कहानियों की परिभाषाएं आपको ऑनलाइन मिली हैं? बहुत सारा है। कृपया परिभाषाओं के कुछ लिंक प्रदान करें जो आप (और आपकी टीम) "अच्छी" परिभाषाओं पर विचार करते हैं। हम आपकी पृष्ठभूमि या जो आपने पहले ही पढ़ा है उसे नहीं जानते हैं। स्पष्ट rehashing में कोई बात नहीं है। कृपया उन संसाधनों के कुछ लिंक प्रदान करें जिन्हें आप पहले से उपयोग कर रहे हैं। –

+0

मेरे लिए मुख्य स्रोतों में से एक रहा है: http://www.scrumalliance.org/articles/169-new-to-user-stories - मुख्य प्रश्न यह है कि हम अभी शुरू कर रहे हैं, क्या ये अच्छी उपयोगकर्ता कहानियां हैं? – Wiredness

उत्तर

10

उपयोगकर्ता की कहानियां ग्राहक मूल्य पर केंद्रित हैं। ... वास्तविक कार्य किया जा रहा है उपयोगकर्ता की कहानी के चारों ओर घूमने वाले सहयोग के माध्यम से सिस्टम विकास प्रगति के रूप में fleshed है। ... दायरे को सीमित करने के लिए, उपयोगकर्ता कहानियों में सहयोगी रूप से विकसित स्वीकृति मानदंड हैं जो परिभाषित करते हैं कि उपयोगकर्ता की कहानी हितधारक की अपेक्षाओं को पूरा करती है। टेस्ट केस अक्सर कोड (परीक्षण संचालित विकास के साथ) के रूप में विकसित किए जाते हैं या कोड के रूप में प्रलेखित किए जाते हैं।

[जोर मेरा।]

एक उपयोगकर्ता के रूप में मैं वेबसाइट पर लॉगिन करने में सक्षम होना चाहता हूं।

एक उपयोगकर्ता के रूप में मैं उपयोगकर्ता नाम के साथ वेबसाइट पर लॉगिन करने में सक्षम होना चाहता हूं।

चूंकि कोई भी ग्राहक मूल्य प्रदान करता है, न तो उपयोगकर्ता कहानियां हैं।

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

लॉगिन, विशेष रूप से, शून्य ग्राहक मान है। यह एक रोडब्लॉक है कि आईटी ग्राहकों के बीच सुधार करता है और निर्णय लेने और कार्यों को करने के लिए आवश्यक मूल्यवान जानकारी। यह एक सुरक्षा तंत्र है, और ज्यादातर लोगों को वास्तव में सुरक्षा पसंद नहीं है। आईटी द्वारा ग्राहक पर सुरक्षा लगाई गई है। सबसे लोकप्रिय पासवर्ड (आईआईआरसी) "aaaaaaaa" है। क्यूं कर? ग्राहकों को सुरक्षा पसंद नहीं है।

विस्तृत, माइक्रोस्कोपिक लॉगिन उपयोगकर्ता कहानियां ग्राहक को वास्तविक मूल्य देखने में विफल होने का एक लक्षण हो सकती हैं।


यह सिर्फ है कि हम वर्तमान सिर्फ दे रहे हैं उपयोगकर्ताओं को बनाने के लिए जो भी वे एक उपयोगकर्ता कहानी

अच्छा के रूप में चाहते हैं मुझे लगता है।

मुझे बताया गया है कि हमें रिपोर्टिंग के लिए उन्हें अलग रखने की आवश्यकता है ताकि हम उपयोगकर्ता अनुरोधों के सब कुछ लॉग रख सकें।

वास्तव में एक खराब योजना नहीं है।

मुद्दा "सामान को समझने के लिए कहा गया है" जिसे "निर्माण कर सकते हैं" से अलग करना है। यह बहुत महत्वपूर्ण है कि उपयोगकर्ताओं को वह बकवास कहना चाहें जो वे कहना चाहते हैं। उन्हें रैमबल देने के लिए एक अच्छी बात है।

समय-समय पर (प्रत्येक स्प्रिंट से पहले) आप बकवास को प्राथमिकता देंगे, उपयोगकर्ता ने कुछ चीजों में कहा था कि (1) आप स्प्रिंट के दौरान निर्माण करने में सक्षम हो सकते हैं, और (2) संभवतः सबसे महत्वपूर्ण और नाटकीय उपयोगकर्ता मूल्य बना सकते हैं सर्जन करना। कुछ कहानियों को नजरअंदाज कर दिया जाएगा। कुछ कम प्राथमिकता होगी। कुछ संयुक्त हो जाएंगे और कुछ विभाजित होंगे। कुछ चीजें जो उपयोगकर्ता ने कहा वह विरोधाभासी होगा। कुछ सीधे झूठ बोलेंगे। कुछ अपूर्ण होंगे। यह सब अच्छा है। यह सिर्फ बकवास है कि उपयोगकर्ता कहने के लिए हुआ था। सीधे देवताओं के मुंह से दैवीय निर्देश नहीं।

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

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

+0

यह मुझे बहुत समझ में आता है। धन्यवाद। – Wiredness

+11

मुझे लगता है कि कहानियां लॉगिन करने का दावा ग्राहक मूल्य नहीं बना रहा है, हालांकि यह बहुत कमजोर है, हालांकि - निश्चित रूप से, अगर कहानी "मेरी डेटा को मेरी सहमति के बिना अन्य उपयोगकर्ताओं द्वारा देखा या छेड़छाड़ नहीं की जा सकती" के आधार पर दोहराया गया था, या "संघीय सरकार एचआईपीएए नियमों के अनुपालन के लिए हमारे ग्राहकों को ठीक नहीं करेगी", ग्राहक मूल्य स्पष्ट हो जाता है। संभवतः वह बिंदु जो आप वास्तव में बनाना चाहते थे वह था कि लॉगिन कहानियों को ग्राहक मूल्य पर जोर देने के लिए फिर से लिखा जाना चाहिए ... नहीं कि सुरक्षा कहानियां आईटी द्वारा स्थापित रोडब्लॉक हैं। –