एज के मामलों के लिए स्वीकृति मानदंड

Question

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

अपनी रक्षा में मैं कहानी के लिए उसके डिज़ाइन को तब तक नहीं जानता जब तक वह इसे लागू नहीं करता, इसलिए सभी संभावनाओं के माध्यम से पुनरावृति करना मुश्किल होगा (क्या यह डीबी या गुण फ़ाइल में कॉन्फ़िगर होगा?)। सादगी के लिए, हम कहते हैं कि हमारे पास एक कैलकुलेटर ऐप में विभाजन जोड़ने के लिए एक कहानी है। आदर्श एससीआरयूएम की दुनिया में, क्या यह स्वीकार्य मानदंड के लिए "शून्य परिदृश्य द्वारा संभाल विभाजन" को जोड़ने के लिए मुझ पर अवलंबित होगा या क्या उसे उन मामलों के माध्यम से काम करना चाहिए क्योंकि वह विकसित करता है ताकि ऐप 5/0 पर निहित न हो? स्पष्ट होने के लिए, इस मामले में मैं यह स्वीकार नहीं करूंगा कि ऐप 5/0 पर मुश्किल से क्रैश हुआ है, लेकिन मैं पास होगा अगर यह लॉग करता है, DIV0 को प्रिंट करता है, या किसी अन्य तरीके से त्रुटि को हैंडल करता है ... बस इतना लंबा जब तक यह नहीं होता है। 'दुर्घटना नहीं।

Comments

कहानी को किनारे करने के लिए आप ध्यान क्यों नहीं देते?

— जेफ ओ

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

— rszalski

Answer 1

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

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

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

Answer 2

टीम को "मेरी नौकरी नहीं, मेरी जिम्मेदारी नहीं" प्रकार के रवैये / मंत्र के विरोध में एक साथ काम करने की आवश्यकता है।

स्वीकृति मानदंड के रूप में आता है:

• व्यापार स्वीकृति
• गुणवत्ता आश्वासन स्वीकृति

आमतौर पर व्यावसायिक स्वीकृति आमतौर पर सवाल का जवाब दे रही है:

• क्या जो सुविधा लागू की गई है, मैं वही करना चाहता हूं जो मैं करना चाहता हूं?

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

यह उम्मीद की जाती है कि व्यावसायिक आवश्यकता को एक पुनरावृत्ति से पहले परिभाषित किया जाना चाहिए ताकि गुणवत्ता आश्वासन गैर-व्यावसायिक आवश्यकताओं पर किसी भी तकनीकी को विकसित कर सके। गुणवत्ता आश्वासन को विनाशकारी मामलों के साथ-साथ किनारे के मामलों को भी विकसित करना चाहिए।

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

एक बार जब व्यवसाय और गुणवत्ता आश्वासन टीम के सदस्य कहानी पर हस्ताक्षर कर देते हैं तो कहानी अंतिम स्वीकृति तक पहुँच जाती है। यह व्यापार स्वीकृति और गुणवत्ता आश्वासन स्वीकृति दोनों के लिए पुनरावृत्ति के दौरान होना चाहिए। यह किया गया (DoD) की परिभाषा है जो अतिरिक्त कहानी के काम को इंगित करता है।

किसी भी नए निष्कर्ष को दोष या अतिरिक्त कहानी स्पाइक्स के रूप में लॉग किया जा सकता है। एक आदर्श दुनिया में यह कभी नहीं होगा, लेकिन वास्तव में आमतौर पर "खोज" की कुछ राशि होती है जो एक फीचर / कहानी पर काम करते समय होती है। यह स्वाभाविक है।

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

क्यूए:

"अरे, डेवलपर हमें इस विशेष परिदृश्य को संभालना चाहिए। मुझे पता चला है कि अगर मैं इस डेटा को इनपुट करता हूं तो मुझे एक त्रुटि मिलती है।"

देव:

"यह किसी भी आवश्यकता में कवर नहीं किया गया था, लेकिन हम इसे कवर करने के लिए कुछ अतिरिक्त कार्यक्षमता जोड़ सकते हैं। ठीक है, हे बिजनेस पर्सन, आप इस मामले के लिए आवेदन कैसे करना चाहेंगे?"

व्यापार:

"चलो हमारे मानक त्रुटि संदेश दिखाते हैं और उपयोगकर्ता को इस परिदृश्य के लिए फिर से प्रयास करने दें। फिर अतिरिक्त प्रयास कितना होगा?"

देव:

