🥐 👧🏾 👩🏿‍🚀 JIRA: स्वादिष्ट सॉफ्टवेयर की समय पर तैयारी के लिए नियम। TLDR 2: आवश्यकताओं का प्रबंधन 🈁 🖐🏽 👩🏿‍🤝‍👨🏻

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

स्रोत

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

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

इन शर्तों के तहत, यह सुनिश्चित करना वांछनीय है कि सभी ग्राहक आवश्यकताओं को आपके "डिजिटल रसोई" में इस तरह से संग्रहीत किया जाता है कि, परियोजना के वितरण के चरण में, परियोजना के सभी इच्छुक दलों की गंभीर निराशा से बचें।

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

आवश्यकताओं को कम करने के लिए नियम

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

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

दूसरे मामले में, आवश्यकताओं प्रबंधन कार्य को कई चरणों में विभाजित किया गया है।

स्रोत

प्रारंभ JIRA में सॉफ्टवेयर विकास / संशोधन के लिए स्रोत दस्तावेज़ का पंजीकरण। प्राप्त सामग्री को कमेंट में कमेंट के साथ अपलोड किया जाता है, जिसमें कमेंट कमेंट में कमेंट में दिए गए होते हैं।

1. पंजीकृत स्रोत दस्तावेज के आधार पर, एक बैठक की योजना बनाई गई है, जिसका उद्देश्य आवश्यकताओं को पूरा करने के लिए जिम्मेदारी की सीमाओं को निर्धारित करना है, "सफेद धब्बे" और "गूढ़" आवश्यकताओं की पहचान करना। बैठक का नियोजन सीधे JIRA में किया जाता है (इसके लिए, "कार्यान्वयन" प्रकार का कार्य पंजीकृत है, कार्य के लिए जिम्मेदार व्यक्ति परियोजना प्रबंधक है, प्रतिभागी पर्यवेक्षक के रूप में पंजीकृत होते हैं, एजेंडा आइटम विवरण में दर्ज किए जाते हैं)। आवश्यकताओं के प्रारंभिक विश्लेषण पर खर्च किया गया समय स्वतंत्र रूप से नियोजित बैठक के लिए उप-मुखियों के रूप में विश्लेषकों द्वारा निर्धारित किया जाता है। यदि विश्लेषण के दौरान सवाल उठते हैं, तो वे बैठक के एजेंडे पर टिप्पणियों में परिलक्षित होते हैं।

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

2. आवश्यकताओं के कार्यान्वयन के लिए विश्लेषक को जिम्मेदार ठहराया जाने के बाद, वह JIRA के साथ प्रत्येक आवश्यकता को स्रोत दस्तावेज़ (लिंक "पूरक") से संबंधित एक अलग कार्य के रूप में पंजीकृत करता है। दावे की प्रारंभिक स्थिति "रेटिंग" है ।

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

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

3. इसके कार्यान्वयन के प्रारंभिक चरण में प्रत्येक आवश्यकताओं के लिए विकसित रोडमैप को देखते हुए, निम्नलिखित मुद्दों को जिम्मेदार विश्लेषक द्वारा हल किया जाना चाहिए:

आवश्यकता की शब्दार्थ सामग्री का स्पष्टीकरण;
कार्यान्वयन की सीमाओं का स्पष्टीकरण।

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

4. एक कार्यात्मक क्षेत्र के कार्यान्वयन के ढांचे के भीतर (एक प्रमुख उपयोग मामला - केस का उपयोग करें) जिम्मेदार विश्लेषक प्रासंगिक आवश्यकताओं से संबंधित "विश्लेषण" प्रकार के कार्यों को तैयार करना चाहिए।

5. यदि आवश्यक हो, तो जिम्मेदार विश्लेषक स्वचालन वस्तु का सूचना सर्वेक्षण करता है।

6. डिजाइन के लिए आवश्यक प्रारंभिक डेटा एकत्र करने के बाद, जिम्मेदार विश्लेषक डिजाइन निर्णय लेता है।

7. डिजाइन निर्णय के परिणामों के आधार पर, विश्लेषक को उन घटकों की सूची को तैयार / स्पष्ट करना होगा जो विकास / संशोधन के अधीन हैं।

8. विकसित डिजाइन समाधान विकास, परीक्षण और प्रलेखन के लिए कार्य बनाने और उनके कार्यान्वयन की जटिलता का पूर्वानुमान लगाने के लिए एक आवश्यक और पर्याप्त स्थिति है।

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

दूसरी ओर, प्रबंधन के दृष्टिकोण से, मैं एक परिणाम प्राप्त करना चाहूंगा जो विकास कार्य के निष्पादन के दौरान ग्राहक के दृष्टिकोण से महत्वपूर्ण है, जो 16 कार्य घंटों में हमेशा प्राप्त करने योग्य नहीं है।

हमारे मामले में, यह निर्णय लिया गया था कि यदि कार्य की जटिलता 8 घंटे से अधिक हो जाती है, तो कार्य के लेखक को इसे अलग-अलग चरणों में विभाजित करना चाहिए (जिसका अर्थ हमेशा उप-प्रकार नहीं होता है)। इसके अतिरिक्त, इन चरणों में से प्रत्येक के लिए विशेष परिणामों की औपचारिक सूची निर्धारित की गई थी। इसके अलावा, PERT पद्धति का उपयोग करके इन सूचियों के आधार पर पूर्वानुमानों की निष्पक्षता बढ़ाने के लिए ऑनलाइन कैलकुलेटर बनाए गए थे ।विभिन्न प्रकारों के कार्यों के लिए कुल जटिलता का निर्धारण (इन उपकरणों के साथ काम करने का अधिक विस्तृत विवरण निम्नलिखित लेखों के प्रकाशन के दौरान दिया जाना चाहिए)। लेकिन एक ही समय में, एक सीमा स्थापित की गई थी कि एकल JIRA कार्य की अधिकतम अनुमानित जटिलता 32 घंटे से अधिक नहीं होनी चाहिए। इस घटना में कि ठेकेदार अपने कार्य की अनुमानित जटिलता से सहमत नहीं है, एक तर्क के रूप में, उसे उसी उपकरण का उपयोग करके, जटिलता की अपनी गणना प्रस्तुत करनी होगी। आवश्यकता के कार्यान्वयन और निष्पादकों के लिए जिम्मेदार विश्लेषक के बीच इस तरह के विवादों को हल करने में मध्यस्थ परियोजना प्रबंधक (टीमलेड) है।

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

10. डिज़ाइन समाधान का कार्यान्वयन "विकास" प्रकार के कार्यों के ढांचे के भीतर किया जाता है।
सॉफ्टवेयर विकास के लिए पहले आवश्यकता से संबंधित कार्य को काम पर रखने के बाद, आवश्यकता को "काम में" स्थिति में स्थानांतरित किया जाना चाहिए (यह जीरा प्लगइन के लिए स्वचालन का उपयोग करके किया जा सकता है )।

11. निर्दिष्ट कार्यान्वयन समय-सीमा के आधार पर, एक या दूसरे सॉफ़्टवेयर रिलीज़ में आवश्यकता के कार्यान्वयन को शामिल करने के लिए एक निर्णय लिया जाता है। ग्राहक को रिलीज़ के रचना या वितरण समय में किसी भी बदलाव के बारे में सूचित किया जाना चाहिए।

12. विकास प्रक्रिया के समानांतर, डिजाइन निर्णय के आधार पर उपयोगकर्ता प्रलेखन का एक संस्करण बनता है।

13. विकास कार्यों को पूरा करने के बाद, प्रोग्रामर को उन घटकों की सूची को स्पष्ट करना चाहिए जिन्हें विकसित / संशोधित किया गया है।

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

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

16. परीक्षण किए जाने से पहले, रिलीज में शामिल कार्यान्वित आवश्यकताओं के बार-बार एकीकरण परीक्षण किए जाते हैं।

17. सॉफ्टवेयर परीक्षण (प्रारंभिक परीक्षण, स्वीकृति) के दौरान कार्यान्वित आवश्यकताओं की शुद्धता की पुष्टि की जा सकती है। परीक्षण के परिणाम "कार्यान्वयन" प्रकार के कार्यों के भाग के रूप में JIRA में दर्ज किए जाते हैं।
आवश्यकता के सही कार्यान्वयन पर ग्राहक से एक दस्तावेज प्राप्त होने के बाद, इसे "बंद" स्थिति में स्थानांतरित किया जा सकता है । इस घटना में कि ग्राहक से आवश्यकता के संबंध में टिप्पणियां प्राप्त की जाती हैं, उसे "निर्दिष्ट" स्थिति में लौटा दिया जाता है(मंच संख्या 8 पर)। उसी समय, टिप्पणियों को JIRA में "रिलेट्स" संचार प्रकार का उपयोग करके मुख्य आवश्यकता से संबंधित अलग-अलग आवश्यकताओं के रूप में तय किया जा सकता है ।

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

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

नई आवश्यकताओं;
कार्यान्वयन पर स्पष्टीकरण;
दोष के;
गलतियां।

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

तिलचट्टे को रंग देने के नियम

जो कुछ नहीं करता वह गलत नहीं है।
थियोडोर रूसवेल्ट

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

इसलिए, यदि परियोजना प्रबंधक आने वाली घटनाओं के प्रवाह का प्रबंधन नहीं करता है, तो बहुत जल्द यह धागा ऐसे प्रबंधक का प्रबंधन करेगा (यदि वह इस धागे में "चोक" नहीं करता है)।

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

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

इस संबंध में, सॉफ्टवेयर पर टिप्पणियों के संबंध में ग्राहक के साथ पत्राचार के दौरान, "त्रुटि" या "दोष" जैसे शब्दों से बचने की सिफारिश की जाती है, कम से कम जब तक यह पूरी तरह से स्पष्ट रूप से स्थापित नहीं हो जाता है। इस बिंदु तक शब्द "टिप्पणी" या "घटना" का उपयोग करने की सिफारिश की जाती है।

घटनाओं को खत्म करने के लिए काम करने की एकीकृत प्रक्रिया को निम्न चरणों के अनुक्रम के रूप में दर्शाया जा सकता है।

स्रोत

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

1. घटना की स्थिति का स्पष्टीकरण। इस कार्रवाई के भाग के रूप में, सॉफ़्टवेयर टिप्पणी के बारे में पूरी जानकारी एकत्र करना आवश्यक है:

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

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

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

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

4. डुप्लिकेट का नियंत्रण। पहले से पहचाने गए दोषों को हटाने के लिए फिर से शामिल होने के मामले में, यह आवश्यकता कनेक्शन "डुप्लिकेट» ( डुप्लिकेट ) के माध्यम से पहले से दर्ज किए गए कार्य से जुड़ी है ।

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

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

6. यदि घटना को पिछले चरणों के दौरान हल नहीं किया गया था, तो आवश्यकता को "असाइन" स्थिति में स्थानांतरित कर दिया जाता है और इसकी घटना के कारणों की पहचान करने और इसके उन्मूलन के लिए कार्यों को तैयार करने के लिए विकास दल के विश्लेषक को स्थानांतरित कर दिया जाता है।

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

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

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

10. आवश्यकता के विकास, परीक्षण और प्रलेखन के लिए संबंधित कार्यों की उपस्थिति परियोजना प्रबंधक के लिए एक निर्णय लेने के लिए एक संकेत है कि सॉफ्टवेयर के किस संस्करण के बारे में पहचान की गई खराबी को ठीक किया जाएगा। उसी समय, परियोजना प्रबंधक "कार्यान्वयन" प्रकार के JIRA कार्य से संबंधित आवश्यकताओं को जोड़कर सॉफ्टवेयर के कार्यान्वयन के लिए एक घटना की योजना बनाता है।

11. यदि आवश्यक हो, परियोजना प्रबंधक संबंधित कार्यों के कार्यान्वयन के लिए नियोजित तिथियों को स्पष्ट करता है और ग्राहक को इस बारे में सूचित करता है।

12. दोष का सुधार "विकास" प्रकार के कार्यों के ढांचे के भीतर किया जाता है।

13. दोष को समाप्त करने के बाद, डेवलपर, यदि आवश्यक हो, तो पता चला दोष के प्रकार और अंतिम रूप दिए गए घटकों की संरचना को स्पष्ट करना चाहिए।

14. यदि आवश्यक हो, तो प्रलेखन निर्दिष्ट है।

15. सहायता समूह के विशेषज्ञ सही कार्यक्षमता का स्वायत्त परीक्षण करते हैं (विकास समूह के विश्लेषक द्वारा गठित परीक्षण कार्य के भाग के रूप में)।
साथ ही, नई आवश्यकता के कार्यान्वयन के मामले में, घटना को "पूर्ण" की स्थिति में स्थानांतरित करने का आधार इसके आधार पर बनाए गए सभी कार्यों की पूर्ति है ("कार्यान्वयन" प्रकार के कार्यों के अपवाद के साथ)।

