2010-05-19 2 views
7

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

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

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

सॉफ्टवेयर की गुणवत्ता को बनाए रखने के दौरान, आप एक बड़े संगठन में सॉफ़्टवेयर की डिलीवरी तेज करने के लिए किस तकनीक का उपयोग करते हैं?

+2

ऐतिहासिक रूप से, वे वास्तव में नहीं है,। –

उत्तर

6

मैं भी एक बड़े और बोझिल संगठन में काम करता हूं। मैंने कई agile software development पद्धतियों को सफलतापूर्वक कार्यान्वित किया है, लेकिन विशेष रूप से दो हैं जिन्हें मैंने विशेष रूप से मूल्यवान पाया है।

Iterative और incremental विकास - अपने रिलीज चक्र को छोटा और तंग रखें। एक बड़ी टीम के पार, यदि रिलीज के बीच कई बदलाव किए जाते हैं, तो आप खुद को एकीकरण दुःस्वप्न में पा सकते हैं।

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

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

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

+1

+1 - दोनों पर सहमत हुए। समायोजन कठिन है, लेकिन मैंने तेजी से रिलीज चक्र देखा है (यहां तक ​​कि छोटे सुधारों के लिए) गुणवत्ता और मनोबल बढ़ाते हैं, और वे बड़े संगठन में दो बड़ी चुनौतियां हैं। – wlangstroth

+0

दोनों टिप्पणियों पर धन्यवाद, धन्यवाद dbyrne और विल। हम Agile लागू कर रहे हैं - जो गरीब डेवलपर्स को खोजने के लिए भी एक शानदार तरीका है। और हमारे पास यूनिट परीक्षण हैं (लेकिन कुछ अलग मामलों को छोड़कर, सही परीक्षण संचालित विकास नहीं)। मुझे लगता है कि वास्तव में यहां दो चुनौतियां हैं - 1 (जैसा ऊपर बताया गया है) - यह पहचानना कि हमें क्या बदलना है और फिर 2 को उस बड़े संगठन में लागू किया जा रहा है जहां बहुत से लोगों को कुछ नया करने की कोशिश करने के लिए राजी किया जाना चाहिए। – Wikis

4

Continuous-Integration

देखें और कृपया The Joel Test: 12 Steps to Better Code पढ़ें।

+0

लिंक स्टडीज जोसेफ लिंक के लिए, विशेष रूप से जोएल परीक्षण। मुझे लगता है कि हम स्कोर करते हैं 5. लेकिन सवाल एक बड़े संगठन को मिलकर काम करने के बारे में अधिक है - क्या उस पर्यावरण के लिए कुछ खास है? (वे अभी भी उपयोगी लिंक हैं, बेशक!) – Wikis

2

प्रक्रिया में सुधार करने के कई तरीके हैं, लेकिन मुख्य घटक modularity है। जिम्मेदारियों को स्पष्ट रूप से अलग करके (कोड और संगठन दोनों में) और स्पष्ट और सुसंगत इंटरफेस को परिभाषित करके, एक बड़ी टीम सभी छोटी टीमों को एक साथ बंधे काम कर सकती है।

+0

हां, मैट एस, आप मॉड्यूलरिटी के बारे में काफी सही हैं - धन्यवाद। हालांकि, अक्सर बड़ी कंपनियां बहुत कम विरासत कोड से निपट रही हैं जब वे छोटे थे ... इसलिए मॉड्यूलरिटी को पीछे से किया जाना चाहिए, और इसके लिए पर्याप्त समय नहीं है ... = :-) यह भी हिस्सा है समस्या - लंबी अवधि के डिजाइन पर विचार करने के बजाय अल्पकालिक सोच। – Wikis

1

समझदार लेकिन उदास बातें:

  • फ्रेड ब्रूक्स: Adding programmers to a late project makes it later

  • गेरी सुस्मान: प्रोग्रामर समानांतर में प्रतिरोधकों की तरह गठबंधन करते हैं।

  • कोई और: परियोजना की लागत प्रोग्रामर की संख्या शेड्यूल की लंबाई के समय की होती है।

कुछ ऐसा काम कर सकते हैं:

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

मैं भाषा के आधार पर उत्पादों की सोच रहा हूँ: SAS, S/R, MATLAB, आदि

+0

धन्यवाद माइक Dunlavey तारीफ के लिए। आपके उद्धरण मुझे द मिथिकल मैन महीने की याद दिलाते हैं। जबकि हम मैटलैब का उपयोग करते हैं, हम एक या दो लोगों को परियोजना को पुनरारंभ करने से परे हैं। इस सॉफ़्टवेयर में हजारों मैन-इन निवेश किए गए हैं (विरासत कोड पर मेरी पिछली टिप्पणी देखें)। – Wikis

+1

@ मार्क: बिल क्लिंटन का उद्धरण, मुझे आपका दर्द महसूस होता है। –

+0

धन्यवाद माइक Dunlavey! मुझे यह भी लगता है ... = :-( – Wikis

संबंधित मुद्दे