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