बहुत ज्यादा संस्करण नियंत्रण और बग ट्रैकिंग ओवरहेड प्रति परिवर्तन?

Question

मैं ऐसी जगह पर काम करता हूं जो सीवीएस-क्रेजी और बुग्जिला-नट्स है।

1. प्रत्येक रिलीज़ से इतनी अधिक शाखाएँ होती हैं कि कोई उन्हें गिन नहीं सकता। हर कोई लगातार ऑटो-मर्ज कर रहा है।

2. इस नौकरी में कोई तरलता नहीं है । सब कुछ लॉक-स्टेप लगता है । एक साधारण सी चीज के लिए भी 25 कदम लगते हैं। यह फैक्ट्री प्रोडक्शन लाइन पर होने जैसा नहीं है: यह हर दिन खुद एक फैक्ट्री स्थापित करने जैसा है।

उदाहरण स्थिति:

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

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

किसी भी अन्य नौकरी में, मैं बस में जाऊँगा और बग को ठीक करूँगा। मुझे बमुश्किल एससीएम का उपयोग करना भी याद है, हालांकि मैंने जो भी नौकरी की है, उसका उपयोग किया है: ऐसा इसलिए है क्योंकि हर दूसरे काम में, वे किसी न किसी तरह से इसे बाहर रखते हैं ।

क्या कोई बिंदु है जिस पर प्रक्रिया रास्ते में हो जाती है और अपने आप में एक अंत बन जाती है? क्या वह भी इंजीनियरिंग है?

Comments

आप के लिए बुरा लग रहा है :( कंपनी है जहाँ आपके काम कर रहे हैं CMMI 3 और अधिक है?

— Artjom

संगठन की तरह लगता है कि पहले बुरी तरह से काट लिया गया है और बचाव में वृद्धि हुई है। शायद आपको इस के इतिहास के बारे में पूछना चाहिए?

और जब से पर्यवेक्षक निरंतर विकर्षणों को प्रोत्साहित करते हैं, तो आपकी नौकरी एक वास्तविक नरक होनी चाहिए ...

— मदिरा

यह एक प्रश्न या एक ब्लॉग पोस्ट है?

— री मियासाका

यदि सॉफ्टवेयर एक परमाणु ऊर्जा संयंत्र के लिए नियंत्रण प्रणाली था तो यह अनुचित नहीं लगता। यदि एक फेसबुक फैन पेज के लिए यह अत्यधिक अत्यधिक लगता है। संदर्भ के बिना यह कहना मुश्किल है कि यह अनुचित है या नहीं: निश्चित रूप से ऐसी परियोजनाएं हैं जिनके लिए यह नहीं है, और अन्य जहां यह निश्चित रूप से है।

— edA-qa मोर्ट-ओरा-वाई

Answer 1

क्या कोई बिंदु है जिस पर प्रक्रिया रास्ते में हो जाती है और अपने आप में एक अंत बन जाती है?

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

यही कारण है कि कुछ अच्छे इंजीनियरों के साथ फुर्तीले स्टार्टअप बड़े, स्थापित निगमों को हरा सकते हैं, जिनके कार्यकर्ता अपनी ऊर्जा का 95% प्रक्रिया और रिपोर्टिंग पर खर्च करते हैं। छोटे स्टार्टअप के कुछ उदाहरण जिन्होंने एक बार अपने प्रतिद्वंद्वियों को हरा दिया और / या पूरी तरह से नए बाजार बनाए:

• Apple (Apple I को 1 इंजीनियर ने बनाया था ; कंपनी में 3 लोग थे तब वापस)।
• Google (मूल रूप से 2 प्रोग्रामर द्वारा बनाया गया )।
• फेसबुक ( मूल रूप से 1- प्रयास)।
• माइक्रोसॉफ्ट ( 1975 में 2- मैन कंपनी)।

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

Comments

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

— एरॉन

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

— आरोह ने

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

— आरोन

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

— एरोन

@Aaronaught: यह फोरम एक वैज्ञानिक पेपर नहीं है। कोई भी, न तो आप और न ही, मेरे द्वारा लिखे गए हर एक वाक्य के लिए एक स्पष्टीकरण प्रदान करने जा रहा है। आप केवल इस उत्तर के लिए पूछ रहे हैं क्योंकि आपको यह पसंद नहीं है। जाहिरा तौर पर यह तंत्रिका को हिट करता है, लेकिन सभ्य तरीके से असहमति के बारे में कैसे? स्टार्टअप्स के लिए बड़े निगमों की धड़कन के रूप में, उदाहरण के लिए उत्पाद विवरण के केवल दो पहले वाक्य पढ़ें: amazon.com/Radical-Innovation-Companies-Outsmart-Upstarts/dp/…

— Joon Pulakka

Answer 2

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

दूसरी ओर, यदि आपके पास अर्ध-कुशल कर्मचारियों की संख्या बहुत कम है और / या गलतियाँ करने की लागत बहुत अधिक है (जैसे उत्तरी गोलार्ध के ऊपर स्पेस शटल मलबे का खतरा) कंपनियां अधिक से अधिक नियमों का पालन करती हैं "और" प्रक्रियाएं "उन्हें आज़माने और कम करने के लिए।

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

यदि आप अपने आप को एक ऐसी कंपनी में पाते हैं, जो इस पहलू में कोई वापसी नहीं करने के बिंदु से आगे निकल गई है, तो आप अपनी नौकरी के बारे में "देखभाल न करने" के लिए खुद को हल कर सकते हैं (जो कि सबसे ज्यादा रुके हैं) या नरक से बाहर निकल रहे हैं अपनी आत्मा के साथ वहाँ बरकरार :)

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

