एजाइल प्रोजेक्ट प्रबंधन

सारांश

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

स्लाइड की विशेषताएं

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

Scrum एक आम तौर पर उपयोग की जाने वाली एजाइल पद्धति है। स्क्रम की टीम भूमिकाएं एक संगठनात्मक चार्ट के रूप में वर्गीकृत की जा सकती हैं जो परियोजना प्रबंधन टीम पर मुख्य हितधारकों का विवरण देती है। (स्लाइड 9)

कानबान बोर्ड ग्राहक सर्वेक्षण दृश्यरूपण का उपयोग एजाइल प्रबंधन के एक रूप के रूप में किया जा सकता है जो कार्य प्रगति में सीमा लगाने, कार्य प्रवाहों को प्रबंधित करने, और सकारात्मक प्रतिक्रिया लूप बनाने में मदद करता है। (स्लाइड 12)

परिणाम

परियोजना प्रबंधन की एजाइल विधि का उपयोग किसी भी आकार के संगठनों द्वारा किया जा सकता है।बड़े संगठनों के लिए जिनमें पुरानी समस्या है, एजाइल विशेष रूप से पारंपरिक वॉटरफॉल मॉडल की तुलना में एक अधिक कुशल कार्यप्रवाह का नेतृत्व कर सकता है।

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

अनुप्रयोग

पद्धति

हम एजाइल पद्धति का अवलोकन करके शुरू करते हैं और यह कैसे परियोजना प्रबंधन में उपयोग की जाती है। [related bracelet="agile"] मूल रूप से सॉफ्टवेयर विकास के लिए एक नई दृष्टि के रूप में विकसित किया गया था, लेकिन इसके सिद्धांतों का अनुवाद किया गया है और परियोजना प्रबंधन, उत्पाद विकास, और यहां तक कि संगठनात्मक प्रबंधन में लागू किया गया है। किसी भी टीम के लिए प्रतिक्रियाशील और तेजी से अनुकूलित होने के लिए, एजाइल पारंपरिक, वॉटरफॉल विधि की तुलना में एक बहुत अधिक मजबूत विधि हो सकती है जहां कार्य एक रैखिक क्रम में पूरा किया जाता है।

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

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

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

लाभ

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

प्रक्रिया

एजाइल प्रोजेक्ट प्रबंधन प्रक्रिया को चरणों में देखा जा सकता है: पूर्वकार्य, प्रोजेक्ट की शुरुआत आवश्यकताओं के प्रारंभिक सेट के साथ (चलिए उन्हें यहां आवश्यकताएं A के रूप में समूहित करते हैं), इस पहले सेट की आवश्यकताओं के लिए प्रतिक्रिया और आवश्यकताएं B, फिर प्रतिक्रिया और आवश्यकताएं C। प्रोजेक्ट की आवश्यकताएं कभी-कभी प्रत्येक चरण के दौरान पूरा करने के लिए कार्यों के रूप में भी जानी जाती हैं।

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

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

अब आप एजाइल प्रक्रिया शुरू करते हैं और प्रोजेक्ट की "समूह A" आवश्यकताओं को पूरा करने का प्रयास करते हैं।इस लाइवस्ट्रीम सुविधा के लिए, मान लीजिए कि आपकी ग्रुप ए की आवश्यकताएं यह हैं कि आप उपयोगकर्ता इंटरफ़ेस कैसे काम करेगा, इसका एक निम्न फ़िडेलिटी वायरफ़्रेम तैयार करें। वायरफ़्रेम विकास में, आपको तीन संभावित संस्करण बनाने की आवश्यकता होगी, फिर कुछ उपयोगकर्ताओं के लिए परीक्षण के लिए एक निम्न फ़िडेलिटी प्रोटोटाइप विकसित करें।

