अनिद्रा और तंत्रिका टूटने के लिए एक उपाय के रूप में JIRA

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

स्रोत

मुश्किल गलतियों का बेटा

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

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

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

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

राष्ट्रीय विकास की विशेषताएं

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

स्रोत

इसके अलावा, सॉफ़्टवेयर विकास के सर्वोत्तम तरीकों के अनुसार इन समस्याओं को हल करने के लिए बार-बार प्रयास किए जाने से निष्कर्ष निकला: ये समस्याएं नहीं हैं, लेकिन राज्य ग्राहक के लिए परियोजना के कार्यान्वयन के लिए अपरिहार्य स्थितियां हैं। कई परियोजनाओं के विश्लेषण ने हमें ऐसी स्थितियों की निम्नलिखित सामान्यीकृत विशेषता विशेषताओं की पहचान करने की अनुमति दी:

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

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

बाहरी स्थितियों के अलावा, जैसा कि यह निकला, सॉफ्टवेयर प्रोजेक्ट में शामिल कर्मचारियों की टीमों द्वारा साझा की जाने वाली सामान्य विशेषताओं को साझा किया गया है।

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

आशा की जीत

दूसरा विवाह जीवन के अनुभव पर आशा की जीत है।
सैमुअल जॉनसन

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

JIRA को ऑटोमेशन प्लेटफॉर्म के रूप में चुना गया था। निम्नलिखित कारकों के संयोजन ने इस विकल्प में योगदान दिया:

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

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

परियोजना प्रबंधन स्वचालन ने शुरू में निम्नलिखित लक्ष्यों का पीछा किया:

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

"स्वचालन के लिए स्वचालन" से बचने के लिए, JIRA में डेटा लेखांकन मॉडल को डिज़ाइन करते समय निम्नलिखित बातों (सीमाओं) को भी ध्यान में रखा गया है:

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

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

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

सिस्टमैटिक। परियोजना प्रबंधन के स्वचालन को परियोजना टीम के सभी कर्मचारियों के कार्यों के सुसंगतता और सुसंगतता में योगदान करना चाहिए ("हंस, कैंसर और पाईक" की स्थिति को रोकना)।

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

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

अंदर बाहर कानन बोर्ड

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

स्रोत

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

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

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

यह ध्यान दिया जाना चाहिए कि "ऑन होल्ड" स्थिति की शुरूआत ने वास्तव में परियोजना टीम के कर्मचारियों के लिए " कन्वेयर स्टॉप बटन " को लागू किया , जिसने परियोजना के शुरुआती चरणों में समस्याओं की सामूहिक पहचान सुनिश्चित की।

विश्लेषण के परिणामस्वरूप, जेआईआरए के साथ परियोजना की जानकारी दर्ज करने के लिए निम्नलिखित मॉडल लागू किया गया था। JIRA द्वारा प्रस्तुत मानक कार्य साझाकरण दृष्टिकोण परियोजना में उपयोग नहीं किया गया था। छह प्रकार के कार्य बनाए गए थे, जो संक्षेप में सॉफ्टवेयर विकास के मुख्य चरणों के अनुरूप थे:

1. "आवश्यकता" - ग्राहक की आवश्यकताओं को पंजीकृत करने के लिए कार्य का प्रकार (JIRA के नए संस्करणों में समान - महाकाव्य);
2. «» – , ( ) ( ) ( JIRA – story);
3. «» – ;
4. «» – , ;
5. «» – , ;
6. "कार्यान्वयन" ग्राहक के कार्यकलापों में विकसित सॉफ्टवेयर पेश करने के लिए किए गए कार्य के परिणामों को रिकॉर्ड करने के लिए कार्य का प्रकार है (परीक्षण, प्रदर्शनों को जारी करना, एक रिलीज / पैच / डेटाफिक्स जारी करना, ग्राहक के सर्वर पर सॉफ्टवेयर को तैनात करना, उपयोगकर्ताओं को प्रशिक्षित करना, आदि)।

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

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


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

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


कार्यों की स्थिति प्रदर्शित करने के लिए, निम्नलिखित रंग योजना को अपनाया गया था:

