क्या एक उपयोगकर्ता कहानी को डेवलपर्स के बीच साझा किया जाना चाहिए? [बन्द है]

Question

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

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

इसके बाद अराजकता आती है। कौन "मालिक" कौन सी कहानी? "प्रगति में" का क्या अर्थ है या "किया गया"? क्या हमें बैक-एंड और फ्रंट-एंड के लिए दो अलग-अलग कहानियां बनानी चाहिए? यदि हां, तो क्या यह फीचर के आधार पर उपयोगकर्ता कहानियों के विचार को नहीं तोड़ता है? हमारे सिस्टम में "उप-कार्यों" की धारणा है, जो इनमें से कुछ समस्याओं को कम करता है। लेकिन उप-कार्य एक अतिरिक्त जटिलता जोड़ते हैं। क्या कोई बेहतर तरीका है? क्या यह स्क्रैम का उपयोग करने का एक "बुरा" तरीका है?

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

Comments

आपने बहुत ही उप-कार्य विचार के साथ इसे कवर किया। इस अवधारणा के बारे में आपको क्या समझना मुश्किल है?

— रिबेल्डैडी

उप-कार्यों को समझना मुश्किल नहीं है, यह सिर्फ और अधिक जटिलता है। इसलिए अब मुझे लगता है कि देव प्रबंधक कहानी के मालिक हैं और प्रत्येक देव का अपना उप-कार्य है। यह अंततः 3 ऑब्जेक्ट्स प्रति फीचर (एक कहानी और दो उप-कार्य) में समाप्त होता है। मुझे लगता है कि यह सिर्फ सामान्य है।

— यूजर 1

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

— जूल्स

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

— पोस्टकोडिज़्म

Answer 1

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

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

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

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

संपादित करें: मैं कुछ स्रोतों के साथ ऊपर के बिंदुओं का बैकअप लेना चाहता था। एक अच्छी उपयोगकर्ता कहानी की विशेषताओं को संक्षिप्त रूप से " INVEST " नामक एक संक्षिप्त नाम के साथ दर्शाया जाता है । यह बिल वेक द्वारा बनाया गया था और इसे स्क्रैम आंदोलन द्वारा लोकप्रिय बनाया गया था। विशेष रूप से स्वतंत्र और कार्यक्षेत्र वाली कहानियों पर ध्यान दें।

कुछ और जानकारी यहाँ और यहाँ ।

Answer 2

कौन "मालिक" कौन सी कहानी?

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

क्या हमें बैक-एंड और फ्रंट-एंड के लिए दो अलग-अलग कहानियां बनानी चाहिए? यदि हां, तो क्या यह फीचर के आधार पर उपयोगकर्ता कहानियों के विचार को नहीं तोड़ता है?

निर्भर करता है। मैंने दोनों तरह से काम देखा है। यदि कहानी इतनी बड़ी है कि दो डेवलपर्स उस पर पूरे समय काम करते हैं, तो शायद इसे विभाजित किया जाना चाहिए। यदि दो डेवलपर्स दो अलग-अलग टीमों का हिस्सा हैं, तो शायद इसे विभाजित किया जाना चाहिए। यदि दो डेवलपर्स अलग-अलग स्प्रिंट के दौरान इस पर काम करेंगे, तो शायद इसे विभाजित किया जाना चाहिए।

क्या यह स्क्रैम का उपयोग करने का एक "बुरा" तरीका है?

याद रखने की कुंजी यह है कि प्रक्रिया आपकी सेवा करने के लिए है, इसके विपरीत नहीं। उपयोगकर्ता कहानियां तकनीकी लोगों और गैर-तकनीकी लोगों के लिए संचार की सुविधा के लिए एक तरीका है। वे बताते हैं कि वे क्या चाहते हैं, हर कोई बातचीत करता है, और फिर आप इसकी प्रगति के बारे में कहानी में प्रतिक्रिया देते हैं।