Answer 3

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

अन्य सभी स्थितियों में लागत की अधिकता व्यवसाय को मार देगी। आगे बढ़ने का समय।

Comments

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

— पोंक

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

— maple_shaft

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

— एसएफ।

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

— Dainius

+1 यह इंगित करने के लिए कि ऐसी परिस्थितियाँ हैं (सॉफ्टवेयर में भी) जो इस स्तर के नियंत्रण के लिए आवश्यक हैं।

— रिवल

Answer 4

इस प्रश्न में वास्तव में दो प्रश्न हैं, जिन्हें अलग से संबोधित करने की आवश्यकता है:

कुछ टीमों के पास विकास की सख्त प्रक्रिया क्यों है?

सरल जवाब है क्योंकि अगर वे नहीं करते हैं, तो गलतियाँ होती हैं। महंगी गलतियाँ। यह विकास के लिए सच है और यह आईटी क्षेत्र के बाकी हिस्सों के लिए भी सच है (sysadmins, DBAs, आदि)।

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

लेकिन अगर आपने कभी इन चरणों के बीच में एक कंपनी देखी है - यहां तक ​​कि उज्ज्वल, प्रतिभाशाली आईटी कर्मचारियों वाली एक कंपनी - तो आप कोई प्रक्रिया नहीं होने या अर्ध-assed प्रक्रिया होने के खतरों को समझेंगे। आप देखते हैं, कर्मचारियों के बीच संचार एक Combinatorial धमाका समस्या से ग्रस्त है; एक बार जब आप किसी एकल टीम पर लगभग 6-10 डेवलपर्स के स्तर तक पहुंच जाते हैं, तो प्रमुख या महत्वपूर्ण दोषों का प्राथमिक कारण प्रतिभा की कमी या पता नहीं है, बल्कि संचार की कमी है।

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

ऐलिस और बॉब दोनों ने कोडिंग कार्यों पर बहुत अच्छा काम किया, लेकिन वे दोनों एक बुरे निर्णय के साथ शुरू हुए ("ऐसा क्या हो सकता है?")। टीम लीड या प्रोजेक्ट मैनेजर उन्हें पोस्टमार्टम के माध्यम से ले जाता है, और फिर से ऐसा करने से रोकने के लिए एक जाँच सूची तैयार करता है:

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

मैं शर्त लगाता हूँ कि, हम में से, यह "प्रक्रिया" सिर्फ सामान्य ज्ञान की तरह लगता है। यह पुरानी टोपी है। लेकिन क्या आप जानते हैं कि बहुत सी छोटी टीमें ऐसा नहीं करती हैं। एक दो सदस्यीय टीम भी स्रोत नियंत्रण के साथ बिल्कुल भी परेशान नहीं हो सकती है। किसे पड़ी है? यह ईमानदारी से आवश्यक नहीं है। टीम के बढ़ने पर ही समस्याएँ होने लगती हैं, लेकिन प्रक्रिया नहीं होती है।

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

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

