जब एक टीम का आकार 10 से अधिक हो जाता है, तो क्या आप अभी भी एक साथ रिलीज की योजना बना सकते हैं?

9

जब अगली रिलीज के लिए क्या काम करना है, यह तय करना और प्रत्येक उपयोगकर्ता कहानी के लिए समय (और किसी दिए गए कहानी के लिए उप कार्यों) का आकलन करना है, तो क्या आप लोग समूह या सिर्फ प्रबंधकों में ऐसा करते हैं?

10 के टीम आकार के लिए, क्या यह व्यावहारिक है?

इसमें कितना समय लगता है?

agile

— codecompleting
स्रोत

9

आपकी टीम इतनी बड़ी क्यों है? यदि आप फुर्तीले होने की कोशिश कर रहे हैं, तो आपके पास एक बड़ी टीम के बजाय दो छोटी टीमें होनी चाहिए। कृपया बताएं कि 10 लोग एक टीम क्यों हैं।

— एस.लॉट

1

केवल एक कारण है कि मैं 10 कार्यशील प्रोग्रामर एक बैठक में भाग लेता हूं, हमारे आईपीओ या दिवालियापन की घोषणा करना है।

— जेएफओ

नहीं, सॉफ्टवेयर लिखा है 3 से अधिक लोगों को कभी भी जारी नहीं किया जाता है। यदि आप काउंटर उदाहरणों के बारे में सुनते हैं: ये सिर्फ अल्फा या बीटा संस्करण हैं।

— लांडे

मैंने लगभग 15 लोगों की टीम पर काम किया है, जहां हमने ऐसा किया है। सबसे बड़ी कमी यह है कि बैठक के दौरान किसी भी बिंदु पर आपके पास लगभग 10 लोग अपने हाथों पर बैठे हुए ऊब रहे हैं - और यह हर हफ्ते कुछ घंटों के लिए होता है। लेकिन, कभी-कभी टीमों को विभाजित करने से अधिक परेशानी और गलत संचार होगा। यह आदर्श नहीं है, लेकिन यह किया गया है।

— 21

3

एक एकल उत्पाद स्वामी द्वारा विभिन्न हितधारकों से इनपुट के साथ प्राथमिकता प्राप्त की जानी चाहिए, जिसमें एक वरिष्ठ डेवलपर शामिल है जो कोड के लिए एक हितधारक है और गैर-कार्यात्मक आवश्यकताओं के लिए जिम्मेदार है क्योंकि व्यावसायिक हितधारक कार्यात्मक आवश्यकताओं के लिए है।

अनुमान बिल्कुल उन लोगों द्वारा किया जाना चाहिए जो काम करेंगे, कभी नहीं एक प्रबंधक द्वारा जो देने के लिए दबाव में है, हालांकि आपकी प्रवृत्ति सही है कि आधा दर्जन से अधिक लोग इस पर बहस करते हुए घंटों बिताएंगे। एक आदर्श दुनिया में, आपको वास्तव में टीम को इस तरह से तोड़ना चाहिए कि कोई 4 से कम नहीं है और एक ही टीम पर 7 से अधिक नहीं है - 5 आदर्श है, IMHO।

यदि यह बिल्कुल संभव नहीं है, किसी कारण से - और आपको यह स्वीकार करने से पहले उस कारण से 5 काना लागू करने की आवश्यकता है, तो यह असंभव है - फिर 4-5 लोगों की एक टीम को उनकी ओर से अनुमान लगाने के लिए टीम द्वारा चुना जाना चाहिए।

— PDR
स्रोत

2

मेरी राय में, आपको 10 लोगों की एक टीम के रूप में रिलीज़ प्लानिंग नहीं करनी चाहिए। सबसे अधिक संभावना है कि आप एक विशाल बैठक के साथ समाप्त हो जाएंगे, जहां किसी भी चर्चा में 6-8 लोग पूरी तरह से डिस्कनेक्ट और ऊब महसूस करेंगे। इसमें जोड़ें कि 3-4 घंटे की थकावट एक साथ एक कमरे में बंद हो। और विचार करें कि अगर 10 लोग बात करते हैं, तो आपके पास बहुत अधिक बातचीत है। यदि वे बात नहीं करते हैं, तो आपको मूल्यवान इनपुट नहीं मिल सकता है।

हमने जोसेफ की कंपनी के साथ कुछ ऐसा ही किया। पिछली रिलीज में हमारे पास 8 इंजीनियर थे और रिलीज की योजना में 2 ठोस सप्ताह लगे। और यह बिल्कुल क्रूर था। प्रत्येक दिन में कुछ घंटे, मुझे लगता है कि हम सभी यथासंभव कम बोलने की कोशिश करना शुरू कर देते हैं ताकि बैठक जल्द से जल्द खत्म हो जाए।

