उपयोगकर्ता कहानी, सुविधा और महाकाव्य के बीच संबंध?

Question

किसी के रूप में जो अभी भी चुस्त नया है, मुझे यकीन नहीं है कि मैं पूरी तरह से उपयोगकर्ता कहानी, फीचर और महाकाव्य के बीच के रिश्ते या अंतर को समझता हूं।

इस प्रश्न के अनुसार , एक फीचर कहानियों का संग्रह है। उत्तर में से एक का सुझाव है कि एक विशेषता वास्तव में एक महाकाव्य है। तो क्या सुविधाओं और महाकाव्यों को एक ही चीज़ माना जाता है, जो मूल रूप से संबंधित उपयोगकर्ता कहानियों का संग्रह है?

हमारे परियोजना प्रबंधक ने कहा कि एक पदानुक्रमित संरचना है:

महाकाव्य -> ​​विशेषताएं -> उपयोगकर्ता कहानियां

और यह कि मूल रूप से सभी उपयोगकर्ता कहानियां इस संरचना के भीतर होनी चाहिए। इसलिए सभी उपयोगकर्ता कहानियों को एक अंब्रेला फीचर के तहत आना चाहिए और सभी विशेषताओं को एक महाकाव्य के तहत आना चाहिए।

मेरे लिए, यह अजीब लगता है। क्या कोई यह स्पष्ट कर सकता है कि उपयोगकर्ता की कहानियाँ, सुविधाएँ और महाकाव्यों का क्या संबंध है? या क्या कोई ऐसा लेख है जो मतभेदों को स्पष्ट रूप से रेखांकित करता है?

Comments

इसका एकमात्र वास्तविक उत्तर "कोई निश्चित उत्तर नहीं है" है। हर व्यक्ति / कंपनियों की व्याख्या थोड़ी अलग है। मेरे लिए, सुविधाएँ और उपयोगकर्ता कहानियां समान हैं, अन्य लोग एक अंतर कर सकते हैं (जो मुझे मूर्खतापूर्ण लगता है), लेकिन न तो सही है या गलत है। मुझे नहीं लगता कि पृथ्वी पर कोई भी निश्चित रूप से आपको बता सकता है, "यह एक महाकाव्य है, यह एक कहानी है, यह एक विशेषता है" ... हालांकि कई लोग कोशिश करेंगे!

— मैटवेवी

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

— जोए गुएरा

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

— इज़्काता

Answer 1

वे वास्तव में बहुत सामान्य शब्द हैं। उनकी व्याख्या करने के कई तरीके हैं, साहित्य में अलग-अलग और लोग उन्हें कैसे देखते हैं। नमक के एक विशाल दाने के साथ मैं जो कुछ भी कहता हूं उसे ले लो।

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

महाकाव्य
- ग्राहक को वेब के माध्यम से अपना खाता प्रबंधित करने की अनुमति दें

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

सुविधाएँ आमतौर पर वर्णन करती हैं कि आपका सॉफ़्टवेयर क्या करता है:

फ़ीचर
- वेब पोर्टल के माध्यम से ग्राहक की जानकारी का संपादन

उपयोगकर्ता कहानियां व्यक्त करना चाहते हैं कि उपयोगकर्ता क्या करना चाहता है:

उपयोगकर्ता कहानी
बैंक क्लर्क के रूप में,
मैं ग्राहक जानकारी को संशोधित करने में सक्षम होना चाहता हूं
ताकि मैं इसे अद्यतित रख सकूं।

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

उपयोगकर्ता कहानी : एक ग्राहक के रूप में, मैं सबसे लोकप्रिय क्रेडिट कार्ड के साथ भुगतान करना चाहता हूं
फ़ीचर सरकार के GOV-TAX-02 XML एपीआई का समर्थन करता है।

परिदृश्य का सवाल भी है, जो आमतौर पर एक फीचर / उपयोगकर्ता कहानी को निष्पादित किया जाएगा। वे आम तौर पर एक विशिष्ट स्वीकृति परीक्षण के लिए सफाई से नक्शा करते हैं। उदाहरण के लिए

परिदृश्य : वापस लेने पैसा
अपने बैंक खाते में $ देखते हुए मैंने 2000 है
जब मैं $ 100 को वापस लेने
तो मैं नकद में $ 100 प्राप्त
और मेरे संतुलन 1900 $ है

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

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

Comments

+1 के लिए "यह महत्वपूर्ण है कि टीम के सभी लोग एक परिभाषा पर सहमत हों"

— मैटवेवी

इस पदानुक्रम में एक उपयोग का मामला कहां फिट होगा?