"यह केवल एक अतिरिक्त घंटे या दो के लिए आसान होगा। मैं इस पुनरावृत्ति के लिए प्रतिबद्ध कर सकता हूं। क्यूए कृपया इस परिदृश्य के लिए अपनी स्वीकृति मानदंडों को अपडेट करें, हमें इसके लिए एक अतिरिक्त कहानी की आवश्यकता नहीं है। धन्यवाद!"

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

Answer 3

सॉफ्टवेयर लिखना जो गलत या अस्पष्ट इनपुट के सामने एक मजबूत तरीके से व्यवहार करता है, सॉफ्टवेयर डेवलपर की नौकरी का एक अनिवार्य हिस्सा है।

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

स्वीकृति परीक्षण वैसे भी किसी भी आवश्यकता दस्तावेज़ का एक महत्वपूर्ण हिस्सा होना चाहिए। यदि कोई आवश्यकता भी स्वीकृति के लिए अपना मापदंड नहीं बताती है, तो यह वास्तव में आवश्यकता नहीं है; यह एक इच्छा है।

Comments

आवश्यकताओं का अनुमान लगाना सॉफ्टवेयर डेवलपर नौकरियों का हिस्सा नहीं है। एक डेवलपर को कैसे पता होना चाहिए कि गलत या अस्पष्ट इनपुट क्या है, अगर यह निर्दिष्ट नहीं है? और ऐसा लगता है कि ऊपर मामला है।

— B:59овиЈ

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

— रॉबर्ट हार्वे

स्वीकृति परीक्षण आवश्यकताओं से आ रहे हैं। यदि वे मौजूद नहीं हैं ...

— Bћовић

मेरे उत्तर में अंतिम पैराग्राफ देखें।

— रॉबर्ट हार्वे

... तो यह एक इच्छा है। मेरे पसंदीदा सॉफ्टवेयर बोलचाल में से एक।

— रबरडक

Answer 4

यहाँ क्या हुआ है कि आप मूल्य की खोज की है । इनपुट वैल्यू के बारे में नहीं सोचा गया था कि कहानी (और स्वीकृति मानदंड) कब लिखी गई थी या कोड कब लिखा गया था। यदि यह स्वीकृति मानदंडों का हिस्सा नहीं है, तो आपके पास कहानी को अस्वीकार करने का कोई आधार नहीं है।

हम अपनी टीम पर क्या करेंगे:

1. अपेक्षित और वास्तविक व्यवहार का विवरण दें।
2. स्वीकृति मानदंड अपडेट करें ताकि नई मिली आवश्यकता का दस्तावेजीकरण हो।
3. अगले पुनरावृत्ति में अन्य सभी स्टोरीज़ और बग्स के साथ बग को प्राथमिकता दें।

यहाँ लाभ यह है कि आप यह विचार करने के लिए मजबूर हैं कि इस बग को ठीक करना या नहीं करना अगली सबसे महत्वपूर्ण बात है। इसे ठीक करना महत्वपूर्ण हो सकता है या नहीं, लेकिन यह महत्वपूर्ण है कि इसका मूल्य माना जाए।

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

Answer 5

कुछ अवलोकन:

... जब मैं उनकी कहानियों को खारिज करता हूं

मैं आपकी कार्य संस्कृति या प्रक्रिया को नहीं जानता, लेकिन मेरे लिए एक कहानी को खारिज करना एक गंभीर कदम है। अगर मैं देव होता, तो मैं इस पर भी जोर देता, क्योंकि यह एक रिकॉर्ड की गई कार्रवाई है जो मुझे और टीम पर बुरी तरह से दर्शाती है।

वह कहता है कि जब से मैं किनारे के मामलों को निर्दिष्ट नहीं करता, वह अनुचित है।

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

मैं कहानी के लिए उसके डिजाइन को नहीं जानता, जब तक वह इसे लागू नहीं करता

आपको डिज़ाइन को जानना नहीं चाहिए। प्रारंभिक शिक्षित अनुमान लगाने के लिए डिजाइन को जानना मददगार हो सकता है, क्योंकि बैकलॉग प्रबंधन के लिए कहानियां आसान या कठिन हैं। लेकिन जब आप कहानियां लिखते हैं तो डेवलपर को अपने डिजाइन में फंसाने से बचें। जब आप केवल PO के लिए एक ध्वनि-सक्रिय कीबोर्ड होते हैं, तो इसका सारा मज़ा बेकार हो जाता है।

---

ऐसा लगता है कि आप लोगों को प्रक्रिया सुधार पर काम करना चाहिए और कुछ टीम बिल्डिंग करनी चाहिए। कुछ चीजें जो मैं प्रक्रिया के लिए सुझा सकता हूं:

