एजाइल में क्रॉस-फंक्शनल बनाम स्व-संगठित बनाम फीचर बनाम कॉम्पोनेंट टीमें

पारंपरिक रूप से, एक प्रोजेक्ट को आधार पर व्यवस्थित किया जाता हैकॉम्पोनेंट टीमें (जैसे UX, डेव, बिजनेस, टेस्टर, और …), किसी भी रिलीज के लिए जिसमें कॉम्पोनेंट विशेषज्ञता की आवश्यकता होती है, उसमें कई कॉम्पोनेंट टीमों को शामिल करने की आवश्यकता होती है। आमतौर पर, अलग-अलग टीमों के अलग-अलग प्राथमिकता सेट होते हैं, जिसके निश्चित रूप से उत्पाद रिलीज चक्र में बॉटलनेक आते हैं।

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

“एक क्रॉस-फंक्शनल टीमें काम पूरा करने के लिए आवश्यक सभी क्षमताएं रखते हैं, टीम के बाहर के लोगों पर निर्भर नहीं होते हैं” — स्क्रम गाइड

कॉम्पोनेंट टीम दृष्टिकोण के विपरीत, एक क्रॉस-फंक्शनल टीमें ऐसे समूह हैं जिनमें कंपनी के विभिन्न कार्यक्षेत्रों से लोग शामिल होते हैं। — इसे केवल तकनीकी विशेषज्ञों (बैक-एंड, फ्रंट-एंड डेवलपर्स, QA इंजीनियर्स, आदि) के साथ नहीं बनाया जाना चाहिए, बल्कि व्यवसाय विश्लेषकों, मार्केटिंग और UX विशेषज्ञों या किसी भी अन्य व्यक्ति के साथ भी बनाया जाना चाहिए जो प्रोजेक्ट में सक्रिय भाग ले रहा हो।

एक स्व-संगठित टीम एक ऐसी टीम है जिसके पास अपने काम को सबसे अच्छे तरीके से पूरा करने के लिए चुनाव करने की स्वतंत्रता होती है, बल्कि टीम के बाहर के लोगों द्वारा निर्देशित होने के बजाय। पारंपरिक प्रबंधन सिद्धांतों के विपरीत, स्व-संगठित शक्तिशाली टीमों को ऊपर से निर्देशित और नियंत्रित नहीं किया जाता है; बल्कि वे टीम सदस्यों के सक्रिय और सामूहिक रूप से सभी स्क्रम अभ्यासों और घटनाओं में भाग लेने से विकसित होती हैं।

पारंपरिक टीम बनाम एजाइल टीम

“एक स्व-संगठन टीम एक ज्ञान कार्यकर्ताओं के समूह से बनी होती है जिन्हें अपने आप को प्रबंधित करना होता है। उन्हें स्वतंत्रता होनी चाहिए” — पीटर ड्रॉकर।

स्क्रम गाइड बताता है “स्क्रम टीम में उत्पाद मालिक, विकास टीम और स्क्रम मास्टर शामिल होते हैं। वे हैं:

“स्क्रम टीमें हैं स्व-संगठित और क्रॉस-फंक्शनल” — स्क्रम गाइड:

घटक टीम बनाम विशेषता टीम

पारंपरिक दृष्टिकोण उत्पाद को अधिक या कम तार्किक और सार्थक रूप से घटकों में बांटना है और उनके लिए घटक टीमों को नियुक्त करना है। हालांकि, ये घटक ग्राहक के दृष्टिकोण के लिए पूरी तरह से अप्रासंगिक हैं।

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

घटक संगठन का बड़ा नुकसान स्पष्ट है: यह मूल्य प्रवाह को धीमा करता है। प्रणाली की अधिकांश विशेषताएं निर्भरताएं बनाती हैं जिनके निर्माण, डेप्लॉय और अंततः रिलीज के लिए घटक टीमों के बीच सहयोग की आवश्यकता होती है। टीमें अपने समय का अधिकांश हिस्सा टीमों के बीच निर्भरताओं पर चर्चा करने और घटकों के बीच व्यवहार का परीक्षण करने में बिताती हैं, बजाय उपयोगकर्ता के लिए मूल्य डिलीवर करने के।