— रेनेग्रिन

यह इस बात पर निर्भर करेगा कि आप अपनी टीम में उपयोग के मामले को कैसे परिभाषित करेंगे। चलो उपयोग के मामले की अपनी RUP शैली मान लेते हैं। उस स्थिति में, उपयोग का मामला परिदृश्य और कहानी दोनों की भूमिका लेगा, दोनों को मिलाएगा, और इस प्रकार RUP में सॉफ़्टवेयर की आवश्यकता केवल उपयोग के मामले में निर्दिष्ट होती है। अपने आप से पूछें: एक कहानी क्या होनी चाहिए ? और क्या उपयोग मामला होना चाहिए ? क्या आपको दोनों की आवश्यकता है? क्यों? व्यक्तिगत रूप से, मैं या तो कहानी का उपयोग करूंगा या मामले का उपयोग करूंगा, लेकिन दोनों नहीं, क्योंकि उनका लक्ष्य एक ही है। फिर भी, यह हमेशा निर्भर करता है। यदि आपके पास प्रत्येक के लिए एक भूमिका है, तो उनमें से प्रत्येक का उपयोग करें; यदि नहीं, तो आप जो जानते हैं उसका उपयोग करें :)।

— लॉरेंट बॉरगुल्ट-रॉय

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

— itj

ये सभी विभिन्न ऊँचाइयों पर हल की जाने वाली समस्या का सिर्फ वर्णन हैं। महाकाव्य ऊपरी प्रबंधन के लिए समझ में आता है। विशेषताएं क्या विपणक महाकाव्य प्रदान करना चाहते हैं। यह दृश्य मध्य-स्तर के प्रबंधकों के लिए काम करता है। उपयोगकर्ता कहानियां उन लोगों के लिए काम तोड़ देती हैं जिन्हें समाधान तैयार करना है, डेवलपर्स और निम्न-स्तरीय प्रबंधन के लिए।

— रफपोर्टिला

Answer 2

महाकाव्य : एक बहुत बड़ी उपयोगकर्ता कहानी जो अंततः छोटी कहानियों में टूट जाती है।

उपयोगकर्ता की कहानी: आवश्यकता की एक उच्च-स्तरीय परिभाषा, जिसमें केवल पर्याप्त जानकारी हो ताकि डेवलपर्स इसे लागू करने के प्रयास का एक उचित अनुमान लगा सकें।

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

फ़ीचर : एक सॉफ्टवेयर एप्लीकेशन या लाइब्रेरी (जैसे, प्रदर्शन, पोर्टेबिलिटी, या कार्यक्षमता) की एक विशिष्ट विशेषता या क्षमता।

http://en.wikipedia.org/wiki/Software_feature

Answer 3

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

स्टैक एक्सचेंज के लिए टैग काम करते हैं और वे आपके लिए भी काम कर सकते हैं।

Comments

ठीक ठीक। मैंने इस प्रश्न पर क्लिक किया कि मुझे इस तरह का उत्तर मिल सकता है।

— ज़िमानो

Answer 4

जिस तरह से हम एपिक्स, स्टोरीज़ और फीचर्स के साथ काम करते हैं, वह इस प्रकार है

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

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

इसके चलते एपिक्स जैसे विषय होते हैं

• उत्पाद सूची ब्राउज़ करें
• उपलब्धता देखें
• मूल्य निर्धारण देखें
• आदेश देना
• आदेश इतिहास देखें

ये उपयोगकर्ता कहानियों के रूप में लिखे गए हैं (उदाहरण के लिए, एक ग्राहक के रूप में, मैं उत्पाद कैटलॉग ब्राउज़ करना चाहता हूं, ताकि मैं एक सूचित खरीद निर्णय ले सकूं), लेकिन वास्तव में विकसित और जारी किए जाने के लिए केवल दस के लिए एक स्टार्टर के रूप में काम करेंगे।

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

यूजर स्टोरी डिलीवरी की इकाई है। यह उपयोगकर्ता की कहानी है जो पूर्ण है या पूरी नहीं है, लाइव नहीं है या लाइव नहीं है।

एक एपिक में बड़ी संख्या में उपयोगकर्ता कहानियां हो सकती हैं, सभी को एक ही समय में विकसित या जारी नहीं किया जाएगा।

एक उदाहरण के रूप में, ब्राउज़ उत्पाद कैटलॉग महाकाव्य में टूट सकता है

• श्रेणी श्रेणी पदानुक्रम नेविगेट करें
• कीवर्ड द्वारा खोज
• फ़िल्टर उत्पाद विशेषताओं द्वारा (जैसे मूल्य सीमा, ब्रांड, रंग, आकार, आदि)

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