जब आप अपने परीक्षण समूह से प्रतिक्रिया इकट्ठा करते हैं, तो इसे "ग्रुप बी" की आवश्यकताओं में लागू करने का समय होता है ताकि आप अपनी अगली पुनरावृत्ति बना सकें। इस बिंदु पर आपका पहला कार्य अध्ययन परिणामों का विश्लेषण और संश्लेषण करना और उन्हें समझना हो सकता है। दूसरा कार्य सॉफ़्टवेयर टीम के साथ UX परिवर्तनों पर चर्चा करना, lofi प्रोटोटाइप को संशोधित करना, और एक और दौर की प्रतिक्रिया के लिए hifi मॉकअप्स बनाना हो सकता है। एक और उपयोगकर्ता समूह को प्रतिक्रिया के लिए आने की अनुसूची तैयार करें, फिर उनकी प्रविष्टि को संश्लेषित करें और "ग्रुप सी" की आवश्यकताओं में लागू करें ताकि आप धुलाई, दोहराई, और जारी कर सकें।

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

प्रक्रिया विवरण

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

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

Scrum

Scrum एजाइल परियोजना प्रबंधन की एक सामान्य विधि है। [related bracelet="scrum"] में छह मुख्य तत्व होते हैं।

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

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

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

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

कानबान

एक और उपयोगी एजाइल विधि है कानबान। [related bracelet="kanban"] एक नोटकार्ड प्रारूप में एक लीन कार्यप्रवाह को दर्शाता है, जिसमें कॉलम विकास प्रक्रिया के कदमों के अनुरूप होते हैं और कार्ड व्यक्तिगत कार्यों के लिए निर्धारित किए जाते हैं।

कानबान प्रक्रिया की साझा परिभाषा और सहमत दिशानिर्देशों के साथ नीतियों को स्पष्ट बनाता है, और नियमित बैठकों के माध्यम से निरंतर सुधार के लिए एक प्रतिक्रिया लूप स्वाभाविक रूप से बनाता है। साथ ही, कानबान बोतलनेक की कमी के माध्यम से कार्यप्रवाह को प्रबंधित करना आसान बनाता है क्योंकि हर कोई देख सकता है कि श्रृंखला में रोकथाम कहां है। और क्योंकि यह बहुकार्य करने से रोकता है, कानबान टीम के सदस्यों को अधिभारित नहीं करता है।

आप रंगों का उपयोग व्यक्तिगत टीम के सदस्यों और उन्हें सौंपे गए कार्यों को प्रतिष्ठित करने के लिए कर सकते हैं। कानबान बोर्ड में कार्यों का एक बैकलॉग, स्वीकृत कार्य, और वे कार्य होते हैं जिन्हें लागू किया, परीक्षण किया, और फिर पूरा किया जाना है।

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

रोडमैप

एक एजाइल रोडमैप को कई वर्षों में प्रगति को ट्रैक करने के लिए परियोजना टाइमलाइन के रूप में उपयोग किया जा सकता है। इस दृश्यीकरण में, तीन अलग-अलग कार्यधाराओं को वर्षों के भीतर ट्रैक किया जा सकता है और ये परियोजना जोखिम स्तर के अनुसार रंगीन की गई हैं। परियोजना [related bracelet="risk"] महत्वपूर्ण है क्योंकि वहां अनिश्चित घटनाएं या स्थितियां हो सकती हैं जो परियोजना की प्रक्रिया को बाधित कर सकती हैं। संभावित परिणामों या संभावित विघ्नों की जागरूकता प्रबंधक और हितधारक दोनों को बेहतर तैयार करती है।

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

हमारी लाइव स्ट्रीम शॉपिंग सुविधा के मामले में, सामग्री निर्माताओं को साइन अप करने में देरी से आपके उपयोगकर्ता आधार को सक्रिय रखने के लिए पर्याप्त सामग्री के बिना कमजोर लॉन्च हो सकता है, या यहां तक कि यह नई सुविधा कैसे काम करती है, इसका ज्ञान नहीं हो सकता है।एक अन्य उच्च जोखिम कार्य सृजनकर्ता डैशबोर्ड की सृजना हो सकती है जहां सृजनकर्ता अपनी सामग्री अपलोड करते हैं। यदि यह बैकएंड ठीक से सेट नहीं किया गया है, तो कोई भी अपनी सामग्री अपलोड करने में सक्षम नहीं होगा या लाइवस्ट्रीम देख पाएगा, जो आपकी लॉन्च को प्रभावी रूप से खत्म कर देगा। (स्लाइड 13)

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