2009-10-06 13 views
17

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

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

क्या किसी को भी जिरा में ऐसा करने का कोई तरीका मिला है, या शायद किसी अन्य उपकरण के साथ जो जेरा के साथ एकीकृत है?

उत्तर

8

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

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

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

चेतावनी: यदि आपको विभिन्न ग्राहकों के साथ आवश्यकताओं को साझा करने की आवश्यकता है, तो यह मुश्किल हो जाएगा। अनुमतियां JIRA प्रोजेक्ट & समस्या प्रकार प्रति कॉन्फ़िगर की गई हैं।

यह सब कहकर, जेरा में बेसलाइन और ट्रेसिबिलिटी जैसे सभ्य आवश्यकताओं के प्रबंधन की विशेषताएं हैं। लेकिन आगे काम के लिए डेटा एकत्र करने के लिए यह ठीक हो सकता है।

+0

धन्यवाद, यह एक दिलचस्प विचार है; मैं वास्तव में उन परियोजनाओं में आवश्यकताओं को प्राथमिकता देना चाहता हूं जो वे संबंधित हैं, लेकिन मैं यह देखने जा रहा हूं कि आपका सुझाव कैसे काम करता है। –

6

हम जिरा के "डुप्लिकेट" या "संबंधित" फ़ंक्शन का उपयोग करते हैं।

तो आप प्रत्येक प्रोजेक्ट में कोई समस्या उठाते हैं, लेकिन आप उन्हें एक साथ जोड़ते हैं। इस तरह आप एक परियोजना द्वारा "स्वामित्व" का एक मुद्दा प्राप्त कर सकते हैं और प्रत्येक पर परिवर्तनों का परीक्षण होने के बाद आप सभी संबंधित परियोजनाओं को बंद कर सकते हैं।

यदि आप अपने प्रोजेक्ट सेटअप में यह समझते हैं तो आप लिंक पर निर्भर करते हैं।

+0

जवाब के लिए धन्यवाद - मैं थोड़ा Sereda के सुझाव को पसंद करते हैं, लेकिन अगर यह काम नहीं करता मैं तुम्हारा एक कोशिश दे सकते हैं। –

0

आप शायद इस मामले में जिरा के अलावा संगम का उपयोग करने के बेहतर हैं।

जीरा का सबसे अच्छा क्या है इसके लिए उपयोग करें, और बाकी सब कुछ के लिए संगम का उपयोग करें।

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

+0

हमारे पास संगठनात्मकता है और इसे मुक्त रूप से प्रलेखन जैसे प्रारंभिक आवश्यकताओं को एकत्रित करने और चर्चा के लिए व्यापक रूप से उपयोग किया जाता है, लेकिन संगठनात्मक विस्तृत आवश्यकता ट्रैकिंग के लिए उपयुक्त नहीं है जो मुझे करने की आवश्यकता है। –

+0

फिर भी, कोई संगम मैक्रोज़ के साथ पागल सामान का बहुत कुछ कर सकता है ... और आप उससे जिरा कार्यों का उल्लेख कर सकते हैं। – Arafangion

0

एक अन्य दृष्टिकोण विकल्प के रूप में मुद्दों के लिए हाइपर लिंक (जैसे 'XYZ-123') के साथ एक बहु-चयन कस्टम फ़ील्ड बना रहा है।

2

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

हमने जो कुछ किया वह वास्तव में कुछ कस्टम फ़ील्ड बनाए गए थे। हमने जो पहला क्षेत्र पेश किया था वह 'प्रोग्रामिंग' और 'चरण' के रूप में 'कैस्केडिंग सिलेक्ट' था। यह उत्पाद मालिकों को एक कार्यक्रम के तहत मुद्दों को समूहित करने की संभावना देता है और कुछ मोटा दीर्घकालिक योजना (कई पुनरावृत्तियों) करता है।

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

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

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

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

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

0

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

समाधान मौजूद है: Rmsis a JIRA plugin: