JIRA: स्वादिष्ट सॉफ्टवेयर की समय पर तैयारी के लिए नियम। TLDR 1: अवसरों की सीमा

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

स्रोत

सामान्य रहस्य

बुद्धिमत्ता काम करने से बचने की क्षमता है, लेकिन ऐसा किया जाता है।
लिनुस टोरवाल्ड्स

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

प्रस्तुति के दौरान परियोजना के एक उपप्रकार के रूप में प्रत्येक प्रकार के JIRA कार्यों पर क्रमिक रूप से विचार करना:

• इन उपप्रजातियों के विनिर्देशों को एकजुट करें;
• संगठित कार्य के लिए व्यावसायिक नियमों को मानकीकृत करना;
• विशिष्ट "नुकसान" और अग्रिम "पुआल बिस्तर" की आवश्यकता वाले स्थानों के नक्शे संकलित करने के लिए;
• प्रत्येक प्रकार के कार्य के लिए मापने योग्य और प्राप्य प्रदर्शन संकेतक निर्धारित करते हैं।

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

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

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

परियोजना की सीमाएँ

किसी भी कठिन कार्य में एक सरल, समझने में आसान, गलत समाधान है।
आर्थर बलोच

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

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

• विकास - नई प्रणालियों (उप प्रणालियों) के निर्माण के लिए अनुबंधों के तहत आवश्यकताएं;
• विकास - मौजूदा उप-प्रणालियों के पर्याप्त संशोधन के उद्देश्य से अनुबंधों के ढांचे के भीतर की आवश्यकताएं;
• विस्तारित समर्थन - ग्राहक की व्यावसायिक प्रक्रियाओं में वर्तमान परिवर्तनों के लिए व्यक्तिगत सिस्टम मॉड्यूल के संचालन को पूरा करने के लिए अनुबंध की आवश्यकताएं;
• वारंटी समर्थन - वारंटी अवधि के दौरान पहचाने गए सॉफ़्टवेयर त्रुटियों का उन्मूलन;
• मूल समर्थन - वारंटी अवधि की समाप्ति के बाद पहचाने गए सॉफ़्टवेयर त्रुटियों का उन्मूलन।

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

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

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

स्रोत

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

इसे ध्यान में रखते हुए, JIRA परियोजना की सीमाओं को परिभाषित करते हुए निम्नलिखित दो विचारों के बीच सामंजस्य सुनिश्चित करना चाहिए।

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

स्रोत: सर्गेई आर्किपेनकोव। प्रोजेक्ट इवैल्यूएशन: क्वैकेरी या शेमनिज़्म

यह कई सॉफ्टवेयर उत्पादों के ढांचे के भीतर नियमित रूप से किए गए काम के परिणामों को रिकॉर्ड करने के लिए व्यक्तिगत JIRA परियोजनाओं के गठन के बारे में सोचने योग्य है (उदाहरण के लिए, नई प्रौद्योगिकियों का अध्ययन करने या बैकअप से संबंधित काम पर कर्मचारियों द्वारा खर्च किए गए समय के लिए लेखांकन)।

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

अलमारियों पर कार्यों को कैसे रखा जाए

मेरे अटारी में केवल उपकरण हैं जिनकी मुझे आवश्यकता है। उनमें से कई हैं, लेकिन वे सही क्रम में हैं और हमेशा हाथ में हैं।
शर्लक होम्स

किसी भी परियोजना पर, हल किए जाने वाले कार्यों की धारा में कर्मचारियों का नेविगेशन सफलता के महत्वपूर्ण घटकों में से एक है। हालाँकि, जैसे-जैसे परियोजना का आयतन बढ़ता है, इस प्रवाह को समझना और अधिक कठिन हो जाता है, जो कि अपने आप में, एक बड़ी परियोजना के प्रबंधन की समस्याओं में से एक बन सकता है। इसलिए, एक एकल समन्वय प्रणाली की परिभाषा जो सभी प्रमुख प्रतिभागियों को समान रूप से आसानी से नेविगेट कर सकती है, परियोजना प्रबंधन स्वचालन का एक अभिन्न अंग है।

हमारी परियोजना में इस तरह की एक समन्वय प्रणाली का आधार निम्नलिखित विचार थे: एक सॉफ्टवेयर उत्पाद, एक नियम के रूप में, एक ब्लैक बॉक्स के रूप में कल्पना की जा सकती है जो तीन मुख्य तरीकों से बाहरी दुनिया के साथ संचार करता है:

• उपयोगकर्ता इंटरफ़ेस के माध्यम से;
• कागज पर छपाई के लिए गठित दस्तावेजों के माध्यम से;
• इलेक्ट्रॉनिक डेटा एक्सचेंज प्रोटोकॉल ( एपीआई / ईडीआई ) के माध्यम से।

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

स्रोत

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

मेरी परियोजनाओं के दौरान, प्रत्येक क्लासिफायरियर के लिए, इसकी अपनी विशेषताओं को धीरे-धीरे प्रकट किया गया था, जिसे एक समान दृष्टिकोण लागू करने का निर्णय लेने पर ध्यान में रखा जाना चाहिए।

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

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

इस संबंध में आराम के प्रेमियों के लिए, शायद JIRA प्लगइन के लिए सबकुछ बहुत मदद कर सकता है।

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

कार्यों के लिए अपनाई गई वर्गीकरण नियम न केवल खोज पर खर्च किए गए समय को कम करते हैं, बल्कि स्वचालित करने की क्षमता भी प्रदान करते हैं:

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

कार्यों को बांधते समय, अपने हाथों को न बांधें

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

स्रोत

JIRA "बॉक्स से बाहर" उपयोगकर्ता को कार्यों के बीच कई अलग-अलग प्रकार के कनेक्शन प्रदान करता है, और इन कनेक्शनों के अनियंत्रित उपयोग से दुखद परिणाम हो सकते हैं। अपने आप को और दूसरों को भ्रमित न करने के लिए, हम JIRA कार्य बंधन के लिए निम्नलिखित बुनियादी नियमों पर सहमत हुए हैं।

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

सभी अवसरों के लिए वर्कफ़्लो

कई परेशानियों का कारण यह है कि हम जितने कामों को पूरा करने की जरूरत है, उतने काम नहीं कर सकते हैं, और जितने पूरे कर सकते हैं।
मैक्सिम डोरोफीव

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

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

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






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

; विशेषताओं को राज्य से राज्य के दौरान होने वाले सभी कार्यों के लिए सामान्य रूप से बदलना निम्न तालिका में वर्णित है, जहां:

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

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

- फ़ील्ड मान साफ़ किया गया है।


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

जारी रखा जाए

हाल ही में, BPM प्रबंधन ( व्यवसाय प्रक्रिया प्रबंधन ) की अवधारणा , जो व्यवस्थित रूप से प्रक्रियाओं के प्रिज्म के माध्यम से कंपनी की गतिविधियों पर विचार करती है , व्यापक हो गई है । BPM की विचारधारा कई आधुनिक प्रबंधन Bibles का आधार है, जैसे:

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

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

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

स्रोत

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

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