चक्र तो चलता ही रहता है। आपके द्वारा देखी गई प्रत्येक "नीति" को आम तौर पर एक वास्तविक समस्या को हल करने के लिए स्थापित किया गया है। जैसा कि जोएल स्पोल्स्की ने २००० में वापस लिखा था (बिल्कुल अलग विषय पर आप, लेकिन प्रासंगिक फिर भी):

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

यदि वह सब कुछ चल रहा था, तो "नो स्नेक" संकेत भी होगा; आखिरकार, सांपों को कोई भी पसंद नहीं करता है। और "नो एलीफेंट" साइन, क्योंकि वे बैठने पर कुर्सियों को तोड़ते हैं।

असली कारण यह है कि संकेत नहीं है ऐतिहासिक है: यह एक ऐतिहासिक मार्कर इंगित करता है कि लोगों को रेस्तरां में अपने कुत्तों को लाने के लिए प्रयास करने के लिए प्रयोग किया जाता है।

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

यह बताता है कि प्रक्रियाएँ क्यों हैं, लेकिन यह पूरी कहानी नहीं है। अन्य आधा है:

प्रक्रिया का पालन करना इतना कठिन क्यों है?

यह वास्तव में जवाब देने के लिए सबसे सरल प्रश्न है: यह इसलिए है क्योंकि टीम (या इसका प्रबंधन) दोहराए जाने वाले परिणामों और कम करने वाले दोषों (ऊपर के रूप में) पर केंद्रित है लेकिन उस प्रक्रिया के अनुकूलन और स्वचालन पर पर्याप्त ध्यान नहीं दिया है।

उदाहरण के लिए, मूल प्रश्न में, मुझे कई समस्याएं दिखाई देती हैं:

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

• वर्चुअल मशीन प्रक्रिया को स्वचालित करने में कोई समय नहीं लगाया गया है। वर्चुअल मशीन पर स्रोत / लाइब्रेरी को प्राप्त करने, कॉन्फ़िगर करने और डाउनलोड करने की पूरी प्रक्रिया 100% स्वचालित हो सकती है। यह एक अप्राप्य प्रक्रिया हो सकती है जिसे आप केंद्रीय सर्वर पर चलाते हैं, जबकि आप अपने स्थानीय मशीन पर बग फिक्स पर काम करते हैं (और केवल स्वच्छ निर्माण का आश्वासन देने के लिए वीएम का उपयोग करते हैं)।

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

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

• कहने की जरूरत नहीं है कि बुगज़िला से एक नए (बेहतर) बग ट्रैकिंग सिस्टम पर जाने से अनुभव का वह हिस्सा बहुत कम दर्दनाक होगा।

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

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

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

---

यदि डेवलपर्स ने एक सप्ताह का समय सभी गैर-कोडिंग कार्यों पर अपने समय को ट्रैक करने में बिताया, तो आप इसे आसानी से जोड़ सकते हैं, प्रबंधन दिखा सकते हैं ... और इसे लागत-लाभ समीकरण आदि में बदल सकते हैं ...

ऊपर का हिस्सा आगे विस्तार के लायक दिखता है।

मैं पुष्टि कर सकता हूं कि यह काम करता है। प्रोग्रामर्स ने मेरे द्वारा काम की गई परियोजनाओं में से कुछ में इसका इस्तेमाल किया और हर बार इसे वांछित बदलावों के लिए प्रेरित किया।

मेरी समग्र धारणा थी कि अगर सही किया जाता है, तो यह चाल प्रबंधन की अज्ञानता और जड़ता की काफी भारी मात्रा को खत्म कर सकती है ।

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

Answer 5

यदि आप एक भारी विनियमित उद्योग में काम कर रहे हैं, तो उस बोझिल प्रक्रिया के लिए कुछ कारण हो सकते हैं: एक दिन आपको ऑडिट किया जा सकता है और आपको यह बताने के लिए अपने सभी रिकॉर्ड दिखाने होंगे कि किसने उस बग को ठीक किया, कैसे, किसने इसकी समीक्षा की, जिसने परीक्षण किया यह, आदि ...