इससे हमारी टीम का आकार दोगुना से अधिक हो गया। इसलिए हम छोटी टीमों में टूट गए जो किसी उत्पाद के क्षेत्र का स्थायी स्वामित्व ले लेंगे। प्रत्येक छोटी टीम में एक लीड थी। तब हमने उच्च स्तर की रिलीज़ प्लानिंग सिर्फ लीड्स के साथ की, जो तेजी से और अधिक कुशलता से आगे बढ़ी क्योंकि अब हमारे पास एक कमरे में केवल 4 डेवलपर्स थे। इस समय के दौरान, हमने यह पहचाना कि कौन सी टीम क्या कहानियाँ और उत्पाद कैसे विभाजित होगी। इसके अलावा इसने पूरे उत्पाद की बड़ी तस्वीर पेश की।

फिर प्रत्येक लीड अपनी टीम में वापस चली गई और रिलीज के हिस्से पर चली गई जिसके लिए केवल वही टीम जिम्मेदार थी। इस समय के दौरान, हमने कुछ विवरणों को भरा और कहानी बिंदु मानों को सौंपा।

अंत में, सब कुछ एक साथ रखा गया था और हमने एक अंतिम वॉकथ्रू (चर्चा से अधिक प्रस्तुति) किया ताकि टीम पर सभी को पता चले कि पूरी टीम के साथ क्या हो रहा है।

हालाँकि हमारे पास इस पद्धति के साथ एक पूर्ण सफल रिलीज़ नहीं थी, लेकिन मुझे लगता है कि कुल मिलाकर रिलीज़ प्लानिंग पहले की तुलना में स्मूथ थी। कुंजी यह थी कि किसी भी बैठक में हमारे पास 3-4 से अधिक डेवलपर्स नहीं थे और सभी की आवाज अभी भी सुनी गई थी।

यदि संभव हो तो मैं आपको अपने 10 डेवलपर्स को 3 समूहों में विभाजित करने की सलाह दूंगा। यदि आप अपनी समग्र रिलीज़ को 3 अधिकतर गैर-अतिव्यापी क्षेत्रों में विभाजित नहीं कर सकते हैं, तो भी 2 समूह एक बड़ी टीम से बेहतर होंगे।

— DXM
स्रोत

2

मैं वास्तव में एक नेतृत्व के रूप में कई परियोजनाओं (और कई टीमों) का हिस्सा हूं, और कुछ ऐसे हैं जो 10+ हैं। लगभग सभी परियोजनाओं पर मैं काम करता हूं, रिलीज की योजना लीड और व्यापारिक विश्लेषकों द्वारा की जाती है। हालांकि, हमारी स्थिति में बीए प्रबंधक नहीं हैं, इसलिए प्रबंधक वास्तव में रिलीज की योजना में भाग नहीं लेते हैं।

अनुमान कार्यान्वयन टीम द्वारा किया जाता है, हालांकि, और यद्यपि दोनों भाग अलग-अलग हैं, वे बहुत संबंधित हैं।

अनुमान यह है कि किसी कार्य को करने में कितना समय लगता है, जबकि रिलीज की योजना तब है जब उन कार्यों को निर्धारित किया जाना है।

योजना व्यावसायिक चिंताओं के अनुसार की जानी चाहिए, जबकि आकलन तकनीकी चिंताओं के अनुसार किया जाना चाहिए। इसलिए अनुमान और योजना का टूटना।

— यूसुफ
स्रोत

4

+1 - नियोजन लीड्स और व्यवसाय द्वारा किया जाता है, लेकिन यह महत्वपूर्ण है कि वास्तविक कार्यकर्ता मधुमक्खियों द्वारा अनुमान लगाया जाए।

— जिम इन टेक्सास

0

यह कार्य एक प्रबंधक द्वारा अधिक कुशलता से किया जाता है। छोटी टीमों में, भूमिकाएँ मिश्रित होती हैं। हर कोई हर चीज में शामिल है। लेकिन जैसे-जैसे आपकी टीम बढ़ती है, यह असहनीय हो जाती है और भूमिकाओं को स्पष्ट रूप से परिभाषित करने की आवश्यकता होती है।

जितना मुझे सब कुछ शामिल करने की इच्छा मिलती है, यह सिर्फ उत्पादक नहीं है।

— एजेसी
स्रोत