जब तक प्रक्रिया आपके लिए काम कर रही है, तब तक यह खराब नहीं हो सकता है।

Answer 3

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

यह कहा जा रहा है, एक व्यक्ति कहानी का मालिक है और यह प्रगति पर अद्यतन करने और हर किसी के अपने काम को सुनिश्चित करने के लिए जिम्मेदार है और यह एक साथ काम कर रहा है। यह हमारे लिए वह व्यक्ति है जो रिपोर्ट करता है कि एक कहानी "की गई" है।

Answer 4

जैसे दूसरों ने सुझाव दिया है, मेरी टीम हमारी उपयोगकर्ता कहानियों को भी कार्यों में विभाजित करती है। यदि आप सॉफ़्टवेयर के माध्यम से अपनी उपयोगकर्ता कहानियों का प्रबंधन कर रहे हैं (जैसे कि JIRA या रैली) तो यह आम तौर पर आसान होता है। फिर यह बताना आसान है कि कहानी के कौन से हिस्से आगे बढ़ रहे हैं।

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

लेकिन किसी भी मामले में, मैं सुझाव देता हूं कि जब तक टीम सहमत नहीं हो जाती है, तब तक "किया" एक कहानी को कॉल नहीं करना चाहिए, जिसमें परीक्षण शामिल है। इस तरह हर किसी के पास अपना इनपुट देने का मौका है। और यदि आप इसे सामूहिक कोड स्वामित्व और कोड समीक्षाओं के बारे में विचारों के साथ जोड़ते हैं तो टीम द्वारा वैसे भी हर कहानी "स्वामित्व" है। यह रास्ते में अलग-अलग लोगों को "सौंपा" जा सकता है, लेकिन अगर कोई बाहर है (बीमार / छुट्टी / बहुत सारी बैठकें? / अन्य) काम अभी भी हो सकता है।

मेरी टीम अक्सर हमारे सुबह के स्टैंड-अप / एससीआरयूएम बैठक के हिस्से के रूप में उपयोगकर्ता कहानियों को स्वीकार करती है। इस तरह हर कोई आसानी से स्वीकार या विवाद कर सकता है कि क्या यह वास्तव में "किया गया" है। दूसरी बार जब हम अपने QA इंजीनियर को ऐसा करने देते हैं - यदि वह संतुष्ट है कि यह परीक्षण किया गया है और काम कर रहा है, और सभी कार्य पूरे हो गए हैं, तो हम उसे पूर्ण कहते हैं।

Answer 5

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

महाकाव्य का लक्ष्य एक बड़ा लक्ष्य है जो जरूरी नहीं कि एक स्प्रिंट / पुनरावृत्ति में फिट हो। समय के साथ सभी कहानियाँ पूरी हो जाती हैं और महाकाव्य समाप्त हो जाता है। महाकाव्य को एक रिलीज में रखा गया है।

इसके बाद अराजकता आती है। कौन "मालिक" कौन सी कहानी? "प्रगति में" का क्या अर्थ है या "किया गया"?

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

अब यह सही मामला प्रगति है। हमारे पास ऐसी कहानियां और डेमो हैं जो विफल हो जाते हैं, उपयोगकर्ता जो कुछ और चाहते हैं, आदि। ऊपर का लक्ष्य है और अधिकांश भाग के लिए यह काम करता है।

Comments

'' हो गया '' का मतलब है कि इसे सफलतापूर्वक प्रदर्शित किया जा सकता है '' - मुझे इस पर यकीन नहीं है। सफल प्रदर्शन का मतलब यह नहीं है कि यह अनिवार्य रूप से क्यूए उत्तीर्ण करता है, जब तक कि आपका प्रदर्शन हर एक कोने के मामले को कवर नहीं करता है कि एक अच्छा परीक्षक इसे फेंक देगा।

— माइक चेम्बरलेन

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

— jmq