जिरा: महाकाव्य बनाम लेबल बनाम घटक

Question

इस ब्लॉग में JIRA में महाकाव्यों की परिभाषा है:

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

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

हालाँकि, मैं आसानी से एक (ब्लॉग से उदाहरण का उपयोग करके) "खाता प्रबंधन" घटक बना सकता था, और उस सुविधा से संबंधित किसी भी कार्य को उस घटक को सौंपा गया है।

इसी तरह मैं भी आसानी से "खाता_ प्रबंधन" के एक लेबल का उपयोग कर सकता हूं, और खाता प्रबंधन सुविधा का एक हिस्सा होने वाली किसी भी कहानी / टिकट को केवल उस लेबल के साथ टैग किया जा सकता है।

तो मेरा सवाल है: क्यों / किन परिस्थितियों में आप एक महाकाव्य का उपयोग करेंगे? क्यों / किन परिस्थितियों में आप एक घटक का उपयोग करेंगे? क्यों / किन परिस्थितियों में आप एक लेबल का उपयोग करेंगे? Ie - सभी तीन (महाकाव्यों, लेबल, घटक) बहुत समान उद्देश्यों (मुद्दों का एक संग्रह समूह) की सेवा करते हैं, क्या अंतर है?

Answer 1

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

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

आप एपिक्स पेज के साथ एटलसियन वर्किंग एपिक के बारे में अधिक देख सकते हैं ।

अवयव तकनीकी टीम के लिए उपयोगी होते हैं क्योंकि वे कई महाकाव्यों में फैल सकते हैं। एक विशिष्ट घटक 'डेटाबेस' या 'यूआई' हो सकता है। JIRA एक विशेष JIRA उपयोगकर्ता के लिए एक विशेष घटक के लिए काम सौंपने का विकल्प प्रदान करता है। उदाहरण के लिए, 'डेटाबेस' के एक घटक के साथ बनाए गए सभी मुद्दों को जिल स्मिथ को सौंपा जा सकता है।

लेबल बहुत अधिक अनुकूलनीय हैं और उन्हें कई कार्य करने की अनुमति देने का लाभ है (इसलिए एक से अधिक लेबल किसी समस्या से संबद्ध हो सकते हैं)। लेबल के साथ यह आपके ऊपर है कि आप उनका उपयोग कैसे करते हैं।

Comments

मैं जोड़ूंगा कि लेबल क्रॉस कटिंग हैं। आप एक ही लेबल के साथ जीरा में विभिन्न प्रकार के मुद्दों को लेबल कर सकते हैं। इस तरह से आप एक कस्टम ध्वज बना सकते हैं जैसे TODO, NEEDS ATTENTION, REQUIRES DOCUMENTATION आदि। आप उसके लिए महाकाव्यों या घटकों का निर्माण नहीं करेंगे।

— बेनी बोटेमा

Answer 2

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

सुविधाओं के लिए महाकाव्यों का निर्माण करें , या जैसा कि @Sateesh द्वारा वर्णित है, बड़ी कहानियों के लिए। उन्हें अपने उद्देश्य को हल करना चाहिए, और एक बार जब व्यवसाय की आवश्यकता होती है, तो उन्हें बंद / किया जाना चाहिए ।

घटक विशेषताएं नहीं हैं । वे प्रणाली के तकनीकी अंग हैं। उनका उपयोग आपके भागों या ... अच्छी तरह से, घटकों: पी ... आपके उत्पाद को वर्गीकृत करने के लिए भी किया जा सकता है ।

लेबल कुछ भी हो सकते हैं, जैसा कि @barnaby ने उल्लेख किया है। आमतौर पर, वे कीवर्ड, कैच-वाक्यांश, शब्द होते हैं, जो लोग किसी कार्य से संबंधित हो सकते हैं, आदि। मैं इसका उपयोग मुख्य रूप से एक दीर्घकालिक परिप्रेक्ष्य से मुद्दों को बेहतर बनाने के लिए करता हूं। एक JIRA प्लगइन है जो आपको एक JIRA लेबल क्लाउड देता है (विशुद्ध रूप से फैंसी उद्देश्यों के लिए, मुझे लगता है: D) जो आपको भी रुचि दे सकता है।

Comments

