SCRUM एक एनवायरमेंट का प्रबंधन कैसे करता है जहां टीम के सदस्यों को साझा किया जाता है?


13

खैर, सवाल खुद कहा। मेरे कार्यस्थल में वे मामले होते हैं, लेकिन साथ ही, कई फुर्तीली किताबें एक ही कार्यस्थल में काम करने को बढ़ावा देती हैं और काम की गति में तेज होने के लिए वर्तमान परियोजना में केंद्रित होती हैं।

शायद मुझे इस विषय के बारे में जानकारी नहीं है, शायद वह इतना सख्त नहीं है, लेकिन इसीलिए मैं यह जानना चाहता था कि एजाइल उन जैसे मामलों में क्या प्रस्तावित करता है।

कोई?


1
साझा करने से आपका क्या मतलब है? क्या आपका मतलब है कि कोई एक टीम से दूसरी टीम में जा सकता है या कोई एक साथ कई टीमों में काम कर सकता है? यह मेरे उत्तर को प्रभावित करेगा।
पीडीआर

जवाबों:


6

स्क्रम पद्धति में यह केवल अनुमान को प्रभावित करता है।

आप प्रत्येक परियोजना के लिए अपने समय के आवंटन के आधार पर उस व्यक्ति के लिए फ़ोकस फैक्टर असाइन करेंगे।

इसलिए, यदि मैं प्रोजेक्ट ए और प्रोजेक्ट बी पर समान रूप से काम कर रहा हूं, तो प्रोजेक्ट ए ऐसे संसाधनों की गणना करेगा:

प्रोजेक्ट ए - 70%
सैम का टीम फोकस फैक्टर - 10 दिन, 100% एलोकेशन (फोकस फैक्टर के बाद 7)
जो - 10 दिन, 100% एलोकेशन (फोकस फैक्टर के बाद 7)
Me - 10 दिन, 50% एलोकेशन (3.5% फ़ोकस फैक्टर) )
कुल: 25 दिन * 70% फोकस फैक्टर = 17.5 अनुमानित वेग

बंटवारे की परियोजनाओं से दक्षता कम होने के कारण, आप पूर्णकालिक टीम के सदस्यों के लिए और अंशकालिक टीम के सदस्यों के लिए अलग से फोकस कारक की गणना भी कर सकते हैं । इस स्थिति में, आप 50% के मेरे प्रोजेक्ट फ़ोकस फैक्टर का उपयोग करेंगे और इसे 25% या 2.5 दिनों के अनुमानित वेग के लिए 50% के व्यक्तिगत आवंटन से गुणा करेंगे ।

व्यवहार में यह कितनी अच्छी तरह काम करता है, यह इस बात का कारक होने वाला है कि आप पहले से जानते हैं कि प्रत्येक परियोजना पर कितना साझा संसाधन खर्च होने वाला है, और अन्य तरीकों से आपके लिए स्क्रम कितना अच्छा काम कर रहा है।


2
इस तरह से करने के साथ मेरा मुद्दा यह है कि यह बहुत अच्छी तरह से स्विचन कार्य के लिए खाता नहीं है। उदाहरण के लिए, 2 सप्ताह (10 दिन) के स्प्रिंट पर विचार करें। एक डेवलपर के पास ५०% फ़ोकस फैक्टर है, जहाँ आप उसे ५ दिनों के लिए सीधे प्राप्त करते हैं, १० दिनों तक हर दूसरे घंटे एक डेवलपर होने से बहुत अलग है। पूर्व बहुत अधिक उत्पादक है। एक चरम उदाहरण, लेकिन आपको मेरी बात समझ में आती है।
ब्रुक

@ बरोक आप केवल फ़ोकस फैक्टर (प्रति व्यक्ति 1 माप) के बारे में बात कर रहे हैं, जो परियोजना आवंटन से अलग है (इस मामले में 50-50 का विभाजन हुआ है)। फोकस कारक एक आदर्श दिन का% है जो आपके वास्तविक दिन के लायक है । आमतौर पर यह लगभग 70-80% है, लेकिन किसी के लिए परियोजनाओं को विभाजित करना शायद कम होगा (जिसे मैंने उत्तर में संबोधित किया था)। यह समय के साथ कुछ स्थिरता पर निर्भर करता है। यदि आपके पास निरंतरता नहीं हो सकती है, तो आपको वास्तव में स्क्रैम भी नहीं करना चाहिए।
निकोल

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

@ बरोक - यह एक अच्छा बिंदु है और आपने मुझे इसके बारे में सोचने में मदद की जो मैंने मूल रूप से नहीं की थी। ऐसा लगता है जैसे हम सहमत हैं।
निकोल

1
@NickC यह करने के लिए प्रशंसनीय लगता है। बहुत कम से कम, मैं आश्वस्त हूं कि टीम के सदस्यों को हर बार बदला जा सकता है, सौभाग्य से ऐसा नहीं होता है। कार्यस्थल हमेशा एक ही रहता है, बस यह कि परियोजना को दिया गया समय कभी-कभी टीम के सदस्य की आधी क्षमता का होता है (क्योंकि टीम का सदस्य 2 अलग-अलग परियोजनाओं से टेक कर रहा है)। लेकिन यह बहुत कम से कम विभिन्न परियोजनाओं के लिए वेग की गणना के लिए उचित लगता है। संदर्भ के लिए धन्यवाद।
Xanathos

