XP/SCRUM के लिए कितना बड़ा है?

Question

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

सिस्टम आकार, टीम आकार, एलओसी आदि के मामले में ऐसी चपल पद्धतियों की सीमा क्या है?

Answer 1

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

Answer 2

एक टीम के भीतर संचार चैनल ऊपरी बाउंड के रूप में (एन * एन -1)/2 के आनुपातिक होते हैं, इसलिए कम से कम ओ (एन^2) के रूप में देखा जा सकता है। फुर्तीली टीमों की विकेन्द्रीकृत प्रकृति का अर्थ है कि संदर्भ का कोई केंद्रीय बिंदु नहीं है और संदर्भ के ऐसे बिंदु की तुलना में संचार ऊपरी सीमा के करीब बढ़ेगा।

जहां आपके पास एक लिखित विनिर्देश और अधिक औपचारिक संरचना है (स्पेक दस्तावेजों की चर्चा के लिए Painless Functional Specification देखें) संचार एक हब-एंड-स्पीच मॉडल के करीब है, जो ओ (एन) चैनलों के करीब है (एन के लिए) परियोजना पर कर्मचारी)। मैंने देखा है कि अधिकांश नियम-थंब टिप्पणी ने 6 या उससे कम समय में एग्इल टीमों के लिए मीठा स्थान रखा है और ऊपरी बाउंड लगभग 10 पर है, हालांकि आपका माइलेज भिन्न हो सकता है।

पीएफएस लेखों में जोएल (हाँ, जोएल) Programme Manager की भूमिका पर चर्चा करता है, जिसका भूमिका विनिर्देश विकसित करना और उसका स्वामित्व है। पीले रंग की कार्यात्मक निर्दिष्टीकरण श्रृंखला इसमें काफी विस्तार से जाती है और यह गैर-तकनीकी प्रबंधन के लिए भी काफी सुलभ है - मैंने इस आलेख में कुछ लोगों को संदर्भित किया है।

Answer 3

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

विचार यह है कि सिस्टम पूरी तरह परिभाषित होने से पहले आप व्यवसाय मूल्य वितरित कर सकते हैं।

Answer 4

स्क्रम को "स्क्रम के स्क्रम" का उपयोग करके स्केल किया जा सकता है।

स्क्रम गठबंधन से Scrums बैठकों के स्क्रम संचालित करने पर इस advice आता है:

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

पुस्तक Agile और Iterative Development भी discuss इस समस्या को।

Answer 5

एग्इल स्केल ठीक है। यह एक रॉकेट विज्ञान नहीं है। वास्तव में यह लगभग मॉड्यूलरिटी है।सॉफ्टवेयर विकास एक सीएएस (कॉम्प्लेक्स एडैप्टिव सिस्टम) है, और लगभग किसी भी सीएएस के रूप में, यह में जटिलता को बेहतर बनाने के लिए मॉड्यूल बेहतर है। स्क्रम का स्क्रम विकास प्रक्रिया स्केलिंग के लिए संभावित मॉड्यूलर दृष्टिकोण में से एक है। कार्यात्मक विभाजन (डेवलपर्स, क्यूए, आदि) एक और मॉड्यूलर दृष्टिकोण है। सबसे बुरा मामला तब होता है जब आपके पास एक बड़ी परियोजना में मॉड्यूल नहीं होते हैं।

प्रोजेक्ट प्रकृति के आधार पर, टीम यह तय कर सकती है कि परियोजना के लिए कौन से मॉड्यूल काम करेंगे। सामान्य पैटर्न कई टीमों को बनाना है जो कुछ कम समेकन मॉड्यूल पर काम करते हैं। प्रत्येक टीम काफी स्वायत्त होनी चाहिए, लेकिन दूसरी टीमों के साथ बातचीत अच्छी होनी चाहिए।

उदाहरण के लिए सीएएस से समानता मानव शरीर है। हमारे पास हृदय और यकृत जैसे अंग हैं। वे अलग मॉड्यूल (कोशिकाओं की टीम :) हैं जो तंत्रिका तंत्र/रक्त/आदि के माध्यम से बातचीत करते हैं।

Answer 6

बर्नी थॉम्पसन द्वारा this blog post पर एक नज़र डालें।

यह माइक्रोसॉफ्ट में स्क्रम/एक्सपी स्केल करते समय कई मुद्दों और व्यापार-बंदों की रूपरेखा बताता है, और इसमें कुछ विचारशील और रोचक समाधान हैं।

उसी ब्लॉग पर अन्य पोस्ट भी हैं जो आपके द्वारा चिंतित पैमाने के इन मुद्दों से निपटती हैं - आईएमओ यह "उगाए जाने वाले लोगों के लिए चुस्त" पर विचारों का स्वर्ण-खान है।

Answer 7

स्केलिंग स्क्रम या कोई चुस्त दृष्टिकोण आपके पर्यावरण पर निर्भर है।

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

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

मैं कई स्क्रम टीमों (~ 20 टीमें - कुछ वितरित - प्रत्येक 10-20 सदस्यों से लेकर) के साथ एक बहुत बड़ी परियोजना का हिस्सा रहा हूं। प्रत्येक के पास अलग-अलग स्टैंडअप थे, और वहां एक स्क्रैम-ऑफ-स्क्रम्स और यहां तक ​​कि एक स्क्रैम-ऑफ-स्क्रम-ऑफ-स्क्रम्स भी था। मुझे लगता है कि हमने वर्कफ़्लो के बजाय कार्यात्मक क्षेत्र द्वारा टीमों को विभाजित करके गलती की है। हमारे विभाजन ने टीमों के बीच भारी एकीकरण प्रबंधन मुद्दों के साथ कोड स्वामित्व के सिलो बनाए।

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