तो यह एक आवश्यक बुराई हो सकती है।

दूसरी ओर, अगर उस प्रक्रिया का कोई औचित्य नहीं है, हो सकता है कि प्रबंधन से भरोसे की कमी के अलावा, आपको अपने प्रबंधक से बात करने की कोशिश करनी चाहिए और उसे बताना चाहिए कि आप कंपनी के लिए समय (और इस तरह से पैसे) कैसे बचा सकते हैं।

इसके सही दिमाग में कोई भी नहीं है जो इसे सही तरीके से समझाया जाए तो यह तेज और बेहतर प्रक्रिया को नकारता है।

लेकिन बदलाव को सही ठहराने के लिए अपने तर्क का बचाव करने के लिए तैयार रहें।

Comments

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

— पोंक

इस तरह की प्रक्रियाएं हालांकि यह मानती हैं कि वर्तमान कार्यान्वयन प्राचीन और दोष मुक्त है। इस तरह की प्रक्रिया को अनिवार्य रूप से एक टूटे हुए उत्पाद में लॉक करना वास्तविक खतरा है।

— eda-qa mort-ora-y

"इसके सही दिमाग में कोई भी नहीं है जो सही तरीके से समझाए जाने पर तेज और बेहतर प्रक्रिया से इनकार करता है।" --- मैं बहुत सोच सकता हूं कि एजेंडा एक निर्णय निर्माता का अनुसरण हो सकता है जहां यह कथन सही नहीं है।

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

— maple_shaft

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

Answer 6

आधी समस्या यह है कि आप एक प्रक्रिया में अप्रचलित साधनों का उपयोग कर रहे हैं, कि वे जहां के लिए डिज़ाइन नहीं किए गए हैं। आप जो वर्णन करते हैं वह आधुनिक DVCSes में बहुत आसान है, बग के प्रति शाखा बनाने के थकाऊ काम के बिना।

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

Answer 7

सॉफ्टवेयर इंजीनियरिंग का अनुशासन स्वाभाविक रूप से "प्रक्रिया के बारे में सब कुछ" तो आश्चर्य की बात है कि अगर यह "बन गया है" तो इस तरह से बिंदु गायब होने का एक तरीका है।

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

आपकी कंपनी एक डेटा बिंदु है, और भारी-भरकम प्रक्रियाओं से दूर या दूर उद्योग-व्यापी प्रवृत्ति में अपने अनुभव को सामान्य बनाना असंभव है। असली सवाल यह है कि आपकी कंपनी, आपके उत्पादों, आपके ग्राहकों और आप, व्यक्तिगत रूप से, प्रोग्रामर के रूप में क्या संतुलन सबसे अच्छा काम करता है? यदि आप उस कंपनी के लिए काम करना पसंद नहीं करते हैं, तो बदलाव को प्रेरित करें या दूसरी नौकरी प्राप्त करें।

Comments

"सॉफ्टवेयर इंजीनियरिंग का अनुशासन" के लिए +1। यह है शब्द के सभी होश में एक अनुशासन,।

— डेन रे

Answer 8

आज जो दूसरा प्रश्न मैंने आपसे देखा है, उससे आप अपनी नौकरी से बहुत दुखी हैं। आप लंबे समय तक नहीं रहे हैं, आप अपने पर्यवेक्षक को बता सकते हैं कि आपको लगता है कि आपने गलती की है, और यह आपके लिए उम्मीद से पहले के तरीकों का हिस्सा है।

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

Comments

अवलोकन अवलोकन :) मैं साक्षात्कार कर रहा हूँ।

— पोंक

सीवीएस मैं साथ रह सकता हूं, कुछ कंपनियों ने मैंने साक्षात्कार के लिए एलआईईडी टू मी के लिए काम किया है कि मैं सिल्वरलाइट के साथ डब्ल्यूसीएफ / आरआईए वेब सेवाएं कर रहा हूं और इसके बजाय मुझे एक प्राचीन पावरबिल्डर आवेदन पर रखा गया था और अभी भी वीएसएस 6 का उपयोग कर रहा था