आमतौर पर, हमारी अधिकांश परियोजनाओं के लिए, हमारे पास दसियों महाकाव्य और सैकड़ों कहानियाँ हैं।

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

ये लेबल समूह के साथ-साथ चलने वाली कहानियों की सेवा करते हैं, इसलिए नहीं कि वे एक ही गतिविधि के विभिन्न प्रकार के होते हैं (उदाहरण के लिए सभी जगह की कहानियाँ), बल्कि इसलिए कि उन्हें एक साथ जारी किया जाना चाहिए।

उदाहरण के लिए, "क्रेडिट कार्ड द्वारा भुगतान करने वाला ऑर्डर" कहानी उसी महाकाव्य के अंतर्गत है, जो "पेपाल द्वारा भुगतान किए गए ऑर्डर को दे रहा है" कहानी है, लेकिन उन्हें एक साथ जारी करने की आवश्यकता नहीं है।

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

नोट : एक सामान्य नियम के रूप में, वह है। यह, अंत में, एक व्यापार निर्णय है। यदि समय-समय पर बाजार महत्वपूर्ण है, तो इनमें से किसी एक के साथ रहने का एक वैध कारण हो सकता है और दूसरा नहीं।

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

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

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

Comments

"... इस प्रकार महाकाव्यों में (संबंधित, लेकिन अलग) कहानियों को तोड़ने के लिए सेवा की जाती है, जिन्हें स्वतंत्र रूप से विकसित किया जा सकता है, जबकि विशेषताएं समूह की एक साथ कहानियों की सेवा करती हैं जिन्हें एक साथ जारी किया जाना चाहिए ..." यूरेका पल !!

— हेनरी रोड्रिगेज 18

यह पोस्ट अधिक अंगूठे के योग्य है! कुडोस!

— गोहाना

Answer 5

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

मुझे जो जवाब पसंद है वह माइक कोहेन के शिविर से है और यह काफी सरल है।

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• महाकाव्य सिर्फ एक बड़ी कहानी है (पदानुक्रमित)
• थीम केवल कहानियों का एक समूह है (बहुत पसंद टैग)

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

तो आपके पीएम की परिभाषा में, फ़ीचर एपिक-स्टोरी पदानुक्रम के बीच में कहीं है।

इस जानकारी के बारे में मेरी जानकारी-आलेख http://www.infoq.com/articles/visualize-big-picture-agile ;-) से इस जानकारी का ग्राफिक है ।

Answer 6

सुविधाएँ और महाकाव्य एक ही बात नहीं हैं।

• एक फीचर यूजर स्टोरी नहीं है।
• एक महाकाव्य एक उपयोगकर्ता कहानी है।
• एक उपयोगकर्ता कहानी एक महाकाव्य हो सकती है।
• एक उपयोगकर्ता कहानी में कई विशेषताएं हो सकती हैं।
• एक फीचर कई यूजर स्टोरीज को 1 पूरा कर सकता है।

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

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

Answer 7

यह सिर्फ समस्या अपघटन है। वे अलग-अलग आकारों को छोड़कर सिर्फ कहानियां हैं।

मैं व्यक्तिगत रूप से उनके आकारों को लेबल नहीं करना पसंद करता हूं, लेकिन यदि आप ऐसा करते हैं तो ठीक है। आप पीएम से पूछें कि आपके कार्यक्षेत्र में परिभाषा क्या है।

Answer 8

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

संयोग से, हम इन असमान स्तरों में से प्रत्येक को "कार्य आइटम" के रूप में संदर्भित करते हैं। कुछ संगठन (ऊपर के कुछ उत्तरदाताओं सहित) कहानियों या उपयोगकर्ता कहानियों (और हमारे पास अतीत में भी) के स्तर को अलग करते हैं, लेकिन हमने इसे बहुत अस्पष्ट पाया, इसलिए हम अब उन्हें कार्य आइटम के रूप में उदारतापूर्वक संदर्भित करते हैं।

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

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

हम अब धीरे-धीरे इस दिशा में विकसित हो रहे हैं, लेकिन प्रगति के पहिये धीरे-धीरे पीसते जा रहे हैं। हम अभी भी इस बात से जूझ रहे हैं कि कैसे काम को काटने के आकार के टुकड़ों में विभाजित किया जाए ताकि हम काम को परिभाषित कर सकें और इसे कई टीमों द्वारा आसानी से पूरा किया जा सके। ऐसा करने के लिए, हमें एक "सब-फ़ीचर" की आवश्यकता होती है, जो एक फीचर से छोटा लेकिन एक स्टोरी से बड़ा होता है। उप-सुविधाओं का उपयोग EACH INDIVIDUAL टीम द्वारा फ़ीचर पर किए गए कामों के लिए किया जा सकता है, या किसी SINGLE टीम द्वारा अलग-अलग समय (अलग-अलग स्प्रिंट में, या यहां तक ​​कि अलग-अलग रिलीज़) में किए गए कामों के लिए किया जा सकता है।