• सुझाव दें कि देव कहानी में कवर किए गए एज मामलों को कवर करने के लिए समय शामिल करते हैं। हेक, इसे प्रत्येक उपयोगकर्ता कहानी का हिस्सा बनाएं। यह शुरू किए गए 0 नए बग के लक्ष्य के माध्यम से आसानी से बचाव योग्य है। समस्या यह है कि देव वर्तमान में इसके लिए योजना नहीं बना रहे हैं। और वह समय से बाहर है जब आप मुद्दों की खोज करते हैं। यह किसी भी तरह से समय लेने वाला है, इसलिए इसे कहानी में रखें जहां यह योजना के दौरान दिखाई देता है।
• अपने परीक्षण के बाद (और वैसे परीक्षण के लिए धन्यवाद!), देव को खोजे गए मुद्दों की एक सूची भेजें। उन मुद्दों का समाधान संतुष्टि के "फिक्सिंग एज मामलों" के खिलाफ जाएगा।
• यदि कुछ भी अधूरा रहता है या बहुत देर से खोजा जाता है, तो तय करें कि क्या कहानी का उपयोग किए गए मामले को पूरा करने के आधार पर किया जाना चाहिए। ज्ञात मुद्दे और काम के आसपास होते हैं। उन्हें जारी नोटों में खुलासा किया और उन्हें ठीक करने के लिए नई कहानियां बनाईं।
• यदि इस प्रक्रिया में कोई विशेष खुरदरा स्थान है जो पुशबैक उत्पन्न करता है, तो अपनी प्रक्रिया को बदल दें! सब के बाद, प्रक्रिया में सुधार स्क्रम का हिस्सा है। उदाहरण के लिए, यदि कहानी को अस्वीकार करने पर आपका देव परेशान हो जाता है, तो टीम को प्रक्रिया में बदलाव का सुझाव दें ताकि अस्वीकृति फिक्स को ट्रिगर न करे। परीक्षण किया और किया और सुधार से पहले ठीक कर दिया।
• टीम के साथ काम करें और उन्होंने क्या उत्पादन किया है और इसका सबसे अच्छा उपयोग आप कर सकते हैं। वे सही काम नहीं करते हैं और न ही आप करते हैं। तो उसके लिए योजना बनाएं। मेरी टीमें आमतौर पर डिवोप्स हो चुकी हैं, इसलिए हमारे पास एक अनप्लान्ड सपोर्ट यूजर की कहानी है, जो कि उभरते हुए मुद्दों के लिए प्रत्येक स्प्रिंट ... अन-प्लान-सक्षम के लिए योजना बना रही है।

Comments

मैं इस बात से सहमत हूं कि आवश्यकताओं के बारे में व्यक्ति को डिजाइन जानने की आवश्यकता नहीं होनी चाहिए। यदि डिज़ाइन आपकी आवश्यकताओं को बदलता है तो आपकी आवश्यकताएं गलत हैं।

— डंक

Answer 6

आवश्यकताओं को स्पष्ट और संक्षिप्त होना चाहिए। यदि वे नहीं हैं, तो वास्तव में आपके साथ क्या हुआ है। यह आपकी गलती है, और सबसे खराब चीज आप तब कर सकते हैं जब आवश्यकताओं को निर्दिष्ट करना चीजों को ग्रहण करना है।

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

लेकिन ऐसे मामलों में, मैं बस लापता अंतराल को भरूंगा और उन्हें डेवलपर को पास करूंगा। सब के बाद, आवश्यकताओं में कीड़े होते हैं।

Comments

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

— रॉबर्ट हार्वे

@RobertHarvey प्रश्न में, शून्य से विभाजन को संभालने के 3 अलग-अलग तरीके हैं। क्यों डेवलपर अपने 4 वें तरीके को लागू नहीं करेगा? आखिरकार, यह निर्दिष्ट नहीं है कि कार्यक्रम को ऐसे मामले में कैसे व्यवहार करना चाहिए। इसके अलावा, ऐसे मामले भी होते हैं जब एक किनारे का मामला स्पष्ट नहीं होता है।

— B:52овиЈ

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

— रॉबर्ट हार्वे

@RobertHarvey खैर, विभाजन को IEEE 754 में काफी अच्छी तरह से परिभाषित किया गया है। ओपी एक दुकान की तरह लगता है जहां मैंने काम किया है। वहां, आवश्यकताएँ आपके डेस्क पर आने वाले एक प्रबंधक को बताती हैं कि वह क्या चाहता है। बेशक, वे कहीं नहीं लिखे गए हैं और अच्छी तरह से समझाया गया है। इसलिए, जब आप गैर-मौजूदा या छायादार आवश्यकताओं के साथ काम करते हैं, तो परिणाम कुछ भी हो सकता है।

— B:06овиЈ

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

— feik