• नीला - कार्य योजना में शामिल है;
• नीला - कार्य प्रगति पर है;
• गुलाबी - कार्य में कोई निष्पादक नहीं है;
• पीला - कार्य लंबित है, समाधान की आवश्यकता है;
• ग्रे - कार्य बंद है (आप इसके बारे में भूल सकते हैं);
• नारंगी - कार्य पूरा करने की समय सीमा बाधित हो गई।

टास्क कार्ड पर लाल शिलालेखों और निशानों का दिखना कार्य के संबंध में तत्काल कार्रवाई की आवश्यकता को दर्शाता है (उदाहरण के लिए, शिलालेख लाल रंग में प्रदर्शित किया गया है यदि समय सीमा निर्धारित नहीं की गई है)।

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

प्राथमिकता लेबल:

- सामान्य;

- महत्वपूर्ण;

- महत्वपूर्ण;

- अवरुद्ध करना।

आवश्यकताओं के ढांचे के बारे में लेबल:

- विकास (मौजूदा प्रणालियों के पर्याप्त संशोधन के उद्देश्य से परियोजनाओं के ढांचे के भीतर की आवश्यकताएं);

- विस्तारित समर्थन (ग्राहक की व्यावसायिक प्रक्रियाओं में वर्तमान परिवर्तनों के लिए व्यक्तिगत सिस्टम मॉड्यूल के संचालन के लिए आवश्यकताएं);

- वारंटी समर्थन (सॉफ्टवेयर त्रुटियों का पता चला);

- गैर-परियोजना गतिविधियाँ (पूर्व-परियोजना गतिविधियों से संबंधित परियोजना प्रबंधक की आवश्यकताएँ, रीफैक्टरिंग , प्रेजेल , नई तकनीकों का विकास, स्टाफ प्रशिक्षण आदि)।

अपेक्षा के कारण के लेबल:

- ग्राहक से अतिरिक्त जानकारी के लिए अनुरोध;

- ग्राहक के साथ समन्वय;

- संबंधित कार्यों / उपशीर्षक के समाधान की प्रतीक्षा कर रहा है;

- सूत्रीकरण का स्पष्टीकरण आवश्यक है।

विशेष टैग:

- कार्य में डेटाबेस को अंतिम रूप दिया गया है;

- कार्य से संबंधित आवश्यकताओं की संख्या (अधिक संबंधित आवश्यकताएं, कार्य जितना महत्वपूर्ण है);

- अनसुलझे उपशीर्षक की संख्या;

- कार्य को फिर से खोजा जाता है।

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

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

झरना फुर्तीला नहीं हो सकता

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

JIRA में कार्यों को पंजीकृत करने के लिए प्रस्तावित दृष्टिकोण का उपयोग करते हुए कार्य संगठन को निम्न योजना में घटा दिया गया था।

1. JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
2. , . , , , . () .
3. , , . , , ( ), () , , , ( ).
4. ( ) , , . . , . «» , ( ).
5. आदर्श रूप से, विकास कार्यों को दर्ज करने से पहले परीक्षण कार्यों का गठन किया जाना चाहिए (जो प्रोग्रामर के लक्ष्यों को निर्दिष्ट करता है)। परीक्षण के दौरान, जिम्मेदार परीक्षक न केवल ज्ञात त्रुटियों का एक लॉग रखता है, बल्कि परीक्षण कार्य और उपयोगकर्ता पुस्तिका में पता लगाए गए अशुद्धियों को भी ठीक करता है।
6. आवश्यकताओं के अनुसार, जिसके अनुसार कार्यों की एक पूरी सूची की योजना बनाई गई थी, कार्यान्वयन कार्य बनते हैं (पंजीकरण के दौरान आवश्यकताओं के कार्यान्वयन के लिए प्राथमिकता और समय सीमा फिर से जेआईआरए में निर्दिष्ट की जाती है)।
7. ग्राहक को डिलीवरी के बाद, अनुरोध को स्वीकृति दस्तावेज के विवरण के अनिवार्य संकेत के साथ "बंद" स्थिति में स्थानांतरित किया जा सकता है।

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

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

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

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

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

जारी रखा जाए

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

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

नए नियमों के तहत JIRA को लागू करने के दो साल के अनुभव ने पुराने सत्य की पुष्टि की है:

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

और सबसे महत्वपूर्ण बात - JIRA आपके लिए यह तय नहीं करेगा कि आप इसकी मदद का उपयोग करेंगे या नहीं।

रुचि के लिए नौकरियां LANIT