हमें फ़ीचर और बिज़नेस एपिक के बीच कई पदानुक्रमित स्तरों की भी आवश्यकता है, लेकिन हमने इसे अभी तक हल नहीं किया है, इसके अलावा सिर्फ उन्हें "थीम्स" के रूप में जाना जाता है - जिसे हम जानते हैं कि यह सही शब्द नहीं है, क्योंकि यह SAFe Investment Themes के साथ आसानी से भ्रमित है। कुछ बड़ी परियोजनाओं (रिलीज) के लिए हमारे पास 5-8 विभिन्न पदानुक्रमित स्तर हैं, प्रत्येक एक काम को छोटे और छोटे टुकड़ों में तोड़ रहा है। आप इन थीम्स को "फ़ीचर ग्रुप्स" होने के रूप में सोच सकते हैं, लेकिन जरूरी नहीं कि यह सही शब्द भी हो।

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

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

लब्बोलुआब यह है कि यह अभी भी हमारे लिए एक कार्य-प्रगति है, और हम अभी भी इसके साथ संघर्ष कर रहे हैं। लेकिन थीम, एपिक, फीचर और स्टोरी की SAFe परिभाषाओं का पालन करते हुए हमें सही दिशा में आगे बढ़ना है!

Answer 9

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

छोटी परियोजनाओं के लिए: महाकाव्य> कहानी पर्याप्त से अधिक है; और आप या तो "सुविधा" कहते हैं।
बड़ी परियोजनाएँ समान हो सकती हैं: उपन्यास> विषय> महाकाव्य> फ़ीचर> कहानी

सबसे अच्छा उदाहरण निम्नलिखित हो सकता है:
उपन्यास = एमएस ऑफिस
थीम = एमएस वर्ड / एमएस एक्सेल ...
एपिक = टेबल्स / फॉन्ट डायरेक्टरी ...
फीचर्स = बेसिक टेबल / टेबल कलर स्कीम / ऑपरेशंस विद सेल ...
स्टोरीज (के लिए) 'टेबल्स' एपिक के भीतर बेसिक टेबल 'की सुविधा = टेबल / ड्रा टेबल / इंसर्ट रॉ / इंसर्ट कॉलम जोड़ें ...

मेरा मानना ​​है कि बैकलॉग के लिए अपनी खुद की स्केलिंग को परिभाषित करते समय ध्यान रखना फायदेमंद है:
1. कहानी: ए) एक स्प्रिंट के भीतर हमेशा संभव; ख) हमेशा अंतिम उपयोगकर्ताओं के लिए परीक्षण योग्य नहीं है
। महाकाव्य / फ़ीचर: क) एक स्प्रिंट अवधि के लायक नहीं है और विघटित होने की आवश्यकता है; बी) हमेशा अंतिम उपयोगकर्ताओं के लिए परीक्षण योग्य होना चाहिए; ग) हमेशा shippable, मुद्रीकृत किया जा सकता है - इसके लिए आरओआई की गणना करें
। 3. जब एपिक> फीचर अनुभाग या स्टिक को एपिक> स्टोरी पर जोड़ या नहीं पर विचार करें : मैं केवल एपिक और स्टोरी के बीच में फीचर डालने की सलाह दूंगा : एपिक नॉन ' t 1 रिलीज़ भी फिट है, इसलिए आपको shippable तत्व को परिभाषित करने की आवश्यकता है जो 1 रिलीज़ अवधि फिट होगा ।

आशा है कि यह उपयोगी है।

Answer 10

हमारे संगठन में हमारे पास निम्नलिखित हैं:

थीम = कहानियों के संग्रह के लिए एक साथ समूह में प्रयुक्त

महाकाव्य = एक बड़ी उपयोगकर्ता कहानी (वास्तव में एक आवश्यकता) का वर्णन करता है जिसे उपयोगकर्ता कहानियों में तोड़ दिया जाना चाहिए

विशेषताएं = यह टिन पर क्या कहता है, आवश्यक उत्पाद की एक विशेषता का वर्णन करता है

उपयोगकर्ता कहानी = यह विस्तार का सबसे निचला स्तर है जहाँ से कार्य प्राप्त होते हैं।