Agile में कौन से समूहों को भाग लेना चाहिए?

Question

मेरी कंपनी में हमारे पास प्रोग्रामर, फ्रंट एंड डेवलपर्स, डिज़ाइनर और यूएक्स टीम सभी एग्इल समूह में भाग लेते हैं। मैं कोई एजिल मास्टर नहीं हूं लेकिन मुझे समझ में आया कि एक टीम के सभी सदस्य किसी भी काम को करने में सक्षम होना चाहिए। डिज़ाइनर, यूएक्स टीम, फ्रेंड एंड डेवलपर्स और sys admins होने के अनुमान में यह अनुमान लगाने के लिए शामिल है कि बैकएंड कार्य कितना समय लगेगा मेरे लिए पागल लगता है। मुझे मुश्किल से पता है! तो मेरा सवाल है कि मैं बहुत कठोर हूं? क्या यह एक Agile पर्यावरण में काम कर सकते हैं?

Answer 1

आपको मूल अवधारणा गलत मिली है ... सभी सदस्यों को कहानियों में काम करने में सक्षम होना चाहिए। कुल क्रॉस-कार्यक्षमता नहीं ... एक डेवलपर अचानक यूआई डिज़ाइनर बनने के लिए उभर नहीं सकता है।

और नहीं। प्रति टीम के सदस्यों की 7 -10 तक सीमित है। तो उस समूह को तदनुसार विभाजित किया जाना चाहिए।

Answer 2

संक्षिप्त उत्तर हाँ है।

यहां तक ​​कि शुद्ध डेवलपर्स की टीमों स्वयं के लिए करते हैं जाएगा विशेषता या विशिष्ट उप के मालिकों में संगठित (जब तक आप काम बारी बारी से करने के लिए उन्हें मजबूर करने के लिए करते हैं, लेकिन यह एक अलग मुद्दा के लिए एक विषय है)। इसलिए, आप कमरे में सदस्यों की एक बड़ी संख्या के साथ कहानियों का अनुमान लगाएंगे जिनके पास कहानी से जुड़े उपप्रणाली के काम का थोड़ा ज्ञान नहीं है।

स्टोरी अनुमान जटिलता/कार्य के पैमाने की तुलना करने के बारे में अधिक होना चाहिए। यह परिभाषित आधार बिंदु से यह दो बार, चार गुना, आठ गुना (या इसी तरह के तराजू) अधिक काम करता है। या, यह इस अन्य आइटम के समान है जिसे हमने आठ में रेट किया था। कम से कम यह लक्ष्य है। स्प्रिंट स्तर (बनाम समग्र बैकलॉग) पर, मुझे लगता है कि टीम अधिक ठोस स्केल (यानी घंटे) के साथ अनुमान लगाना पसंद करती हैं।

विशिष्ट विषयों में लोगों के लिए, आप अनुमान प्रक्रिया में शामिल होना चाहते हैं या नहीं। यदि उन व्यक्तियों को कार्य की जटिलता की उचित समझ है, तो अनुमान अन्य सदस्य के समान ही हो सकते हैं। यदि नहीं, तो उन्हें अनुमान नहीं देना चाहिए।

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

Answer 3

Agile टीमों को "क्रॉस-फ़ंक्शनल" माना जाता है - यानी बहुत से विशेषज्ञ कुछ ओवरलैप के साथ मिलकर काम कर रहे हैं।

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

नहीं टीम के सभी सदस्यों को इस पर काम करने के लिए पूरा समय है उन कार्यों को करो।

मत भूलना लोगों को शामिल करना:

• जो बातें हस्ताक्षर करने के लिए की जरूरत है,
• लोग हैं, जो डीएनएस की तरह सामान्य सुविधाओं के लिए प्रशासन, LDAP
• नेटवर्क व्यवस्थापक
• लोग हैं, जो खरीद और बनाए रखने के हार्डवेयर,
• सुरक्षा लोग ...

मैं उन परियोजनाओं में शामिल रहा हूं जहां सॉफ्टवेयर समय पर तैयार था लेकिन DNS या हार्डवेयर नहीं था - जहां तक ​​ग्राहक का संबंध है, #fail है। आपके नियंत्रण से बाहर की चीजें आपको किसकी सहायता की आवश्यकता होगी? टीम लीड, कोच और स्क्रम मास्टर्स को सही लोगों को शामिल करने के लिए पुनरावृत्ति या दो आगे दिखना चाहिए।

तकनीकी बिक्री और व्यवसाय सहित अनुमानों और किकऑफ मीटिंग्स में शामिल सभी सही लोगों को प्राप्त करना महत्वपूर्ण है। टेक बिक्री में लगता है कि वे मदद नहीं कर सकते हैं लेकिन अक्सर वे ग्राहक के बारे में प्रश्नों का उत्तर दे सकते हैं जो अनुमानों में सर्वसम्मति बनाने में मदद कर सकते हैं।

Answer 4

Agile सहयोग और सामान्य ज्ञान के बारे में है। उस ने कहा, मुझे लगता है कि यह मूल रूप से वास्तविक टीम के लिए उबाल जाएगा। क्या वे कुशलता से सहयोग कर सकते हैं? यदि नहीं, तो आपको इसे ठीक करने की आवश्यकता हो सकती है। आपके पीछे की ओर आपको क्या बताता है? Agile एक रास्ता है, गंतव्य

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

Answer 5

मेरी कंपनी में हमारे पास प्रोग्रामर, फ्रंट एंड डेवलपर्स, डिज़ाइनर और यूएक्स टीम सभी एग्इल समूह में भाग लेते हैं। मैं कोई एजिल मास्टर नहीं हूं लेकिन मुझे समझ में आया कि एक टीम के सभी सदस्य किसी भी काम को करने में सक्षम होना चाहिए।

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

डिज़ाइनर, यूएक्स टीम, फ्रेंड एंड डेवलपर्स और sys admins होने के अनुमान में यह अनुमान लगाने के लिए कि एक बैकएंड कार्य कितना समय लगेगा, मुझे पागल लगता है। मुझे मुश्किल से पता है! तो मेरा सवाल है कि मैं बहुत कठोर हूं? क्या यह एक Agile पर्यावरण में काम कर सकते हैं?

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