— मेपल_शफ्ट

ahh ouch @maple_shaft, यह कठोर है। फिर भी सोचें कि आप ग्रैंड किडिज़ को क्या बता सकते हैं ... मैंने पावरबिल्डर ऐप पर काम किया ...: डी # जीवन-विफल

— बेनामी टाइप

Answer 9

मैं इस बारे में बताने जा रहा था कि कैसे सॉफ्टवेयर इंजीनियरिंग बहुत खराब प्रोग्रामर के साथ भर रही है, लेकिन आप जिस स्थिति का वर्णन करते हैं वह भयानक है।

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

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

उद्यम के पहियों को रोल करने में बहुत मज़ा नहीं है, लेकिन मैंने पाया है कि नवाचार, रचनात्मकता और प्रतिभा के छोटे बुलबुले कुछ कंपनियों में मौजूद हैं।

Comments

एक भयानक परिदृश्य में चमक खोजने की कोशिश करने के लिए +1।

— बेनामी टाइप

Answer 10

आप शायद एक प्रक्रिया उन्मुख कंपनी में काम करते हैं । मैं इसके बजाय एक परिणाम उन्मुख कंपनी खोजने की कोशिश करूंगा , जहां यह मायने रखता है कि आप क्या नहीं करते हैं।

मेरी कंपनी में हमारे पास एक "प्रक्रिया" भी है (लेकिन यह बहुत सरल है) .. लेकिन जब यह रास्ते में हो जाता है तो मैं नियम तोड़ता हूं और कदमों को छोड़ देता हूं। कोई भी मुझे कभी भी कुछ नहीं कहेगा क्योंकि मैं शॉर्टकट लेकर कुछ भी नहीं तोड़ता क्योंकि मुझे परिणाम मिलते हैं।

Answer 11

क्या कोई बिंदु है जिस पर प्रक्रिया रास्ते में हो जाती है और अपने आप में एक अंत बन जाती है? क्या वह भी इंजीनियरिंग है?

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

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

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

जैसा कि अन्य टिप्पणीकारों ने उल्लेख किया है, सीवीएस उच्च-शाखाओं वाले विकास मॉडल के लिए नौकरी का सबसे अच्छा साधन नहीं है, लेकिन मैं यह भी ध्यान देता हूं कि आप विलय के लिए जिम्मेदार नहीं हैं ... इसलिए इसके बारे में चिंता न करें।

आपकी अधिकांश शिकायतें अनिवार्य रूप से प्रतीत होती हैं "मुझे विकास के दौरान या बाद में परीक्षण नहीं करना है!" चलो अपने कदम नीचे तोड़ो, बिंदु से इंगित करें।

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

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

इस प्रक्रिया के बारे में दूरस्थ या असामान्य रूप से केवल एक ही चीज़ VM चीज़ है। एक उचित मौका है जिसे उचित माना जाएगा यदि हम जानते हैं कि आप किस डोमेन में काम कर रहे हैं।

Answer 12

दिलचस्प। क्या आपके पास परीक्षक हैं? उन्हें कुछ करना चाहिए। मैं एक हूं, और जहां मैं काम करता हूं हमारे पास एक सभ्य समाधान है।

एक कार्यात्मक दोष के लिए, जैसे आप समझा रहे हैं, हमारी प्रक्रिया इस प्रकार है:

1. मैं वीएम में दोष के लिए परीक्षण करता हूं (या तो ग्राहक द्वारा रिपोर्ट किया जाता है, या मेरे खोजपूर्ण परीक्षण के दौरान, या डब्ल्यू / ई)
2. बग पाया जाता है / repro'd।
3. मैं बग बनाता हूं। कीड़े शामिल हैं:
   • बग को देखने के लिए स्थापना के बिंदु से पूर्ण रिप्रो।
   • VM के एक स्नैपशॉट का लिंक
   • सिस्टम की जानकारी, कोई विशेष सेटिंग जो मुझे बनाने की आवश्यकता थी।
