क्या कहानियों द्वारा आवश्यकताओं के विनिर्देशों को लिखना एक अच्छा विचार है?

Question

हम इस समय अपनी वर्तमान परियोजना में चुस्त तरीकों का उपयोग कर रहे हैं, और हमारे पास इन जैसी कहानियों के ढेर हैं:

• एक सहायक के रूप में, मैं ग्राहक को धनवापसी का भुगतान करना चाहता हूं ताकि जब वे अनुरोध करें तो उन्हें कुछ पैसा मिल सके

• एक ग्राहक के रूप में, मैं खरीदारी के लिए भुगतान करना चाहता हूं ताकि मैं अपना आइटम प्राप्त कर सकूं।

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

अब समस्या यह है कि क्योंकि बहुत सारी कहानियां हैं, यह तुरंत स्पष्ट नहीं है, सिस्टम के किसी भी हिस्से के लिए जो कहानियां इससे संबंधित हैं।

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

क्या कहानियों को लिखना एक अच्छा विचार है? क्या हमने कहानियों को गलत तरीके से लिखा है?

Comments

आप माइक कोहन पढ़ना चाहते हैं: ( amazon.com/User-Stories-Applied-Development-ebook/dp/B000SEFH1A )

— मैथ्यू फ्लिन

Answer 1

यह विवादास्पद हो सकता है लेकिन यहाँ यह हो जाता है!

---

हमने एक वास्तविक समय प्रणाली पर काम किया है, जहां मेरे अतीत के मालिकों में से एक ने सुझाव दिया है कि चलो AGILE करें! वास्तव में उस पर प्रबंधन को जीतना आसान था; हालाँकि, यह कहा से आसान था।

कहानियों की अवधारणा अच्छी है - लेकिन बहुत आगे रहने के लिए, यह काफी अस्पष्ट है। क्या एक कहानी है, वास्तव में? असली मुद्दा यह है कि कहानियों का उपयोग करना alone(और उपयोग मामलों के लिए भी उतना ही है) के कई मुद्दे हैं - निम्नानुसार हैं:

1. आवश्यकताएँ संदर्भ से बाहर नहीं हो सकती हैं (जब तक कि आप कई बार सकल पुनरावृत्ति नहीं कर रहे हैं)। मान्यताओं, पृष्ठभूमि ज्ञान और अन्य आवश्यकताएं हैं जो एक दी गई आवश्यकता से जुड़ी हुई हैं; वे केवल एक संदर्भ के तहत और केवल एक विशिष्ट आदेश के तहत समझ में आते हैं। सबसे महत्वपूर्ण एक को लागू करना सबसे पहले व्यावसायिक समझ में आता है, लेकिन जब आप उन्हें कम से कम फाइल करते हैं - जब आप उन्हें इकट्ठा करते हैं तो शुरुआत से ही पूरा संदर्भ रखें। आवश्यकता शब्द अपने आप में जटिल है और वास्तव में उपयोग-केस / कहानियों तक सीमित नहीं है। वास्तव में कहानियां कार्रवाई योग्य हैं, लेकिन फिर ऐसी आवश्यकताएं हैं जो कार्रवाई योग्य नहीं हो सकती हैं, जैसे कि प्रदर्शन, बाधाओं को पूरा किया जाना, व्यवसाय प्रबंधन आदि।

2. आवश्यकताओं को आकार में उपयुक्त होने की आवश्यकता है और मात्रात्मक तरीके से आपको कभी भी 1 से अधिक बड़ी कहानी की आवश्यकता नहीं हो सकती है! क्या वास्तव में 1 कहानी है?

   • क्या यह एक पूर्ण विस्तृत परिदृश्य है? (उदाहरण के लिए एक कहानी जब एटीएम लेनदेन को अस्वीकार करता है)
   • क्या यह उपयोगकर्ता द्वारा किए जाने वाले कार्य का एक सेट है? (उदाहरण वापसी के बारे में पूरी कहानी)
   • या यह यूजर इंटरफेस में एक स्क्रीन है? (उदाहरण के लिए एक पूर्ण कहानी के रूप में निकासी स्क्रीन)।
   • कहानियों के साथ वास्तव में बहुत कुरकुरा व्यापार नियमों को कैसे निर्धारित किया जाए? ईमानदारी से, यह उपरोक्त में से कोई भी हो सकता है। मुद्दा यह है कि आप कितने सीमित और दानेदार हैं, यह एक व्यक्तिगत शैली है। अगर यह काम करता है तो यह ठीक है;

3. डोमेन ज्ञान वास्तव में आवश्यकता है! एक साधारण उदाहरण, एक वास्तुकार जोग्लास, स्टील और लकड़ी के विभिन्न गुणों को जानता है । यह ज्ञान भवन के प्रति आवश्यकता दस्तावेज का हिस्सा नहीं है! उसी तरह, यदि आप एक बैंकिंग सॉफ्टवेयर लिख रहे हैं - बैंकिंग के बारे में अवधारणाओं के पूरे समूह हैं। आवश्यकता के रूप में उन्हें बताते हुए,यह स्वयं को गैर-ट्रैफ़िक बनाता है क्योंकि यह आपको यह नहीं बताता है कि दुनिया के काम करने के तरीके के विपरीत सॉफ़्टवेयर को क्या करना चाहिए । क्या कहानी में ऐसे डोमेन पेचीदगियां शामिल हैं? या क्या यह इसे बाहर करता है?

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

तो आपके सवाल पर आ रहा हूँ:

क्या कहानियों को लिखना एक अच्छा विचार है? क्या हमने कहानियों को गलत तरीके से लिखा है?

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

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

Comments

अगले-टू-लास्ट पैराग्राफ को सीधे चुस्त द्वारा संबोधित किया जाता है: ग्राहक / उत्पाद मालिक टीम के साथ काम कर रहे एसडब्ल्यू को वितरित करने के लिए काम कर रहा है।

— लादिस्लाव Mrnka

+1, यह बताने के लिए कि यह कैसा है। "कहानियों की अवधारणा अच्छी है - लेकिन बहुत आगे रहने के लिए, यह काफी अस्पष्ट है।"

— NoChance

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

— लादिस्लाव मृंका

कॉकबर्न की पुस्तक उपयोग के मामलों पर विहित संदर्भ है, इसलिए यदि यह एकमात्र विश्वसनीय स्रोत है, तो कम से कम यह स्रोत है। उपयोगकर्ता की कहानियाँ के लिए, देखें माइक कोहन के उपयोगकर्ता की कहानियाँ एप्लाइड ( amazon.com/User-Stories-Applied-Development-ebook/dp/B000SEFH1A )

— मैथ्यू फ्लिन

Answer 2

> Writing specs by stories? a good idea?

हाँ यदि आप अपनी कहानियों की अन्योन्याश्रितियों और प्राथमिकताओं का प्रबंधन कर सकते हैं।

यहाँ कहानी के नक्शे के बारे में एक लेख है जो आपको कई उपयोगकर्ता सूची बनाने और मंगाने में मदद कर सकता है।

Answer 3

इस उत्तर को लिखते समय, मुझे एहसास हुआ कि यह परीक्षण के बारे में नहीं है, यह प्रलेखन के बारे में है। आपको पहले चुस्त घोषणापत्र पढ़ना चाहिए :

[हम मूल्य] व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर

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

क्या कहानियों को लिखना एक अच्छा विचार है?

हाँ, imho, यह है। इसे "व्यवहार चालित विकास" या "उदाहरण के द्वारा विनिर्देशन" कहा जाता है। रूबी में एक महान उपकरण ककड़ी है जो उस में मदद करता है।

अब समस्या यह है कि क्योंकि बहुत सारी कहानियां हैं, यह तुरंत स्पष्ट नहीं है, सिस्टम के किसी भी हिस्से के लिए जो कहानियां इससे संबंधित हैं।

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

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

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

यह असामान्य नहीं है कि एक महत्वपूर्ण मॉड्यूल में एक छोटे से बदलाव से सैकड़ों एकीकरण परीक्षण टूट जाते हैं। यहीं से यूनिट टेस्टिंग स्टेप्स में आती है।

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

क्या हमने कहानियों को गलत तरीके से लिखा है?

मुझे लगता है, आपको बस अपनी कहानियों को उपयोगकर्ता द्वारा महाकाव्यों में व्यवस्थित करने की आवश्यकता है, जैसे "ग्राहक", "सहायक", या सुविधाओं / स्क्रीन / वर्कफ़्लोज़ ("खरीद", "वापसी") द्वारा।

और फिर, विनिर्देश परीक्षण इकाई परीक्षण के लिए एक प्रतिस्थापन नहीं हैं। अधिक पढ़ें

Answer 4

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

कहानियों द्वारा चश्मा लिखना? एक अच्छा विचार?

चंचल इसे मना नहीं करता है। चंचलता में आप अधिकतम गति में अधिकतम व्यापार मूल्य देने के लिए जो कुछ भी कर सकते हैं, वह कर सकते हैं। इसलिए यदि लेखन चश्मा कुछ ऐसा है जिसे आपको अधिक व्यावसायिक मूल्य देने की आवश्यकता है तो ऐसा करना बिल्कुल ठीक है।

आपका उदाहरण दो उपयोगकर्ता कहानियां दिखाता है। वे शायद आपके व्यवसाय तर्क में किसी तरह से संबंधित हैं लेकिन यह बहुत ही सामान्य परिदृश्य है।

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

फुर्तीली छोटी से मध्यम परियोजनाओं के लिए सबसे अच्छा काम करता है छोटी टीम के साथ पूरे आर्किटेक्चर को टीम में साझा किए गए मौन ज्ञान के रूप में रखा जाता है। चलना योजना के दौरान आप अपनी चुनी हुई कहानियों के माध्यम से जाएंगे, वर्तमान कार्यान्वयन पर प्रभाव पर चर्चा करेंगे और कहानी को पूरा करने के लिए आवश्यक कुछ कार्य लिखेंगे। इस तरह के मामले में असली दस्तावेज स्वचालित स्वीकृति और एकीकरण / यूनिट परीक्षण रखने वाला टेस्ट सूट होगा। एक बार जब आपका SW या टीम बढ़ता है, तो मौन ज्ञान आंशिक रूप से कुछ प्रलेखन के लिए स्थानांतरित करना होगा।

Answer 5

अब यह वह जगह है जहाँ अमूर्त एक प्रमुख भूमिका निभाता है। आपको प्रासंगिक परिप्रेक्ष्य के संबंध में कहानियों को देखना होगा। बयानों में संज्ञाओं और क्रियाओं को इकट्ठा करें और उनकी पुष्टि करें। आप अपने मॉडल को व्यक्तिगत मान्यताओं पर आधारित नहीं कर सकते । विस्तार पर भी ध्यान दें।

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