16. ऑफ़लाइन परीक्षण करने के बाद, अद्यतन में और वर्तमान रिलीज़ में फिक्स शामिल है।

17. डिलीवरी की रिलीज में शामिल करने के लिए योजनाबद्ध सभी सुधारों की तत्परता के बाद, एकीकरण परीक्षण किया जाता है। एकीकरण कार्यान्वयन का परीक्षण JIRA में "कार्यान्वयन" प्रकार के संगत कार्य के लिए एक उप-कार्य के रूप में तय किया जा सकता है।

18. सॉफ़्टवेयर अपडेट स्थापित तरीके से ग्राहक को प्रेषित किए जाते हैं। हालांकि, "बंद" की स्थिति के लिए प्रासंगिक आवश्यकताओं के कार्यों का हस्तांतरण घटना के उन्मूलन के ग्राहक दस्तावेजी साक्ष्य प्राप्त करने के बाद ही संभव है।

स्रोत

कोई भी डेवलपर जानता है कि सबसे बड़ी गलतियाँ वे हैं जो आवश्यकताओं के गठन / विनिर्देशन के चरण में समय पर पता नहीं लगाई गई थीं।

आवश्यकता बर्फ़ीली नियम

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

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

स्रोत

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

इस मामले में, निम्नलिखित सामग्रियों के पत्र का उपयोग करके स्पष्टीकरण किया जा सकता है:

. 4.5.6. : « 1, 2 3 «». , , ».

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

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

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

"आवश्यकता" प्रकार के कार्य में श्रम लागत का लेखा-जोखा करते समय, इसके शोधन पर सीधे खर्च किए गए समय को ही दर्ज किया जाता है। अन्य सभी श्रम लागतों को संबंधित प्रकारों (या उनके उप-प्रकारों) के कार्यों में दर्ज किया जाता है। पिछले लेख

में वर्णित सामान्य विशेषताओं के अलावा, लंबी और दर्दनाक प्रक्रिया के दौरान JIRA में "आवश्यकता" प्रकार के प्रत्येक कार्य के लिए अतिरिक्त विशेषताओं का एक सेट परिभाषित किया गया था।

«»


*	( ).
	: ( , , .. ); ; — ( , , ); ; ( , ); /; (, , , , , ).
	, (, ).
()	. , , ( ).
	– . . . . , . - .
	, : ; ; ; ; ; .
	( - ). , . «» .

	, ( )
	/ ( PSP IBM): ( , ); ; ( , ); ( , , ); ( , -, ); ( , ); ( ); ( , , , , ); ( , ); , .
— , .
	: ; ; ; ; ; ; ; ; ; ; ; — , ; (e-mail).


	/ ( JIRA , [ ].[ ].[() ])

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

* सुविधाएँ भरने की विशेषता, सभी प्रकार के कार्यों के लिए सामान्य।

राज्य से राज्य में संक्रमण करते समय "आवश्यकता" प्रकार के कार्य के विशिष्ट गुणों को बदलना निम्नलिखित तालिका द्वारा वर्णित किया गया है, जहां:

- एक विशेषता परिवर्तन संभव है;

- आवश्यक डेटा प्रविष्टि।

जारी रहती है

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

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

वर्णित दृष्टिकोण के ढांचे के भीतर, आवश्यकताओं के एक परस्पर सेट का समन्वय, साथ ही संदर्भ की अनुमोदित शर्तों में परिलक्षित ग्राहक कल्पनाओं की एक यथार्थवादी व्याख्या, "विश्लेषण" प्रकार की समस्याओं को हल करते समय किया जाना प्रस्तावित है, जिनमें से विशेषताओं को लेख में प्रस्तुत किया जाएगा "जिरा: स्वादिष्ट सॉफ्टवेयर की समय पर तैयारी के लिए नियम। TLDR 3: डिज़ाइन समाधान। ”

JIRA: स्वादिष्ट सॉफ्टवेयर की समय पर तैयारी के लिए नियम। TLDR 2: आवश्यकताओं का प्रबंधन

आवश्यकताओं को कम करने के लिए नियम

तिलचट्टे को रंग देने के नियम

आवश्यकता बर्फ़ीली नियम

जारी रहती है

More articles: