2010-04-30 14 views
8

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

स्क्रम मॉडल में एक साथ चलने वाली कई परियोजनाओं को आप कैसे प्रबंधित करते हैं? ज्यादातर समय हमारे पास मुख्य परियोजनाएं होती हैं और कुछ छोटे होते हैं। आप कई स्पिंट्स को कुशलता से कैसे जोड़ते हैं?

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

+1

आईएमएचओ स्क्रम आपकी टीम के लिए सही नहीं हो सकता है। –

+0

शायद हमारे पास अभी कुछ भी नहीं था (उच्चतम प्राथमिकता पर काम कर रहा है)। लेकिन मुझे वास्तव में कुछ करने की आवश्यकता महसूस होती है। मैं अन्य कंपनियों (बड़े लोगों को यकीन है) से स्क्रम जानता था कि मैं इसे क्यों कोशिश करना चाहता था। लेकिन हम इसके साथ पूरी तरह से लचीला हैं। हम सिर्फ एक सिस्टम की तलाश में हैं। शायद यह अंत में एक बहुत ही संकर समाधान होगा। मैं सिर्फ एक शुरुआती बिंदु चाहता था। – meo

+0

@VadimKotov इसे पोस्ट करने के 7 साल बाद और उत्तर दिया गया: डी जो भी – meo

उत्तर

6

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

अलग-अलग परियोजनाओं को अलग-अलग स्पिंट्स में शेड्यूल करने का प्रयास करने के लिए आप क्या कर सकते हैं, यानि पूरी तरह से प्रोजेक्ट 1 पर समर्पित एक स्प्रिंट करें, फिर प्रोजेक्ट 2 पर पूरी तरह से स्प्रिंट करें। यदि परियोजनाएं बहुत अलग दायरे हैं, तो आप विचार कर सकते हैं स्पिंट्स की लंबाई बदलती है, उदाहरण के लिए एक बड़ी परियोजना पर 3 सप्ताह का स्प्रिंट करें, फिर शायद एक छोटे से एक सप्ताह का स्प्रिंट।

शुद्ध स्क्रम में स्पिंट की लंबाई वास्तव में पत्थर में नक्काशीदार है, लेकिन फिर, आईएमओ बिंदु को "शुद्ध स्क्रम कार्यान्वयन" बैज नहीं बल्कि आपकी टीम के लिए एक वास्तविक वास्तविक जीवन प्रक्रिया प्राप्त करना है।

(अस्वीकरण: मैं आपकी समस्या को देखें: मैं स्क्रम मास्टर :-)

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

स्क्रम में बड़ी परियोजना के स्पिंट की योजना बनाने की संभावना है, लेकिन आने वाले समर्थन कार्यों के लिए आपका कुछ समय "टाइमबॉक्स" होगा। जैसे यदि औसत पर आप अन्य परियोजनाओं का समर्थन करने वाले प्रत्येक मासिक स्प्रिंट में 5 दिन व्यतीत करते हैं, तो आप प्रत्येक स्प्रिंट में समर्थन के लिए 5 दिन के संसाधनों (हालांकि आप समय की गणना करते हैं) आवंटित करते हैं।

अन्य विकल्प अन्य तरीकों पर विचार करना पड़ सकता है, जैसे कि Kanban, जहां कोई स्प्रिंट या योजना नहीं है, बल्कि टीम ग्राहकों से मांग के आधार पर पूरी तरह से (या मुख्य रूप से) काम करती है।

+0

दार्शनिक रूप से मैं इसके साथ 100% सहमत हूं। लेकिन इस अभ्यास में एक छोटी सी कंपनी में एक बड़ी परियोजना पर 1 महीने का स्प्रिंट करना असंभव है, जो अन्य सभी परियोजनाओं को पीछे छोड़ देता है। हमारे पास परियोजनाओं के साथ बहुत से छोटे ग्राहक हैं जो कुछ दिनों में किए जा सकते हैं। लेकिन हम उन्हें एक महीने तक इंतजार नहीं कर सकते हैं। क्या आपको मेरी समस्या है? मैं (छद्म-) स्क्रम मास्टर हूं और बॉस नहीं:/मैं बिना ब्रेक के स्पिंट्स करना चाहता हूं। लेकिन मैं कुछ महीनों के बाद अपना काम खो देता हूं क्योंकि हम बहुत सी छोटी परियोजनाओं से जी रहे हैं जिन्हें तेजी से किया जाना है। – meo