10

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

सामान्य तौर पर, आपको निश्चित रूप से टीम को समान रखने की कोशिश करनी चाहिए और यदि आप कर सकते हैं तो स्प्रिंट के दौरान कम से कम समर्पित करें।


2
हाँ सचमुच! परियोजना के बीच सदस्यों को साझा करने की कोशिश में शामिल सभी परियोजनाओं में देरी हो रही है। इससे कोई मतलब नहीं है कि लोगों को विभाजित करना और चीजों को तेजी से पूरा करना होगा।
मार्टिन विकमैन

सामान्य ज्ञान के लिए +1, आप इसे तीन महीने में पूरा करने के लिए तीन महिलाओं को गर्भधारण करने का अधिकार नहीं दे सकती हैं। यह एक विशिष्ट कार्य के लिए लोगों को समर्पित करने के लिए अधिक समझ में आता है।
maple_shaft

मेरा मानना ​​है कि यह वास्तव में स्क्रैम का एक "मुख्य स्तंभ" है। पोस्टर का संदर्भ देते समय लगता है कि "इस स्थिति में एजाइल क्या कहता है" (बनाम स्क्रेम) क्या एक एजाइल (गैर-
स्क्रैम

1

मेरी राय में यह सभी परियोजनाओं को बहुत बुरी तरह प्रभावित करेगा। यह केवल अनुमान लगाने या योजना बनाने की बात नहीं है। हां आप यह कह सकते हैं कि यदि टीम के सदस्यों को तीन परियोजनाओं के लिए आवंटित किया जाता है और उनके पास प्रत्येक परियोजना के लिए 33% आवंटन है, तो आपको वह सब कुछ पता है जिसकी आपको ज़रूरत है और आप कर रहे हैं लेकिन यह सच नहीं है।

संदर्भ स्विचिंग बहुत महंगा है। इसके अलावा कई समानांतर परियोजनाओं के लिए पूर्ण प्रतिबद्धता बनाए रखना असंभव है, इसलिए डेवलपर समय के उन 33% प्रतिशत 33% से दूर हैं जब डेवलपर को केवल एक परियोजना के लिए सौंपा गया है।

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

टकराने नहीं करने के लिए भी आपको सभी बैठकों की योजना बनानी होगी। आपको यह भी समझना चाहिए कि बैठक वास्तव में बेकार है और इस वजह से कम से कम बैठकों की आवश्यक संख्या होनी चाहिए ताकि अभी भी इस प्रक्रिया पर नियंत्रण रखा जा सके। लेकिन अगर आपके पास तीन परियोजनाओं पर काम करने वाली टीम के सदस्य हैं, तो उन्हें उन तीन परियोजनाओं के लिए सभी बैठकों में भाग लेना चाहिए => तीन बार अधिक बैठकें जहां डेवलपर किसी भी व्यावसायिक मूल्य का उत्पादन नहीं करता है।

निष्कर्ष के रूप में फुर्तीली अपशिष्ट को कम करने के बारे में भी है (हाँ यह लीन दृष्टिकोण से है) और टीमों के सदस्यों को साझा करना अपशिष्ट को पेश करने और उत्पादकता को कम करने के मामले में सबसे खराब विफलताओं में से एक है। मुझे लगता है कि किसी एकल परियोजना के लिए 33% आवंटन के लिए दिया गया व्यावसायिक मूल्य पूर्ण समय आवंटन के 10-16% से वितरित व्यावसायिक मूल्य के बराबर होगा। इसका मतलब है कि डेवलपर न केवल परियोजना पर 1/3 समय भाग लेगा, बल्कि उस समय के दौरान उसकी उत्पादकता 1/3 से 1/2 के बीच होगी।


1

SCRUM साझा सदस्यों के बिना एक प्रतिबद्ध टीम होने पर आधारित है, इसलिए आप पूछ सकते हैं:

हमें बताया गया है कि हमें सही == असत्य बनाना चाहिए, हम एक्स कैसे करते हैं

यदि यह SCRUM नहीं है, तो इसे SCRUM न कहें!


0

मुख्य प्रश्न परियोजना के लिए टीम के सदस्य की प्रतिबद्धता के बारे में है। आदर्श रूप से, एक टीम के सदस्य को परियोजना की सफलता के लिए पूरी तरह से प्रतिबद्ध होना चाहिए। इसका मतलब यह नहीं है कि उनका समय पूरी तरह से परियोजना के लिए समर्पित है, लेकिन जब वह परियोजना के लिए काम कर रहे हों, तो उन्हें काम करने के लिए जो भी आवश्यक हो, वह उपलब्ध हो।

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

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


0

मेरा मानना ​​है कि स्क्रैम के मुख्य पहलुओं में से एक पर टीम को एक समय पर केंद्रित रखना है (एक परियोजना, एक कहानी, एक कार्य ...)

आपने उस स्थिति में "एजाइल प्रपोज" क्या किया है, जहां आप संसाधनों को एक परियोजना के लिए आवंटित नहीं कर सकते हैं ... आप इनमें से किसी एक को आज़माने पर विचार कर सकते हैं:

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

उम्मीद है की यह मदद करेगा!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.