योएल टेस्ट का निर्धारण कितना अच्छा अपनी टीम के लिए एक अच्छी तरह से ज्ञात परीक्षण है। आप बिंदुओं के बारे में क्या सोचते हैं? क्या आप उनमें से किसी से असहमत हैं? क्या आप कुछ जोड़ना चाहेंगे?
योएल टेस्ट का निर्धारण कितना अच्छा अपनी टीम के लिए एक अच्छी तरह से ज्ञात परीक्षण है। आप बिंदुओं के बारे में क्या सोचते हैं? क्या आप उनमें से किसी से असहमत हैं? क्या आप कुछ जोड़ना चाहेंगे?
जवाबों:
जेफ एटवुड के पास द प्रोग्रामर बिल ऑफ राइट्स हैं ।
पोस्ट से:
- प्रत्येक प्रोग्रामर के पास दो मॉनिटर होंगे
- प्रत्येक प्रोग्रामर के पास एक तेज़ पीसी होगा
- प्रत्येक प्रोग्रामर के पास माउस और कीबोर्ड का विकल्प होगा
- प्रत्येक प्रोग्रामर के पास एक आरामदायक कुर्सी होगी
- प्रत्येक प्रोग्रामर के पास तेज़ इंटरनेट कनेक्शन होना चाहिए
- प्रत्येक प्रोग्रामर के पास काम करने की शांत स्थिति होगी
ऐसा लगता है कि कुछ आइटम हैं जो मैं जोएल की सूची में देखना चाहता हूं। विशेष रूप से हार्डवेयर के क्षेत्र में (दोहरी मॉनिटर, तेज पीसी, माउस / कीबोर्ड, आरामदायक कुर्सी, तेज कनेक्शन)।
केवल एक चीज का उल्लेख नहीं किया गया है जिसमें एक आरामदायक और समायोज्य डेस्क है ।
यह सब बदलकर जोड़ा जा सकता है:
वर्तमान # 9: क्या आप उन सर्वोत्तम औज़ारों का उपयोग करते हैं जिन्हें पैसे खरीद सकते हैं?
सेवा
बेहतर # 9: क्या आप सबसे अच्छा उपकरण का उपयोग करते हैं और उपकरण पैसे खरीद सकते हैं?
यह दिलचस्प है कि बिंदु 8 अब पढ़ता है:
8. Do programmers have quiet working conditions?
जब वह पढ़ता था (कुछ इस तरह)
8. Do programmers have their own office?
और अंतिम पैराग्राफ अभी भी शुरू होता है:
अब चलो उन्हें दीवारों और दरवाजों के साथ अलग-अलग कार्यालयों में स्थानांतरित करें।
मुझे हमेशा इस परीक्षण पर संदेह था कि मैंने जितने स्थानों पर काम किया है - दोनों कर्मचारी और आगंतुक के रूप में - केवल अपने कार्यालयों वाले लोग ही निदेशक और वरिष्ठ प्रबंधक हैं।
वास्तविक दुनिया में सॉफ्टवेयर लिखना आमतौर पर एक टीम गतिविधि है, आपको अपने टीम के साथियों से विचारों को उछालने आदि के लिए बात करने की आवश्यकता होती है और जो अलग-अलग कार्यालयों में लोगों के साथ त्वरित मैसेजिंग सिस्टम के साथ भी करना मुश्किल है। चीजों को बाहर निकालने और लोगों को कोड और आरेख दिखाने में सक्षम होने से बहुत हद तक मदद मिलती है। यह कहना नहीं है कि वितरित टीमें काम नहीं कर सकती हैं - वे स्पष्ट रूप से कर सकते हैं और कर सकते हैं, यह सिर्फ समस्याओं का एक अलग सेट है।
मैं क्या कहूंगा कि प्रत्येक टीम को 6-8 लोगों का अपना कार्यालय होना चाहिए (यह मानते हुए कि टीम का आकार है)। इस तरह वे अन्य टीमों को परेशान किए बिना बातचीत कर सकते हैं (यदि कोई हो) और बिक्री टीम या आगंतुकों द्वारा परेशान किए बिना अपने काम पर लग जाएं (एक जगह मैंने काम किया तो आप सीधे विकास क्षेत्र में सामने के दरवाजे के माध्यम से आए)।
यदि आप अन्य डेवलपर्स के साथ काम कर रहे हैं, लेकिन प्रत्येक अलग-अलग परियोजनाओं पर काम कर रहा है, तो एक साझा कार्यालय उपयोगी हो सकता है - लेकिन केवल अगर आप मीटिंग रूम में बैठकें लेने और अन्य लोगों की समय सीमा आदि का सम्मान करने के बारे में सख्त हैं।
दूसरों के अधिकांश स्वयं स्पष्ट सत्य हैं।
मेरे लिए एकमात्र सौदा ब्रेकर है:
8. Do programmers have quiet working conditions?
दिलचस्प यह है कि यह सवाल स्टैक ओवरफ्लो नौकरी पोस्टिंग द्वारा विफल होने की सबसे अधिक संभावना है।
कुछ सवालों को फेल होना मुश्किल है, खासकर अगर कंपनी में एक से अधिक प्रोग्रामर हैं:
1. Do you use source control?
2. Can you make a build in one step?
4. Do you have a bug database?
दूसरों के बारे में मैं वास्तव में परवाह नहीं है। मेरा मतलब है, ईमानदारी से:
12. Do you do hallway usability testing?
झूठा पता लगाने के लिए एक है:
5. Do you fix bugs before writing new code?
मेरा कहना है कि यह एक अच्छा "आधार रेखा" है, लेकिन किसी भी मापने के उपकरण के साथ अन्य कारक हैं। उदाहरण के लिए, मैंने जिस कंपनी के लिए काम नहीं किया है, उसने डेली बिल्ड्स (मुझे पता है, मुझे पता है) किया है, लेकिन उनमें से कुछ बहुत अच्छे हैं।
मेरे पास व्यक्तिगत रूप से कुछ अन्य आइटम हैं जिन्हें मैं एक सूची में जोड़ूंगा।
कुछ भी नहीं है कि इन मदों में पिछले नियोक्ताओं से "मुझे नाराज कर दिया" है, और अच्छी तरह से वे अब तेजी से ट्रैक सवाल है कि मैं हर अवसर के बारे में पूछ रहे हैं।
मैं जोएल के अधिकांश बिंदुओं से सहमत हूं। मैं "दालान प्रयोज्य परीक्षण" के बारे में इतना निश्चित नहीं हूं। प्रयोज्यता परीक्षण, निश्चित, लेकिन वास्तव में दालान से किसी को पकड़कर उन्हें अपने कार्यक्रम का परीक्षण करना, भले ही यह उनका काम न हो? जो लोगों को गुदगुदाने के लिए एक शानदार तरीका लगता है।
जोएल टेस्ट यह परीक्षण नहीं करता है कि टीम कितनी अच्छी है। यह परीक्षण करता है कि आपकी टीम जोएल टेस्ट का कितनी अच्छी तरह पालन करती है।
आपकी टीम कितनी अच्छी है, इसका बेहतर परीक्षण यहां दिया गया है। मैं इसे ग्रैंडमास्टरबी टेस्ट कहता हूं। इसका एक सवाल है।
1) क्या आप कोई अच्छा सॉफ्टवेयर लिखते हैं?
यह मेरे लिए अप्रासंगिक है कि आप 'हॉलवे टेस्ट' करते हैं या नहीं, या आपके पास कौन सा स्रोत नियंत्रण है, या आपकी निर्माण प्रक्रिया क्या है (यदि एक है - हर एक लैग्यूज उनके पास नहीं है)। एक टीम का असली माप उनके द्वारा बनाए गए सॉफ़्टवेयर की गुणवत्ता है।
मूल रूप से, आप जोएल टेस्ट के हर एक कदम का पालन कर सकते हैं, और फिर भी बकवास कोड और उत्पादों के साथ समाप्त होते हैं जो कभी जहाज नहीं करते हैं। उदाहरण के लिए, स्रोत नियंत्रण जादुई रूप से किसी को बेहतर कोडर नहीं बनाता है; यह कोड को प्रबंधित करना आसान बनाता है। और विजुअल स्टूडियो का नवीनतम संस्करण होने का मतलब यह नहीं है कि आपका एप्लिकेशन विजुअल स्टूडियो 2005 के साथ लिखे जाने से बेहतर काम करेगा ।
हालांकि मुझे लगता है कि यह सामान्य अर्थों में अच्छी समझ रखता है, मुझे यह सूची विशिष्ट प्रकार के सॉफ्टवेयर पर केंद्रित है जो फॉग क्रीक सॉफ्टवेयर करता है ( संकोचन )। यह वास्तव में आश्चर्यजनक नहीं है, क्योंकि वह एक अन्य पोस्ट, फाइव वर्ल्ड्स के बारे में भी बात करता है । और उस दुनिया के बाहर बहुत सारे घटनाक्रम हैं।
कुछ स्थितियाँ हैं जो वास्तव में बहुत मायने नहीं रखती हैं यदि आप उदाहरण के लिए एक उपग्रह या एक वेंडिंग मशीन के लिए सॉफ़्टवेयर विकसित करते हैं , जैसे दैनिक बिल्ड (3) या प्रयोज्य परीक्षण (12)।