+0

@meo, कृपया मेरा अपडेट देखें। –

1

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

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

एक बार जब आप शिफ्ट कर लेते हैं, तो आपको यह पता लगाना चाहिए कि आप अपनी 1 या 2 परियोजनाओं पर स्क्रम-डाउन (या जो भी शब्द है) जारी रख सकते हैं, और शेष को वितरित करने के लिए मशीन पर हैंडल चालू कर सकते हैं।

6

आपको 1 सप्ताह की दौड़ की आवश्यकता है। 1 प्रोजेक्ट केवल प्रति स्प्रिंट। यह एक झूठ है कि आप एक साथ कई परियोजनाओं पर काम करके सॉफ्टवेयर को तेजी से वितरित कर सकते हैं। बड़ी परियोजना एक रिलीज विकसित करने के लिए कई स्पिंट ले सकती है जहां आपके छोटे बच्चों के साथ, आप प्रत्येक स्प्रिंट के बाद रिलीज़ हो सकते हैं।

यदि आपकी परियोजनाएं अलग-अलग पीओ/क्लाइंट्स के लिए हैं तो यह और भी महत्वपूर्ण है कि आप एक समय में केवल एक पर काम करें; अन्यथा आपकी प्राथमिकताओं लगभग हमेशा संघर्ष में होगी।

2

स्क्रम मॉडल में एक साथ चलने वाली कई परियोजनाओं को आप कैसे प्रबंधित करते हैं? ज्यादातर समय हमारे पास मुख्य परियोजनाएं होती हैं और कुछ छोटे होते हैं। आप कई स्पिंट्स को कुशलता से कैसे जोड़ते हैं?

एक विकल्प समानांतर में एकाधिक स्पिंट चलाने के लिए है, भले ही यह आदर्श नहीं है, कई टीमों (जाहिर तौर पर 100% समर्पित नहीं) का हिस्सा बनने के लिए। मुझे यकीन नहीं है कि यह आपके संदर्भ में समझ में आएगा, हालांकि, मैं स्क्रम जोड़ मूल्य के साथ छोटी परियोजनाओं को चलाने के लिए आश्वस्त नहीं हूं।

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

1

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

उदाहरण के लिए, स्क्रैम में मुझे सबसे उपयोगी लगता है कि एक चीज रेट्रोस्पेक्टिव है क्योंकि यह उन सत्रों में है जहां आप काम करने के तरीके में सुधार करते हैं। हालांकि रेट्रोस्पेक्टिव्स को उपयोगी बनाने के लिए आपको उस काम को मापने की आवश्यकता है जो आप कुछ आइटमों के लिए कर रहे हैं जिन्हें आप करने के लिए तैयार हैं। तो क्यों स्पिंट्स के समान कुछ नहीं है और उन वस्तुओं के लिए स्प्रिंट प्लानिंग करें जो आप अगले 1-2 सप्ताह करना चाहते हैं (छोटे सप्ताह आपके मामले के लिए अधिक उपयुक्त हैं)। दैनिक स्क्रम मीटिंग करें ताकि आप सभी तीनों को पता चले कि दूसरों के लिए क्या हो रहा है और उचित रूप से भर सकते हैं। फिर स्प्रिंट के बाद आप बैठ सकते हैं और सोच सकते हैं कि आप कैसे सुधार कर सकते हैं। यदि कुछ और नहीं है, तो रेट्रोस्पेक्टिव्स का नतीजा आपको बताएगा कि यह आपके लिए काम करता है या नहीं।

मुझे सख्त स्क्रम प्रोजेक्ट स्कीम को अनुकूलित करने की कोशिश करने में विश्वास नहीं है यदि इसका अर्थ है कि समानांतर में दौड़ें चलाना या केवल एक ही परियोजना के साथ छोटे स्पिंट्स को दूसरों को हर दूसरे सप्ताह छेड़छाड़ करने के लिए छोड़ दें।