यदि कोई प्रोजेक्ट के सॉफ़्टवेयर विकास भाग के लिए स्क्रम का उपयोग करता है, तो क्या कोई अभी भी किसी परियोजना पर "अन्य" कार्यों के लिए पीएमबीके या कुछ अन्य परियोजना प्रबंधन पद्धति का उपयोग करता है। व्यापार, विपणन, प्रशिक्षण कार्यों। पारंपरिक परियोजना प्रबंधन यानी संदर्भित गैर सॉफ्टवेयर विकास कार्यों का परियोजना प्रबंधन क्या है?Agile Project Management
हमने कंपनी, मॉडलिंग, बनावट और एनीमेशन कलाकार के अन्य विभागों में स्क्रम का विस्तार किया है। हमें विधि को थोड़ा सा अनुकूलित करना था, लेकिन यह अच्छी तरह से काम करता है। हमें समस्याएं थीं जो चुस्त पद्धति का उपयोग करके हल की गई थीं। कुछ छोटे विभाग (ऑडियो, विशेष प्रभाव) पहले से ही ठीक काम कर रहे थे इसलिए हमने जो टूटा नहीं था उसे ठीक करने की कोशिश नहीं की। Agile उनके लिए एक अनावश्यक ओवरहेड जोड़ा होगा।
एक कंपनी में सभी विभागों के लिए एक ही पद्धति का उपयोग करना आवश्यक नहीं है, सर्वोत्तम सभी को हर किसी की जरूरतों के लिए अनुकूलित किया जाना है। लेकिन प्रोग्रामर के अलावा अन्य लोगों के लिए स्क्रम समाधान हो सकता है, लेकिन कुछ अनुकूलन की आवश्यकता हो सकती है। दैनिक स्टैंड-अप, स्पिंट्स, बैकलॉग, वे कई प्रकार की नौकरियों के लिए एक अच्छी बात हो सकते हैं।
आपने अन्य विभागों में एससीआरयूएम कैसे कार्यान्वित किया है, क्या आपके पास उन कार्यों की एक सूची है जो लोग स्वयंसेवक हैं या आप कार्य सौंपते हैं? – Joanne
स्क्रम एक सॉफ्टवेयर विकास विधि नहीं है बल्कि एक परियोजना प्रबंधन विधि है।
इसके अलावा स्क्रम अक्सर Lego, या अन्य कलाकृतियों ("59 मिनट स्क्रम" के लिए खोज) के साथ पेश किया जाता है। इसलिए इसका उपयोग किसी प्रोजेक्ट के सभी कार्यों को संभालने के लिए किया जा सकता है, जो भी उनके स्वरूप हैं।
इन तकनीकों के बारे में सीखना बहुत अच्छा है, क्या मैं सुझाव दे सकता हूं कि आपका मुख्य फोकस वास्तव में प्रोजेक्ट चलाने और सामान पूरा करने पर है?
संपादित करें: यह एक गंभीर बिंदु है, एक फेंकने वाली कूल्हे नहीं।
पीएमबीके में एक परियोजना को निश्चित दायरे, अवधि और बजट के रूप में परिभाषित किया गया है। परियोजना की विफलता को इस "लौह त्रिभुज" के तीन किनारों में से एक को तोड़ने के रूप में परिभाषित किया गया है। स्क्रम सिद्धांतों का एक सेट है, और कुछ ठोस अभ्यास, Agile मूल्यों के आधार पर, ज्ञान के सभी प्रकार के काम से निपटने के लिए, और विशेष रूप से उन विकास प्रयासों के लिए डिज़ाइन किया गया है जो परियोजनाएं नहीं हो सकती हैं, या लचीली गुंजाइश, अवधि या बजट हो सकती है।
आप सही हैं कि स्क्रम केवल सॉफ्टवेयर विकास प्रक्रिया के कुछ पहलुओं से निपटता है, जैसे नियोजन। यह केवल कुछ भूमिकाओं, बैठकों और कलाकृतियों को परिभाषित करता है, यह इसे यथासंभव लचीला रखने के लिए है। स्क्रम, सॉफ्टवेयर विकास के बाहर मूल्य स्ट्रीम के हिस्सों को संबोधित कर सकता है, और चाहिए। हालांकि, जैसा कि आपने उल्लेख किया है, यह सॉफ़्टवेयर इंजीनियरिंग प्रथाओं, और व्यवसाय के मामले का विश्लेषण करने जैसी कई चीजों से निपटता नहीं है।
अक्सर मानक स्क्रम समाधान उन मामलों पर "टीम को निर्णय लेने" देना है जो सीधे स्क्रम द्वारा निर्दिष्ट नहीं हैं। अक्सर इस तरह के मामलों से निपटने के लिए दिशानिर्देश अन्य संस्कृतियों और मूल्य या सिद्धांत-प्रणाली से आते हैं जैसे कि एक्सपी, या दुबला सॉफ़्टवेयर विकास। स्क्रम टीमों के लिए उपयोगी सामान प्रदान करने वाली अन्य संस्कृतियों में रियल विकल्प, बढ़ती निधि विधि, ईवो शामिल हैं।
कुछ पीएमबीके सामग्री एक "प्रोजेक्ट मैनेजर" या स्क्रम टीम पर पीओ के लिए उपयोगी हो सकती है, हालांकि किसी को सावधान रहना पड़ता है क्योंकि पीएमबीओके सामान का मतलब है कि स्क्रम पर आधारित तुलना में एक अलग मूल्य-प्रणाली है। Agile संस्कृति के भीतर समाधान देखने के लिए आमतौर पर सबसे अच्छा है। पीएमबीके की कुछ चीजें अभी भी एक चुस्त संदर्भ में लागू होती हैं।
यदि आप "फुर्तीली परियोजना प्रबंधन" से संबंधित मेलिंग सूचियों की तलाश करते हैं तो आपको ऐसे विषयों पर चर्चा करने वाले कई संपन्न समुदाय मिलेंगे।
यदि आपका सॉफ़्टवेयर विकास प्रयास एक बड़ी परियोजना का सिर्फ एक पहलू है - उदाहरण के लिए, एक नया वित्तीय उत्पाद तैयार करना - तो सुनिश्चित करें कि आपको सभी कार्यों को व्यवस्थित करने के लिए किसी प्रकार की परियोजना प्रबंधन पद्धति को नियोजित करना होगा शामिल। पीएमबीके के सिद्धांतों के अनुसार प्रबंधित एक परियोजना में एक स्क्रम-आधारित सॉफ़्टवेयर विकास प्रयास को चुनौती देना चुनौतीपूर्ण हो सकता है, हालांकि, चूंकि पीएमबीके ने परियोजना निष्पादन के लिए एक रैखिक, चरणबद्ध दृष्टिकोण निर्धारित किया है, जबकि अन्य Agile पद्धतियों की तरह स्क्रम, पुनरावृत्ति के माध्यम से वृद्धिशील सुधार को बढ़ावा देता है। यह कहना नहीं है कि दोनों एक साथ नहीं हो सकते हैं। बाकी सब कुछ की तरह, यह कार्यान्वयन के लिए नीचे आता है। बस व्यावहारिक होना और अपनी जरूरतों के तरीकों को अनुकूलित करना याद रखें, न कि दूसरी तरफ।
Agile विकास और पीएमबीके को मिश्रित नहीं किया जाना चाहिए। यदि आप करते हैं, तो आप Scrummerfall के साथ समाप्त होने की संभावना है।मैंने पारंपरिक परियोजना प्रबंधकों के साथ यह देखा है जो चुस्त में परिवर्तित हो जाते हैं। वे इसे प्राप्त नहीं करते हैं और पुराने पैटर्न पर वापस आते हैं।
हालांकि, मेरी राय में एससीआरयूएम परियोजना प्रबंधन के लिए आवश्यक सभी को शामिल नहीं करता है। इस तरह के शासन के लिए एक समग्र रणनीति की कमी है। एक संभावना एससीआरयूएम को EVO project/value management या अन्य मूल्य प्रबंधन विधियों के साथ जोड़ रही है। हालांकि इसे ग्राहक के साथ एक अलग प्रकार के कानूनी अनुबंध की आवश्यकता होगी। परियोजनाएं तब एक सतत प्रक्रिया की तरह होती हैं जो समय बक्से होती है, बजट या अंत तक रोकती है जब ग्राहक को लगता है कि वह अपने निवेश से कम लाभ प्राप्त करता है (व्यवसाय के मामलों और लक्ष्य उपायों का उपयोग करके)। एक अतिरिक्त लाभ यह है कि ग्राहक आपको अल्पकालिक आपूर्तिकर्ता की तुलना में दीर्घकालिक साझेदार के रूप में अधिक देखेगा।
मैंने ईवीओ परियोजना/मूल्य प्रबंधन पर पढ़ने की कोशिश की है लेकिन सामग्री को बहुत जटिल और वर्बोज़ ढूंढें। क्या आपने इसका सफलतापूर्वक उपयोग किया है? – Joanne
मुझे लगता है कि यह प्रश्न [प्रोग्रामर.एसई] के लिए अच्छा होगा, अगर इसे माइग्रेट करना बहुत पुराना नहीं है। –