मैं हाल ही में एक दुबला विकास टीम बनाने के बारे में बहुत सोच रहा हूं। अंततः, मैं अपने छोटे सॉफ्टवेयर हाउस को कम संख्या में समान विचारधारा वाले लोगों के साथ खोलना चाहूंगा। लक्ष्य अमीर बनने के लिए नहीं होगा, बल्कि एक स्वस्थ कार्य वातावरण होगा।
अब तक, मैं निम्न के रूप में एक दुबली टीम को परिभाषित कर रहा हूं:
- छोटे;
- स्व आयोजन;
- सभी सदस्यों के मन में क्यूए होना चाहिए;
- सदस्यों को कई भूमिकाएं निभाने में सक्षम होना चाहिए
अंतिम बिंदु यह है कि मैं थोड़ा चिंतित हूं क्योंकि मंत्र के रूप में ...
डेवलपर्स खराब परीक्षक बनाते हैं।
जबकि मैं समझता हूं कि, अक्सर, डेवलपर अपने कोड या अपने सहकर्मी के कोड को गुणवत्ता के उच्च-स्तरीय आकलन करने के लिए "बहुत करीब" होते हैं, मुझे यकीन नहीं होता कि वे वास्तव में खराब परीक्षक हैं। इसके विपरीत, मेरी राय है कि एक अच्छे डेवलपर के गुण एक अच्छे परीक्षक के गुणों के साथ बहुत अधिक ओवरलैप करते हैं।
यह सही है, मैं देव / परीक्षक समस्या के आसपास होने के विभिन्न तरीकों के बारे में सोच रहा था और मुझे विश्वास है कि मैं एक व्यवहार्य मॉडल के साथ आया हूं।
मेरे मॉडल की आवश्यकता है:
- 2+ परियोजनाओं के साथ एक छोटा सा सॉफ़्टवेयर हाउस
- एगाइल (पुनरावृत्त) विकास और वितरण के लिए दृष्टिकोण
- प्रति प्रोजेक्ट 1 टीम
- टीम के सभी सदस्य सॉफ्टवेयर डेवलपर होंगे
- उनकी नौकरी का विवरण स्पष्ट रूप से विकास , गुणवत्ता आश्वासन , परीक्षण और वितरण को जिम्मेदारियों के रूप में बताएगा
यदि इन सभी पूर्व शर्तो को पूरा किया गया है, तो परियोजनाएं निम्नलिखित फैशन में आयोजित की जा सकती हैं (यह उदाहरण दो परियोजनाओं, ए और बी का उल्लेख करेगा ):
- टीम का प्रत्येक सदस्य डेवलपर भूमिका और परीक्षक भूमिका के बीच वैकल्पिक रूप से काम करेगा
- यदि कोई टीम सदस्य प्रोजेक्ट A पर डेवलपर है , तो वे प्रोजेक्ट B पर एक परीक्षक होंगे
- सदस्य एक समय में केवल 1 परियोजना पर काम करेंगे, और इसलिए के रूप में कार्य होने की उम्मीद है या तो एक देव या एक परीक्षक।
- एक भूमिका चक्र में देव के रूप में 3 पुनरावृत्तियां और परीक्षक के रूप में 2 पुनरावृत्ति (फिर से, दो अलग-अलग परियोजनाओं पर) शामिल हैं।
- प्रोजेक्ट टीमों में हर समय 3 देव और 2 परीक्षक होंगे।
- सदस्य भूमिका चक्र 1 पुनरावृत्ति द्वारा चरण से बाहर होना चाहिए।
- यह टीम में परिवर्तन की अचानकता को कम करता है। प्रत्येक पुनरावृत्ति के लिए, 2 देवता और 1 परीक्षक पिछले पुनरावृत्ति के समान रहेंगे।
उपरोक्त को देखते हुए, मैं निम्नलिखित पेशेवरों और विपक्षों को देखता हूं:
पेशेवरों
- कंपनी भर में परियोजना ज्ञान वितरित करता है।
- सुनिश्चित करता है कि टीम के सदस्य उस कोड का परीक्षण नहीं कर रहे हैं जो उन्होंने लिखने में मदद की है।
- आउट-ऑफ-फेज रोल साइकिल का मतलब है कि किसी भी परियोजना में 100% सदस्य स्विच नहीं है।
- वैकल्पिक भूमिकाएँ उबाऊ परियोजनाओं की एकरसता को तोड़ती हैं।
विपक्ष
- दोनों परियोजनाओं के पुनरावृत्तियों को कसकर युग्मित किया गया है। यदि एक परियोजना आधी से एक पुनरावृत्ति को रद्द करने और फिर से शुरू करने के लिए थी, तो दोनों परियोजनाएं सिंक से बाहर हो जाएंगी। इससे भूमिका-चक्र को प्रबंधित करना मुश्किल हो जाएगा।
- डेवलपर्स को काम पर रखने पर टिका हुआ टेस्टर्स के रूप में अच्छी तरह से काम कर रहे हैं।
मित्रों और सहकर्मियों के साथ इस दृष्टिकोण पर चर्चा करने पर मुझे मिश्रित समीक्षा मिली है। कुछ का मानना है कि कुछ डेवलपर्स कभी इस तरह की भूमिकाएं करना चाहते हैं, जबकि अन्य मुझे बताते हैं कि वे व्यक्तिगत रूप से इसे आजमाना पसंद करेंगे।
तो मेरा सवाल है: क्या इस तरह का मॉडल व्यवहार में काम कर सकता है? यदि नहीं, तो इसे एक कामकाजी मॉडल में बदल दिया जा सकता है?
नोट: संक्षिप्तता के लिए मैंने केवल देव और परीक्षक भूमिकाओं पर ध्यान केंद्रित किया है। यदि आवश्यक हो तो मैं अन्य भूमिकाओं पर विस्तार करूंगा।