4. वह बग देव को सौंपा जाता है। जब वे एक तय I पर काम कर रहे हैं:
   • टेस्ट केस बनाएं
   • मैन्युअल परीक्षण को एक स्वचालित परीक्षण में लिखें या परिवर्तित करें

फिर मैं एक संकल्प की प्रतीक्षा करता हूं, और देव की किसी भी तरह से मदद करता हूं, जिसकी उन्हें जरूरत है। जब यह हल के रूप में वापस आता है, मैं:

1. फिक्स की पुष्टि के लिए स्वचालित परीक्षण मामले और एक मैनुअल संस्करण (कभी-कभी) चलाएं।
2. बग को बंद करें।

TL; DR: यदि आपके पास परीक्षक नहीं हैं, तो आपको कुछ चाहिए। यदि आपके पास कुछ है, तो वे 'अपना हिस्सा' नहीं कर रहे हैं।

Answer 13

टॉम डेमार्को:

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

... जितना अधिक आप नियंत्रण पर ध्यान केंद्रित करते हैं, उतनी ही संभावना है कि आप एक ऐसी परियोजना पर काम कर रहे हैं जो अपेक्षाकृत मामूली मूल्य के कुछ देने के लिए प्रयास कर रही है।

मेरे दिमाग में, यह सवाल बहुत महत्वपूर्ण है कि सॉफ्टवेयर प्रोजेक्ट को कैसे नियंत्रित किया जाए, पृथ्वी पर हम इतने सारे प्रोजेक्ट क्यों कर रहे हैं जो इस तरह के मामूली मूल्य प्रदान करते हैं? ...

सॉफ्टवेयर इंजीनियरिंग: एक आइडिया किसका समय और आया है?

Comments

क्या यह स्पष्ट नहीं है? पैसा बनाने के लिए। गंदे सेक्सी पैसे।

— maple_shaft

Answer 14

"फिर मैं उस सिंगल बग फिक्स के लिए एक शाखा बनाता हूं,"

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

Answer 15

मुझे लगता है कि अधिकांश प्रक्रिया स्वचालित हो सकती है , ताकि बग पर काम शुरू करने से पहले वर्चुअल मशीन और शाखा निर्माण (संकलन कोड, डिबगर स्थापित करना आदि) आपके लिए किया गया था।

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

इसलिए मुझे लगता है कि यह प्रक्रिया "शीर्ष पर" थोड़ी हो सकती है, लेकिन यह है कि वास्तविक समस्या प्रक्रिया का समर्थन करने के लिए कस्टम स्वचालित टूल की कमी है।

Answer 16

यो यार, आपकी सोची हुई प्रक्रिया सही है कि आपने जो बताया वह पूरी तरह से भद्दा है और एक गलत प्रदर्शन है कि सॉफ्टवेयर में गलत चीजें कैसे हो सकती हैं। यहाँ अच्छी खबर है, हालांकि, वहाँ कई कंपनियां हैं जो सच्ची आत्माओं में एजाइल का अभ्यास कर रही हैं। मैं जिस कंपनी में काम करता हूं, वह एक ऐसी है। इन दिनों और thatz असली खुशखबरी कई हैं।

जिस समय आपको समझ में आता है कि आपके कार्यस्थल पर चीजें वास्तव में सही नहीं हैं, तो दो ऐसी चीजें हैं जो आप कर सकते हैं - या तो आप सकारात्मक परिवर्तन को प्रभावित कर सकते हैं या उस स्थान को छोड़ सकते हैं और एक बेहतर जुड़ सकते हैं।

CVS या कोई भी विन्यास प्रबंधन प्रणाली खराब नहीं है। दुर्भाग्य से जिस तरह से इसका उपयोग किया जाता है, वास्तव में इसके उद्देश्य को जाने बिना, पूरे संगठन के लिए इस # दर्द का कारण बनता है! @ # $।

फुर्तीला सुब्रमण्यम द्वारा लिखी गई किताब "प्रैक्टिस ऑफ ए एजाइल डेवलपर" के माध्यम से एजाइल वास्तव में क्या है, इसकी त्वरित समझ पाने के लिए। आसानी से समझने योग्य भाषा में इसकी अच्छी तरह से लिखी गई है।

अच्छे नसीब की शुभकामनाय!