विकास प्रक्रिया पर एक नजर

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

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

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

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

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

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

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

“आप नियंत्रित नहीं कर सकते कि क्या नियंत्रित करना असंभव है,
और जिसे मापा नहीं जा सकता, उसे नियंत्रित नहीं किया जा सकता है। ”

वर्कफ़्लो का दृश्य नियंत्रण भी एक अच्छी तरह से स्थापित प्रक्रिया का एक महत्वपूर्ण घटक है। कानबन पद्धति मेरे करीब है, लेकिन कुछ अतिरिक्त के साथ। मैंने यह पता लगाने की कोशिश की कि ऐसा कंबन बोर्ड कैसा दिख सकता है:

निम्नलिखित संकेतन का उपयोग यहां किया गया है:

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

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

सारांश के रूप में, मैं फिर से प्रक्रिया के प्रमुख बिंदुओं को सूचीबद्ध करूंगा:

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