जोएल परीक्षण कितना अप-टू-डेट है? [बन्द है]

Question

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

Comments

जोएल टेस्ट सॉफ्टवेयर डेवलपमेंट और डेवलपर हायरिंग प्रक्रियाओं पर निर्देशित है। जिस तरीके से आप अपने सॉफ़्टवेयर को लाइसेंस देते हैं या आप उससे संबंधित अपना स्रोत प्रकाशित करते हैं या नहीं करते हैं?

— मार्जन वेनेमा

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

— निकल्स

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

— मार्जन वेनेमा

मेरे साथ ज्ञान साझा करने के लिए धन्यवाद। यह सच है कि बैकअप महत्वपूर्ण है, लेकिन विकास विशिष्ट नहीं है।

— निकोलस

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

— gnat

Answer 1

मुझे लगता है कि जोएल परीक्षण आज तक है - यह उतना ही अद्यतित है जितना कि अन्य सॉफ्टवेयर लेखन जो कि "कालातीत" है।

एक कल्पना के बिना उत्पाद विकास (जिसमें सॉफ्टवेयर विकास शामिल है) करना केवल पागलपन है।

आप कैसे जानते हैं कि आप कहाँ जाना चाहते हैं?

केवल एक ही बिंदु है जो मैं एक युक्ति लिखने के बारे में करूँगा (मुझे नहीं लगता कि वास्तव में जोएल का चश्मा बहुत अच्छा है ... कुछ भी नहीं से बेहतर है, लेकिन उतना अच्छा नहीं जितना कि हो सकता है)। वह बिंदु है:

युक्ति लिखते समय, केवल यह कहें कि उत्पाद क्या करना चाहिए, न कि यह कैसे किया जाए।

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

[इस नियम का केवल एक अपवाद है: कभी-कभी एक विशेष कार्यान्वयन विवरण या विधि अनिवार्य या आवश्यक है, जिस स्थिति में इसे रखा जाता है। उदाहरण के लिए, यदि सॉफ़्टवेयर को PHP में लिखा जाना चाहिए और यह परक्राम्य नहीं है, तो यह अंदर चला जाता है। कल्पना। इसके बहुत कम उदाहरण होने चाहिए।]

मैं जोड़ सकता हूं: बग ट्रैकिंग न होना समान पागलपन का कार्य है। यह बस संचालित करने के लिए सबसे अधिक लाभहीन और मूर्खतापूर्ण तरीका है और बहुत दर्द और पीड़ा देगा।

Comments

बहुत शीघ्र और मूल्यवान उत्तर के लिए धन्यवाद। पागलपन का एक और उदाहरण जो मुझ तक पहुंचा वह कथन था कि हर चीज की प्राथमिकता समान होनी चाहिए। ऐसा लगता है कि इन पागल नियमों के विपरीत करने से सफलता मिलेगी।

— निकल्स

"हर चीज की समान प्राथमिकता होती है" - "सब कुछ # 1" के रूप में भी जाना जाता है। यह स्पष्ट रूप से, बकवास है। सब कुछ प्राथमिकता से, क्रूरता से, HARM TO THE BUSINESS के संदर्भ में होना चाहिए। फिर आप # 1 पर काम करते हैं। यदि आपको किसी कारण से # 1 पर रोक दिया जाता है, तो आप # 2 पर काम करते हैं। और इसी तरह। यदि आपके पास कुछ ऐसे लोग हैं जो किसी कारण से # 1 पर काम नहीं कर सकते हैं और वे # 9 पर काम करना समाप्त करते हैं - तो ठीक है बशर्ते एक अच्छा कारण हो। ("मुझे यह पसंद आया और यह और इसके कोयूओल" एक अच्छा कारण नहीं है)। फिर से प्राथमिकता देना भी ठीक है। साप्ताहिक से अधिक बार ऐसा करना भी पागलपन है।

— जल्‍दी से जल्‍दी से

ज्ञान के लिए धन्यवाद। मैं पूरी तरह सहमत हूं कि हर चीज को प्राथमिकता दी जानी चाहिए। मेरे साथी ने यह भी कहा कि हमारे पास कोई मुद्दा नहीं होना चाहिए और कोई मुद्दा ट्रैकर नहीं होना चाहिए। लेकिन मुझे लगता है कि मुद्दों का दस्तावेजीकरण सही है और यहां तक ​​कि बाजार के नेता भी मुद्दे पर नजर रखते हैं। फिर से, नियम के विपरीत काम करना होगा ...

— निकल्स

@ 909Niklas आपको शायद अपने भावी जीवन को और अधिक आरामदायक रखने के लिए एक और साथी प्राप्त करना चाहिए ...

— मार्सेल

+1 बस के लिए: जब कोई युक्ति लिखते हैं, तो केवल यह कहें कि उत्पाद को क्या करना चाहिए, न कि यह कैसे करना है।

— मार्सेल

Answer 2

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

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

दूसरे, "दैनिक बिल्ड" प्रश्न को निरंतर एकीकरण के बारे में एक प्रश्न में बदलना चाहिए। जब तक आप ऐसे सॉफ़्टवेयर का निर्माण नहीं कर रहे हैं, जिन्हें बनाने में घंटों लगते हैं (जो 99.99% स्थानों पर काम नहीं कर रहे हैं), तो सवाल यह पूछना चाहिए कि क्या कंपनी निरंतर एकीकरण का उपयोग करती है।

जोएल परीक्षण के अधिकांश वास्तव में सब पर दिनांकित नहीं है। यह अभी भी काम के माहौल का संकेत पाने का एक अच्छा तरीका है।