"घटक विशेषताएं नहीं हैं।" - यह एक दिलचस्प अंतर है, क्या अंतर है? वहाँ सुविधा के लिए घटक के लगभग 1: 1 मानचित्रण होने में एक खतरा है?

— एडम पार्किन

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

— कृष्णन

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

— कृष्णन

मुझे यकीन नहीं है कि ये भ्रम वास्तव में सवाल को हल करेंगे। घटक और लेबल हमेशा के लिए नहीं होते हैं - एक सिस्टम डिज़ाइन इस तरह बदल सकता है कि एक दिया गया घटक अब मौजूद नहीं है। एक लेबल विभिन्न कारणों से अप्रासंगिक हो सकता है। जब आप इसे पूरी तरह से तोड़ देते हैं, तो एक महाकाव्य, लेबल और घटक सभी बस उन पर विभिन्न प्रतिबंधों के साथ वर्गीकरण होते हैं जो आप उनके साथ कर सकते हैं (यद्यपि अजीब प्रतिबंध - एक कहानी को दो महाकाव्यों की आवश्यकता नहीं हो सकती है? एक कहानी शामिल नहीं हो सकती है? दो घटक;)। मुझे एटलसियन की डिज़ाइन बहुत प्रेजेंटेशनल नहीं लगती।

— एरिक

ऐसा लगता है कि घटक वास्तव में कई असाइनमेंट की अनुमति देते हैं, जो अच्छा है, इसलिए घटकों और लेबल के बीच का परिसीमन अधिक उपयोगी हो जाता है क्योंकि घटक केंद्र द्वारा नियंत्रित होते हैं जबकि लेबल मुक्त-रूप होते हैं।

— एरिक

Answer 3

जोड़: एटलसियन ने अब अपने दृष्टिकोण से यह बताते हुए एक नया लेख बनाया है।

https://www.atlassian.com/agile/delivery-vehicles

मेरी राय / उपयोग।

लेबल और अवयव लगभग सीधे और अच्छी तरह से पहले से ही उत्तर दिए गए हैं।

घटक उदाहरण हैं

• एंड्रॉइड क्लाइंट ऐप
• सर्वर एपीआई
• डेटाबेस आदि .....

लेबल उदाहरण।

• व्यावसायिक तर्क क्षेत्र (पूर्व आदेश, चालान, उपयोगकर्ता, उत्पाद)
• कोड की गुणवत्ता में सुधार
• Refactor
• प्रयोज्य
• उपयोगकर्ता अनुरोध / शिकायत आम तौर पर जो कुछ भी चीजों को वर्गीकृत करने में मदद करता है।

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

महाकाव्य काम के बड़े निकाय हैं

बड़ा? 10 स्प्रिंट्स? 10 कहानियां? 20 कहानियाँ? और क्या?

व्यक्तिगत रूप से मैं महाकाव्य को लक्ष्य के रूप में वर्गीकृत करूंगा ।

वार्षिक / तिमाही पूर्वव्यापी में आपकी कंपनी सभी सदस्यों और हितधारकों के साथ बैठक करती है, और निम्नलिखित के लिए निष्कर्ष निकालती है

1. हमें और अधिक प्लेटफार्मों को लक्षित करने की आवश्यकता है (महाकाव्य = प्लेटफ़ॉर्म विस्तार )
2. हमारे सहायक कर्मियों को मुद्दों को संभालने के लिए अधिक उपकरणों की आवश्यकता होती है। ( समर्थन उपकरणों को समृद्ध करें )
3. सॉफ्टवेयर का उपयोग करना बहुत कठिन है! ( Redesign UI UX )

इसका अर्थ होगा उन सामान्य आवश्यकताओं में से प्रत्येक को कवर करने के लिए कहानियों के सेट के साथ 3 महाकाव्य

Comments

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

— मैक्स कास्कॉन

इसका उत्तर होना चाहिए। इतने सारे उत्तर मैं यहाँ और इंटरनेट पर देख रहा हूँ जिनका कोई उदाहरण नहीं है। यह उदाहरण के साथ एक ही है - मूल उत्तर दयनीय है @BarnabyGolden

— TheBlackBenzKid

Answer 4

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

लेबल सिर्फ सुविधा के लिए हैं। इसका भौतिक महत्व नहीं हो सकता है।